CDS Hooks Dynamic Behavior

[bvdh]

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:

1. All hooks, except order-select are requested once. Order-select CDS services are recalled when the order changes. The new cards will replace the existing ones.
2. CDS services are ordered in a list. The first server is called and the cards are shown. When the user closes this card, the next CDS Server will be called
3. All CDS Services are updated when the context changes.

Card behavior

1. All cards remain in place, additional CDS calls will add new cards to the list.
2. Cards are only removed when this is explicitly done by the end-user
3. Cards are removed when a suggestion is followed.

The specification does not state what the expected behavior is. What is the expected behavior?

[bvdh]

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:

1. The current spec has very limited support for Cards that require updates depending to changes in the scratch-patch of the CDS-Client.
2. Ideally, a CDS Service should be re-run when the related data changes.
3. 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 #503

A 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:

1. 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.

2. 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.

[brynrhodes]

Part 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.

[bvdh]

Yes, but I think that this is not sufficient and that further specification in line with is mentioned above is required.