Stream: cds hooks
Topic: Discovery Endpoint
Matt Varghese (May 13 2020 at 23:10):
How are folks using the discovery endpoint?
For some leading questions on what I'm trying to get at from the above:
- From the service side - do you dynamically adapt or change what is returned based on properties of the request?
- From the client side - when and how often do you query the discovery endpoint? Who or on whose behalf do you do that (for example: app store manager / hospital analyst / physician end user)? Do you query it at the global level and see new services etc., or do you query it at a service level only to get properties of a specific service?
There was a discussion after the CDS Hooks track kickoff, where we started with whether the discovery endpoint should be behind JWT Authentication or not. And this led to an attempt to try to understand how discovery endpoint is being used in the real world.
Steve Millard (May 14 2020 at 12:02):
As a service, our service discovery endpoint sits behind an authentication layer. Configuration would be required for a client to use our services. Our response could change based on what was in the request and the result of business logic used to process the request.
Chuck Feltner (May 14 2020 at 13:23):
As a client, we call the discovery endpoints at startup to determine the available services and get the requested prefetch information for each service. We are using it in production in this manner.
Dennis Patterson (May 14 2020 at 13:37):
Chuck, if a CDS Service publishes new services on their discovery endpoint as well as changing prefetch requirements, does this mean you dynamically pull in these changes during a start-up event? i.e. you automatically start calling the new services in prod during a hook event they're interested in, as well as adjusting to any prefetch changes?
Chuck Feltner (May 14 2020 at 13:52):
Dennis, yes to some extent. In our administration setup for CDS Hooks, for each allowed CDS Service we specify their base URL, auth clientId, hooks they are allowed to call, and scopes allowed for prefetch. So there is still some coordination needed. It has been used where the CDS Service decided they also needed an additional FHIR resource so they updated their prefetch information and we granted the additional prefetch scope.
Dennis Patterson (May 14 2020 at 15:05):
administration setup sounds like manual work. Part of this discussion about discovery endpoint is getting a feel for how much of the discovery endpoint is used at CDS Client runtime to dynamically flex vs more administrative/manual config
Chuck Feltner (May 14 2020 at 16:03):
Yes, the manual work is dealing with the granting of authorization. The parts of the discovery endpoint that are treated dynamically are the service id and the prefetch.
Dennis Patterson (May 14 2020 at 16:06):
if a CDS Service endpoint trusted by T-System adds another service to its discovery endpoint that also listens for patient-view, will that automatically start being invoked in prod?
Raj M (May 14 2020 at 16:52):
As service, we do dynamically adapt and change our response based who is calling. who is calling is determined by jwt [combination of one or more of the following: tenant , issuer and jwk uri ]
Raj M (May 14 2020 at 17:09):
The core value of Discovery Endpoint is realized if it used dynamically by the CDS clients. On a related note, as a hooks service provider we do use contents defined in discovery end point (dynamically for every incoming request to us) in addition to serving the same through discovery endpoint
- to establish link between a particular service id and jwt variables (tenant, issuer and jwks uri) to validate (authorization and authentication ) hooks request
- use prefetch definition for our needs to check on the prefetch data completeness and do additional fhir query to get the clinical data
So we have the need to maintain discovery endpoint like content irrespective of the requirement to expose discovery end point to cds client or not
Dennis Patterson (May 15 2020 at 13:44):
Within the bounds of the spec, yes clients should be sending the JWT for all calls to the CDS Service endpoint. Given that, the following could be true:
The CDS Service can then
- vary the services advertised in discovery
- adjust prefetch definitions if there are subtle client differences such as custom query parameters
- track/whitelist calls from CDS Clients ('iss') and optionally for specific tenants
Dennis Patterson (May 15 2020 at 13:45):
What I'm trying to understand is industry assumptions around responsiveness to discovery endpoint updates after initial client registration.
- A CDS Service could update its prefetch requirements. A CDS Client could then be responsive to pull in those changes
- A CDS Service could change the id for a service or introduce a new service for a client-supported hook. I'm curious what the expectations are or existing behavior is for this behavior?
Last updated: Apr 12 2022 at 19:14 UTC
