Open bvdh opened 5 years ago
Some key CDS-Hooks use cases include:
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, 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?
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?
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?
This behavior results in the following issues:
The issue of multiple Cards from the same service could addressed by introducing the following change:
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:
An explicit or implicit definition of on what scratch-patch change the hook is triggered, e.g.
The use of FHIR-path in such situations is also discussed in #6.
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.
Yes, 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?