Stream: cds hooks
Topic: Introduction of unsupported elements by an update
Lloyd McKenzie (Aug 09 2018 at 16:57):
Is it legal for an update to introduce an extension/core element that the client doesn't support? Or more specifically, should we explicitly indicate that clients should watch for this and potentially suppress suggestions/cards that would result in changes they can't execute?
Isaac Vetter (Aug 09 2018 at 16:59):
Extensions should be ignored, per FHIR, right?
Core elements are tougher ...
Lloyd McKenzie (Aug 09 2018 at 17:01):
Any element you don't support can be ignored unless it's a modifier (in which case you need to look at where it is)
Lloyd McKenzie (Aug 09 2018 at 17:01):
The question is whether it's ok to display an option to a provider and have them click on it, only to have the EHR not actually do what the option said.
Lloyd McKenzie (Aug 09 2018 at 17:01):
(Or at least not completely...)
Lloyd McKenzie (Aug 09 2018 at 17:02):
If the narrative from the hook service is retained, ignoring elements may be less critical, so this is slightly related to the thread I raised on narrative.
Isaac Vetter (Aug 09 2018 at 17:21):
ack, wrong thread.
Isaac Vetter (Aug 09 2018 at 17:24):
In practice, I'd expect the CDS service to not send me FHIR resources that I can't understand. That's maybe naive. Could the EHR's FHIR server's CapabilityStatement statement help the CDS service understand what's possible?
Lloyd McKenzie (Aug 09 2018 at 17:26):
It could - but only if the CapabilityStatement included profiles for each supported resource. And the tricky bit is that might vary by context. If you manage chemotherapy orders separately from regular prescriptions, you might support more elements/extensions in your chemo module than you do in the other module. CapabilityStatement won't help there.
Lloyd McKenzie (Aug 09 2018 at 17:26):
(CapabilityStatement profiles by resource are optional. Not sure how many systems are currently exposing them.)
Kevin Olbrich (Aug 09 2018 at 18:40):
I'd think the service provider would put together an ImplementationGuide for their service and the EHR would look at that and make a determination how/if to support that service prior to installation.
Lloyd McKenzie (Aug 09 2018 at 18:54):
Maybe. That's certainly outside any expectation documented in the Hooks specification so far. There's also the question of evolution of both the hook service and the EHR client. While making sure things are smooth at design-time should always be the objective, having a runtime check to avoid problems seems wise to me.
Kevin Olbrich (Aug 09 2018 at 20:45):
Agreed
Robert Sax (Aug 13 2018 at 10:38):
Based on our experience, an implementation guide by the service provider is necessary in any case - there are too many details which are not part of the specification to support a consumer building an interface to the service. To augment it, we have provided an extension to each discovery service for CapabilityStatements which describe the resources and fields which our service depends on for prefetch/context/FHIR data gathering requests. Given the above scenario, it might help to have separate CapabilityStatements on covering what we may create or update.
Isaac Vetter (Aug 13 2018 at 15:56):
we have provided an extension to each discovery service for CapabilityStatements which describe the resources and fields which our service depends on for prefetch/context/FHIR data gathering requests
@Robert Sax - wow!
When you say CapabilityStatement, do you mean that ya'll are extending your discovery endpoint with extensions to describe capabilities OR that you're extending a FHIR CapabilityStatement resource to describe your CDS Hooks services' capabilities?
Robert Sax (Aug 13 2018 at 16:06):
The discovery endpoint has extensions which provide a URL for the CapabilityStatement for each service. The CapabilityStatement describes the set of FHIR resources our service consumes, and for each the set of fields that we use. We did not extend CapabilityStatement to describe the CDS Hooks services' capabilities.
Isaac Vetter (Aug 13 2018 at 17:22):
Robert - that's really neat. May I ask if there was a production / customer need to do this? Is this being used? Or rather, are ya'll going above and beyond by programmically describing your service/app's FHIR requirements.
In practice, I've seen lots of SMART apps but precious few of them have created CapabilityStatements that define their requirements.
Robert Sax (Aug 13 2018 at 17:45):
I guess a bit of both (need vs above/beyond). As a service provider, we want more integrations. To support this with limited resources, it would be ideal to have a very detailed implementation guide/specification to help the integrations move forward. CapabilityStatements by themselves cannot take the place of an implementation guide, but do provide a detailed look at the data we need or will use if provided, which may change on a service-to-service basis or even a client-to-client basis. It is clear that many EMR vendors implement partial FHIR support (ie not all resources, subset of fields, etc), so this helps both them and us understand where work needs to be done to make the integration successful.
David Hay (Aug 20 2018 at 20:57):
is this the {baseURL}/cds-services endpoint? Interested how you added extensions as it doesn't return a FHIR resource... (or did you simply add extra elements to the service description?
Isaac Vetter (Aug 21 2018 at 18:38):
Hey David, CDS Hooks defines a really simple extension capability, see: https://cds-hooks.org/specification/1.0/#extensions
Last updated: Apr 12 2022 at 19:14 UTC
