Stream: cds hooks
Topic: docs: issue 15: cds-service discovery
Github Notifications (Jan 14 2017 at 22:15):
olbrich opened issue 15
When it comes to service discovery, it may make sense for the CDS service discovery endpoint to interrogate the CapabilityStatement of the EHR that is attempting service discovery.
This would allow a service discovery endpoint to be able to determine if the EHR in question supports the necessary FHIR resources and is of an appropriate version to successfully interact with the CDS service and filter out responses as necessary.
This might require calls to
/cds-servicesto include an iss parameter.
Github Notifications (Jan 14 2017 at 22:15):
olbrich edited issue 15
Github Notifications (Jan 14 2017 at 22:37):
Penumbra69 commented on issue 15
You're proposing a negotiated 2-way capability handshake?
As I understood it, discovery is really one way: Designed for the configured EHR to discover what Hooks / capabilities the services URL have available (allowing the endpoint server / service to be modified/added to without impacting the EHR at all.)
You are saying you'd like that to go both ways?
I just wonder, given the current implementation design flow, how a URL for a CDS-Hook server got into the EHR without the EHR being able to support it. If we were talking about placing a CDS-Hook URL in a centralized "discovery" server that the EHR had never seen/used/been configured for -this makes sense.
Do you have a specific use case in mind?
Github Notifications (Jan 14 2017 at 22:46):
As a provider of CDS services, it makes sense for me to have a url that describes all of my services. Multiple integration partners would want to interrogate the same url and each should only get back a list of services that are compatible with their EHR.
This also allows me to take a progressive enhancement approach. For example.. if I have an integration partner that is in the process of implementing several FHIR resources, I won't advertise a service to them until they have implemented the capabilities that are required to successfully use the tool.
Github Notifications (Jan 14 2017 at 22:53):
Penumbra69 commented on issue 15
Help me - what am I missing here?
From my perspective - If an EHR can't consume a hook because it hasn't been configured to do so - it therefore wouldn't call the hook it doesn't recognize, right?
My spitball thought experiment:
If 3 servers A, B, C called the same hooks service endpoint (call it Q) with hooks 1, 2, 3, 4, 5.
Let A recognize hooks 1, 2
Let B recognize hooks 1, 3
Let C recognize hooks 4, 5How would A be troubled by 3, 4, 5 - similarly B with 2, 4, 5 and C with 1, 2, 3?
They wouldn't recognize the hooks they didn't configure, and just wouldn't call on the service for them - right? Are you concerned that they would, and in turn break because they weren't prepared?
Last updated: Apr 12 2022 at 19:14 UTC
