Table of Contents
...
Effective public health and research action depends on access to timely, relevant, and complete data. Unfortunately, the availability and quality of data to public health, particularly data captured in EHRs, remains limited: current data systems and exchange standards are siloed, and existing interoperability standards are administratively cumbersome, underutilized, or otherwise limited in application and scope. Many state and local programs do not have the data necessary to assess hepatitis C disease burden and its distribution in their communities, let alone monitor trends in key epidemiological parameters and health outcomes, like those captured in the HCV care cascade (as shown in Figure 1 below). In the absence of such situational awareness, public health programs lack the information necessary to efficiently and effectively direct public health action and population health research activities. The public health consequences of this current state are illustrated by, but certainly not unique to, hepatitis C surveillance.
...
Figure 1. HCV Care Cascade
Goals of the Use Case
Develop a use case to ensure the MedMorph architecture supports the electronic reporting of comprehensive hepatitis C data by health care providers and health systems to public health, researchers, and other potential users, such as clinical registries and quality reporting entities
Improve the efficiency and effectiveness of hepatitis c data throughout the HCV care cascade cycle from clinical settings/EHRs to public health in a timely, less burdensome, complete fashion
Objectives to help guide this goal include:
Optimize access to hepatitis C data that are already captured within the EHR
Reduce the implementation and reporting burden on providers and health systems by automating electronic reporting and minimizing duplicative data demands whenever possible
Align with existing statutory/policy requirements
...
Figure 2 below is the Abstract Model that illustrates the actors, activity, and systems involved in the eICR workflow when a patient has been diagnosed with hepatitis C.
...
Figure 2. Hepatitis C eICR Abstract Model
The EHR sends a notification to the Backend Services App when there has been activity in topics in which the app subscribes to. The Backend Services App then queries the EHR and the EHR returns the appropriate data. The Backend Service App receives and validates the data and sends the data to the Trusted Third Party. The Trusted Third Party checks the reportability of eICR, generates a Reportability Response RR), and sends the RR to the EHR, PHA/Research Organization/Data Repository, and Backend Services App. The Backend Services App may send the RR to the EHR and sends the report to the Public Health Authority (PHA).
...
Figure 3 below illustrates the flow of events and information between the actors for the hepatitis C eICR workflow.
...
Figure 3. Hepatitis C eICR Activity Diagram
eICR Sequence Diagram
Figure 4 below represents the interactions between actors in the sequential order that they occur in the hepatitis C eICR workflow.
...
Onboarding of EHRs and or tracking systems
The use, IT/data governance and or versioning of FHIR between trading entities
Consent models for data exchange:
For public health purposes, existing authorities are sufficient and no consent is required.
For research use cases:
IRB approvals, intended purpose, and consent for the intended purpose is included
Other areas to investigate:
https://www.hl7.org/fhir/consent.html (Look at ResearchSubject and ResearchStudy resources in FHIR and their relationship to Consent Resource)
Patient Level data, LDS, Deidentified data sets, and relationships to consent.
The activity network query space has not been reconciled with FHIR RESTFUL queries. How do queries on eHealth exchange, CommonWell map into authorities?
Data that is stored outside the EHR (e.g., PDMP data) may not be available (e.g., Hepatitis C wants drug use data)
Any activities that are not associated with a clinical order or clinical visit (e.g., drive-up COVID test, STD test, adult immunization at the pharmacy )
Data lag vs. real-time (especially for research use cases) - the difference in time for use cases.
The Reference Architecture defines trigger events and timing offsets in relationship to trigger events, and actions to be performed based on trigger events.
Clinical trials (not observation) - data safety monitoring board - so there is a realtime use case for clinical trials (but maybe different for observational research) – HL7 Vulcan Accelerator program
Data provenance (recognized authority - but how much do we trust the data from those systems outside of the EHR and the EHR ingests the data - and the detail of information and method of transmission e.g., orally reported, substantiated with material or electronic)
The MedMorph Reference Architecture IG would recommend (or require in available) support for Provenance as defined by USCDI and apply to all data classes being reported.
...