Stream: patient empowerment
Topic: Suggesting new extensions for provider directories
Lee Surprenant (Jun 19 2020 at 13:07):
for the devdays hackathon, our team explored some ideas around choosing new providers and providing them with medical history.
one of the ideas we had is particularly simple technically but I personally think could make a suprisingly big difference (in the long run). first, I wanted to get this community's opinion on whether its worth trying to bring this forward to someone that can do something about it...
One aspect of the CMS rule for the 21s century cures act is that "under this rule, MA organizations, Medicaid FFS programs, CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities are required to make provider directory information available via the Provider Directory API. This API must be accessible via a public-facing digital endpoint on the payer’s website. To facilitate this, we link to the DaVinci PDEX Plan Net IG"
So here is the idea: what if, as part of these provider directories, insurers would provide not just the name, location, contactinfo, and "accepting new patients" status of each provider, but also "whether they support electronic interchange of health information"? is anyone doing this yet? has anyone considered it? is it worth pursuing?
Josh Mandel (Jun 19 2020 at 13:14):
these kinds of connections are indeed very helpful, and they have been a regulatory focus. The DaVinci implementation guide you linked to includes information about fhir endpoints that provider might have: http://hl7.org/fhir/us/davinci-pdex-plan-net/2020Feb/StructureDefinition-plannet-Endpoint.html (linked from Organization)-- would be good to understand what you see as the gaps.
Lee Surprenant (Jun 19 2020 at 13:17):
thanks josh. I havn't been much involved with provider directory stuff, just "joined" that community this last connectathon and so my knowledge is pretty limited. i had seen the Endpoint profile but definitely havn't worked with it yet. will check it out and come back.
Lee Surprenant (Jun 19 2020 at 13:18):
for our hack project, we took the pdex plan-net reference implementation and added these fields so that when you search for providers, you see:
- are they accepting new patients (part of the spec already)
- do they support patient access apis
- do they support patient upload of information (which has the furthest to go it seems); and
- do they support receiving clinical information from the insurer
Lee Surprenant (Jun 19 2020 at 13:20):
think its possible to get 2, 3, and 4 from this Endpoint profile?
Lee Surprenant (Jun 19 2020 at 13:21):
i guess that might be https://build.fhir.org/ig/HL7/VhDir//StructureDefinition-endpoint-usecase.html
Lee Surprenant (Jun 19 2020 at 13:31):
oh cool, in the latest draft they've made this an extensible binding to https://build.fhir.org/ig/HL7/davinci-pdex-plan-net/ValueSet-EndpointUsecaseVS.html
Dave deBronkart (Jun 19 2020 at 13:31):
I'm very interested in the ability to see which providers actively practice interop!
At the Society for Participatory Medicine we've long envisioned enabling consumer choice by somehow letting participatory practices identify themselves. If this info became available by API it could be mashed into things like HealthGrades listings. See for instance their Patient Safety and Patient Experience awards, which leverage data published elsewhere. https://www.healthgrades.com/quality/patient-safety-patient-experience
(HCAHPS is notoriously weak as a measure of reality; that's not my point - it's that when data becomes available, it can be used, and it enables consumer choice, which rewards practices who do it. And I think that's what we want to do.)
Dave deBronkart (Jun 19 2020 at 13:36):
I'm pretty sure @Morgan Gleason and @Bray Patrick-Lake would shout "HECK YES!" (at least) to the idea of being able to search for providers based on whether they willingly accept existing health records.
Of course for cases as complex as theirs it will take years before that vision is fully recognized. Doesn't matter. For much simpler cases there will be an advertising advantage to providers who have some sort of "No clipboard required!" badge.
Lee Surprenant (Jun 19 2020 at 13:37):
so, to me, the only potential "gap" in the current IG might be a patient-focus on the endpoint use case valueset.
I'm actually not actually sure how i'd express those 3 datapoints from above using the valueset
Dave deBronkart (Jun 19 2020 at 13:37):
What do other countries think about this?? I know the world is different outside the perverse US money-based system, so I wonder if this would be attractive there.
Josh Mandel (Jun 19 2020 at 13:37):
@Dave deBronkart https://dashboard.healthit.gov/datadashboard/documentation/ehr-products-mu-attestation-data-documentation.php gives you another perspective on this information, showing you for each provider which electronic health record tool they have adopted, which in turn gives you a view onto their capabilities for sharing it with patients.
Dave deBronkart (Jun 19 2020 at 13:39):
@Josh Mandel Can we prototype what sort of display could be created using that info?
Josh Mandel (Jun 19 2020 at 13:40):
so, to me, the only potential "gap" in the current IG might be a patient-focus on the endpoint use case valueset. I'm actually not actually sure how i'd express those 3 datapoints from above using the valueset
I think (2) from your list is basically the presence of an endpoint with an appropriate code (it would be good to clarify whether the "patient requested" code is the right one for this, or a new code is needed, because it's not an obvious fit for me).
(3) with respect to uploads, I suppose you could try to look at the capability statement you find for the endpoint you discovered in step 2. Of course in practice the answer is simply no they don't support it :-) there's currently no regulatory mandate for this. For (4) oh boy, I'm really not aware of an existing workflow that would even cause this information flow to happen without provider involvement; don't know that I would focus automated discovery for this piece yet, but maybe I'm missing something here.
Dave deBronkart (Jun 19 2020 at 13:40):
@Josh Mandel I gotta run, but that looks like the kind of data someone like the NPWF would like to plunder, consistent with their excellent Get My Health Data resource site.
Dave deBronkart (Jun 19 2020 at 13:41):
That site btw is where I first blogged I want a health data spigot, which has become my social media avatar
image.png
Josh Mandel (Jun 19 2020 at 13:41):
Josh Mandel Can we prototype what sort of display could be created using that info?
Someone could, sure. They have a bunch of CSV files. The last time I looked into this I had a very particular goal in mind, with respect to finding API documentation.
Dave deBronkart (Jun 19 2020 at 13:44):
Dave deBronkart said:
That site btw is where I first blogged I want a health data spigot, which has become my social media avatar
Now I'm starting to wonder if the time has come to propose a future Golden Spigot award, for achievement in "tapping into" a patient's data sources and just letting it flow.
Lee Surprenant (Jun 19 2020 at 13:45):
(3) with respect to uploads, I suppose you could try to look at the capability statement you find for the endpoint you discovered in step 2. Of course in practice the answer is simply no they don't support it :-) there's currently no regulatory mandate for this.
yes, aware of this, but this is where we'd like to get to eventually, right? like for "consumer-directed data exchange" we need to be able to actually share it back to the providers in a way it can be trusted, right?
Josh Mandel (Jun 19 2020 at 13:49):
Oh we totally need to make progress here, but I don't think discovery of which endpoints support this capability is the hard or important part. The important part is getting more endpoints to support it, and learning from that experience. when we've got something that actually works, mandating that providers publishe the endpoints becomes feasible.
Lee Surprenant (Jun 19 2020 at 13:50):
i guess the "idea" here is what Dave was saying: if we can make visible which providers DO support it, we can maybe help to drive the demand?
Lee Surprenant (Jun 19 2020 at 13:51):
like it would be cool to get things to where we don't need a national mandate to deliver what people want
Lee Surprenant (Jun 19 2020 at 13:52):
(4) oh boy, I'm really not aware of an existing workflow that would even cause this information flow to happen without provider involvement; don't know that I would focus automated discovery for this piece yet, but maybe I'm missing something here.
not saying there would be no provider involvement and really not even sure if there's an appetite for this, was just thinking that with things like DaVinci PDEX / CDEX, it should be technically feasible. perhaps in some use cases having a billing-centric history of the patient will be better than having no history at all?
Josh Mandel (Jun 19 2020 at 13:53):
But today does anyone? Has anybody had a good experience using some kind of automated API for this purpose? I think we're too early to put the emphasis on Discovery. But I'm happy to be proven wrong :-)
Lee Surprenant (Jun 19 2020 at 13:53):
anyway, maybe the 3 I mention aren't the right ones to expose in the provider directory, but then what are the right ones? i'm looking for what would make sense to the patient to say "this provider can get your medical records from your other providers/you/somewhere else without you physically providing them or faxing them stuff"
Josh Mandel (Jun 19 2020 at 13:56):
I would focus on patient access as the real win. Describing other business practices of providers is super hard; for one thing, you need to figure out how to describe practices that don't involve these endpoints at all, like looking update about you and commonwell or Care quality. I think it's a question of focus for us.
Josh Mandel (Jun 19 2020 at 13:56):
If we had a great way to figure out who's accepting new patients and who gives you your data through an API, that would feel like a win.
Dave deBronkart (Jun 19 2020 at 13:56):
Josh Mandel said:
But today does anyone? Has anybody had a good experience using some kind of automated API for this purpose? I think we're too early to put the emphasis on Discovery. But I'm happy to be proven wrong :-)
Chicken-egg error! Information that drives consumer choice is used by some people, though I don't have time to go dig out specifics. One source that's been funded by large employers for years is Leapfrog Group's Hospital Safety Grade, which munges and munches safety data reported to CMS. I dug into it and blogged when they first started publishing in 2012.
Dave deBronkart (Jun 19 2020 at 13:57):
It was amusing at first to see people with low grades complain about having no factual basis, until it was pointed out to them that it was a summary of their own data as reported to CMS. :-)
Josh Mandel (Jun 19 2020 at 13:58):
But I think you're missing my point. There is a chicken-and-egg problem is about support, not discovery. Support is about providers offering a service and patients using it (or for that matter, patients demanding a service and providers coming around). Scalable Discovery only matters later.
Dave deBronkart (Jun 19 2020 at 13:58):
Importantly, these grades have driven real improvement. If you want, I can dig that out.
Dave deBronkart (Jun 19 2020 at 13:59):
Josh Mandel said:
But I think you're missing my point. There is a chicken-and-egg problem is about support, not discovery, it is about providers offering a service and patients using it. Scalable Discovery only matters later.
I gotta run (as I said 20 minutes go :-)) but indeed I seem to not be understanding. Say more about support, please, and I'll be back later. (Yell if I don't respond.)
Lee Surprenant (Jun 19 2020 at 13:59):
If we had a great way to figure out who's accepting new patients and who gives you your data through an API, that would feel like a win.
totally agree. and i see it happening which is amazing (in no small part thanks to your amazing efforts). not detracting from that. just saying that I don't think that solves the "how does a new provider get my medical history" part of it. i know there's tons of work done in that space with HIEs and whatnot, just wondering how we can expose "does this provider support it" level info so that patients can factor that in when they chose a provider
Josh Mandel (Jun 19 2020 at 14:03):
Yeah, we just need to be realistic about which methods are actually relevant for people making decisions. Today participating in some of these Nationwide exchanges is probably the most relevant way that information is flowing, even though there's plenty I don't love about it. Tell me another actual kind of information flow that is happening today that patients should care about, and we can talk about how to surface details about it.
Josh Mandel (Jun 19 2020 at 14:05):
I hate to get philosophical or negative here; I think this is super important and I just want to make sure we are putting in effort in places where it is going to pay off. I think we need to first show that the technology works, and then try to make it easy for people to learn who supports the technology. (Otherwise we risk requiring people to fill out a bunch of forms and publishing a bunch of checbox data that's going to be trivial or meaningless.)
Josh Mandel (Jun 19 2020 at 14:06):
That's roughly what I mean by support and then discovery.
Lee Surprenant (Jun 19 2020 at 14:08):
Today participating in some of these Nationwide exchanges is probably the most relevant way that information is flowing
how do we indicate that a provider pariticipates in an exchange and can pull your records from there?
Lee Surprenant (Jun 19 2020 at 14:09):
note: I'm not trying to define any Endpoint in this case. just trying to indicate to the patient that this provider can [at least potentially] get your history
Josh Mandel (Jun 19 2020 at 14:10):
Fair enough; I just think that winds up being true for everyone. Once you put in all the caveats and qualifications.
Lee Surprenant (Jun 19 2020 at 14:14):
that is an interesting comment...maybe my understanding of the problem is wrong. i was under the impression that its pretty rare for someone to visit a provider and have that provider say "we were able to pull your medical history from the exchange so no need for you to go get it from your previous providers and bring it to us"
Lee Surprenant (Jun 19 2020 at 14:15):
or i guess thats why you mean by "caveats and qualifications"
Lee Surprenant (Jun 19 2020 at 14:17):
anyway, this has been a great convo, thanks! I think we both agree on one thing which is that plan-net should be more clear about how to indicate whether a provider supports patient access apis...although hopefully soon that will be most if not all too :-)
Lee Surprenant (Jun 19 2020 at 14:18):
my biggest concern on that one is that I have some concern with the payers' ability (and motivation) to meaningfully track that piece of info
Lee Surprenant (Jun 19 2020 at 14:18):
any ideas there?
Vassil Peytchev (Jun 19 2020 at 14:36):
Lee Surprenant said:
any ideas there?
How would we approach a federated provider directory, where the information from, for example, Careequality is integrated and available in the payer's API? And yes, today, getting your existing medical history to a new provider is done by getting it from the previous providers who have treated you.
Michele Mottini (Jun 19 2020 at 14:48):
how to indicate whether a provider supports patient access apis
It is simple: if your provider is in https://open.epic.com/MyApps/Endpoints patient access APIs are accessible and usable, if the provider is not on that list they are unavailable or very very hard to connect to
Lee Surprenant (Jun 19 2020 at 16:12):
Cool link, wasn't aware of that one. But no other vendors supported argonaut?
Lee Surprenant (Jun 19 2020 at 16:14):
I did a quick analysis and I think this list has more than 100 providers that aren't on that one: https://support.apple.com/en-us/HT208647
Michele Mottini (Jun 19 2020 at 16:23):
Yes, but those are Apple-specific connections. Does not mean that any app can connect to those
Michele Mottini (Jun 19 2020 at 16:25):
so yes, there are other available end points besides the ones in the Epic list - but you have to find them and then convince whoever controls them to give you access - both things that are very (very) hard
Dave deBronkart (Jun 19 2020 at 19:51):
These lists of Apple-only and Epic-only (and Fitbit-only) people are anathema. We are about interop!!!
Or am I misunderstanding?
Michele Mottini (Jun 19 2020 at 19:57):
The Epic list is not Epic-only - those are end points of Epic systems that anyone can connect to
Michele Mottini (Jun 19 2020 at 19:58):
The Apple list on the other had is what Apple can connect to - other cannot (in general)
Michele Mottini (Jun 19 2020 at 19:59):
We are about interop!!
Others aren't
Josh Mandel (Jun 19 2020 at 22:27):
These lists of Apple-only and Epic-only (and Fitbit-only) people are anathema. We are about interop!!!
Or am I misunderstanding?
I think you are misunderstanding, or at least we disagree :-) Today the widest interoperability we have is through standardized, interoperable APIs where access control is partitioned by vendor. As such, those vendors are able to publish authoritative lists describing the endpoints in their network, allowing others to the discover, connect, and build on top. Indeed, anyone can take these independent endpoint lists and compile them into an aggregated list, but the secret is that for this to be successful you need to actually add value (making sure it stays up to date with the sources with very little lag, reconciling any formatting difference is, annotating with additional data, etc). ONC is requiring more publication at the vendor level, and maybe once there's more than a few lists to scrape, aggregating content will become a more attractive proposition. But again, discovery is not the hard part. Today everyone who actually has a wide network has made it discoverable. The problem is that most have no network.
Dave deBronkart (Jun 19 2020 at 23:20):
So, @Josh Mandel , perhaps indeed I'm misunderstanding, which would be great! As someone not steeped at all in the technology nor the commercial world, dialog with people like you is invaluable to me.
I think I hear you saying that each vendor is publishing its own directory of things it knows about and/or has vetted, which is not at all an exclusive list of things it will talk to. Am I hearing that correctly?
Dave deBronkart (Jun 19 2020 at 23:23):
Josh Mandel said:
But I think you're missing my point. There is a chicken-and-egg problem is about support, not discovery. Support is about providers offering a service and patients using it (or for that matter, patients demanding a service and providers coming around). Scalable Discovery only matters later.
Okay, I'm back as promised, but I'm done for today (for this week!) so for now I'm just saying I need more tutorial and maybe we should take this off-list (or at rename it!).
Josh Mandel (Jun 19 2020 at 23:51):
Let's take off-list (happy to chat 1:1 next week)! Have a great weekend.
Hamish MacDonald (Jun 20 2020 at 00:17):
@Dave deBronkart I would like to help make an interop "badge" happen as early as next year, rather than years from now. It is long overdue and institutions (not just practices) being formally branded as interop is a logical next step in the evolution of FHIR - as well as raising public awareness of the benefits to them of FHIR data that they can actually get at. I really like @Josh Mandel starting point of "If we had a great way to figure out who's accepting new patients and who gives you your data through an API, that would feel like a win."
Hamish MacDonald (Jun 20 2020 at 00:47):
Dave deBronkart said:
What do other countries think about this?? I know the world is different outside the perverse US money-based system, so I wonder if this would be attractive there.
Yes, needs to be global mark / badge / cert. I can speak for the APAC region that I know of no such effort (unsurprisingly).
Hamish MacDonald (Jun 20 2020 at 01:14):
Lee Surprenant said:
anyway, maybe the 3 I mention aren't the right ones to expose in the provider directory, but then what are the right ones? i'm looking for what would make sense to the patient to say "this provider can get your medical records from your other providers/you/somewhere else without you physically providing them or faxing them stuff"
What you said here about "this provider can...without you..." sounds something like "FHIR Smart" (Too close to SMART on FHIR?). In any case, something that is easy to riff and encapsulates what Provider X does for you regarding your data will be needed. This thingy is going to need patient adoption, so it needs to be "adoptable".
Dave deBronkart (Jun 20 2020 at 01:27):
@Hamish MacDonald, welcome :slight_smile:
Brendan Keeler (Jun 21 2020 at 17:53):
Worth noting - Almost all providers already have a basic path to accept patient information via Direct messaging, given that technology was mandated by MU2
Brendan Keeler (Jun 21 2020 at 17:53):
Not the perfect solution but definitely a broadly available technology to accomplish the end goal (that very few PHRs are currently utilizing)
Lee Surprenant (Jun 22 2020 at 14:45):
FYI I raised the how to properly represent patient access endpoints in PDEX-plan-net? at https://chat.fhir.org/#narrow/stream/229922-Da.2BVinci.2BPDex.2BPlan-Net/topic/Exposing.20patient.20access.20endpoints
Last updated: Apr 12 2022 at 19:14 UTC
