FHIR Chat · docs / Issue #15 cds-service discovery · cds hooks

Stream: cds hooks

Topic: docs / Issue #15 cds-service discovery

Github Notifications (Apr 25 2017 at 09:25):

kpshek commented on Issue #15

@olbrich - My apologies for not commenting on this issue much earlier.

I agree with you in that CDS services (when possible), should utilize a progressive enhancement approach to their functionality. That is, the CDS service makes every attempt to work with the FHIR capabilities of each EHR.

We've been working under the assumption that the EHR is solely responsible for determining which CDS services they consume or integrate with. This includes likely offline coordination between the CDS service provider and EHR. I see your viewpoint though that in order to remove manual coordination, the CDS service would need to be able to advertise the FHIR resources it requires.

One way to do this would be to pass the iss parameter in the Discovery request to the CDS service (/cds-services) like you suggested. The complication here is that some EHRs will support multiple FHIR versions so the EHR would need to call Discovery for each FHIR version they support.

Another way to do this would be for the CDS service to list the FHIR resources it needs in the Discovery response. However, this provides a more coarse grained view and doesn't get into the specific fields that the CDS service may require on each FHIR resource.

Taking a step back, we have this exact same concern today with SMART on FHIR. That is, EHRs have no way of knowing if a given SMART app will work based on the current FHIR capabilities of the EHR. However, this hasn't been an issue due to the aforementioned offline coordination between the EHR and SMART application. Barring this offline coordination, the SMART app needs to either utilize a progressive enhancement approach (as you mentioned) or communicate to the user that it requires data which isn't available. I think the same is true for CDS services.

My thoughts are that we don't make any changes for the time being regarding this for the following reasons:
- We're relying on that offline coordination -- both within CDS Hooks and SMART on FHIR
- CDS services should utilize a progressive enhancement approach. If required data is not available, it can communicate that to the user via a card (this also may relate to our errors discussion in #14)

Github Notifications (Apr 25 2017 at 09:27):

kpshek edited 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-services to include an iss parameter.

Last updated: Apr 12 2022 at 19:14 UTC