Stream: Endpoint Discovery
Topic: ONC Forum Session
Wayne Kubick (Aug 10 2020 at 18:17):
@Ryan Howells and I are participating in a session at the ONC Interop Forum, hosted by @Matt Rahn . We're interested in input from the Community. Here's the session description: Track 3: API Standards and Innovation
FHIR Endpoint Discovery and Monitoring
FHIR servers are proliferating across the nation, making health data more readily available for application developers and consumers. This session will feature perspectives on FHIR endpoint discovery and monitoring from several industry stakeholders. It will also debut the "Lantern" system, being used to monitor the availability and adoption of FHIR API service-based URLs by select users across the U.S
Jens Villadsen (Aug 10 2020 at 21:28):
If you take FHIR out of the equation, I would say its in pretty good shape in DK. While the API's are listed in the public space, you can't use them unless your company has a proper clearance (private practitioners mostly) or act on behalf of one of the public actors ... and most of the API's are focused on use by practitioners
Grahame Grieve (Aug 10 2020 at 21:34):
thanks. who lists them, what's the curation, and why would you get it listed?
Jens Villadsen (Aug 10 2020 at 21:52):
its mostly national stuff though - meaning its the government that lists it there and they curate both the list and the data of the services (sort of)
Jens Villadsen (Aug 10 2020 at 21:54):
in addition the communication between practitioners and hospitals/elderly homes/specialty doctors and so on is async message based communication where the national authorities maintain a single registry with a couple of thousand entries where everybody can send to everybody
Jens Villadsen (Aug 10 2020 at 21:55):
but none of all that rhymes with FHIR so far ...
Grahame Grieve (Aug 10 2020 at 22:03):
well, the FHIR bit is orthogonal, right? None of that would be any different if they decided to use FHIR instead of something else for the actual exchanges?
John Moehrke (Aug 11 2020 at 01:58):
Similar nationwide directory of healthcare service endpoints for the nationwide health exchange are managed in the USA. Sequoia has one that is based on FHIR platform, but mostly has XCA endpoints so far today. They are discussing how this could be FHIR endpoints. But this use is for Treatment, Payment, Public-Health... Not yet patient access.
John Moehrke (Aug 11 2020 at 01:59):
What is the use-case for this endpoint discovery?
John Moehrke (Aug 11 2020 at 02:02):
Top contenders for a FHIR based solution are the HL7 VhDIR, and the IHE mCSD. The IHE is focused purely on organizational endpoint with less focus on people.
Oliver Egger (Aug 11 2020 at 07:41):
For the Swiss EPR where we will have multiple certified communities and the configuration for this communities can be discovered by a central managed government service. The technical specification is a national profile which builds upon IHE HPD defines functionalities for the Swiss EPR circle of trust in order to provide a trustworthy list of certified communities. This list also contains information about relevant endpoints of the certified communities. It is mostly WS endpoints (XCA, XCPD), public certificates and contains today only one FHIR Endpoint for AuditEvents. Maybe for a future version it can be migrated to IHE mCSD as @John Moehrke mentioned, today it is Webservice/LDAP. https://www.bag.admin.ch/dam/bag/de/dokumente/nat-gesundheitsstrategien/strategie-ehealth/gesetzgebung-elektronisches-patientendossier/gesetze/epdv_edi_erg_2.3_ausgabe3_anhang_5.pdf.download.pdf/Ergaenzung_2.3_Anhang_5_EPDV_EDI_Ausgabe_3.pdf
Ryan Howells (Aug 11 2020 at 17:16):
The two biggest use cases in the near term @John Moehrke are patient facing apps attempting to connect and post-2021, payer-to-payer data exchange where payers need to retrieve data from any other CMS payer in the country. We know FAST is working on this issue but it's not clear where their discussions are at this point. Here are the slides from my section of the ONC presentation today. https://www.slideshare.net/secret/CqTcrqbOIP7OO8
John Moehrke (Aug 11 2020 at 17:23):
The reason I ask is because the current working models are tied into a specific set of use-cases and thus fit within the trust framework of that set of use-cases. Payer access would be similar to the existing systems, which are professional organization to organization access. Where as Patient access often needs to be within a different trust framework that is more focused on singularly THE patient. This is not insurmountable, but is a very different trust framework, much harder in the USA without an identity framework.
Ryan Howells (Aug 11 2020 at 18:08):
Understood. Since one of the permitted purposes of the TEFCA is patient access and we're working with orgs on a digital identity federated trust framework, we're expecting it will eventually all come together. I think it's also important to separate trust from the actual directory itself. Both are needed but our focus in today's session was where and how do we publish the directory and how will we as an industry monitor the end points. Project Lantern (https://lantern.healthit.gov/) helps with the monitoring but not with the publication of the directory.
John Moehrke (Aug 11 2020 at 18:50):
trust is not enforced by the directory... but the reason to be in the directory is because that endpoint is part of a trust framework purpose that the directory is supporting. So it is an affinity to be in the directory, not a trust enforcement.
Michele Mottini (Aug 11 2020 at 18:53):
[Lantern] helps with the monitoring but not with the publication of the directory.
?
they publish all the end points - the directory is available there
John Moehrke (Aug 11 2020 at 18:59):
yup, world READ, closed Create/Update/Delete.
Matt Mayer (Aug 11 2020 at 20:49):
Michele Mottini said:
[Lantern] helps with the monitoring but not with the publication of the directory.
?
they publish all the end points - the directory is available there
Lantern makes the list of endpoints that it is regularly querying available, but that does not make it _the_ centralized FHIR endpoint directory, especially since the endpoints Lantern is querying are only the endpoints already publicly available in vendor-published lists. Acting as _the_ centralized endpoint directory was not the original intent of Lantern, but as of right now it does seem to be the only location where an aggregation of vendor-published lists can be gathered.
The big challenge faced by lantern right now is that there are only 2 small publicly available vendor lists to pull from at the moment. If every vendor published their lists of endpoints, and Lantern consumed those lists -- THEN I think Lantern, with it's endpoint export functionality, would begin to look like _the_ centralized endpoint repository.
Josh Mandel (Aug 12 2020 at 13:59):
I think the Lantern goals are great and will provide very useful infrastructure, so don't take this the wrong way -- but the argument above basically says that if (and only if) we get to the point where all data needed to create a central registry are publicly available in a decentralized fashion, then Lantern could be "_the_ centralized repository". But if all the data we need are publicly available in a decentralized fashion, there is no need for a single official centralized registry. It is still nice and convenient infrastructure and a great utility, but there's no need to consider it official or unique.
(Put another way, the value of a centralized registry beyond convenience is typically that the organization running it has access to some non-public information or an ability to review/bless data and make them official.)
John Moehrke (Aug 12 2020 at 14:12):
Yet another Directory. all problems in computer science can be solved by another level of abstraction. -- David Wheeler
Matt Mayer (Aug 12 2020 at 14:15):
You're exactly right -- I think we're saying the same thing which is why i said "but that does not make it _the_ centralized FHIR endpoint directory, especially since the endpoints Lantern is querying are only the endpoints already publicly available in vendor-published lists".
One of the benefits of, Lantern (although we only use publicly available endpoint lists) is that it does "bless" the data in a way since Lantern "knocks on the door" of all the vendor-provided endpoints to make sure that someone is home --meaning that a Lantern aggregation would be better than a blind sum of all of the vendor provided lists in that the Lantern aggregation can provide a list of only the endpoints that responded with HTTP 200. This -- combined with the fact that Lantern would be doing the work of interfacing with all of the vendor's endpoint list formats is why I say that in the case that all vendors did publish their list that Lantern would being to look like a centralized endpoint repository.
John Moehrke (Aug 12 2020 at 14:22):
How do we prevent malicious endpoints from showing up and acting like they have legitimate data? They could generate bad data, they could offer a CREATE endpoint that someone might accidentally push their data into. They might do other things, we never can predict malicious future use.
John Moehrke (Aug 12 2020 at 14:26):
John Moehrke said:
How do we prevent malicious endpoints from showing up and acting like they have legitimate data? They could generate bad data, they could offer a CREATE endpoint that someone might accidentally push their data into. They might do other things, we never can predict malicious future use.
Note I am fine with an EXPLICIT deferring of this decision. That is a "Security Considerations" that clearly indicates that this is a known risk that must be addressed later. This deferral would be based on the need to more urgently address directory needs, and expectation that agile approach can address this technical debt. --- I don't like it, but would rather it be explicit than ignored.
Josh Mandel (Aug 12 2020 at 18:36):
is that it does "bless" the data
I'd say it expresses its own opinion, which again is great, but Lantern asserting "this endpoint is up and looks good" isn't more authoritative than anybody else running similar checks and making similar assertions. There's nothing "special" like there would be if, say, ONC decided that endpoints Lantern was unaware of wouldn't count as valid under their information blocking rules or somesuch.
Alexander Henket (Aug 14 2020 at 08:30):
For patient access we have a a couple of components working together. A processable registry of data services (patient summary, lab, gp data, medication, ...), a processable registry of providers for those data services and their endpoints, and a processable whitelist of providers allowed on the network. The endpoints in the registry are not the data services themselves, but the authorization end points. If authorization is successful they get redirected to the data.
Except for the Provider Registry none of the above is FHIR enabled. In part this is conscious design as the architects want the MedMij framework to be a multi industry thing and fear FHIR-lock in. This also explains some of the authorization design and the subscription model.
Ryan Howells (Sep 19 2020 at 02:07):
Update from the payer side: Most of the major payers we spoke to this week in CARIN are planing to publish their endpoints in their developer portal on a publicly available site. They do not currently have a plan to use NPPES (at least for now).
Can @Karl M. Davis @Dave Hill comment on whether NPPES is capable of receiving payer end points today? The payers we spoke to this week didn't think the capability was available yet.
Last updated: Apr 12 2022 at 19:14 UTC
