Discovery service Response to include full URL of CDS service

[Gokulm84]

Hi, In the discovery service response, the {id} specifies portion of the URL. {baseUrl}/cds-services/{id} Is there a reason why I cant return a "Full URL". The discovery service may return a list of available CDS-Hooks services in the market, not necessarily with in the same domain ({baseurl}). If {id} cant be used for that purpose can we introduce a optional parameter {url} for this purpose?

[kpshek]

By design, the Discovery endpoint and the CDS Service endpoint are to be deployed to the same base URL. This aids in our security/trust model as the Discovery endpoint is only able to advertise services hosted on the same domain. If the domain used for Discovery differs from that of the CDS Services advertised in /discovery, now CDS Clients must verify the domain of those endpoints again.

Keeping everything on the same base URL aids in both simplicity of our security model as well as making the understanding of the URL paths predictable for all.

Out of curiosity, can you clarify your question with a concrete example of the Discovery and CDS Service URLs you want?

[Gokulm84]

In a large organization, there might be multiple products offering CDS services. Few services may be internally Hosted on Private cloud and some service on Azure/ AWS. EHR's need one Discover service which provides the list of available CDS services. Now how would I solve this problem. Also, We have a scenario where we have few internal cds-services and few we partnered with third party vendors. We want to maintain the list of CDS-services and a single discovery service. { "services": [ { "hook": "patient-view", "title": "Static CDS Service Example", "description": "An example of a CDS Service that returns a static set of cards", "id": "static-patient-greeter", "prefetch": { "patientToGreet": "Patient/{{context.patientId}}" } }, { "hook": "medication-prescribe", "title": "Medication Echo CDS Service", "description": "An example of a CDS Service that simply echos the medication being prescribed", "id": "https://vm1.azure.com/cds-services/medication-echo", "prefetch": { "patient": "Patient/{{context.patientId}}", "medications": "MedicationRequest?patient={{context.patientId}}" } , { "hook": "medication-prescribe", "title": "Medication Echo CDS Service", "description": "An example of a CDS Service that simply echos the medication being prescribed", "id": "https://thirdpartyvendor/cds-services/medication-echo", "prefetch": { "patient": "Patient/{{context.patientId}}", "medications": "MedicationRequest?patient={{context.patientId}}" } } ] }

[kensaku-kawamoto]

Can’t one just create a Web page or equivalent that points to all the endpoints and shows the info?

Ken

================== Kensaku Kawamoto, M.D., Ph.D., M.H.S. Associate Chief Medical Information Officer Vice Chair for Clinical Informatics, Department of Biomedical Informatics

On Feb 13, 2019, at 9:25 AM, Gokulm84 notifications@github.com<mailto:notifications@github.com> wrote:

In a large organization, there might be multiple products offering CDS services. Few services may be internally Hosted on Private cloud and some service on Azure/ AWS. EHR's need one Discover service which provides the list of available CDS services. Now how would I solve this problem. Also, We have a scenario where we have few internal cds-services and few we partnered with third party vendors. We want to maintain the list of CDS-services and a single discovery service. { "services": [ { "hook": "patient-view", "title": "Static CDS Service Example", "description": "An example of a CDS Service that returns a static set of cards", "id": "static-patient-greeter", "prefetch": { "patientToGreet": "Patient/{{context.patientId}}" } }, { "hook": "medication-prescribe", "title": "Medication Echo CDS Service", "description": "An example of a CDS Service that simply echos the medication being prescribed", "id": "https://vm1.azure.com/cds-services/medication-echo", "prefetch": { "patient": "Patient/{{context.patientId}}", "medications": "MedicationRequest?patient={{context.patientId}}" } , { "hook": "medication-prescribe", "title": "Medication Echo CDS Service", "description": "An example of a CDS Service that simply echos the medication being prescribed", "id": "https://thirdpartyvendor/cds-services/medication-echo", "prefetch": { "patient": "Patient/{{context.patientId}}", "medications": "MedicationRequest?patient={{context.patientId}}" } } ] }

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/cds-hooks/docs/issues/463#issuecomment-463265678, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFrPEMwpQqWot6v-oW652giKsD6zNUcjks5vNDyCgaJpZM4a4RRy.

[Gokulm84]

Our intention is not to display all the available services rather provide the configuration for EHR. Below is the workflow we are trying to achieve

1. EHR calls Discovery service
2. Based on the trigger points, lets say the action is "order-review", EHR's gets the list of available services for "order-review" hooks from the discovery service response.
3. EHR fire the requests in parallel for each CDS services.
4. Cards returned by each service is displayed.

My issue is very simple, Why cant I use the full urls in case of my example? I understand the security concerns around it. Other than that is there a reason no to use full urls?

[dennispatterson]

There's a subtle difference here in the purpose of what is meant by discovery. The discovery service's primary purpose is allowing an EHR to discover all CDS services that exist at a particular endpoint, not for an EHR to discover all CDS services it supports.

It sounds like what's missing in your implementation is a directory or other means to catalog the whitelist of CDS service endpoints supported by your EHR. You may look at using the discovery endpoints out-of-band at registration time and then have your implementation keep track of the whitelisted services it should call for a given hook.

[Gokulm84]

There's a subtle difference here in the purpose of what is meant by discovery. The discovery service's primary purpose is allowing an EHR to discover all CDS services that exist at a particular endpoint, not for an EHR to discover all CDS services it supports.

It sounds like what's missing in your implementation is a directory or other means to catalog the whitelist of CDS service endpoints supported by your EHR. You may look at using the discovery endpoints out-of-band at registration time and then have your implementation keep track of the whitelisted services it should call for a given hook.

Just to be clear we are not EHR. we are CDS service provider with multiple CDS services ( both internal and partnered with 3 rd party services) AS you mentioned, I want our discovery service to provide a list of all available cds-services(not just on one end point, but multiple endpoints) to the caller.

[dennispatterson]

EHR or not, this seems to be conflating a directory of multiple endpoints with the discovery of services at a single endpoint. I still recognize that you have a problem you're trying to solve...just not sure the discovery endpoint is the right mechanism.

What are your thoughts on addressing the implied security/trust model challenges that would result with your proposal?

[anshunigam]

EHR or not, this seems to be conflating a directory of multiple endpoints with the discovery of services at a single endpoint. I still recognize that you have a problem you're trying to solve...just not sure the discovery endpoint is the right mechanism.

What are your thoughts on addressing the implied security/trust model challenges that would result with your proposal?

Thanks, are you thinking risk that discovery service get compromise and may return malicious endpoints?

[dennispatterson]

A CDS Client is establishing trust with a Service provider at a particular domain. The discovery endpoint lists what services are offered at that domain. If the discovery endpoint is instead a directory pointing to different domains, the client isn't going to feel comfortable calling arbitrary domains that are knowingly or unknowingly listed. The client has to work to establish trust with each of those other domains.

I'd encourage you to either (a) register each of these separate domains (and their own discovery endpoints) with the CDS Client or (b) stand up an API Gateway-style solution that presents the CDS Services under one domain and abstracts away the underlying hosting model.

[isaacvetter]

@Gokulm84 - I'm closing this issue, because it sounds like the issue was meaningfully discussed and alternatives were identified.

Re-open if you disagree.

Isaac