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:

  • Continue testing of Measure evaluation using US-Core 3.1.1 compliant FHIR servers
  • Test Measure Terminology Service capabilities, including version-specific expansion.
  • Test PlanDefinition $apply semantics
  • Test QI-Core Authoring Capabilities

Long Description

The Clinical Reasoning Track will continue focused testing of quality measures using data available from USCore 3.1.1 compliant FHIR servers:

Type

Test an Implementation Guide

Prerequisites

By role:

Track Lead(s)

Bryn Rhodes 

Track Lead Email(s)

bryn@databaseconsultinggroup.com or fhir@icf.com 

Specification Information

Implementation Guides:

Call for participants

Providers, Payers, and other related HIT vendors

Zulip stream

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

Track Kick off Call

August 24 (10 AM ET)-Connectathon Planning/Working Session Recording (Passcode: H9??Bsef)
August 31 (10 AM ET)-Connectathon Planning/Working Session Recording (Passcode: ?C=H8k*6)
September 7 (10 AM ET)-Connectathon Planning/Working Session Recording (Passcode: d*C9g=5F) FSH and JSON Demo Artifacts 
September 14 (10 AM ET)-Connectathon Kickoff Recording (Passcode: $$ArwgF2) Kickoff Presentation 

Connectathon Manager: http://conman.clinfhir.com/?event=con31

Connectathon will meet in Maryland Ballroom A, B and C. The tables will have signs on them for each of the tracks. When there is no breakout session the track may be back in the Maryland Ballroom. 



Clinical Input Required?N/A
Related Tracks?Care Planning, Public Health, CDS Hooks, Da Vinci DEQM Gaps in Care and Vulcan Schedule of Activities

Testing Scenario:

Quality Measure Testing:

System roles:

  • Knowledge Repository
  • Terminology Server
  • Clinical Data Repository
  • Reporting System
  • Receiving System

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

RequirementTest CaseExpected Outcome

Code System 1: Representation

  • url
  • url&version
  • name
  • status
  • experimental
  • publisher
  • description
  • caseSensitive

TODO (build URL and identify CodeSystem)

CodeSystem resources that conform to ShareableCodeSystem
Content as expected (validate url, version, name, title, experimental, status, publisher, description)

Source of truth for CodeSystem resources being:

  • FHIR specification (for ballot bound code systems)
  • terminology.hl7.org (for HL7 and external code systems)
Code System 3: Retrieve

Code System 4: Search by

  • url
  • url&version
  • identifier
  • name
  • title
  • description
  • code (exact match)


Code System 6: $lookup

Code System 7: $validate-code

Value Set 1: ShareableValueSet



Value Set 2: ComputableValueSet

Value Set 3: ExecutableValueSet

Value Set 4: PublishableValueSet

Value Set 5: Retrieve

Value Set 6: Search by:

  • url
  • url&version
  • identifier
  • name
  • title
  • status
  • description
  • code
  • offset


Value Set 8: $validate-code

  • url
  • valueSetVersion
  • activeOnly
  • displayLanguage
  • code
  • system
  • system-version
  • coding
  • codeableConcept
  • check-system-version
  • force-system-version


Value Set 9: $expand

  • url
  • valueSetVersion
  • activeOnly
  • displayLanguage
  • limitedExpansion
  • default-to-latest-version
  • system-version
  • cehck-system-version
  • force-system-version
  • manfiest
  • expansion
  • includeDraft


Quality Program 1: Representation

Quality Program 2: PublishableLibrary

Quality Program 3: Retrieve



Quality Program 5: $expand

Quality Program 7: $package

Quality Program 8: Release Manfiest

Server Operations 1: metadata?mode=terminology

Server Operations 2: Batch support


Clinical Decision Support Testing:

System roles:

  • Knowledge Repository
  • Terminology Server
  • Clinical Data Repository
  • Clinical Reasoning Engine
  • Healthworker Application

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

Test data: https://build.fhir.org/ig/WorldHealthOrganization/smart-anc/examples-first-contact.html#step-05-quick-check

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.
Bonus point: The healthworker application uses the new PlanDefinition/$apply semantics (i.e. no CarePlan returned, only a RequestGroup)

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.