1 00:00:07,390 --> 00:00:09,700 Brendan Iglehart: Welcome to Hard Problems, Smart Solutions, the 2 00:00:09,700 --> 00:00:13,420 Newfire Podcast, where we explore the toughest challenges and the smartest 3 00:00:13,420 --> 00:00:14,920 solutions with industry leaders. 4 00:00:15,590 --> 00:00:19,040 I'm Brendan Iglehart, Staff Healthcare Architect at Newfire Global Partners 5 00:00:19,390 --> 00:00:20,760 and your host for this episode. 6 00:00:21,439 --> 00:00:24,220 In each episode, we bring you conversations with top innovators 7 00:00:24,240 --> 00:00:27,750 and decision-makers tackling the biggest issues across industries. 8 00:00:28,320 --> 00:00:31,830 Whether you're looking for insights to drive your own strategies or to learn 9 00:00:31,850 --> 00:00:33,560 from the best, you're in the right place. 10 00:00:33,900 --> 00:00:34,420 Let's get started. 11 00:00:37,735 --> 00:00:41,155 Hello everyone, today we're discussing the transformative power of accurate 12 00:00:41,155 --> 00:00:44,895 provider directories with Ron Urwongse, co-founder of Defacto Health. 13 00:00:45,665 --> 00:00:49,315 Ron is a pioneer in healthcare data interoperability and transparency, 14 00:00:49,665 --> 00:00:53,475 with a career dedicated to optimizing provider directories and creating scalable 15 00:00:53,475 --> 00:00:55,025 solutions for the healthcare industry. 16 00:00:55,755 --> 00:00:58,715 From leading the development of innovative data tools at Defacto Health, 17 00:00:59,095 --> 00:01:03,645 to his prior work with CAQH, Ron has tackled some of the most critical 18 00:01:03,645 --> 00:01:05,135 issues in provider data management. 19 00:01:06,035 --> 00:01:09,995 If you're navigating the complexities of healthcare interoperability and regulatory 20 00:01:09,995 --> 00:01:12,225 compliance, this episode is for you. 21 00:01:12,745 --> 00:01:14,305 Ron, welcome to the podcast. 22 00:01:14,867 --> 00:01:16,141 Ron Urwongse: Hi Brendan, it's great to be here. 23 00:01:17,114 --> 00:01:20,654 Brendan Iglehart: Ron, getting started, your career spans critical milestones 24 00:01:20,664 --> 00:01:22,604 in healthcare data innovation. 25 00:01:23,304 --> 00:01:26,464 Can you walk us through your journey, particularly how your experiences 26 00:01:26,464 --> 00:01:29,554 have shaped your approach to solving interoperability challenges? 27 00:01:31,682 --> 00:01:32,442 Ron Urwongse: Certainly, Brendan. 28 00:01:33,102 --> 00:01:36,502 So I started off in the early 2000s as a programmer. 29 00:01:36,502 --> 00:01:39,662 I think it's important to call that out because I've had my share of 30 00:01:39,662 --> 00:01:45,432 experiences with not the best data, sometimes inaccurate, sometimes always 31 00:01:45,442 --> 00:01:51,162 messy data and well-documented APIs and not as well-documented APIs. 32 00:01:51,182 --> 00:01:56,442 So I have firsthand experience as a developer having to interact with all 33 00:01:56,452 --> 00:01:58,792 these developer tools and documentation. 34 00:01:59,432 --> 00:02:04,732 I, uh, took the leap to go to business school and study at M. I. T. Sloan, 35 00:02:05,222 --> 00:02:08,972 started my career as a product manager in a small healthtech company in 36 00:02:08,972 --> 00:02:10,752 Boston called Vecna Technologies. 37 00:02:11,692 --> 00:02:15,552 I had a chance to manage a variety of different products there from 38 00:02:15,552 --> 00:02:18,702 infection surveillance solutions and patient check-in kiosk 39 00:02:19,342 --> 00:02:23,852 for private hospitals, but also government-run hospitals within 40 00:02:23,902 --> 00:02:25,172 the Department of Veterans Affairs. 41 00:02:25,762 --> 00:02:29,642 I made the leap to CAQH soon after that, and I spent a good chunk 42 00:02:29,642 --> 00:02:34,472 of time there managing shared utilities on the payer side. 43 00:02:34,952 --> 00:02:38,522 Pretty much every aspect of provider data I had a chance to touch there: 44 00:02:38,812 --> 00:02:40,642 credentialing, provider enrollment, 45 00:02:41,062 --> 00:02:45,852 Provider Directory and I had the opportunity to interact directly 46 00:02:45,852 --> 00:02:49,572 with payers and providers on both sides of the problem. 47 00:02:50,092 --> 00:02:54,782 It was that at CAQH where I had a chance to see some of the new 48 00:02:54,792 --> 00:02:58,642 government rules coming out and see how the payers were being required to 49 00:02:58,642 --> 00:03:00,612 publish their Provider Directory data 50 00:03:00,902 --> 00:03:02,392 via standards-based API. 51 00:03:02,882 --> 00:03:08,102 And I looked at the data and it was incredibly valuable and voluminous. 52 00:03:08,102 --> 00:03:11,572 And I I thought, well, I've got to do something about this. 53 00:03:11,592 --> 00:03:15,692 So I needed to start Defacto Health with my co-founder, Tarun Theogaraj. 54 00:03:16,152 --> 00:03:18,282 And, uh, that's where we are today. 55 00:03:18,322 --> 00:03:22,612 We've been working on integrating with and querying these Payer-Provider 56 00:03:23,342 --> 00:03:24,552 Directory APIs ever since. 57 00:03:26,794 --> 00:03:27,564 Brendan Iglehart: That's really great. 58 00:03:28,199 --> 00:03:31,089 So provider directories are often called the backbone of 59 00:03:31,089 --> 00:03:32,729 healthcare interoperability. 60 00:03:32,789 --> 00:03:36,059 And as a patient and as many listeners being patients, I think we can 61 00:03:36,059 --> 00:03:40,169 all understand the importance of accuracy with those directories. 62 00:03:40,459 --> 00:03:43,599 So, from your perspective, why are they so vital to operational 63 00:03:43,619 --> 00:03:46,019 efficiency and patient care outcomes? 64 00:03:47,364 --> 00:03:49,424 Ron Urwongse: Yeah, so we can start with the easy stuff. 65 00:03:49,654 --> 00:03:52,764 I mean, the use case that pretty much all of us are familiar with, 66 00:03:53,294 --> 00:03:58,344 which is looking up a provider in a Payer- Provider Directory. 67 00:03:58,764 --> 00:04:02,724 And, I think most people, when they're searching for providers, they probably 68 00:04:02,724 --> 00:04:08,024 start in a Google search googling "cardiologist near me," or asking a friend 69 00:04:08,454 --> 00:04:13,454 "Hey, do you know a good PCP in the area? I just moved here." But the second 70 00:04:13,454 --> 00:04:17,384 step after that is often, well, let me look up this provider in my payers' 71 00:04:17,384 --> 00:04:21,384 directory just to make sure that they're in the network and they accept the plan. 72 00:04:21,734 --> 00:04:24,924 Incredibly important for the patient engagement and for 73 00:04:24,924 --> 00:04:26,464 the provider search use case. 74 00:04:27,104 --> 00:04:31,534 But if, if you take a step back and look at how the Provider Directory is 75 00:04:31,754 --> 00:04:35,644 the intersection between all sorts of different parties within healthcare, 76 00:04:35,664 --> 00:04:37,424 so there's the payer and the provider. 77 00:04:37,884 --> 00:04:39,904 There's also the payer and regulators. 78 00:04:40,014 --> 00:04:45,154 Regulators are responsible for overseeing how robust or I guess what they say 79 00:04:45,194 --> 00:04:49,884 adequate a provider of a payer's network is within a certain geography. 80 00:04:50,354 --> 00:04:54,204 Regulators do look at information source from provider directories 81 00:04:54,514 --> 00:04:58,244 to make that judgment call to see, okay, for this particular geography, 82 00:04:58,244 --> 00:04:59,524 you've got this many members. 83 00:04:59,959 --> 00:05:03,669 Do you have the right number of PCPs, cardiologists, et cetera, 84 00:05:03,999 --> 00:05:07,469 to be able to service that type of population within that geography? 85 00:05:08,209 --> 00:05:13,339 Moving from there, especially within this realm of interoperability, uh, 86 00:05:13,339 --> 00:05:18,179 what we're seeing is that payers are very interested in finding the most 87 00:05:18,179 --> 00:05:22,589 efficient ways to integrate with the providers within their network. 88 00:05:22,649 --> 00:05:25,849 They need to collect clinical information for all sorts of use cases 89 00:05:25,939 --> 00:05:30,359 for quality, for risk adjustment, for care coordination and value-based care. 90 00:05:30,929 --> 00:05:33,679 And historically, it's been manual chart chases. 91 00:05:34,179 --> 00:05:39,209 In an intermediate stage, there's these bespoke integrations with a particular 92 00:05:39,209 --> 00:05:44,854 health system hospital which I know you're quite familiar with, but in this 93 00:05:45,034 --> 00:05:50,964 next phase payers are really looking to integrate with providers FHIR APIs 94 00:05:51,014 --> 00:05:54,944 because they're more standards-based, they're more efficient and theoretically 95 00:05:55,064 --> 00:05:59,814 they'll be able to get to the data a lot faster and a lot more efficiently. 96 00:06:00,064 --> 00:06:04,654 And so a big part of that is knowing what providers are a network 97 00:06:05,244 --> 00:06:06,714 and where their endpoints are. 98 00:06:07,004 --> 00:06:10,004 You know, we've been thinking about all this time provider directories 99 00:06:10,394 --> 00:06:14,554 answering questions about who is a provider, where are they located, 100 00:06:14,554 --> 00:06:16,154 what kind of specialties do they have? 101 00:06:17,004 --> 00:06:20,954 But on the other end of it, it's what is their digital contact information? 102 00:06:20,964 --> 00:06:22,174 What EHR are they using? 103 00:06:22,174 --> 00:06:24,774 What's the URL for the API that I need to ping? 104 00:06:25,034 --> 00:06:27,804 So that's the other aspect of provider directories that is kind 105 00:06:27,804 --> 00:06:31,224 of up and coming and becoming more important for the overall industry. 106 00:06:32,711 --> 00:06:36,421 Brendan Iglehart: You mentioned earlier the term adequacy or adequate 107 00:06:36,431 --> 00:06:37,981 in the context of directories. 108 00:06:38,001 --> 00:06:39,301 What does that specifically mean? 109 00:06:39,301 --> 00:06:42,571 I have a hunch that there's there's regulation and requirements around 110 00:06:42,621 --> 00:06:45,251 how that's used, but I'm curious to get your perspective on that. 111 00:06:46,231 --> 00:06:50,441 Ron Urwongse: Yeah, I'm going to overly simplify it and for those professionals 112 00:06:50,441 --> 00:06:56,491 who are a little bit more involved in the adequacy use case, they'll be 113 00:06:56,491 --> 00:06:58,021 able to provide a ton more detail. 114 00:06:58,211 --> 00:07:05,031 But in the most basic form, payers are supposed to present a provider network 115 00:07:05,031 --> 00:07:06,901 that can service their members' needs. 116 00:07:07,351 --> 00:07:11,121 And at the very basic, you've got some type of member population. 117 00:07:11,486 --> 00:07:15,206 And you need to have a certain number of providers to be able to service 118 00:07:15,256 --> 00:07:16,356 that member of the population. 119 00:07:16,406 --> 00:07:21,216 So a certain number of primary care physicians, cardiologists, behavioral 120 00:07:21,216 --> 00:07:25,876 health, pulmonologists, etc. And depending on the line of business, 121 00:07:25,886 --> 00:07:28,166 there's Medicare, Medicaid and Exchange. 122 00:07:28,166 --> 00:07:29,936 They all have different rules, but 123 00:07:30,341 --> 00:07:35,971 the regulator sets these types of ratios to dictate, okay, for your particular 124 00:07:35,971 --> 00:07:39,541 population within this geography, you need to have this many providers. 125 00:07:39,551 --> 00:07:43,621 So you can see how the directory plays a role in there because the directory has 126 00:07:43,621 --> 00:07:48,351 information about providers, what their specialties are, and where they're located 127 00:07:48,791 --> 00:07:50,221 from a geographic basis. 128 00:07:50,431 --> 00:07:54,861 So you can certainly bump that data up against member data and where 129 00:07:54,931 --> 00:07:59,361 the members are to be able to make some assessments on the adequacy 130 00:07:59,361 --> 00:08:01,251 or the robustness of a network. 131 00:08:01,251 --> 00:08:04,190 And what's interesting is that payers are looking to go 132 00:08:04,190 --> 00:08:05,780 beyond just regular adequacy. 133 00:08:06,000 --> 00:08:10,246 They want to know, how does my network compare relatively with other 134 00:08:10,256 --> 00:08:12,236 payers' networks within the geography. 135 00:08:12,686 --> 00:08:17,386 And so it's going beyond just compliance with regulatory requirements, but 136 00:08:17,386 --> 00:08:20,046 it's how competitive am I in a market? 137 00:08:20,226 --> 00:08:24,736 And can I can I make some type of claim that I've got the most robust 138 00:08:24,736 --> 00:08:28,616 network for a particular type of member population within this geography? 139 00:08:29,892 --> 00:08:30,382 Brendan Iglehart: Got it. 140 00:08:30,921 --> 00:08:35,511 The CMS interoperability rule that came out, I believe last year put additional 141 00:08:35,521 --> 00:08:40,311 focus on prioritizing Provider Directory API, so I'm curious to get your 142 00:08:40,311 --> 00:08:44,791 perspective on this regulation and others and how they're shaping the industry's 143 00:08:44,791 --> 00:08:47,131 focus on innovation in the space. 144 00:08:48,395 --> 00:08:53,076 Ron Urwongse: Yeah, the original CMS Final R ule on interoperability came out 145 00:08:53,076 --> 00:08:56,636 in 2020 and was effective in, uh, 2021. 146 00:08:57,116 --> 00:09:00,256 I remember these dates because I, we timed the founding and the launch 147 00:09:00,256 --> 00:09:03,616 of Defacto Health right around that time when the APIs were gonna be 148 00:09:04,096 --> 00:09:07,676 available and when payers were going to be required to publish them. 149 00:09:08,196 --> 00:09:12,285 So that, that was the first time the Provider Directory requirement came 150 00:09:12,285 --> 00:09:14,815 into play in these standard-based APIs. 151 00:09:15,430 --> 00:09:20,826 The most recent requirement it persists the the obligation for the 152 00:09:20,826 --> 00:09:24,936 payers to publish their directory data via API which is good. 153 00:09:24,936 --> 00:09:28,726 It's a signal to the industry that, hey, these APIs aren't going anywhere. 154 00:09:29,036 --> 00:09:33,286 In fact, the the regulators are building on top of previous requirements. 155 00:09:33,736 --> 00:09:35,666 The previous requirements don't go anywhere. 156 00:09:35,686 --> 00:09:36,446 They remain. 157 00:09:36,956 --> 00:09:41,966 And CMS is introducing new requirements for new APIs, like a prior authorization 158 00:09:42,396 --> 00:09:47,466 API, and a, um, I think they call it a Provider Access API, where providers 159 00:09:47,546 --> 00:09:51,866 can access information from payers on patients that they're seeing as well. 160 00:09:52,276 --> 00:09:57,156 So what's interesting is, is if you go into the rule, they describe all sorts of 161 00:09:57,606 --> 00:10:01,766 use cases where these APIs interact with each other and interplay with each other. 162 00:10:01,866 --> 00:10:06,056 Within the prior authorization use case, a predecessor requirement is 163 00:10:06,306 --> 00:10:10,816 knowing whether a provider is even in network before they can provide 164 00:10:11,206 --> 00:10:16,246 care that needs to be authorized by a payer to, to a to a covered member. 165 00:10:16,596 --> 00:10:19,496 You know, all that to say that the old requirements aren't going anywhere. 166 00:10:19,506 --> 00:10:23,046 The regulators are imagining use new use cases and new APIs that 167 00:10:23,046 --> 00:10:24,956 will be highly dependent on. 168 00:10:25,546 --> 00:10:26,976 The older requirements. 169 00:10:27,346 --> 00:10:32,066 And I guess most payers, all payers need to really consider that 170 00:10:32,066 --> 00:10:36,196 where if they're not meeting the requirements from the previous rule, 171 00:10:36,406 --> 00:10:39,716 they're they're playing catch up with these new requirements as well. 172 00:10:41,275 --> 00:10:43,965 Brendan Iglehart: Like many problems in healthcare, there's a combination 173 00:10:43,975 --> 00:10:48,075 here of kind of a technology problem as well as a kind of rights to 174 00:10:48,075 --> 00:10:50,165 data or access to data problem. 175 00:10:50,175 --> 00:10:54,275 So how do you view the interplay of those here, especially in light of, 176 00:10:54,365 --> 00:10:56,885 again, some of those regulations that have come out recently? 177 00:10:56,895 --> 00:11:00,385 How is, how is that relationship between the different parties 178 00:11:00,515 --> 00:11:02,175 here evolved over time? 179 00:11:04,021 --> 00:11:09,071 Ron Urwongse: It is an evolving mindset where if you rewind the clock back, five 180 00:11:09,071 --> 00:11:14,541 years, if you ask any payer, you know, who owns the provider network information 181 00:11:14,541 --> 00:11:15,931 and who should have access to it. 182 00:11:16,901 --> 00:11:21,181 I think they would say I, as a payer on this information and I give access to 183 00:11:21,181 --> 00:11:24,261 it on specifically to members and to, 184 00:11:24,651 --> 00:11:29,201 you know, folks who are, uh, who I have business with, and so that they can 185 00:11:29,201 --> 00:11:33,831 get the care that they need, or they can do other jobs that are required. 186 00:11:35,401 --> 00:11:40,111 You're getting to a point where, regulators are asserting that 187 00:11:40,171 --> 00:11:44,271 actually this information, while it's collected by the payer, and 188 00:11:44,791 --> 00:11:48,601 perhaps owned by the payer, but it is still made available to the public. 189 00:11:49,371 --> 00:11:51,671 And they've asserted that it is public data. 190 00:11:52,481 --> 00:11:54,831 And that mind shift is happening. 191 00:11:55,321 --> 00:12:00,741 And I think that the payers are evolving with it, too, whether complying with the 192 00:12:00,741 --> 00:12:02,301 rules, just to comply with the rules. 193 00:12:02,626 --> 00:12:06,246 But now they're also realizing all the different jobs this data can 194 00:12:06,246 --> 00:12:09,446 do, especially when payers have access to each other's data via 195 00:12:09,446 --> 00:12:10,496 their Provider Directory APIs. 196 00:12:11,536 --> 00:12:14,336 You're also seeing that with patient data, too. 197 00:12:14,336 --> 00:12:18,096 Payers are obligated to make data available via Patient Access APIs. 198 00:12:18,636 --> 00:12:23,316 Now, the, uh, the initial use case around that and the mandatory use 199 00:12:23,376 --> 00:12:28,816 cases that I, as a patient I can access information either from a provider or a 200 00:12:28,816 --> 00:12:31,486 payer, but I authorize how it gets used. 201 00:12:32,406 --> 00:12:38,258 Now, if payers, there's a, a use case within uh, the CMS rule called 202 00:12:38,388 --> 00:12:43,078 Payer-to-Payer Data Exchange, where perhaps there are payers with 203 00:12:43,108 --> 00:12:47,468 overlapping coverage on a particular member or a patient, or there's an 204 00:12:47,478 --> 00:12:48,868 old payer and there's a new payer. 205 00:12:49,608 --> 00:12:52,128 They've got the right to exchange that data 206 00:12:52,703 --> 00:12:56,373 between themselves, and they can use a lot of the same infrastructure that was 207 00:12:56,393 --> 00:13:02,023 created for the Patient Access API to be able to enable that data exchange. 208 00:13:02,503 --> 00:13:04,463 I think all that to say there's a shifting mindset. 209 00:13:04,663 --> 00:13:09,053 There's more willingness to share this data and also more interest in 210 00:13:09,053 --> 00:13:13,363 using, uh, various types of data that are being published via these APIs. 211 00:13:15,329 --> 00:13:18,449 Brendan Iglehart: You mentioned it earlier on the evolution of FHIR, and so I want 212 00:13:18,459 --> 00:13:23,049 to touch on the evolution of different data standards here and how that affects 213 00:13:23,049 --> 00:13:27,199 us as well, because as we both know, just because you make available an API for a 214 00:13:27,199 --> 00:13:31,019 certain type of data doesn't necessarily mean that that can be useful if the data 215 00:13:31,019 --> 00:13:35,139 is structured in different ways across organizations and other source systems. 216 00:13:35,149 --> 00:13:39,919 So what are some of the kind of inputs here, such as FHIR and others that are 217 00:13:39,919 --> 00:13:44,649 impacting and how data is structured as you're able to increasingly retrieve 218 00:13:44,649 --> 00:13:46,259 this from payers and other parties? 219 00:13:47,626 --> 00:13:51,016 Ron Urwongse: Back in 2020, when I was first looking at these APIs that the 220 00:13:51,016 --> 00:13:57,206 payers were publishing and then, into the early part of 2021, I got really spoiled. 221 00:13:57,736 --> 00:14:02,086 So I took a look at and I remember them, it was United Healthcare, it was 222 00:14:02,096 --> 00:14:07,376 Humana and Cigna, big national payers, they probably have a huge IT bucket. 223 00:14:07,446 --> 00:14:13,236 They can put the right investment in place to be able to publish amazing APIs. 224 00:14:13,746 --> 00:14:15,936 I remember in particular Humana documentation. 225 00:14:15,986 --> 00:14:18,066 I think United too was really good. 226 00:14:19,126 --> 00:14:22,516 I was talking before about as a developer, having the experience 227 00:14:22,636 --> 00:14:27,176 of interacting with well-documented APIs versus not well-documented APIs. 228 00:14:27,196 --> 00:14:28,636 These first ones were really good. 229 00:14:29,671 --> 00:14:32,501 And, started querying them and all the data that I was expecting to 230 00:14:32,501 --> 00:14:35,821 come back with coming back when I passed in the right query parameters. 231 00:14:37,101 --> 00:14:42,481 And I, uh, mistakenly thought that, well, gosh, if these first three APIs 232 00:14:42,481 --> 00:14:46,071 are going to be good, then probably the next 150 are going to be good as well. 233 00:14:46,561 --> 00:14:48,101 That was absolutely not the case. 234 00:14:48,651 --> 00:14:55,301 A fter that, I think the ratio was maybe 9 out of 10 of the APIs that we 235 00:14:55,301 --> 00:15:00,961 encountered first were broken in some way, shape or form, and that was, everything 236 00:15:00,961 --> 00:15:05,531 from, uh, not publishing any data at all, the query parameters were broken, 237 00:15:05,541 --> 00:15:10,651 not performance, not well documented, authorization requirements and approval 238 00:15:10,921 --> 00:15:13,451 channels were not being monitored. 239 00:15:13,831 --> 00:15:16,011 But, it's evolved and matured over time. 240 00:15:16,192 --> 00:15:19,912 You know, most of the Payers-Provider Directory APIs are now working. 241 00:15:19,912 --> 00:15:22,782 There's still a tail of smaller payers where it's not. 242 00:15:23,342 --> 00:15:28,002 The FHIR standard for, uh, the Directory APIs in particular, the the 243 00:15:28,002 --> 00:15:33,452 Da Vinci Plan Net implementation guide was really good too, to get started. 244 00:15:33,772 --> 00:15:39,847 And without the existence of that implementation guide, I wouldn't have 245 00:15:40,077 --> 00:15:43,497 a common ground to be able to interact and communicate with the payer saying, 246 00:15:43,677 --> 00:15:46,767 Hey, I'm expecting this data, this data is supposed to do this job. 247 00:15:47,317 --> 00:15:53,307 The IG not only talks about what data needs to be available and the logical 248 00:15:53,307 --> 00:15:57,842 model and how different entities relate to each other, but also this is, 249 00:15:58,487 --> 00:16:00,867 these are the jobs that patients are trying to do with the data. 250 00:16:02,277 --> 00:16:06,877 Now, what it doesn't do, though, and I think there are opportunities 251 00:16:07,377 --> 00:16:13,037 either through a Da Vinci workgroup, broader HL7, or perhaps some, you 252 00:16:13,037 --> 00:16:18,927 know, USCDI plus venue where we can talk about the quality of the data. 253 00:16:19,367 --> 00:16:24,647 There's no standardization on the quality of the data, how accurate it needs to be, 254 00:16:24,647 --> 00:16:25,967 how do you even test that? 255 00:16:26,597 --> 00:16:30,587 I mean, particular CMS program offices have put a stake in the ground and 256 00:16:30,587 --> 00:16:34,267 said, "Hey, Provider Directory needs to look this way. We're auditing it 257 00:16:34,267 --> 00:16:39,057 this way. And this is how you should measure it." But, you know, other lines 258 00:16:39,057 --> 00:16:44,727 of business aren't that prescriptive and it's not, there's no requirements 259 00:16:44,727 --> 00:16:46,537 on that on the commercial side that 260 00:16:46,537 --> 00:16:51,847 I've seen beyond, you know, some no-surprises act and, um, update timeline. 261 00:16:52,317 --> 00:16:54,287 So I think that's a huge opportunity. 262 00:16:54,762 --> 00:16:59,372 HL7, FHIR, some of these IGs, really great about describing logical models 263 00:16:59,372 --> 00:17:05,602 and what data formats should be, but data quality, I, I think is, uh, an opportunity 264 00:17:05,622 --> 00:17:07,282 for the industry to mature even more. 265 00:17:09,101 --> 00:17:11,671 Brendan Iglehart: So, as we both know, technology really plays a 266 00:17:11,671 --> 00:17:16,051 transformative role in terms of how healthcare data gets better and 267 00:17:16,061 --> 00:17:18,581 more useful to drive innovation. 268 00:17:18,581 --> 00:17:23,121 And so I'm curious, um, are there other innovations such as like public data sets 269 00:17:23,121 --> 00:17:27,621 or other APIs that we haven't touched on that you're really optimistic about growth 270 00:17:27,621 --> 00:17:29,881 and kind of on silo in some of this data? 271 00:17:31,486 --> 00:17:31,786 Ron Urwongse: Certainly. 272 00:17:31,876 --> 00:17:34,506 We've been talking a lot about Provider Directory. 273 00:17:34,856 --> 00:17:38,381 We touched a little bit upon Patient Access API. 274 00:17:38,381 --> 00:17:43,781 So the patient data I think the next data set that I haven't touched upon, 275 00:17:43,781 --> 00:17:47,471 but that is probably on everybody's mind right now is the price transparency data. 276 00:17:48,471 --> 00:17:51,471 Both hospitals, as well as health insurers, have been 277 00:17:52,141 --> 00:17:57,171 required to publish their negotiated rate within these huge 278 00:17:57,201 --> 00:17:59,081 massive machine-readable file. 279 00:17:59,581 --> 00:18:05,806 All with the idea that patients, consumers, employers, uh, even 280 00:18:05,806 --> 00:18:10,716 regulators can see the rates, they can make better decisions on purchasing or 281 00:18:10,726 --> 00:18:13,256 finding high quality, low-cost care. 282 00:18:14,286 --> 00:18:16,066 And maybe bending the cost curve. 283 00:18:16,066 --> 00:18:18,536 I think there's probably more of a convergence in the cost curve 284 00:18:18,546 --> 00:18:20,906 than necessarily bending it down. 285 00:18:21,586 --> 00:18:24,406 But predictability, predictability can be good too. 286 00:18:24,846 --> 00:18:26,776 I think there's a whole lot of opportunity there. 287 00:18:27,171 --> 00:18:31,991 I think the price transparency data is, uh, suffering from some of the same 288 00:18:31,991 --> 00:18:36,311 challenges as Provider Directory data in terms of data quality and consistency 289 00:18:36,311 --> 00:18:38,921 and data format and standardization. 290 00:18:39,321 --> 00:18:43,101 But I see a lot of work going on there between public sector and private 291 00:18:43,101 --> 00:18:47,831 sector to converge on what this data could look like and what it should do. 292 00:18:47,841 --> 00:18:50,441 So, I, I see a lot of opportunity to. 293 00:18:50,926 --> 00:18:54,096 Leverage interplay between Provider Directory and the price 294 00:18:54,106 --> 00:18:55,746 transparency data over time. 295 00:18:57,888 --> 00:19:00,388 Brendan Iglehart: And I guess on that front, like, I'm personally the kind of 296 00:19:00,518 --> 00:19:05,128 kind of guy who likes to email the mayor and, you know, my elected officials and 297 00:19:05,508 --> 00:19:08,278 help to, in my mind, move things along. 298 00:19:08,288 --> 00:19:10,438 What what can people who are listening to our innovators in 299 00:19:10,438 --> 00:19:14,338 this space do to kind of contribute and advance some of these causes? 300 00:19:14,338 --> 00:19:18,848 Obviously, there's things like public comments on different regulations that are 301 00:19:18,848 --> 00:19:21,768 coming out, but do you have any thoughts on on that and how people can pitch in? 302 00:19:22,848 --> 00:19:23,368 Ron Urwongse: Yeah. 303 00:19:23,468 --> 00:19:27,678 So, as you said, public comments on any number of emergent rules, I'm 304 00:19:27,678 --> 00:19:32,108 sure with the new administration taking place, there will be a whole 305 00:19:32,118 --> 00:19:37,988 slew of new proposed rules that the public can review and comment upon. 306 00:19:38,038 --> 00:19:42,173 There's an interesting experiment going on within the state of Oklahoma 307 00:19:42,573 --> 00:19:46,243 in the early part of this year, in the National Directory of Health. 308 00:19:46,993 --> 00:19:51,923 So CMS released an RFI around this notion of a national directory a couple of years 309 00:19:51,923 --> 00:19:59,103 ago, and the whole idea of it is to create a common utility that collects data one 310 00:19:59,103 --> 00:20:03,753 time from a bunch of healthcare providers and makes it available to any number of 311 00:20:03,903 --> 00:20:08,913 other organizations, including government agencies, payers, other providers. 312 00:20:09,423 --> 00:20:13,533 The whole idea is to reduce and rationalize the administrative 313 00:20:13,533 --> 00:20:14,393 burden around that. 314 00:20:14,933 --> 00:20:19,253 What's neat is that CMS is doing this out in the open and that as 315 00:20:19,253 --> 00:20:22,063 they establish it, they will be releasing public data sets from it. 316 00:20:22,523 --> 00:20:24,813 It's going to benefit from more eyeballs. 317 00:20:25,153 --> 00:20:30,613 If you're in this space and you're taking a look at directory data or data sets 318 00:20:30,623 --> 00:20:33,023 that are adjacent to directory data, 319 00:20:33,183 --> 00:20:36,483 it might be interesting to take a look at what's going on there and see if 320 00:20:36,873 --> 00:20:40,203 this centralized national directory approach is going to move the needle. 321 00:20:43,068 --> 00:20:45,288 Brendan Iglehart: So, as we both know, collaboration is, is 322 00:20:45,298 --> 00:20:47,038 vital to success in health care. 323 00:20:47,038 --> 00:20:50,558 Some, can you speak on a little bit of the collaboration and work that 324 00:20:50,558 --> 00:20:54,678 you've done specifically with perhaps different payers to help kind of 325 00:20:54,678 --> 00:20:58,018 advance this cause and especially related to your, your current company? 326 00:20:59,273 --> 00:20:59,793 Ron Urwongse: Sure. 327 00:20:59,833 --> 00:21:04,823 A big part of what we do, I would venture to say, perhaps the majority of what we 328 00:21:04,823 --> 00:21:10,193 do, is review payers' APIs and provide them with constructive feedback around it. 329 00:21:10,903 --> 00:21:15,743 You know, I mentioned that early on 9 out of 10 payers API, particularly Provider 330 00:21:15,743 --> 00:21:19,773 Directory APIs, had some type of issue that blocked us from being able to use it. 331 00:21:20,193 --> 00:21:24,553 And so what we've done, we've actually tried to streamline this process where 332 00:21:24,553 --> 00:21:28,913 we have test cases that we make available to the payer so that we tell them, Hey, 333 00:21:28,913 --> 00:21:31,413 this is how we're going to test the API. 334 00:21:31,723 --> 00:21:37,253 And then we create a, um, nice little scorecard that shows we've done 335 00:21:37,253 --> 00:21:40,853 these tests, here are the results for these tests, here are the specific 336 00:21:40,853 --> 00:21:43,353 reproduction steps that you can take 337 00:21:43,353 --> 00:21:47,203 if you want to reproduce the results that we made feel free to bring that back 338 00:21:47,203 --> 00:21:49,033 to your technical team or your vendor. 339 00:21:49,513 --> 00:21:54,473 Uh, we've had an opportunity to interact with many technical teams across many 340 00:21:54,473 --> 00:21:58,563 payers and their vendors and provide this constructive feedback and working 341 00:21:58,573 --> 00:22:02,403 in collaboration to get these APIs working, not just for us, but for 342 00:22:02,403 --> 00:22:04,453 anybody else who wants to query them. 343 00:22:05,058 --> 00:22:07,858 So and we're doing that at no cost to the payer. 344 00:22:07,898 --> 00:22:10,708 We want the APIs to work so that we can get it. 345 00:22:10,718 --> 00:22:13,678 But the side benefit is that they're available to the 346 00:22:13,678 --> 00:22:15,198 rest of the industry as well. 347 00:22:15,748 --> 00:22:22,008 The other thing that we are doing is, uh, we are using the APIs to assess 348 00:22:24,038 --> 00:22:25,908 the the accuracy of the data. 349 00:22:26,248 --> 00:22:31,308 What we've noticed is that if a critical mass of payers agree that 350 00:22:31,348 --> 00:22:36,018 a provider is at an address and has a particular phone number, that it's 351 00:22:36,028 --> 00:22:39,388 very likely that provider is actually there and has that phone number. 352 00:22:39,878 --> 00:22:44,623 It's like the, uh, like the jelly bean exercise at the carnival where you've got 353 00:22:44,893 --> 00:22:49,233 thousands of jelly beans within a jar, and you ask a hundred people, 354 00:22:49,233 --> 00:22:50,613 how many jelly beans are in that jar? 355 00:22:50,893 --> 00:22:51,713 Everybody's wrong. 356 00:22:52,263 --> 00:22:53,303 Actually, everybody's wrong. 357 00:22:53,313 --> 00:22:54,563 Maybe one person's right. 358 00:22:54,583 --> 00:22:58,733 But if you average everybody's guesses together, then it's very 359 00:22:58,733 --> 00:23:01,823 close to the actual number of jelly beans, like one or two off. 360 00:23:02,403 --> 00:23:06,733 It's it's a similar approach around Provider Directory, where, you know, 361 00:23:06,743 --> 00:23:11,343 every Payers' Directory is wrong, but where they agree and where they disagree 362 00:23:11,343 --> 00:23:14,353 is incredibly informative to figure out what's right and what's wrong. 363 00:23:14,803 --> 00:23:18,643 And so we're sharing some of these results with payers right now just 364 00:23:18,653 --> 00:23:23,233 to help them improve the accuracy of their data as upstream as possible. 365 00:23:24,192 --> 00:23:24,802 Yeah. 366 00:23:25,160 --> 00:23:25,220 Brendan Iglehart: I've 367 00:23:25,220 --> 00:23:30,239 seen similar technology in place on kind of patient level data so the concept of 368 00:23:30,239 --> 00:23:35,779 a master master patient index and mapping your specific data your organization owns 369 00:23:35,779 --> 00:23:37,689 with kind of public and other data sets. 370 00:23:37,699 --> 00:23:40,889 So that's that's really cool to hear that that could be applicable here as well. 371 00:23:41,416 --> 00:23:45,936 So external providers like Newfire often play a crucial role in scaling 372 00:23:45,936 --> 00:23:47,706 solutions like this effectively. 373 00:23:48,126 --> 00:23:52,106 So I'm curious if you can tell us a little bit about how you view partnerships in 374 00:23:52,116 --> 00:23:56,246 fostering innovation and then ensuring success with with complex projects. 375 00:23:58,394 --> 00:23:58,594 Ron Urwongse: Yeah, so, 376 00:23:58,594 --> 00:24:01,930 just thinking back to my own experience with payers at Defacto Health. 377 00:24:03,000 --> 00:24:06,820 We can only go so far into the payer organization. 378 00:24:07,210 --> 00:24:10,970 Actually, sometimes we've been on so many phone calls with these payers that they 379 00:24:11,330 --> 00:24:17,210 forget that we're an external party and they think they're contracted with us 380 00:24:17,270 --> 00:24:19,800 and we have to remind them that actually, no, you're not paying us anything, we're 381 00:24:19,800 --> 00:24:23,500 just doing this as a service to you guys, but also to get your APIs to work. 382 00:24:24,070 --> 00:24:27,430 But still, we, we can only go so far into the organization. 383 00:24:27,835 --> 00:24:30,815 We can provide evidence of incorrect data. 384 00:24:30,815 --> 00:24:36,285 We can provide evidence of maybe upstream issues where processes 385 00:24:36,515 --> 00:24:38,555 are are not implemented correctly. 386 00:24:39,055 --> 00:24:43,505 But it really takes an organization like Newfire that has direct engagements 387 00:24:43,545 --> 00:24:45,785 with these payers to be able to assess. 388 00:24:46,365 --> 00:24:50,675 Actually, these are the upstream issues, both from a technology perspective, but 389 00:24:50,675 --> 00:24:52,595 perhaps from a governance perspective. 390 00:24:53,005 --> 00:24:58,505 And, and I think with Newfire's abilities, both from a technical and 391 00:24:58,505 --> 00:25:02,515 a management consulting perspective, there, there is an opportunity to 392 00:25:03,135 --> 00:25:07,045 establish better governance and to clean the data as upstream as possible. 393 00:25:08,685 --> 00:25:10,355 Brendan Iglehart: And looking forward, what what are some of the 394 00:25:10,355 --> 00:25:15,335 trends or technologies do you think will further transform innovation 395 00:25:15,345 --> 00:25:18,455 in this space, whether it be Provider Directories, usability or 396 00:25:18,455 --> 00:25:21,045 accuracy, what are some things that you're kind of keeping an eye on? 397 00:25:21,045 --> 00:25:24,505 Or if you had your to rub your magic crystal ball that you 398 00:25:24,505 --> 00:25:26,125 expect to see in the coming years? 399 00:25:27,408 --> 00:25:30,828 Ron Urwongse: The magic wand that I've been I've been craving 400 00:25:30,878 --> 00:25:35,197 for years is this idea of an appointment API on the provider side. 401 00:25:35,337 --> 00:25:41,937 So for a practice or a health system and their EHR or, and, or their 402 00:25:41,937 --> 00:25:47,616 appointment system, could they surface up some type of standards-based API 403 00:25:47,617 --> 00:25:49,607 to answer a couple of questions? 404 00:25:49,637 --> 00:25:54,252 One is for a given provider, this is for available appointments 405 00:25:54,282 --> 00:25:56,532 within the next 30 to 90 days. 406 00:25:56,982 --> 00:26:00,302 And also, here's an ability to actually book an appointment. 407 00:26:00,832 --> 00:26:05,242 There are a couple of IGs that were published years ago from the Argonaut 408 00:26:05,362 --> 00:26:10,052 Project that address these particular use cases; I believe they've only 409 00:26:10,052 --> 00:26:11,792 been implemented a handful of time. 410 00:26:12,442 --> 00:26:14,992 I'm seeing some renewed interests in it. 411 00:26:15,622 --> 00:26:18,132 Some interesting interests on the payer side. 412 00:26:19,002 --> 00:26:22,402 I've heard through the grapevine that some payers are incorporating 413 00:26:22,412 --> 00:26:25,582 direct appointment capabilities within their directories. 414 00:26:25,958 --> 00:26:30,108 If you think about it for a second, if you can get information about 415 00:26:30,818 --> 00:26:32,478 actual appointment availability, 416 00:26:32,958 --> 00:26:36,433 the particular practice locations that providers are accepting 417 00:26:36,433 --> 00:26:38,129 patients and providing appointments. 418 00:26:38,129 --> 00:26:42,792 That goes a very long way to clean up these directories. 419 00:26:43,313 --> 00:26:47,693 Because if a provider is not actually providing appointments at a particular 420 00:26:47,693 --> 00:26:50,703 address, maybe as a payer, you don't want to publish it in your directory. 421 00:26:51,103 --> 00:26:57,923 Or maybe you want to only surface up the providers who have the most the 422 00:26:57,923 --> 00:27:02,343 most immediate availability within your search results so that members 423 00:27:02,353 --> 00:27:06,473 or consumers will have an easier time getting appointment because getting 424 00:27:06,473 --> 00:27:11,493 appointment right now, you might call 5, 6, 10 doctors until you find one with 425 00:27:12,043 --> 00:27:13,753 a near term appointment availability. 426 00:27:13,753 --> 00:27:15,083 So that's one. 427 00:27:15,203 --> 00:27:17,913 I wish there were a magic wand to make that happen faster. 428 00:27:18,303 --> 00:27:22,223 I am optimistic that some of this renewed interest is going to move the needle some. 429 00:27:23,430 --> 00:27:24,850 Brendan Iglehart: And I think that brings up a good point. 430 00:27:24,870 --> 00:27:29,440 This, this aligns with my thinking on the kind of phases of the rollout of EHRs is 431 00:27:29,450 --> 00:27:33,830 the first phase is just to get the kind of base technology or systems in place and 432 00:27:33,830 --> 00:27:35,590 get data flowing between organizations. 433 00:27:35,590 --> 00:27:39,740 But then what's really cool from there is, is the use cases and the problems 434 00:27:39,760 --> 00:27:43,920 you can solve once you can take that for granted, which, as we both know, 435 00:27:43,980 --> 00:27:46,010 and healthcare can take a bit of time. 436 00:27:46,010 --> 00:27:49,210 But once it's there, unlocks some, some great possibilities. 437 00:27:50,030 --> 00:27:53,645 Ron Urwongse: You know, I think that's why people stay within this field for 438 00:27:53,645 --> 00:27:58,430 so long for decades at a time, because: A, it takes that long for change to 439 00:27:58,430 --> 00:28:03,020 happen and B, I think for those of us who want to see the end of the story, 440 00:28:03,030 --> 00:28:08,210 who want to see the next or want to see all of the pre-work in place really 441 00:28:08,210 --> 00:28:10,320 pay off by 5, 10 years down the road. 442 00:28:10,770 --> 00:28:12,490 There will be an opportunity to do that. 443 00:28:12,540 --> 00:28:16,780 I do think it's iterative, we shouldn't view the the 1st generation 444 00:28:16,780 --> 00:28:20,890 of these APIs or machine-readable files as a failure by any means. 445 00:28:20,990 --> 00:28:24,720 It's just the 1st version and the 2nd version of the 3rd version. 446 00:28:24,720 --> 00:28:28,040 Are you get are going to get better as the public provides 447 00:28:28,040 --> 00:28:29,300 more constructive feedback. 448 00:28:29,730 --> 00:28:34,200 And as their expectations increase on what that data should be able to do. 449 00:28:35,681 --> 00:28:37,801 Brendan Iglehart: I'm going to link this back to something that we were talking 450 00:28:37,801 --> 00:28:41,641 about earlier is really the patient perspective and the fact that we are 451 00:28:41,641 --> 00:28:45,071 all ultimately consumers of a lot of the technology that we are creating. 452 00:28:45,071 --> 00:28:48,431 So from that lens of a patient, what are some of the things that you're most 453 00:28:48,431 --> 00:28:52,721 excited about in terms of what these advances will will bring to the floor? 454 00:28:54,453 --> 00:28:57,563 Ron Urwongse: We'll go back to some of the the future innovations 455 00:28:57,563 --> 00:28:59,753 and trends that I was predicting. 456 00:29:00,413 --> 00:29:03,974 But I think there will come a time, you know, and you can call me out on 457 00:29:03,974 --> 00:29:07,731 this, we can have another podcast in 5 years to see if I'm right or I'm wrong, 458 00:29:08,281 --> 00:29:11,211 but I think there will come a time when these directories are going to be 459 00:29:11,211 --> 00:29:17,751 more accurate, where we can search for providers by appointment availability, 460 00:29:18,161 --> 00:29:23,471 where it's going to be a whole lot easier to get your data as a patient. 461 00:29:23,968 --> 00:29:28,119 And where you can use that data to help inform provider search 462 00:29:28,129 --> 00:29:30,650 plan selection, cost estimation. 463 00:29:31,170 --> 00:29:33,260 These are rules that are on the book. 464 00:29:33,720 --> 00:29:37,600 These are data that are available, but they need to get refined and the 465 00:29:37,650 --> 00:29:39,360 quality of the data needs to improve. 466 00:29:39,860 --> 00:29:43,870 And innovators out there need to bring these data sets together. 467 00:29:44,270 --> 00:29:49,010 But I'm optimistic that it's going to happen just because it's more public and 468 00:29:49,010 --> 00:29:53,700 there are so many eyeballs on, not only the data, but also these API capabilities. 469 00:29:54,160 --> 00:29:55,660 I do think it's gonna happen. 470 00:29:57,645 --> 00:30:00,245 Brendan Iglehart: Yeah, I think it's really exciting to me just kind of 471 00:30:00,245 --> 00:30:04,285 seeing the trends and healthcare moving toward a more consumer centric 472 00:30:04,325 --> 00:30:09,182 perspective but in current state, not giving people the the data and the 473 00:30:09,192 --> 00:30:11,112 resources to necessarily be consumers. 474 00:30:11,112 --> 00:30:14,332 So, the closer that we get to that, I think, is really, really 475 00:30:14,332 --> 00:30:15,802 a cool future to look forward to. 476 00:30:17,431 --> 00:30:21,041 Ron, for organizations that are looking to be tech-forward and kind of get 477 00:30:21,041 --> 00:30:24,981 ahead of some of these regulations, what are things that you recommend 478 00:30:24,981 --> 00:30:30,441 that they look at and take steps to do around the directories and other 479 00:30:30,441 --> 00:30:33,221 interoperability topics as those advance? 480 00:30:34,632 --> 00:30:37,952 Ron Urwongse: If I had to recommend one thing, it would be listen 481 00:30:37,992 --> 00:30:41,562 to the people who are trying to use your data and your API. 482 00:30:42,412 --> 00:30:48,232 They have they have a lot of feedback and constructive feedback and take that into 483 00:30:48,242 --> 00:30:52,182 consideration as you're working with your tech team or your vendor and improving 484 00:30:52,182 --> 00:30:59,047 them and making decisions on roadmaps and backlog with in particular for directory. 485 00:30:59,467 --> 00:31:04,132 What I would recommend for health insurers is that they take a look at all the places 486 00:31:04,132 --> 00:31:09,362 the data surfacing, the web directory, the Provider Directory, API, any CRM 487 00:31:09,392 --> 00:31:13,612 systems that they have, any data sets that they're obligated to submit to the 488 00:31:13,612 --> 00:31:15,762 government, price transparency files. 489 00:31:16,262 --> 00:31:20,262 And ask the question, how aligned are these data? 490 00:31:20,817 --> 00:31:21,917 And it could be very simple. 491 00:31:21,917 --> 00:31:25,677 It could be, okay, the number of practitioners in each of these data sets. 492 00:31:26,447 --> 00:31:27,167 Is it about right? 493 00:31:28,377 --> 00:31:29,527 Are they within the ballpark? 494 00:31:30,167 --> 00:31:32,327 And, what is the overlap between all of them? 495 00:31:32,687 --> 00:31:34,467 That would be incredibly informative. 496 00:31:34,817 --> 00:31:38,207 And the reason I bring it up is because folks like me and 497 00:31:38,207 --> 00:31:40,017 others are doing that on our end. 498 00:31:40,067 --> 00:31:42,447 If you guys did that on your end, it would make sure that the data was 499 00:31:42,457 --> 00:31:47,217 aligned and it could also identify some upstream data governance issues. 500 00:31:47,947 --> 00:31:53,037 I think around Provider Directory as well, it's having a repeatable, reproducible 501 00:31:53,077 --> 00:31:57,147 accuracy measure that is aligned with how the industry is measuring. 502 00:31:57,167 --> 00:32:00,307 I think we're, I mentioned it before, but we still don't have an 503 00:32:00,307 --> 00:32:05,237 industry-wide definition about how how Provider Directories should be 504 00:32:05,487 --> 00:32:07,197 measured from an accuracy perspective. 505 00:32:07,727 --> 00:32:11,087 And then I think the final thing that I would mention for health insurers is 506 00:32:11,537 --> 00:32:13,927 clean the data as upstream as possible. 507 00:32:14,487 --> 00:32:19,847 Don't just clean it up at the API side or the, if you've got a dock finder 508 00:32:20,587 --> 00:32:26,567 there, if you clean it further upstream within your PDM system, then you've got 509 00:32:27,097 --> 00:32:30,497 a number of other downstream systems that are going to benefit from it. 510 00:32:30,867 --> 00:32:34,477 And by the way, if you clean it upstream all the way on the provider side, giving 511 00:32:34,477 --> 00:32:38,237 that critical constructive feedback to the providers, it's going to help out 512 00:32:38,427 --> 00:32:40,397 not only you, but other payers as well. 513 00:32:40,972 --> 00:32:44,792 And then recommendations on the provider side, because right now they 514 00:32:44,792 --> 00:32:48,512 don't have a whole lot of regulatory requirements around this directory data. 515 00:32:49,012 --> 00:32:53,182 But if they did want to get ahead of it, it's take a look at what the payers are 516 00:32:53,182 --> 00:32:57,692 saying about your providers and where they're at and what their specialties are. 517 00:32:58,302 --> 00:32:59,142 That's informative. 518 00:32:59,172 --> 00:33:02,132 There are probably all sorts of differences between what you're 519 00:33:02,132 --> 00:33:03,532 submitting and what they're publishing. 520 00:33:03,957 --> 00:33:06,987 And having that second pair of eyeballs from that part of the 521 00:33:06,987 --> 00:33:08,557 industry would also be helpful. 522 00:33:08,587 --> 00:33:12,187 And it's going to be easier to do that with these APIs and with 523 00:33:12,187 --> 00:33:13,357 these machine-readable files. 524 00:33:15,168 --> 00:33:19,168 Brendan Iglehart: This conversation, like most in healthcare technology, bring to 525 00:33:19,168 --> 00:33:23,198 light a lot of complex challenges, but also makes me feel really optimistic 526 00:33:23,198 --> 00:33:27,448 about the advancements and the and the things that are coming down the pipe. 527 00:33:27,448 --> 00:33:31,318 So really appreciate your time, Ron, and bringing clarity and actionable 528 00:33:31,328 --> 00:33:34,468 strategies to some of the most complex challenges of our day. 529 00:33:35,418 --> 00:33:36,058 Ron Urwongse: Thanks Brandon. 530 00:33:36,077 --> 00:33:36,857 It's been a pleasure. 531 00:33:37,949 --> 00:33:40,889 Brendan Iglehart: Ron, thanks for bringing clarity and actionable strategies to one 532 00:33:40,889 --> 00:33:42,809 of healthcare's most complex challenges. 533 00:33:43,639 --> 00:33:46,529 Your work here in improving Provider Directories underscores the 534 00:33:46,529 --> 00:33:49,689 importance of data-driven solutions in creating more efficient and 535 00:33:49,699 --> 00:33:51,319 transparent healthcare systems. 536 00:33:52,374 --> 00:33:55,484 To our listeners, today's conversation highlighted the vital role of 537 00:33:55,524 --> 00:33:58,024 accurate provider directories in transforming healthcare. 538 00:33:59,060 --> 00:34:02,320 As we navigate the evolving landscape of interoperability and compliance, 539 00:34:02,380 --> 00:34:06,100 the insights shared here offer valuable guidance for driving meaningful change. 540 00:34:06,770 --> 00:34:10,930 Thanks for joining us on Hard Problems, Smart Solutions, the Newfire podcast. 541 00:34:11,060 --> 00:34:11,900 See you next time.