Stream: implementers
Topic: Endpoint Resource
Michael Donnelly (May 09 2016 at 15:24):
@Brian Postlethwaite , @Kevin Paprocki will definitely be interested in this.
Michael Donnelly (May 09 2016 at 15:24):
http://hl7-fhir.github.io/endpoint.html
Michael Donnelly (May 09 2016 at 15:34):
Initial thoughts:
Michael Donnelly (May 09 2016 at 15:36):
- endpoint is the right name
- payloadType should be 0..*
- a valuable status would be one to indicate an endpoint isn't ready yet
Michael Donnelly (May 09 2016 at 15:36):
The last would be when you want clients to know about your endpoint and be ready to use it as soon as it goes online.
Michael Donnelly (May 09 2016 at 15:37):
To that end, a date when it becomes active would be useful. (This comes from experience with Epic's Care Everywhere Phone Book which has and uses that feature.)
Michael Donnelly (May 09 2016 at 15:41):
Our customers have separate test and production instances. They have their own endpoints and certificates. We are extremely careful to avoid contamination between the two. Is that concept worth including?
Brian Postlethwaite (May 09 2016 at 15:41):
So another value in the status type that is in preparation/testing stage or something like that?
Brian Postlethwaite (May 09 2016 at 15:42):
We do have the period on there so that you can forecast de-activating, or indicating will become available.
But would like some feeback on this. Was just a sugestion for intiial discussions
Peter Bernhardt (May 09 2016 at 15:43):
endpoint == metadata. Why not just include this info in the conformance statement? Is there a good rationale for having another level of abstraction for meta information about service capabilities?
Kevin Paprocki (May 09 2016 at 15:43):
We'd also want to be able to handle the use case of a planned downtime, we could probably use status for that
Brian Postlethwaite (May 09 2016 at 15:44):
This is an example of this type of resource as defined in use in the MiHN system (live in DSTU2) and would be replaced by this resource
http://sqlonfhir-may.azurewebsites.net/fhir/Basic/ElectronicService-12182/_history/1?_format=html
Brian Postlethwaite (May 09 2016 at 15:45):
The difference between conformance and this resource is that conformance is more about a complete picture of me, and endpoint is details for others (for purposes, and not just FHIR services)
Kevin Paprocki (May 09 2016 at 15:47):
Peter, from my perspective endpoint is more than just metadata, it's also a URL for where to engage that service.
Michael Donnelly (May 09 2016 at 15:48):
There's a difference between a tesing *status* and a tesing *endpoint*. The test and prod servers exist in parallel in perpetuity.
Kevin Paprocki (May 09 2016 at 15:54):
I think we'd need a 'type' element to track that. where type can be 'for testing' or 'for production'
Josh Mandel (May 09 2016 at 15:56):
@Brian Postlethwaite I don't quite understand this Endpoint vs. Conformance distinction. In your description, it sounds like (a summarized version of) Conformance should be usable for this purpose.
Michael Donnelly (May 09 2016 at 15:58):
Other than date, does http://hl7.org/implement/standards/fhir/conformance.html have any required elements?
Brian Postlethwaite (May 09 2016 at 15:58):
I'd like to retain the drafting as seperate resource and get everything we need in it documented, and then consider what that would look like if was done as a conformance resource. And have a full definition of everywhere it links to/from
Brian Postlethwaite (May 09 2016 at 15:59):
(Yes, not against using conformance, just want to ensure all the needs are pre-captured - and why it isn't linked anywhere until this stuff is clarified)
Elliot Silver (May 09 2016 at 16:00):
Just to confirm where this is going: Do we replace all the DICOM WADO-RS urls in e.g, ImagingObjectSelection with Endpoints?
Brian Postlethwaite (May 09 2016 at 16:01):
I would hope that anywhere we are including details for connecting to another system, it should be using this resource.
Not just an un-informative URL on some other resource. Then you have all the other information about statuses, contactin details when something goes wrong, security details.....
Elliot Silver (May 09 2016 at 16:02):
Is there an element that says this endpoint is a FHIR server, WADO-RS server, or XDS Repository? I see an element that says that the endpoint serves up "XDS Discharge summaries", but not that it is an XDS Doc Repository.
Brian Postlethwaite (May 09 2016 at 16:03):
Can be able to describe more than jsut FHIR services (so you can include connection details for an XDS service, or others..)
Elliot Silver (May 09 2016 at 16:03):
Yes, but how do you code the service offered at that endpoint?
Brian Postlethwaite (May 09 2016 at 16:04):
This is ony a first draft, and yes will want to cover this.
Brian Postlethwaite (May 09 2016 at 16:07):
I wanted to ensure that I got all the relevant interested parties involved in the conversation.
Elliot Silver (May 09 2016 at 16:11):
For, e.g., a RESTful service, the url http://www.server.com/myService/AResource/1234/SubResources/5678, would be coded in a resources as an Endpoint reference (pointing to an Endpoint describing http://www.server.com/myService) and a uri/string/???? with a value of "AResource/1234/SubResources/5678"?
Brian Postlethwaite (May 09 2016 at 16:19):
The current thinking is that it describes a place where you will send/find information.
In the case of a FHIR server, the address would be the baseURL of the service, the format(s) supported (json/xml) and which resource types to interact with.
Not sure how the complete URL fits into the picture, that's just a resoruce that you might find at that location.
In messaging could just be a POST only thing.
Elliot Silver (May 09 2016 at 16:25):
Splitting out the endpoint from the variable part of the URL would be useful in cases where a server moves (or two servers get merged). Just update the endpoint resource, rather than having to modify all, e.g, DocumentReferences that reference that server. Or, if you do need to modify the variable part, then you can find all the relevant resources by doing a _reverseInclude on the Endpoint.
Michael Donnelly (May 09 2016 at 16:28):
That's compelling, @Elliot Silver
Michael Donnelly (May 09 2016 at 16:29):
@Josh Mandel , would it be appropriate to use conformance for endpoints that are not FHIR resources?
Josh Mandel (May 09 2016 at 16:33):
But @Elliot Silver, cool URIs don't change ;-)
Josh Mandel (May 09 2016 at 16:33):
@Michael Donnelly I don't think it would be great to use a conformance endpoint to describe something other than a FHIR implementation.
Brian Postlethwaite (May 09 2016 at 16:34):
So I guess that's a +1 for it not being conformance then.
Josh Mandel (May 09 2016 at 16:36):
Where does Endpoint say whether it's a FHIR server, or an XDS server, or whatever?
Brian Postlethwaite (May 09 2016 at 17:09):
Some combination of payload format/type would be used, needs to be fleshed out in terms of defining the valueset bindings etc there.
Ewout Kramer (May 09 2016 at 17:28):
Has there been discussion whether we need FHIR to move into this space? We could use Conformance registries to do FHIR service discovery - do we really need to cover entereprise-wide discovery for services as well in FHIR? I am not strictly against it, but every resource added does have a cost in maintenance....
Elliot Silver (May 09 2016 at 17:29):
I don't think payload format/type works to describe the service type. An FTP server, or XDS server, or UNC path can return any type of payload. Actually, I think coding the service type is more useful than coding the payload type.
Elliot Silver (May 09 2016 at 17:32):
@Josh Mandel agree, but mine do. :-(
Brian Postlethwaite (May 09 2016 at 17:37):
This has come from the folks that are all working in the provider directory space (for the use cases listed in the draft resource - and sure there are more than I put in)
Brian Postlethwaite (May 09 2016 at 17:38):
And we have 1 implementation of it using Basic running in the USA
(In Australia we have another partial standard that covers this topic, and has been running for many years)
Lloyd McKenzie (May 10 2016 at 01:35):
It could be that we move some information out of Conformance and hang "FHIRConformance" as a resource off of EndPoint (allowing for the possibility of other things hanging off it in the future)
Brian Postlethwaite (May 10 2016 at 01:46):
Hmm.
Michael Donnelly (May 10 2016 at 12:57):
That makes some sense, @Lloyd McKenzie
Brad Genereaux (May 10 2016 at 14:10):
In terms of WADO-RS URLs (or WADO-URI or WADO-WS, for that matter), it's at the moment strategically unclear whether we would use Endpoint to point to study/series level only - or go all the way down to instance level (same discussions as been had in II previously).
Michael Donnelly (May 10 2016 at 14:11):
@Brad Genereaux , that sounds like a uri, not an endpoint.
Brad Genereaux (May 10 2016 at 14:16):
@Michael Donnelly No - it's a bit more complicated than that - as from that "endpoint", there's a lot that still can be tweaked by the caller (i.e., if we want just the metadata or a specific frame - which is tweaked on the URI itself). There's a "just the right level" that is still being worked out (how to be closest to endpoint and furthest away from uri).
Michael Donnelly (May 10 2016 at 14:17):
Interesting. I hadn't thought about it that way.
Richard Braman (FLY.HEALTH) (May 07 2021 at 22:18):
I want to ask the community some pressing questions in my mind about the Endpoint resource. Maybe hopefully this discussion will make interop better or at least let me understand the current practice.
First let me say that there is an effort by several organizations to publish a directory of Endpoints of all the FHIR servers in the clinical, payer, and other realms. FLY Health is developing an Endpoints resource that serves as such a directory: https://api.fhirfly.io/network/Endpoint. This is very much as WiP, but could become a resource for the community. I think there are many issues with having a single source of truth for endpoints; however we can broach that subject later/
-
If My App has different client id (and maybe secret) for each different API vendor (Cerner, Epic, Allscripts, Humana, Aetna, etc) how would Endpoint discovery tell the app which clientid to use to connect to an .address?
-
If my app looked to the Endpiont resource (maybe using .payloadType), could it understand that an endpoint was serving clinical data, payer data, SANER data, or something else?
Josh Mandel (May 07 2021 at 23:38):
Your (1) above suggests we have very different concepts of what an Endpoint directory is meant to accomplish. Why would an endpoint directory be in charge of "tell[ing an] app which client id to use"?
Richard Braman (FLY.HEALTH) (May 08 2021 at 00:01):
How else would the app know which client id to use? Enlighten me please.....
Richard Braman (FLY.HEALTH) (May 08 2021 at 00:02):
If the app knew server x was epic, the app would use its epic app client id.
Richard Braman (FLY.HEALTH) (May 08 2021 at 00:17):
here's some spec reference: https://www.hl7.org/fhir/managing.html#discovery "Client systems discover the 'current' set of relevant servers by querying a central location for the Endpoints for servers that carry relevant data for a particular community. As servers join or leave the community, the list of potential endpoints would change. Clients would discover relevant servers by querying for endpoints of particular types and then retrieve more information by looking up the CapabilityStatements for each server"
Richard Braman (FLY.HEALTH) (May 08 2021 at 00:18):
But if its a secure server that requires auth, how does the client app know which client id to use? I think this is a very straightforward question.
Josh Mandel (May 08 2021 at 01:04):
For example in current registration schemes, apps receive (from the vendor portal / registration process) a list of FHIR servers and client IDs/secrets at registration time. If new endpoints come online later, they'll need to request new secrets.
Richard Braman (FLY.HEALTH) (May 08 2021 at 13:50):
Josh, I think we are misunderstanding each other. I have registered my app with Epic , Cerner, Allscripts, and 20 other vendors. They each gave the app a client id for a sandbox. Are you saying that in production, each instance of an Epic FHIR server requires its own client id ? How would that ever be manageable for the app? If there are 5000 healhcare providers with 5000 fhir servers, how does an app manage 5000 client ids to let a user connect to the server of their choice?
Josh Mandel (May 08 2021 at 15:27):
This varies by vendor; with Epic a client gets a distinct secret for every endpoint it connects to.
Josh Mandel (May 08 2021 at 15:29):
So at the end of the day you need to choose an ID and a secret based on the actual fhir server URL. Generally that server URL will host metadata with additional information about the vendor; I could see populating the end point with something like that too.
Richard Braman (FLY.HEALTH) (May 09 2021 at 23:01):
Thats a real bummer Josh. This scales horribly for a Patient Access app with a large number of potential endpoints, especially when there is such a small number of vendors and this could be simplified. Is there any desire from other HL7 members to improve this?
Josh Mandel (May 09 2021 at 23:14):
That's a big component of what "FAST" is looking at; would check UDAP.org as an example example in this area.
Richard Braman (FLY.HEALTH) (May 10 2021 at 12:45):
I have read both FHIR at scale and UDAP. The problem with the former is that its findings haven't been mandated as final rules. And while FAST specifically addressed the Endpoint discovery question, it did not consider the client_id problem. UDAP has no teeth, even though DCRP would solve the client id problem if the app can specify its client id. But UDAP is not in any mandate, and as anyone in Health IT knows, the only things that get done are the things that are mandated by ONC or CMS, and even then, as in the case of C32 transitions of care, here we are 10 years after it started and it still has no meaningful use. The main problem is that no one really wants to share data, and these little blocks go unnoticed by most regulators who aren't technically proficient enough to identify them. Orgs can say "Look how open we are!", all the time realizing that connecting to their data is not going to happen at any real scale because of the blocks that are in place. I have designed a Patient Access app that works just like a browser. It has the World's greatest privacy policy (https://fhirfly.app/privacy) and doesn't store any user data other than on the user's local device. It is designed the way I would want it designed as a user to keep my health data private and between me and my doctor/insurance company. It will likely be years before it sees the light of day, because connecting to whatever health care provider I want as a user is not possible because of the very real blockers I mentioned in this thread. With all the time and money we have invested in this, that seems crazy, and honestly quite maddening. Sorry for the rant.
Craig McClendon (May 10 2021 at 14:40):
Forgive me if I'm misunderstanding something here, but wouldn't each application need to maintain its own lookup of servers it can communicate with and the details it needs to do so?
The client IDs will be specific to an application and could be rotated or expired. URLs could change, etc. Seems like each app will need to maintain it's own list.
That's not to say that a repository that has ALL known FHIR servers would not be useful to the community - it would. But you'd still need to maintain your own subset for the servers your app can communicate with.
Richard Braman (FLY.HEALTH) (May 10 2021 at 14:49):
craig , at scale interoperability means my app can communicate with any server that adheres to the FHIR standard. It is understood the app need to have a client id for the API, but the point is if there are 5000 client ids and secrets for one app, it wont scale. If the Endpoint could provide a hint as to what vendor backs the API, and the vendors agreed to have one client id for all the FHIR server endpoints they have in their stable, then the problem becomes much more manageable...
Richard Braman (FLY.HEALTH) (May 10 2021 at 14:51):
Josh, the only field I see in the Endpoint resource that could be used is Endpoint.header. If we could specify a server header like https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Server for the vendor it would solve one part of the problem. Then vendors would just need to agree to assign one client id across all their client's APIs.
Richard Braman (FLY.HEALTH) (May 10 2021 at 14:52):
Server: Allscripts Sunrise 18.4
Craig McClendon (May 10 2021 at 14:54):
I don't see the scalability problem. When the user chooses a server in the app, it calls your central API to get the current connection details and uses those for the session to query the FHIR server. If you are trying to avoid the need for a central API to store those details - I don't think that is realistic or likely secure. You'll want the ability to update things quickly - such as may be the case if an app id was compromised.
Richard Braman (FLY.HEALTH) (May 10 2021 at 14:57):
The question is how to make it more managable. Again, no doubt that the client has to maintain a configuration. Its about the manageability of that configuration .
Craig McClendon (May 10 2021 at 15:02):
What is unmanageable about making an API call like:
GET /myserverregistry/?server=stmarys787676313
Which checks your db and returns back the client ID and baseURL for that provider the user chose?
Richard Braman (FLY.HEALTH) (May 10 2021 at 15:06):
Well craig, there are almost 1 million active MDs in the US (nevermind internationally, plus 6,090 hospitals, plus plus plus). If each one is expected to have a FHIR server for 21c cures, and every vendor assigns a unique client id and secret for every app, that is a configuration problem.
Richard Braman (FLY.HEALTH) (May 10 2021 at 15:10):
The question is really are going to scale this thing we have all worked on so hard, or is it just a dream? I have 10 years invested in this. Community over Competition?
Richard Braman (FLY.HEALTH) (May 10 2021 at 15:13):
Craig if we used a server header in the Endpoint.header that identified the EHR vendor like GET /myserverregistry/?server=Allscripts+Sunrise+18.4, then the problem becomes much more manageable. Then a simple policy like Vendors shall only issue one client id to a registered app for all their production FHIR APIs, we actually have scale.
Richard Braman (FLY.HEALTH) (May 10 2021 at 15:17):
Well almost scale. The next issue is Source of Truth for Endpoints. Vendors are publishing their FHIR Endpoints on deep linked web pages , git hub repos (have a look at this one https://github.com/cerner/ignite-endpoints/issues/2 ), the information is out of date, wont be updated til next year. Come on guys, we can do better.
Josh Mandel (May 10 2021 at 16:27):
Having endpoints online and providing a way for apps to connect is a huge start, which is why it has been my focus for this first phase. By the time ONC's current rules are in effect, each vendor will have a list of endpoints published, and a process in place to register apps. I'm pretty confident in the ability of app developers to manage connections (at least that's something they can do without relying on outside parties to take action).
Richard Braman (FLY.HEALTH) (May 10 2021 at 23:17):
What do you think about the Server header in Endpoint.header?
It seems to fit the use of the field as described in the spec..
John Moehrke (May 11 2021 at 12:24):
The UDAP work is currently being brought into HL7. Thus you should engage with the UDAP sub-workgroup of the Security WG and help develop this into a system that you would agree with and that would function. The next tcon is today https://confluence.hl7.org/pages/viewpage.action?pageId=111124331
Richard Braman (FLY.HEALTH) (May 12 2021 at 16:22):
John, I went on the meeting yesterday but the call was cut off before the floor was open to ask about this.
Richard Braman (FLY.HEALTH) (May 12 2021 at 18:15):
craig mcclendon said:
What is unmanageable about making an API call like:
GET /myserverregistry/?server=stmarys787676313
Which checks your db and returns back the client ID and baseURL for that provider the user chose?
Hey Craig, instead of using a non FHIR endpoint to hold the client id of the app registered to a Server, I used the FHIR Device Resource:
https://api.fhirfly.io/network/Device/FHIRFLY
FHIRFLY comes from the Server Header set in Endpoint.
https://api.fhirfly.io/network/Endpoint?name=FHIRFLY
John Moehrke (May 12 2021 at 19:16):
@Luis Maas ?
Last updated: Apr 12 2022 at 19:14 UTC
