- Created by Gayathri Jayawardena, last modified on Jan 16, 2023
Short Description | Continue the testing and use of FHIR-based Quality Measures for use in Quality Measurement programs, including CMS, Gaps in Care (GIC) and Clinical Decision Support (CDS) Use Cases. The focus of this connectathon will be to:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Long Description | The Clinical Reasoning Track will continue focused testing of quality measures using data available from USCore 3.1.1 compliant FHIR servers:
There will also be tests of potential drug-drug interaction clinical decision support (PDDI CDS) at three points in the CPOE workflow:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Type | Test an Implementation Guide | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Related Tracks? | Care Planning, Public Health, CDS Hooks, Da Vinci DEQM Gaps in Care and Vulcan Schedule of Activities | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Call for participants | Providers, Payers, and other related HIT vendors | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Track Prerequisites | By role for testing of quality measures:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Track Lead(s) | Bryn Rhodes (testing of quality measures) Richard Boyce (testing of PDDI CDS) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Track Lead Email(s) | Bryn Rhodes: bryn@databaseconsultinggroup.com or fhir@icf.com Richard Boyce: rdb20@pitt.edu or boycerd@upmc.edu | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Specification Information | Implementation Guides: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Zulip stream | Testing of Quality Measures: https://chat.fhir.org/#narrow/stream/179220-cql PDDI CDS: https://chat.fhir.org/#narrow/stream/358049-PDDI_CDS | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Track Kick off Call | Meeting details for all calls listed below (Wednesday's at 10 AM ET):
Connectathon Artifacts
![]() | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
System Roles | See below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Testing Scenario (quality measure): | Quality Measure Testing: System roles:
Scenarios (Exam125FHIR and Exam130FHIR) Individual and Summary Measure Report Action: The reporting system uses data requirements from the knowledge repository and value sets from the terminology server to construct and issue FHIR queries against the clinical data repository to retrieve the data of interest for the measure and subject(s). Action: The reporting system posts data gathered from the clinical data repository to the receiving system. Action: The reporting system issues an $evaluate-measure to the receiving system to calculate the measure and displays the results. Precondition: The knowledge repository has measure and library resources loaded. The terminology server has value sets loaded. The clinical data repository has patient information loaded. Measure content: Exam125FHIR Exam130FHIR Test data: Exam125FHIR Exam130FHIR Success Criteria: The reporting system displays expected results for the selected measure and subject. Bonus point: The reporting system displays expected population results for all test patients Terminology Service Testing NOTE: The NLM's R4 FHIR Terminology Service will be available for participants to use. Use of this server requires a current UMLS license, as well as access to the UAT instance for the FHIR R4 functionality. Please provide track leads with your UMLS user id so we can coordinate access to the UAT instance. Note also that the above version-specific expand scenario is currently only partially supported by the VSAC's FHIR instance, and testing should be focused on use of the R4 ValueSet resources returned. BASE URI: https://uat-cts.nlm.nih.gov/fhir/r4 Using the UAT base URI, instead of our production server base URI (https://cts.nlm.nih.gov/fhir/r4), allows our software engineers to respond to issues and make adjustments/corrects in real time, when possible, during the connectathon. People who have requested UAT permissions will have permissions on the UAT server: https://uat-cts.nlm.nih.gov/fhir/r4, not necessarily on the production server: (https://cts.nlm.nih.gov/fhir/r4).
Clinical Decision Support Testing: System roles:
Scenarios (WHO Antenatal Care) Routine Encounter Decision Support, Step 5 - Quick Check Action: The healthworker application uses WHO Antenatal Care content from the knowledge repository and terminology server to facilitate delivery of guideline-based care as part of a routine pregnancy encounter. Specifically, the application displays the Questionnaire for Step 05 - Quick Check, pre-populating available data from the clinical data repository based on the current status of the patient. Action: The user fills out the Quick Check questionnaire, indicating that no danger signs are present. The application issues a PlanDefinition/$apply with the results of the completed Questionnaire to the clinical reasoning engine Action: The clinical reasoning engine processes the Quick Check PlanDefinition with the given input data and determines the contact can proceed as normal and returns the results. Precondition: The knowledge repository has WHO ANC content loaded. The terminology server has WHO ANC value sets loaded. The clinical data repository has patient information loaded, and in the expected state of an in-progress routine pregnancy contact. ANC content: https://build.fhir.org/ig/WorldHealthOrganization/smart-anc/downloads.html Success Criteria: The healthworker application displays guidance provided by the clinical reasoning engine, indicating no danger signs are present and the contact can proceed as normal. Bonus point: The healthworker application has content from multiple implementation guides loaded to demonstrate inter-leaving decision support based on the common process model described in CPG. Variant: User indicates a symptom that is a danger sign, decision support returns referral to emergency department Security and Privacy Considerations: This track will use all synthetic data and open FHIR endpoints. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Testing Scenario (PDDI CDS): | PDDI CDS Clinical Decision Support Testing: System roles:
Scenarios (PDDI CDS) Subscribe to CDS Services Action: The healthworker application subscribes to PDDI CDS services from the clinical reasoning engine. Precondition: The clinical reasoning engine has loaded the PDDI CDS services for patient-view, order-select, and order-sign (all to handle the warfarin-NSAIDS PDDI for this run). Success Criteria: The healthworker application receives a valid CDS Hooks service response listing all three services, including prefetch templates. Example: CDS Service subscribe request: https://cds.ddi-cds.org/cqf-ruler-r4/cds-services Patient-view Action: The healthworker application uses PDDI CDS from the clinical reasoning engine to deliver suggestions about PDDIs based on data about a specific patient in the EHR at the time that a patient chart is loaded (patient-view). Precondition: The clinical reasoning engine has loaded the PDDI CDS service for patient-view (warfarin-NSAIDS for this run). The clinical data repository has patient information loaded and has subscribed to the PDDI CDS service for patient-view. Success Criteria: The healthworker application displays guidance provided by the clinical reasoning engine, indicating the appropriate branch of the PDDI CDS rule. Example: Pre-condition:
POST https://cds.ddi-cds.org/cqf-ruler-r4/cds-services/warfarin-nsaids-cds-patient-view { Expected response: CDS Cards describing a potential DDI and suggesting management options. The "basic" order-sign scenario - order-sign only Action: The healthworker application uses PDDI CDS from the clinical reasoning engine to deliver suggestions about PDDIs based on data about a specific patient in the EHR at the time that a new medication order is being signed (order-sign). Precondition: The clinical reasoning engine has loaded the PDDI CDS service for order-sign (warfarin-NSAIDS for this run). The clinical data repository has patient information loaded and has subscribed to the PDDI CDS service for order-sign. Success Criteria: The healthworker application displays guidance provided by the clinical reasoning engine, indicating the appropriate branch of the PDDI CDS rule. Example: Pre-condition:
POST https://cds.ddi-cds.org/cqf-ruler-r4/cds-services/warfarin-nsaids-cds-sign { Expected response: CDS Cards describing a potential DDI and suggesting management options. The "advanced" scenario - coordination of order-select and order-sign Action: The healthworker application uses PDDI CDS from the clinical reasoning engine to deliver suggestions about PDDIs based on data about a specific patient in the EHR at the time that a new medication order is being selected (order-select). Precondition: The clinical reasoning engine has loaded the PDDI CDS services for order-select and order-sign (warfarin-NSAIDS for this run). The clinical data repository has patient information loaded and has subscribed to the PDDI CDS service for order-sign. The healthworker application has configured the order-sign CDS Hook by setting the filter-out-repeated-alerts setting for pddi-configuration-items to "false" and the order-select CDS Hook by setting cache-for-order-sign-filtering to "true" Success Criteria: The healthworker application displays guidance provided by the clinical reasoning engine at order-select, indicating the appropriate branch of the PDDI CDS rule, but does not repeat the information at order-sign. Pre-condition:
First POST { Second POST https://cds.ddi-cds.org/cqf-ruler-r4/cds-services/warfarin-nsaids-cds-sign
Expected response: CDS Cards describing a potential DDI and suggesting management options. Security and Privacy Considerations: This track will use all synthetic data and open FHIR endpoints. |