2022-05 Clinical Reasoning

The Clinical Reasoning track will also:

• Partner with the eCR/MedMorph track to conduct public health reporting testing.
• Test the use of FHIR resources in alignment with FHIR R4 Implementation Guides (IG) such as QI-Core IG, Quality Measure IG and the Data Exchange for Quality Measures (DEQM) IG.
• Expand TestScript coverage of capabilities. 
• Test the following 2022 Reporting CMS/HEDIS Measures for FHIR R4:
  • Eligible Clinician (EC) Measures
    • CMS122v10 Diabetes: Hemoglobin A1c (HbA1c) Poor Control (> 9%)
    • CMS124v10 Cervical Cancer Screening
    • CMS125v10: Breast Cancer Screening (also health plan level BCSE HEDIS measure)
    • CMS130v10 Colorectal Cancer Screening
    • CMS347v5 Statin Therapy for the Prevention and Treatment of Cardiovascular Disease
    • CMS74v11 Primary Caries Prevention Intervention as Offered by Primary Care Providers, including Dentists
  • Eligible Hospital (EH)/Critical Access Hospital (CAH) Measures
    • CMS104v10 Discharged on Antithrombotic Therapy
    • CMS190v10 Intensive Care Unit Venous Thromboembolism Prophylaxis
    • CMS529v2 Hybrid Hospital-Wide Readmission
    • CMS506v4 Safe Use of Opioids - Concurrent Prescribing
    • CMS844v2 Core Clinical Data Elements for the Hybrid Hospital-Wide (All-Condition, All-Procedure) Risk-Standardized Mortality Measure (HWM)
    • Pre-Rulemaking
      • CMS816v1 Hospital Harm - Severe Hypoglycemia
      • CMS871v1 Hospital Harm - Severe Hyperglycemia
  • If you are interested in testing past measures, visit: https://docs.google.com/spreadsheets/d/1DocNOIX3ZYWCzOxSHw00sl21WHWx5SeazrlSCUcjqqs/edit#gid=852465089

https://chat.fhir.org/#narrow/stream/179220-cql 

Sign-up for the latest news and to be added to the kickoff calendar invite by emailing fhir@icf.com

Track Details

New Attendees
If you have not previously attended a Connectathon, HL7 has recorded an orientation session that covers the basics of FHIR, how to read an IG, the US Core profile, FHIR testing, tools and what to expect at a Connectathon. 

FHIR Cheat Sheets

• R4/R5/CDS Hooks: https://fire.ly/resources/
• FHIR Shorthand: http://hl7.org/fhir/uv/shorthand/FSHQuickReference.pdf
  

Testing Artifacts

If you plan to test during the Connectathon, you will need to be setup in Connectathon Manager. Account setup instructions can be found here.  

• Measure Content: https://docs.google.com/spreadsheets/d/1DocNOIX3ZYWCzOxSHw00sl21WHWx5SeazrlSCUcjqqs/edit#gid=852465089

• Quick start guide: https://github.com/DBCG/connectathon/wiki/Quickstart

• Authoring Walkthrough: https://github.com/alphora/cqf-ccc#setting-up
• Scenario Index:

• • Exchange Scenarios
  • ValueSet Scenario
  • Opioid Decision Support Scenario
  • PlanDefinition $apply Scenario
  • Public Health Reporting Scenario 
    
  • Group Subject Scenario
  • Attribution Scenario

Connectathon Artifacts (recordings are posted in Whova Video Gallery. Whova FAQs)

• May 2022 Track Report-Out: https://docs.google.com/document/d/1LygEwf_BRH5kHsIydh2ZlGhQPzvk-E96LjdGqW4RoDg/edit
  
  
• Tuesday, May 3, 2022
  • Track Introduction
  • Clinical Quality Reporting in FHIR
• Wednesday, May 4, 2022
  • Quality Measure data exchange workflow – Telligen acting as a data consumer
  • Track Highlights
  • Bulk Data and Patient List
    
    

• May 2022 Recorded Sessions
  • QI-Core IG Overview 
    
  • Clinical Quality Reporting in FHIR 

