Chair: @Bryn Rhodes
Scribe: @Bryn Rhodes
Minutes Approved as Presented
Meeting Minutes from Discussion
|Decision Link(if not child)|
|Management||Minutes Approval||2019-09-25 Meeting Agenda|
Discussion on how to connect information between order-select and order-sign
Issue being addressed is avoiding duplicate alerting on an order if a decision support service is given the same medication in an order-select and an order-sign hook
One potential solution is the use of the URL in the card to provide an "identifier" for the recommendation that the EHR could use to ensure it's not displaying duplicates
Relevant links to the specification:
Relevant zulip discussion from the connectathon:
Use of the PlanDefinition Documentation URI is great for providing information back to the clinician and calling system about the source of the recommendation, but it's not clear that the EHR has enough information to support making the decision about whether the card should be shown as a "duplicate". In Hooks "Source" rather that "Link" might be a better attribute to utilize.
Concern from the service side is that adding state tracking to the service significantly complicates the logic and service implementation, and potentially introduces unintended consequences (i.e. how long should a dismissed recommendation be ignored?). Could filtering be used to reduce noisy alerts? Yes but that puts the burden on the institution to configure services and systems. Autofiltering by the client potentially leads to legal concerns - arguments pro and con for why the CDS service should do this.
One option is to use the existing CDS Hooks mechanisms (such as extension configuration (see http://hl7.org/fhir/us/davinci-crd/2018Sep/hooks.html#configuration-options) ) to support user and institution configuration for filtering based on numerous features of the PDDI CDS.
Configuration option is a good potential approach, will consider how that can be incorporated in the PDDI IG.
Overwhelming feedback is to make the decision support service smarter
Could card UUID be used instead? As in the CDS service could return a card that had previously been delivered and the EHR would know to "replace" it. Larger discussion about card lifecycle.
Link to slides presented: REDUCED-update-to-HL7-CDS-and-Pharm-WGs-09182019.pptx
FHIR Tracker Items
[#24619](https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=24619&start=0) - Rename RequestGroup to RequestOrchestration
Needs more discussion, will post to Zulip
[#24675](https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=24675&start=0) - Searching for unmitigated DetectedIssue
[#24617](https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=24617&start=0) - Ability to reference a goal in RequestGroup
[#24618](https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=24618&start=0) - Support definitional participants in RequestGroup
[#23876](https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=23876&start=0) - Change clinical-protocol to protocol
[#24432](https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=24432&start=0) - Revising Clinical Reasoning Module to update Evidence and related Resources
|Committee would like time to review|
|Adjournment||Adjourned at 11:00|