Stream: patient empowerment
Topic: Browse my feeds (naive wish list item)
Dave deBronkart (Jul 06 2019 at 17:11):
I'm going to post this early, so if it's utterly infeasible I can get schooled, and if it could be feasible, we can start thinking where & how.
For maximum ease of consumer exploration, it will be great if a new "exploring adopter" person (ordinary citizen who's heard about the FHIR standard and has acquired SOME tool or other) can somehow browse all available feeds, from provider systems and apps and devices. This will be, as I say, for "exploring" adopters, not ones with a well defined purpose.
Grahame Grieve (Jul 26 2019 at 22:09):
"feeds" - not sure what you mean?
Dave deBronkart (Jul 28 2019 at 05:09):
Sorry, that was so unclear, and probably worded incorrectly.
I think I mean all sources of data available to him/her via FHIR. Perhaps this means all hospitals with FHIR servers or endpoints, perhaps it means apps or gadgets that offer FHIR data feeds ... Truly, for the naive explore to stumble around and become wide eyed at how intriguing and impressive the FHIR world is.
Grahame Grieve (Jul 28 2019 at 09:18):
there's nothing to this point. and each feed has to be authenticated separately...
Lloyd McKenzie (Jul 28 2019 at 13:51):
We'd love to know what all of the FHIR endpoints around the world were. However, there's no registry and no obligation to register.
David Hay (Jul 28 2019 at 18:11):
there is this page: http://www.fhir.org/implementations/registry - but it's a fairly incomplete list I suspect...
Josh Mandel (Jul 28 2019 at 18:26):
And more practically today vendor specific lists. The best example is probably https://open.epic.com/MyApps/Endpoints with over 330 health systems.
David Hay (Jul 28 2019 at 18:30):
Is there a cerner equivalent that you're aware of?
Josh Mandel (Jul 28 2019 at 18:32):
In theory there's https://github.com/cerner/ignite-endpoints but it doesn't really work -- the content has not been updated since the initial commit over a year ago, and at that point when I spot checked about 30 endpoints I could not figure out whether any of them were active and associated with a real practice. Cerner's consumer app model (at least, for MU3 patient access APIs) also does not provide a way to register apps across the whole set of providers; each provider needs to individually approve each app before a patient can connect, so consumer app registrations have no way to scale.
Dave deBronkart (Jul 29 2019 at 03:57):
Thinking out loud, and with curiosity not passion yet - as the general public learns about the standard, it may be useful if somehow a place arises that's more or less complete, in which people can rummage.
But time will tell.
I hope the nascent patient workgroup will keep an eye on both constituencies - patient innovators and consumers - or at least explicitly be about innovators and explicitly punt consumer awareness to someone else, and be blunt about the fact that we're not doing it.
Dave deBronkart (Jul 29 2019 at 11:37):
Thinking out loud, and with curiosity not passion yet - as the general public learns about the standard, it may be useful if somehow a place arises that's more or less complete, in which people can rummage.
But time will tell.
I hope the nascent patient workgroup will keep an eye on both constituencies - patient innovators and consumers - or at least explicitly be about innovators and explicitly punt consumer awareness to someone else, and be blunt about the fact that we're not doing it.
Michele Mottini (Jul 30 2019 at 11:16):
There is https://fhirendpoints.github.io/ - that at the moment being is mostly the Epic list with a bit more details, but hopefully will grow
Dave deBronkart (Jul 31 2019 at 01:34):
Is this what I've been mumbling about, sorta? From today's HISTalk coverage of the BlueButton Developer Conference:
"Providers will also publish their endpoints in the NPI database, making them accessible to others."
For newbies: NPI is the National Provider Identifier (see, doctors get to have a unique identifier...) So I'm guessing each provider will have an additional field in his/her/its profile?
John Moehrke (Jul 31 2019 at 11:41):
yes, the NPI already has a home in the Practitioner.identifier...
Dave deBronkart (Jul 31 2019 at 12:16):
@John Moehrke I think you are talking about a place for NPI in a provider's data object(?? I'm making up my lingo), but I meant the opposite, I think- a place in the provider's NPI record for their FHIR endpoint. Yes?
Josh Mandel (Jul 31 2019 at 12:18):
Right now these links happen through organizations: a practitioner has an NPI and can belong to an organization. An endpoint is associated with an organization. so if you know the NPI of a practitioner you can look up organizations they are affiliated with and if you know the organization ID can look up endpoints to connect. That's the theory at least :-)
John Moehrke (Jul 31 2019 at 12:27):
would a human clinician have a FHIR endpoint?
There are definitions for Provider Directories that hold information about Organizations, health service locations and the kinds of services offered there, and these can include the clinician details too... These specifications are being rolled out. They could include the FHIR endpoint where ever appropriate. -- for example this spec http://build.fhir.org/ig/HL7/VhDir/
Virginia Lorenzi (Jul 31 2019 at 14:18):
In addition to Grahame's point about needed credentials, you would need a browser app that all vendors supports and except for Epic sites as far as I know, each provider site has to authorize the browser app even if the API is live. Please correct me if their are other APIs out there that don't require this. As far as credentials AthenaHealth allows patient app users use the same credentials at multiple sites that use AthenaHealth. I think Debi said another vendor did this as well.
Virginia Lorenzi (Jul 31 2019 at 14:21):
John - you have me thinking of the patient being an endpoint. At Cinderblocks I got to meet patient advocate Mighty Casey (@mightycasey) who has a QR code linking to her medical record tattooed on her chest.
Debi Willis (Jul 31 2019 at 14:45):
Only Cerner requires an app be white listed per provider organization. For other EHRs, once your application is tested with the EHR vendor and you have your application client ID and secret from the vendor, the applications don't need to be authorized (as in white listing) by each provider site. We do need the clinic's FHIR endpoint and other pieces of information to list them in our consumer app. Epic lists all the information needed for their sites who already have their API implemented (https://open.epic.com/MyApps/Endpoints). Other EHRs tell their clinics to reach out to us to give us their FHIR endpoint and other required information. Some clinics are confused about that because they think that once they have the API, any FHIR apps can be used. As far as AthenaHealth goes, my understanding is they are not ready for FHIR apps because they don't have a way for patients to authenticate yet. We have reached out many times and when they do respond, that is the feedback we are getting.
Debi Willis (Jul 31 2019 at 14:55):
Starting on page 273 of the ONC Cures NPRM is text that speaks about publicly posting FHIR Endpoints. This is really important for patients to retrieve their data from all their providers "without special effort". I am hoping this becomes a reality. (Epic is already doing this.) Here is the text:
ii. Publication of FHIR Endpoints
In order to interact with a FHIR RESTful API, an app needs to know the “FHIR Service Base URL,” which is often referred to colloquially as a “FHIR server’s endpoint.”93 The public availability and easy accessibility of this information is a central necessity to assuring the use of FHIR-based APIs without special effort, especially for patient access apps. Accordingly, we propose to adopt in § 170.404(b)(2) a specific requirement that an API Technology Supplier must support the publication of Service Base URLs for all of its customers, regardless of those that are centrally managed by the API Technology Supplier or locally deployed, and make such information publicly available (in a computable format) at no charge. In instances where an API Technology Supplier is contracted by an API Data Provider to manage its FHIR server, we expect that this administrative duty will be relatively easy to manage. In instances where an API Data Provider assumes full responsibility to “locally manage” its FHIR server, the API Technology Supplier would be required, pursuant to this proposed maintenance requirement, to obtain this information from its customers. We strongly encourage API Technology Suppliers, health care providers, HINs and patient advocacy organizations to coalesce around the development of a public resource or service from which all stakeholders could benefit. We believe this would help scale and enhance the ease with which Service Base URLs could be obtained and used.
John Moehrke (Jul 31 2019 at 15:05):
John - you have me thinking of the patient being an endpoint. At Cinderblocks I got to meet patient advocate Mighty Casey (@mightycasey) who has a QR code linking to her medical record tattooed on her chest.
I think a human patient does make sense to have "a" endpoint, where they combine all their data and publish it for 'appropriate' use. How they determine appropriate, and how they authorize... is a tough problem, but not one that is beyond current technology.. just something that no one has yet made easy enough for a common person (Geeks can do it).
Brendan Keeler (Aug 01 2019 at 09:30):
@Debi Willis Cerner is certainly not the only EHR vendors to require organizational authorization. Meditech and other EHRs (Virence/GE, I think) do as well.
Brendan Keeler (Aug 01 2019 at 09:30):
Last updated: Apr 12 2022 at 19:14 UTC