• January 2022 Recorded Sessions
  • Building a Synthea Module for Measure Developers
  • Implementation of Vocabulary types in CQL 1.5
    
    
• September 2021 Recorded Sessions
  • QI-Core IG Review and Authoring
  • Quality Measurement and Reporting w/FHIR and CQL
  • Reusable Data Elements and Sharing Logic
  • VSAC FHIR API Roadmap
    
    

System Roles (Quality Reporting)

• Producer - System of record for clinical information such as an EHR
• Consumer - A system that aggregates data from multiple sites related to reporting quality measures such as a payer, HIE, reporting vendor or public health registry
• Reporter - A system that sends quality reporting data and results
• Receiver - A system that receives quality reporting data and results
• Repository - A system that supports retrieval and distribution of quality measure specifications
• Terminology Service - A system that supports distribution of terminologies required for measure evaluation

Systems capable of playing these roles should implement the exchange and reporting scenarios as described in the Data Exchange for Quality Measures implementation guide.

The Producer role should be a FHIR Server implementing at least the US Core profiles and capability statement, and ideally implementing the QI Core profiles, as described in the producer server capability statement:

http://build.fhir.org/ig/HL7/davinci-deqm/CapabilityStatement-producer-server.html

The Consumer role should implement the consumer server capability statement:

http://build.fhir.org/ig/HL7/davinci-deqm/CapabilityStatement-consumer-server.html

The Reporter role should implement the reporter client capability statement:

http://build.fhir.org/ig/HL7/davinci-deqm/CapabilityStatement-reporter-client.html

The Receiver role should implement the receiver server capability statement:

http://build.fhir.org/ig/HL7/davinci-deqm/CapabilityStatement-receiver-server.html

The Repository role should implement at least the Shareable Measure Repository capability statement. To participate in the Data Element submission workflow, the Repository role should implement the Publishable Measure Repository capability statement:

http://build.fhir.org/ig/HL7/cqf-measures/measure-repository-service.html

The Terminology Service role should implement the Measure Terminology Service capability statement:

http://build.fhir.org/ig/HL7/cqf-measures/measure-terminology-service.html

The CQF Ruler, a reference implementation of FHIR Clinical Reasoning based on the HAPI FHIR Server is available to either play the Consumer, Receiver, and CDS Service roles, or to help guide and test implementations in preparation for the track.

A test instance of the CQF Ruler is available here: http://cqm-sandbox.alphora.com/

Data Exchange Scenarios

For these scenarios, the Producer and Consumer exchange the data-of-interest for a quality measure, either by push or pull

This is the EHR Reference Implementation server endpoint for the Medication Reconciliation Post Discharge use case to test the DEQM $submit-data operation - https://api-v8-stu3.hspconsortium.org/DaVinciMRPProvider/open

This is the Payer Reference Implementation server endpoint for this use case - https://api-v8-stu3.hspconsortium.org/DaVinciMRPPayer/open

Data Element Submission Scenarios

The following diagram illustrates the overall flow for these scenarios:

The overall steps in the scenario are:

1. Setup- Using the Knowledge Repository and Terminology Service to obtain all the necessary content to run
2. Attribution/Selection- Using provider attribution methods and initial population criteria to determine applicable patients
3. Submission- Gathering and submitting the data-of-interest using the $submit-data operation
4. Evaluation- Retrieving calculated performance results using $evaluate-measure
5. Care Gaps- Retrieving gaps-in-care information using $care-gaps

The following scenario descriptions are patterns for specific scenarios, for the May 2022 Connectathon we are focusing on individual push and evaluate using colorectal cancer screening measure, for complete description refer to: https://github.com/cqframework/ecqm-content-qicore-2022

Individual Exchange Scenarios

Push Scenario ($submit-data)

• Action: An EHR playing the role of the Producer uses the $submit-data operation to report the data-of-interest for an MRP measure
• Precondition: The EHR has appropriate data to produce the data-of-interest for the measure, either based on the test data, or by walking through a simulated workflow that produces the data required
• Success Criteria: The Consumer receives the data and successfully processes the data
• Bonus Point: Run the operation multiple times throughout a simulated measurement period to feed incremental data of interest for the measure to the Consumer

