FHIR Chat · docs / Issue #74 Communicate CDS Hooks specification version · cds hooks/github

Stream: cds hooks/github

Topic: docs / Issue #74 Communicate CDS Hooks specification version

Github Notifications (Mar 26 2018 at 06:00):

kpshek 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 (Mar 26 2018 at 10:44):

robs16 commented on Issue #74

I'll disagree that we don't need to address this today as Stanson Health's solution is already providing multiple versions in production. The reality that the movement of the standard is rather slow, resulting in either un-official versions (which I have 2 of now) or extension needs which get augmented over time both on the caller and service ends. For example, the change from patient and encounter in the main request to being part of the context was a significantly breaking change - I realize the spec isn't official yet, but not allowing early implementations (and thereby multiple versions) leads to a chicken and the egg problem. At the moment URL differences are used, in part to allow easy movement by the EMR from one version to the next with minimal support by the service as well as supporting 'custom' versions on a one-off basis.

With respect to every call containing the Hooks specification, I believe this still should require the version(s) supported shown in the discovery or via some other mechanism. Ideally that would be coupled with the specification details in some form, such that an implementer could access those details and build their interface to the service without additional documentation.

As mentioned above, this and the FHIR version (which we certainly have 2 standards and both in production to various degrees) should be implemented similarly.

Ultimately I don't think this is a particularly hard issue to solve, and I really don't see it as controversial - unless the standard is a dead-end, there will be multiple versions.

Github Notifications (Mar 26 2018 at 13:52):

bkaney commented on Issue #74

FWIW, since the return of the discover call is also subject to variations across CDS Hooks versions, I'd opt to expose the version as an HTTP Header.

Github Notifications (Oct 01 2018 at 18:32):

mattvarghese commented on Issue #74

I just want to add here that we are also now affected by this. We have released code where user is at the top level. However, user has now been moved to the context. Yet there is no version or any kind of differentiator we can include to allow the CDS Service to determine whether the payload has this change or not, (short of looking to see where the user is).

So adding myself also on the list of affected parties requesting some capability on this front.

Last updated: Apr 12 2022 at 19:14 UTC