Stream: patient empowerment
Topic: Curated directory of apps & endpoints
Dave deBronkart (Jan 17 2020 at 14:00):
I'm proactively creating a new subject here, branching off of Abbie's Charter (Revisions) thread.
Dave deBronkart (Jan 17 2020 at 14:07):
For starters is there a reason we shouldn't create a wiki where people can volunteer their endpoints and others can vouch for "Yup, it works"?
Also for starters re apps, is there a reason we can't start a similar wiki where developers can post "I do FHIR" (with some level of detail I presume) and others can up-vote and comment?
None of this is intended to replace a "real" solution hosted somewhere someday; it's intended to get things moving and kindle discussions on what's real.
Michele Mottini (Jan 17 2020 at 14:14):
We (CareEvolution) maintain a public list of end points at https://fhirendpoints.github.io/
Dave deBronkart (Jan 17 2020 at 15:57):
Wow, at first glance that looks terrific! What do others think? Thanks!
Abbie Watson (Jan 17 2020 at 17:57):
There's also the Cerner ignite-endpoints repository, which has something like 1,500 DSTU2 endpoints.
https://github.com/cerner/ignite-endpoints/blob/master/dstu2-patient-endpoints.json
Abbie Watson (Jan 17 2020 at 17:59):
The file is nearly 2 years stale now, but the way Cerner approached FHIR rollout was to forklift their entire network at the same time rather than piecemeal rollout. So it's a reasonably complete picture.
Michele Mottini (Jan 17 2020 at 18:57):
that list has only the 'small' Cerner clients - we found out that the big hospitals are not there
Brendan Keeler (Jan 18 2020 at 18:53):
@Ryan Howells and Carin have ideas in terms of a centralized repository, based on previous tweets. Hoping that's advanced
Ryan Howells (Feb 04 2020 at 14:00):
We would still like to do that @Brendan Keeler although it's still super early. Huge thanks to @Michele Mottini and his team for putting together their list although much of it is largely available on Epic's website today. The big challenge is there isn't a single EHR company I'm aware of who has posted all of their client end points online because they believe a few of their contracts limit them from doing so. The list @Abigail Watson references unfortunately is useless since Cerner uses a single API to connect to apps. We checked that list more than a year ago and most of the providers didn't even have a provider website stood up yet.
Abbie Watson (Feb 05 2020 at 01:08):
Why is a provider website needed, though? Isn't that precisely the point of running a registry or directory or phonebook? To put into a single spot the information so they don't have to do it themselves?
See... I'm thinking about the problem more in terms of a) mapping the FHIR ecosystem and b) understanding what percentage of network coverage that our longitudinal timeline can access. So I'm inclined to start by loading up all 5000+ hospitals in the US that receive Medicare funds into our database; adding in the publicly curated lists of endpoints, and maybe feeding all that into a spider bot to go out and crawl the metadata routes and capability statements. Maybe setting a worklist also, and simply assigning someone to work the list and cold call the hospitals.
With that kind of approach, a partial network map provides more visibility than no network map.
Dave deBronkart (Feb 05 2020 at 01:14):
Why is a provider website needed, though?
What do you mean by a provider website?
I fully support whatever y'all competent professionals need/want to do. Total confidence in your judgment. I'm thinking additionally of the newcomer experience, as people who never DREAMED of being a @John Keyes or @Kristina Sheridan start to realize that there might be something they could actually due to acquire some of that "Knowledge is power" stuff.
I dunno whether that helps with your question but it's true in any case.
Brendan Keeler (Feb 05 2020 at 17:05):
Abigail - Cerner doesn't have pure OpenID patient authentication and access on those endpoints like Epic does, to my knowledge. Requires each app to work with the hospital as a gatekeeper to be enabled first. Really only Epic that currently has the vendor level, true patient access approach. Anyone who works with patient auth and consumer apps (@Ricky Sahu or @Ricky Bloomfield, looking at you) please correct me if I'm wrong.
http://fhir.cerner.com/authorization/
@Michele Mottini made this awesome spreadsheet a little while ago that shows the details across vendors. Note Cerner has a "whitelisting" step per HCO: https://docs.google.com/spreadsheets/d/1C9faN7Ne0DIgrmXbMVBcff9KTotuejIEbpr4ZPE3tUE/edit#gid=0
Brendan Keeler (Feb 05 2020 at 17:06):
Simply put, FHIR endpoints do not necessarily means SMART support. And SMART support do not necessarily mean full patient auth with no provider/HCO gatekeeping.
Ricky Sahu (Feb 05 2020 at 19:08):
@Brendan Keeler you're correct
Michele Mottini (Feb 08 2020 at 08:44):
Due to CareEvolution internal policy changes the end point list at https://fhirendpoints.github.io is no more. If someone wants to take that over I'll be happy to transfer ownership of the GitHub repo (that contains the data as of around one month ago)
Abbie Watson (Feb 08 2020 at 16:57):
Oh, that's too bad. We can park it in the Clinical Meteor org, which is a catch all for useful healthcare related javascript libraries that are no longer maintained, until a proper directory gets stood up.
Michele Mottini (Feb 10 2020 at 08:35):
Here is the last published version: fhirendpoints.zip
Virginia Lorenzi (Feb 12 2020 at 23:43):
Well gee whiz endpoints have been on my mind lately. With Apple, the provider gets to determine how their endpoints relates to their organizational structure which can lead to a rational listing on an application. We have many listings and some point to the same endpoint but it makes sense with our geography and how our patients know the local hospitals or clinics. Just because an organization has an endpoint doesn't tell you how to represent it on your application to make most sense to your customers. In the CMS Patient Access rule - one of the two rules that we are waiting on - providers are supposed to put their endpoints in a national directory. I hope that that will make rational sense.
Josh Mandel (Feb 12 2020 at 23:46):
There is also the expectation that vendors will list endpoints on behalf of their customers in a potentially vendor-specific place -- which misses the opportunity for the kind of cross-cutting provider-centric approach you are describing here, But which is still a lot better than the lack of transparency we have today. It allows for downstream structure to be layered on.
Brendan Keeler (Feb 13 2020 at 05:15):
Agree. Vendor specific would be a huge step forward.
Clean organization lists are going to be hard. We see that manifest with Carequality and Commonwell already.
In a similar vein, provider lists, such as DirectTrust's, suffer from quality issues.
In my mind, aggregation of each directory is the first problem, after which cleansing and cleanup to optimize can be done. Better to have a sloppy list of an endpoints than to put strict constraints that deter participation.
Josh Mandel (Feb 13 2020 at 21:29):
Yep. If every vendor had a list even close to the quality of https://open.epic.com/MyApps/EndpointsJson we'd be way better off. (Of course, for that list, the obvious improvement opportunity would be to say something about the real-world entities, like providing URL, NPI, etc, so developers didn't have to manually review each one to figure out what health system it represents.)
Brendan Keeler (Feb 14 2020 at 01:49):
No fun if it's too easy, right? :joy:
Cooper Thompson (Feb 17 2020 at 14:56):
What sort of metadata would be most useful to include in an endpoint directory like open.epic, other than NPI(s)?
Debi Willis (Feb 17 2020 at 15:16):
These items would be handy to have in the directory:
• Organization Name
• Organization Location Address, City, State, Zip (Lat and Long would be really nice)
• Organization EMR Name (There are some differences between implementations)
• Organization Base FHIR URL
Brendan Keeler (Feb 17 2020 at 15:43):
Similar to the Carequality directory except FHIR endpoints instead of xds.b.
Brendan Keeler (Feb 17 2020 at 15:46):
The ultimate dream is a unified and cleansed directory of endpoints of organizations and their constituent facilities, with provider directory information like Direct addresses attached underneath.
Bart Carlson (Feb 17 2020 at 20:23):
I couldn't agree more! What we need is a target date to have this all in place. And, then work backwards to lay out a plan to get there.
Dave deBronkart (Feb 17 2020 at 20:40):
Bart Carlson said:
What we need is a target date to have this all in place. And, then work backwards to lay out a plan to get there.
Isn't "this all" a bit ambitious?? It would sure be useful to have a decent sized partial list. I can imagine that some providers might then start getting embarrassed by not being on the list, which might help motivate them to get on board.
Bart Carlson (Feb 17 2020 at 20:59):
I agree we need steps to get to the end game! To me creating a partial list is just one of the many steps we need to do to get to the unified and cleansed directory of end points (e.g. National Unified Master List) with a target date. So, could we put together a partial list by December 2020? Or, some date sooner? If so, then what do we need to do to to develop the partial list? And, what are all the other steps we need to do to get to a National Unified Master List?
Dave deBronkart (Feb 17 2020 at 23:00):
How about some milestones tied to events? HL7 conference, then DevDays Amsterdam in November?
Such artificial, meaningless occasions sometimes are amazingly motivating...
Bart Carlson (Feb 17 2020 at 23:56):
I like it! Could you circulate a draft to get the discussion started? Maybe pick the major planned HL7 events over the next two years and put a trial goal next to each one. I'm sure others will have lots of good ideas!
Brendan Keeler (Feb 18 2020 at 02:12):
I think I'm a little more pessimistic. It's enough of a problem that the list of endpoints are being seen as a proprietary company asset. The major patient auth players are not necessarily sharing and collaboratively building a repository. And given access for most EHRs is negotiated at the HCO level by each vendor, it's not just a listing.
Not playing a ton personally in that space outside of personal interest as a developer, but entire companies exist right now solely based on clean, organized patient auth endpoint directories. Commotidized access to endpoints is where the industry should end up after Cures goes through, but until then, it's a differentiator and there's little incentive for vendors to share.
Jose Costa Teixeira (Feb 18 2020 at 05:35):
European legislation is moving towards having approved apps. Germany has done it (on paper), Belgium will move there too.
Jose Costa Teixeira (Feb 18 2020 at 05:37):
Personally, I think the issue (and the real goal) is not "the list" - but more the governance and criteria and statuses and categories on that list.
Jose Costa Teixeira (Feb 18 2020 at 05:40):
Possibly I'm deviating from topic, in which case apologies.
We're looking at e.g. "Official List of authorised medication management apps that can be prescribed and will be reimbursed"
Jose Costa Teixeira (Feb 18 2020 at 05:40):
or "List of certified endpoints for my imaging data".
Craig Newman (Feb 18 2020 at 13:16):
@alix goss or @Robert Dieterle - Can you add your thoughts on where ONC's FAST (FHIR at Scale Taskforce) Directory tiger team is at in terms of developing a standard directory of endpoints?
Ryan Howells (Feb 25 2020 at 22:18):
I agree with @Brendan Keeler. Curation of a complete FHIR end point directory is (unfortunately) going to take some time. There are architectural, legal, and policy barriers to making it happen quickly. First step - We need to see the finalized CMS and ONC rules. If the requirement to publish the FHIR client-specific end points is finalized then the vendors will put into motion a plan to change their agreements with their clients so the end points can be published. Many will also need to make the technical infrastructure changes to make those end points discoverable.
We can certainly start with the list others have began to curate but a complete list won't be available for a while. Others should chime in if they feel differently.
Mikael Rinnetmäki (Feb 27 2020 at 07:35):
In Europe, if we get momentum behind the International Patient Access, we should certainly take listing of the available API's as one of the discussion items. How, where, when, how are all parties incentivized.
Virginia Lorenzi (May 28 2020 at 15:49):
Carin Alliance (@Ryan Howells ) announced today just such a directory which they plan to support: https://www.carinalliance.com/wp-content/uploads/2020/05/CARIN-Blog-05.27.2020.pdf All of these apps attest to the CARIN Code of Conduct: https://www.carinalliance.com/our-work/trust-framework-and-code-of-conduct/
To request to be added to the list: https://myhealthapplication.com/list-your-app
Its free to be listed.
In the context of this chat - I do wish it said FHIR-enabled as a checkbox.
Dave deBronkart (May 29 2020 at 14:30):
Thanks, Virginia! Love this list - 11.5 months after we tried to start it at DevDays Seattle! :-) Thanks to CARIN!
Virginia Lorenzi said:
In the context of this chat - I do wish it said FHIR-enabled as a checkbox.
@Virginia Lorenzi I imagine "FHIR enabled" could have many meanings - did you have something specific in mind?
Hey @Ryan Howells how might we (individually or as a group) go about requesting a "Uses FHIR" checkbox? Should be pretty able to ask each one how they use FHIR.
Ryan Howells (May 29 2020 at 14:37):
Great question, @Dave deBronkart and thanks to @Virginia Lorenzi for announcing this to the group. We really want your feedback on how we can improve the site!!! Actually, every application on the site uses FHIR APIs to access health records. It's one of the questions we ask as part of the onboarding process. Other ideas you have for what we should be doing to onboard these apps would also be helpful.
Dave deBronkart (May 29 2020 at 14:39):
Well jeeze, Ryan, please trumpet that or post a FHIR logo or something! Lots of the world out there (especially consumers) don't that yet, and seeing the logo or tag displayed EVERYWHERE helps create momentum. Again, thanks
I mean, "FHIR" doesn't even appear in the announcement PDF. :slight_smile:
Dave deBronkart (May 29 2020 at 14:39):
In the app gallery, what does it mean to be "1upHealth affiliated"??
Ryan Howells (May 29 2020 at 16:46):
It's a great comment @Dave deBronkart. Our board revisited the idea of affiliations today and we're going to do some additional thinking on the topic before we post that section on the site. Affiliations tried to convey too much (where there were connected, who they were connected to, what best practices they attested to, etc.) It was an 'experiment' on how we begin to build transparency and trust in the ecosystem. Feedback like this is really helpful. Keep it
coming!
Dave deBronkart (May 29 2020 at 16:47):
The next thing people will need is SOME sort of first-level ability to differentiate what these different species are. I don't have solution - just sayin'
Dave deBronkart (May 29 2020 at 16:48):
VERY happy y'all have started this. Ready to blog, once there's some clarity to what people will find when they knock!
Brendan Keeler (May 30 2020 at 04:22):
1up is an intermediary platform for some consumer apps
Dave deBronkart (May 30 2020 at 18:00):
Thank you! I’m starting to think my main value around here may be as Asker Of Partially Naive Questions as we starting morphing from “no you can’t” to “maybe you can, if you know what you’re doing”
Last updated: Apr 12 2022 at 19:14 UTC
