Should CDS Services indicate the FHIR version they require?

[kpshek]

CDS Services will undoubtably be coded to a particular version of FHIR. Should they expose the expected FHIR version as part of the discovery endpoint?

Production EHR vendors will likely support multiple versions of FHIR. If an EHR knows what FHIR version the CDS Service excepts, it can invoke the service with the appropriate FHIR URL.

This is analogous to what Cerner is doing today with their support of SMART apps. The Cerner system stores the FHIR version the SMART app expects and uses this information when launching SMART apps to send it the desired FHIR URL for the expected FHIR version. Note that this is not part of the SMART specification but an out-of-band step that is being done. However, with our discovery endpoint in CDS Hooks, we have an opportunity to formally define this.

(Logging this here for discussion at the HL7 Connecthaton in Baltimore Sept 17-18, 2016)

[jmandel]

I think it's a natural thing to include in the discovery endpoint.

We might make it an array-valued field to support CDS Services that know how to handle >1 version of FHIR — but I'd rather just say: if your service covers this, then you should expose two discovery documents and two entry points to your services.

[kpshek]

In discussion with @brynrhodes and @isaacvetter, we discussed that we shouldn't address this issue at this time given the flux/uncertainty of how FHIR will be handling versions, especially with how versioning may differ between resources in the future.

Given that the community has agreed that there will be manual integration work between an EHR and CDS Service provider (see discussion in #15), this will be handled during that integration work.

As such, we agreed that we should defer this issue post 1.0 and until we know how FHIR will approach versioning.

[mattvarghese]

I would like to request 'un-deferring' this issue. Right now, there is no version anywhere. So if I have a CDS Service, and a client sent me a request, how do I tell if the prefetch is using DSTU2/STU3/R4 resources, without hitting the FHIR metatdata endpoint unnecessarily? I think we are at a point where the standard is mature enough that this question should probably be addressed.

If I've missed other discussions around this, my apologies. However, I would like to request that there be the list of versions supported at the discovery endpoint, and the specific version being sent included in the CDS Hook request.

[mattvarghese]

Bumping this issue up based on the discussion on Zoom today at the May 2020 Virtual Connectathon. We should add supported version to the discovery endpoint documentation, and version in use to the CDS Hooks request, and possibly also the response though the response should not use a different version than the request.

[dennispatterson]

Zulip conversation - https://chat.fhir.org/#narrow/stream/179159-cds-hooks/topic/Specifying.20the.20FHIR.20version

[dennispatterson]

A year later, this discussion came up again at the May 2021 Virtual Connectathon. :)

Services are handling this by setting up separate base urls devoted to a specific version or separate service ids devoted to a particular version. One CDS Service provider shared that their CDS Service is essentially the same behind the scenes but they have to do this to know which version is being used.

CDS Clients handle this out of band at registration time, configuring specific endpoints for specific versions.

If FHIR version were to be included in payloads, it should be done in two places:

• Allow CDS Services the ability to advertise the FHIR Versions (plural if applicable) that an endpoint supports on discovery endpoint, if nothing else than to expedite registration and remove the question from having to be asked by a human or the need to infer based on human interpretation of url or service naming
• Have CDS Clients send the FHIR version along with hook invocation so that if a CDS Service would like to have a single point of entry, it becomes possible. CDS Services are still free to dedicate base urls or service ids to particular FHIR versions if they desire.

Lastly, note that if a CDS Service advertises a particular FHIR Version, there must be consistency across hook context, prefetch data, and any querying back into the FHIR server. This is not intended to enable or promote mixing versions.