FHIR Chat · docs / Issue #74 CDS Hooks Version for a Service · cds hooks/github

Stream: cds hooks/github

Topic: docs / Issue #74 CDS Hooks Version for a Service

Github Notifications (Aug 04 2017 at 13:12):

bkaney edited Issue #74

Are there any thoughts on how to advertise/handle the CDS Hooks service version?

This could be handled as part of the service discovery -- e.g. include the version as an attribute in the cds-services payload.

{
  "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",
      "cds-hooks-version": "1.0.0"
    }
  ]
}

Github Notifications (Aug 08 2017 at 13:07):

robs16 commented on Issue #74

I agree that the version of CDS Hooks is relevant. However wouldn't that also potentially impact the fields/etc in the discovery endpoint? Do you see mixing versions of cds hooks (ie 2 services, 1 with hooks v1 and another with hooks v2)? If not, perhaps it should at the same level as "services". This should probably also align with how to represent the FHIR version that the service supports - #3.

Github Notifications (Jan 29 2018 at 20:49):

olbrich commented on Issue #74

possible options:

1. version the api url.. [base_url]/v1.0/cds-services and then redirect [base_url]/cds-services to the latest version available. Not great since it ties you to a particular url, but it's not terrible since it's unlikely that others will be storing the URL in a large number of places.
2. add cds-hooks-version to the cds-service definition. Also not great because you need to parse the definition in order to find out what version it needs.
3. use the Content-Type / Accept header approach to negotiate a mutually supported version between the client and server.

see #154

Last updated: Apr 12 2022 at 19:14 UTC