Pull Scenario ($collect-data)

• Action: A Consumer uses the $collect-data operation to gather the data-of-interest for an MRP
• Precondition: The EHR has appropriate data to produce the data-of-interest for the measure, either based on the test data, or by walking through a simulated workflow that produces the data required
• Success Criteria: The Producer responds to the $collect-data and the Consumer is able to successfully process the response
• Bonus Point: Run the operation multiple times throughout a simulated measure period to collect incremental data of interest for the measure

Group Exchange Scenarios

For the Group Exchange scenarios, we focus on the need for payers to track status of members for a screening measure, a Colorectal Cancer Screening measure in this case. The scenarios are based on the case where a payer sends a request to a provider for the screening information for a group of covered patients.

These scenarios will attempt to use the Bulk Data API as specified in the FHIR specification. In particular:

• $collect-data will use bulk data to communicate the response
• $submit-data will use an implementation of bulk data import to communicate the payload of the request

Push Scenario ($submit-data)

In the push scenario, the provider - through some interface in their system - gathers the screening information for the set of patients and submits it:

• Action: An EHR playing the role of the Producer uses a batch of $submit-data interactions to report the data-of-interest for the COL measure for the set of patients
• Precondition: The EHR has appropriate data to produce the data-of-interest for the measure, either based on the test data, or by walking through a simulated workflow that produces the data required
• Success Criteria: The Consumer receives the data and successfully processes the data
• Bonus Point: The provider system uses the Bulk Data format to send the information

Pull Scenario ($collect-data)

In the pull scenario, the payer uses the $collect-data operation to request through the provider's API

• Action: A Consumer uses a batch of $collect-data interactions to gather the data-of-interest for a COL measure for a set of patients
• Precondition: The EHR has appropriate data to produce the data-of-interest for the measure, either based on the test data, or by walking through a simulated workflow that produces the data required
• Success Criteria: The Producer responds to the $collect-data batch and the Consumer is able to successfully process the responses
• Bonus Point: The payer system uses the Bulk Data format to request the information

Reporting Scenarios

For these scenarios, a Reporter and Receiver exchange the data and results of a quality measure.

Individual Report Scenario

• Action: A Reporter reports the data and results for an Individual MRP, COL, or VTE-1 measure to a Receiver
• Precondition: The Reporter has appropriate data to produce the individual MeasureReport for the measure
• Success Criteria: The Receiver receives a completed MeasureReport and verifies that it has the correct data and the calculated result is correct for the individual
• Bonus Point: Use a subscription to notify the Receiver when the report is ready for retrieval

Summary Report Scenario

• Action: A Reporter reports the results for a Summary MRP, COL, or VTE-1 measure to a Receiver
• Precondition: The Reporter has appropriate data to produce the summary MeasureReport for the measure
• Success Criteria: The Receiver receives a completed MeasureReport and verifies that it has the expected result for the population
• Bonus Point: Use a subscription to notify the Receiver when the report is ready for retrieval
  
  

Calculation Scenarios

For these scenarios, a Receiver requests the calculation of a quality measure by a Reporting system.

Individual Report Scenario

• Action: A Receiver uses $evaluate-measure to request the data and results for an Individual MRP, COL, or VTE-1 measure from a Reporter
• Precondition: The Reporter has appropriate data to produce the individual MeasureReport for the measure
• Success Criteria: The Receiver receives a completed MeasureReport and verifies that it has the correct data and the calculated result is correct for the individual
• Bonus Point: Use asynchronous result calculation (MeasureReport status = in-progress)
  
  

Summary Report Scenario

• Action: A Receiver uses $evaluate-measure to request the results for a Summary MRP, COL, or VTE-1 measure from a Reporter
• Precondition: The Reporter has appropriate data to produce the summary MeasureReport for the measure
  
• Success Criteria: The Receiver receives a completed MeasureReport and verifies that it has the expected result for the population
  
• Bonus Point: Use asynchronous result calculation (MeasureReport status = in-progress)
  

Group Subject Scenario

• Action: A Receiver uses $evaluate-measure with the subject parameter referencing a Group resource
  
