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.
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.
