Skip to end of metadata
Go to start of metadata

Chair:  @Bryn Rhodes

Scribe: @Bryn Rhodes


Minutes Approved as Presented 


Agenda Topics

Agenda Outline

Agenda Item

Meeting Minutes from Discussion

Decision Link(if not child)
Management Minutes Approval2019-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 ) 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]( - Rename RequestGroup to RequestOrchestration

Needs more discussion, will post to Zulip

[#24675]( - Searching for unmitigated DetectedIssue

[#24617]( - Ability to reference a goal in RequestGroup

[#24618]( - Support definitional participants in RequestGroup

[#23876]( - Change clinical-protocol to protocol

[#24432]( - Revising Clinical Reasoning Module to update Evidence and related Resources

Committee would like time to review


 Next agenda

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

 Adjourned at 11:00

Supporting Documents

Outline Reference

Supporting Document

Minute Approval