• Precondition: The Reporter has appropriate data to produce the summary MeasureReport for the measure including a Group resource referencing 2 or more Patient resources
  
• Success Criteria: The Receiver receives a completed MeasureReport and verifies that it has the expected result for the population, or errors when input parameters are contradictory
• Bonus Point: Expected results are captured using http://build.fhir.org/ig/HL7/cqf-measures/StructureDefinition-test-case-cqfm.html
  

1. $evaluate-measure Subject of Patient/XXX and measureType = summary // Should error (What about a Group with only one Patient?)
2. $evaluate-measure Subject of Group/XXX and measureType = individual // Should error ??? why not individual report for each Patient in the Group? What about $care-gaps?
3. $evaluate-measure Subject of Group/XXX and measureType= = summary // Expected results

Attribution Scenario

• Action: Use http://build.fhir.org/ig/HL7/cqf-recommendations/OperationDefinition-cpg-library-evaluate.html with subject referencing an ATR Group resource
• Precondition: Library resource with CQL that can create a Group resource for Patients which are a subset of Patients from an ATR Group resource passed in as the subject parameter
• Success Criteria: Group resource is returned with the expected set of Patients
• Bonus Point: Use the returned Group resource in the Group Subject Scenario; use "parameters" input parameters to feed into the evaluation CQL logic; ; $evaluate-measure where the measure has been adapted to define Supplemental Data Elements (SDE) which use "attribution data elements" such as Encounter location (practice site)

(Describe CQL to return a subset of the ATR Group)

(Describe parameters for CQL that can be used to select Patients from the ATR Group, e.g., NPI of a practitioner or identifier of a Location (practice site))

Valueset Scenario

• Action: A system uses $expand?url=[valueset]&version=[version]&system-version=[system-version] to request a version-specific valueset expansion from a terminology service
• Precondition: The system has valueset versions and codesystem versions loaded
• Success Criteria: The system receives a complete expansion of the appropriate value set version
• Bonus Point: The system successfully returns two separate expansions for the same valueset

Content for this scenario specifically uses the EXM125v9 and EXM125v10 measure, focusing on the differences between value set expansions between the value sets used in the different reporting years. Specifically:

For the Bilateral Mastectomy value set, the v10 expansion includes new codes:

• 836436008: Simple mastectomy of bilateral breasts using robotic assistance (procedure)
  
• 870629001: Bilateral mastectomy for female to male transsexual (procedure)
  

For the Mammography value set, the v10 expansion does not include CPT codes in the v9 version:

• G0202: Screening mammography, bilateral (2-view study of each breast), including computer-aided detection (cad) when performed
  
• G0204: Diagnostic mammography, including computer-aided detection (cad) when performed; bilateral
  
• G0206: Diagnostic mammography, including computer-aided detection (cad) when performed; unilateral
  

Use the valueSetVersion and system-version parameters to request these expansions.

TestScript resources formally describing these scenarios are provided here: https://github.com/cqframework/ecqm-content-r4/tree/master/input/tests/Touchstone/ValueSets

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
This UAT Base URI is no longer included on the FHIR Terminology Service for VSAC Resources as it has become a public page that points to the production servers. However, the capability statements and other important documentation are included on the FHIR Terminology Service for VSAC Resources page.

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).

Public Health Reporting Scenario

System Roles (PHR)

Clinical System - A system that deals with health data and potentially reportable events
Reporting Application - A system that focuses on identifying and submitting potentially reportable events
Receiving System - A system that receives potentially reportable events

Negative Chlamydia Screening Report Scenario

• Action: A Reporting Application is notified by a Clinical System of a potentially reportable event, and uses the eRSD specification to:
• Determine the jurisdiction of residence and jurisdiction of care for the event
• Determine whether the event is potentially reportable, given condition-specific value sets and jurisdiction-specific criteria as specified in the rule filter portion of the eRSD specification
• If the event is potentially reportable, submit a mock eICR to the receiving system

• Precondition: The Clinical System has appropriate data representing a negative chlamydia screening result
• Success Criteria: The receiving system is notified of and receives a potentially reportable eICR for a negative chlamydia screening result
• Bonus Point: Demonstrate the pattern is effective for other conditions that exhibit similar potential to reduce the number of potentially reportable events submitted through jurisdiction-specific and condition-specific configuration
  
  

