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:
The Clinical Reasoning Track will continue focused testing of quality measures using data available from QI-Core 4.1.1 compliant FHIR servers:
Eligible Hospital (EH) Measures - Hybrid
Eligible Hospital (EH) Measures - OQR
Note that the above are measure specifications exported from the MADiE development tool and extracted into the appropriate folders in the https://github.com/cqframework/ecqm-content-qicore-2023 repository as a FHIR Content IG so they can be viewed and tested in a VS Code environment using the CQFramework CQL plugin. If you are interested in testing past measures, we have all the content from previous connectathons still available, see the Measure Content Index at: https://docs.google.com/spreadsheets/d/1DocNOIX3ZYWCzOxSHw00sl21WHWx5SeazrlSCUcjqqs/edit#gid=852465089
Multiple Provider Patient Scenario
Attribution flow prepared by Michelle Currie
Grouping Value Set Expansion Scenario
ClaimsData Testing Scenario
Test an Implementation Guide
|Care Planning, Public Health, CDS Hooks, Da Vinci DEQM Gaps in Care and Vulcan Schedule of Activities|
Call for participants
Providers, Payers, Reporting Vendors, Decision Support Vendors, and other related HIT vendors
By role for testing of quality measures:
Track Lead Email(s)
Track Kick off Call
Connectathon Event Artifacts
Measure Calculation Tool (MCT) demo slides:
Quality Measure Testing:
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.
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
Multiple Provider Scenario:
Two groups are registered with CMS --
Patient Jane Doe has several encounters with Practitioner John Smith - all at the same location/facility and all the encounters have codes related to Medicare Part B
All of the data for the above is coming from a single organization (EIN/TIN 00000) and a single FHIR output from their EHR
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.
Test cases for terminology testing are detailed in the Quality Measure IG as a set of Thunder Client tests:
Clinical Decision Support Testing:
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.
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