Skip to end of metadata
Go to start of metadata

Chair:  @Bryn Rhodes

Scribe: @Bryn Rhodes


Attendees


Minutes Approved as Presented 

X

Agenda Topics

Agenda Outline

Agenda Item

Meeting Minutes from Discussion

Decision Link(if not child)
Management Minutes Approval2019-09-25 Meeting Agenda
Methodology

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:

https://cds-hooks.org/specification/1.0/#source

https://cds-hooks.org/specification/1.0/#link

Relevant zulip discussion from the connectathon:

https://chat.fhir.org/#narrow/stream/179159-cds-hooks/topic/September.202019.20Connectathon

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 (smile)

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

https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Rename.20RequestGroup.20to.20RequestOrchestration



[#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




Management

 Next agenda

  • CDS Hooks STU Update Review/Vote
  • FHIR Tracker Items


 Adjournment
 Adjourned at 11:00

Supporting Documents

Outline Reference

Supporting Document

Minute Approval


Tasks

  •