Repository navigation
CDS Hooks Dynamic Behavior #504
Description
Activity
Some further thoughts on this issue
Key use cases
Some key CDS-Hooks use cases include:
Show card based on FHIR data
A card is shown that is based on data from the FHIR repo. If FHIR data the advice is based on changes (in the CDS-Client memory). Is the Card updated? What triggers updating of cards?
Multiple cards relate to the same FHIR/context data
Multiple cards, from multiple CDS-Services relate to the same FHIR/context data. The CDS-Client decides to update information a CDS Sever depends upon, an update to the resource(s) will be present in the scratch-patch of the CDS-Client/EMR. Cards may still refer to the old data and would be invalid.
How do we detect this and update the related Cards?Card suggestion is overruled
A Card is presented that provides a suggestion that solves an issue. The Suggestion is followed. Later another change overrides that suggestion causing the original issue to re-appear. How do we trigger/determine that the CDS-Service needs to be queried?
Same advice is given from multiple hooks (PDDI)
This came up in a CDS working group call and is related to this issue.
A CDS-Service is called multiple times using different hooks. Similar advice is given on different hooks. How to prevent showing the same advice multiple times?Issues to resolved
This behavior results in the following issues:
- The current spec has very limited support for Cards that require updates depending to changes in the scratch-patch of the CDS-Client.
- Ideally, a CDS Service should be re-run when the related data changes.
- The specification should have a mechanism that prevents the same advice from appearing several times.
Possible approaches/solutions to these issues
Prevent the same advice multiple time.,
The issue of multiple Cards from the same service could addressed by introducing the following change:
- Add an optional adviceId to a Card
- Only the last Card with the same adviceId is to be shown. New cards override the old one.
- An empty Card, only holding an empty summary, an adviceId and source field, indicates the card should be removed.
Trigger a CDS-Service recall
Hooks are defined with a context they act on. One way of handling this would be to recall the service when the context of the hook changes. This is how the order-select and order-sign are defined.
So far as I understand, all other hooks except patient-view are deprecated in favor of order-select and order-sign. Although less important to order-select and order-sign, in the case the advice is based on other Resources this issue also applies. A comment on this specific for patient-view has been filed in #503A solution could be to re-run the CDS-Service when data that corresponds to the prefetch changes (in the scratch-patch) and provide access to the changed data. This could be defined as a new hook .
This hook should hold two new elements:-
An explicit or implicit definition of on what scratch-patch change the hook is triggered, e.g.
- a FHIRpath expression that uses the scratch-patch as a transaction bundle as input - including a change field
- List basic FHIR search expressions that operate on scratch-patch - when result changes - recall and include the data.
-
Indicate what data from the scratch-patch should be included in the CDS-Service call, e.g.
- A REQUIRED field with a prefetch like search expression - if the result changes - recall the CDS-Service.
- A FHIRpath expression that operates on the scratch-patch, include the result of the FHIRpath expression.
The use of FHIR-path in such situations is also discussed in #6.
Reacted by César NascimentoPart of a potential resolution here is to add documentation around concurrency expectations and the potential issues associated with inferencing on outdated data to the Security & Safety discussion in the specification.
Reacted by César NascimentoYes, but I think that this is not sufficient and that further specification in line with is mentioned above is required.
In various discussions during the Connecthaton and over the last weeks a noticed a large difference in the approach to the CDS Hooks Card dynamics.
Some of the variations observed include:
Card behavior
The specification does not state what the expected behavior is. What is the expected behavior?