Decision Support Scenarios

System Roles (CDS)

CDS Service - A system that provides decision support guidance via the CDS Hooks API
CDS Client - A system that consumes decision support via the CDS Hooks API

Systems capable of playing these roles should implement the CDS Hooks API. Systems may also support ingestion of computable decision support content as described in the Clinical Guidelines implementation guide.

PlanDefinition $apply Testing

This track will test and discuss feedback on potential simplifications of the PlanDefinituion $apply semantics, including the mergeNestedCarePlans option introduced in the CPG IG, as well a new proposed requestGroupsOnly parameter. The testbed for this scenario and associated testing content is available in the https://github.com/cqframework/pd-apply repository, Instructions for running the tests can be found in the repository readme.

There is an option to try this in a web-UI. Go to https://smart-on-fhir-17eef.web.app/ with the feature accessible by the "$apply custom PlanDefinition..." button at the bottom. Here you can add a transaction FHIR bundle with PlanDefinitions, ActivityDefinitions, Library, and ValueSets in order to test the RequestGroup implementation using Encender. Note: your Library will need to have a JSON ELM in it.

To connect it to an EHR, we've been using https://smart-on-fhir-17eef.web.app/launch.html as the launch url, which directs us to a page to select which EHR we launched from. E.g. https://launch.smarthealthit.org/

Use cases providing content for testing this scenario, including the use of questionnaires to both provide missing information, as well as gather information as part of the process:

• ASBI: https://github.com/asbi-cds-tools
• Cervical Cancer: https://github.com/ccsm-cds-tools/ccsm-cds-with-tests (questionnaire is still a draft)
• WHO ANC: https://build.fhir.org/ig/WorldHealthOrganization/smart-anc/artifacts.html (multiple questionnaires)
• CDC Opioid + CDS4CPM: https://build.fhir.org/ig/cqframework/opioid-cds-r4/artifacts.html (I can't find the questionnaire for this use case)
• NACHC HIV
• OHSU HTN https://build.fhir.org/ig/OHSUCMP/htnu18ig/artifacts.html (I can't find the questionnaire for this use case)
• Lung Cancer Screening

Opioid Decision Support

The Centers for Disease Control and Prevention (CDC) have issued guidelines relating to the prescription of opioids:https://www.cdc.gov/drugoverdose/prescribing/guideline.html (Opioid Prescription Guideline)

The Opioid Prescribing Support Implementation Guide represents several recommendations of this guideline as computable artifacts using the FHIR Clinical Reasoning Module:

http://build.fhir.org/ig/cqframework/opioid-cds/ (Opioid Prescribing Support Implementation Guide) (STU3)

http://build.fhir.org/ig/cqframework/opioid-cds-r4/ (R4 version)

This scenario will focus on testing usage with the new order-select hook for recommendations #5, #10, and #11

• Action: The chart is opened for a patient that is currently prescribed opioids and has not had the recommended urine drug screening, so the recommendation for a urine drug screening is displayed
• Success Criteria: An EHR user is provided appropriate guidance when viewing a patient that is currently prescribed opioids
• Bonus Point: The logic accesses an extension as a first-class element of the model

For the purposes of this scenario, long-term opioid therapy is defined as use of opioids on most days for > 3 months, and the patient does not have metastatic cancer. To determine these, the CDS Service will need to access:

• Current Medication List
• Problem List
• Encounter Diagnoses within 12 months

For communicating medications, the service will expect information in a MedicationRequest or MedicationStatement, with at least the following supplied:

• Medication as an RxNorm code
• Dosage
• Frequency

The implementation guide provides computable artifacts describing the calculations for MME based on the CDC Guidance. The CDS Service can use these representations to provide the functionality described for this scenario.

TestScript(s): All testing materials can be accessed from the Connectathon GitHub Repository: https://github.com/dbcg/connectathon

Security and Privacy Considerations: The scenarios and reference implementations here run using open (i.e. unsecured) connections. Systems SHALL NOT use PHI in any form, or data derived directly from PHI.