Quality Measure Testing: System roles: - Knowledge Repository
- Terminology Server
- Clinical Data Repository
- Reporting System
- Receiving System
Scenarios 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 --
MIPS Group: GroupA / TIN: 00123 (this group is comprised of Practitioner/TIN pairs: John Smith/ TIN 00XXX and Jane Smith/TIN 00YYY)
MIPS Group: GroupB / TIN: 00999 (this group is comprised of Practitioner/TIN pairs: John Smith/TIN 00ZZZ and Kelly Smith/TIN 00YYZ) 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
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). Test cases for terminology testing are detailed in the Quality Measure IG as a set of Thunder Client tests: https://github.com/HL7/cqf-measures/tree/master/thunder-tests Code Systems: - THO Condition Clinical Status Codes
–https://terminology.hl7.org/3.1.0/CodeSystem-condition-clinical.html - FHIR Request Intent Codes
–https://hl7.org/fhir/R4/codesystem-request-intent.html - US Core Condition Category Codes
–https://hl7.org/fhir/us/core/STU3.1.1/CodeSystem-condition-category.html - THO V3 Act Encounter Codes
–https://terminology.hl7.org/3.1.0/CodeSystem-v3-ActCode.html - QI Core RAND Appropriateness Score Codes
–https://hl7.org/fhir/us/qicore/STU4.1.1/CodeSystem-appropriateness-score.html Value Sets: - FHIR Condition Clinical Status
–https://hl7.org/fhir/R4/valueset-condition-clinical.html –https://hl7.org/fhir/R4/valueset-request-intent.html - US Core Condition Category
–https://hl7.org/fhir/us/core/STU3.1.1/ValueSet-us-core-condition-category.html - THO V3 Act Encounter Code
–https://terminology.hl7.org/3.1.0/ValueSet-v3-ActEncounterCode.html - QI Core RAND Appropriateness Score
–https://hl7.org/fhir/us/qicore/STU4.1.1/ValueSet-qicore-appropriateness-score.html 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
| 
