Table of Contents

Description

The purpose of the use case is to demonstrate how public health programs and research stakeholders can leverage and build upon current investments^[1] in electronic case reporting (eCR) to improve the availability of data that advance national public health priorities, in this case, eliminating hepatitis C as a public health threat in the United States^[2].

Problem Statement

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

Scope of the Use Case

In-Scope

• Collect standardized hepatitis C data from health care providers' health systems

• Define under what circumstances an EHR system must create and transmit a report to public health

• Identify the data elements to be retrieved from the EHR to produce the report

• Identify and report current HCV infection to public health and through bi-directional communication send information back to health care systems

 Out-of-Scope

• Validation of the EHR data

• Data captured outside the EHR and communicated directly to registries

  • This includes electronic reporting from laboratories directly to public health, as well as data sent from pharmacy systems directly to clinical registries

• Changes to existing provider workflow or existing data entry

• Policies of the clinical care setting to collect consent for data sharing

User Stories

User stories describe real-world observations including actors, events, systems, trigger events, and actions. We have included two user stories to describe the MedMorph hepatitis C use case.

User Story 2: Pregnant Woman and Exposed Infant – HCV Care Cascade

Diagnostic Flow

Patient A, a pregnant woman (hereafter, “Mom”), visits her OBGYN, Dr. A, for her initial prenatal care visit. During this visit, Dr. A orders routine prenatal labs, including an FDA-approved hepatitis C antibody test^[5]. An onsite lab tech draws a blood specimen from Mom via venipuncture and sends the specimen to an offsite lab.

The lab performs the recommended testing. In this case, the anti-HCV test is reactive, so an FDA-approved NAT assay for HCV RNA is performed on the same specimen (reflex testing). This, too, is reactive, indicating that Mom is currently infected with HCV. The lab sends results electronically to Dr. A. Receipt of any HCV antibody and/or HCV RNA test result in the EHR automatically triggers an electronic initial case report (eICR) to public health, as well as any clinical registry with which Dr. A’s practice is affiliated.  

NOTE: the report triggered should include information indicative of current pregnancy. Ideally, this information would be communicated using emerging standards for representing pregnancy status^[6]. Alternatively, and/or additionally, other information in the EHR could be defined as being a reasonably reliable proxy indicator of potential pregnancy and so included in the report if present (e.g., calculated time since last menstrual period, recent prenatal panel test ordered).

Because current HCV treatment regimens are not approved for use during pregnancy, Dr. A does not immediately initiate a referral for treatment.

Delivery Flow

Several months later, Mom goes into labor and arrives at the hospital. Mom’s HCV infection status is communicated to the hospital staff and captured in its EHR (e.g., in the problem list or medical history) so healthcare staff can take necessary additional precautions.

Mom delivers a healthy baby girl (hereafter “Baby”). Data on the delivery and its outcome are captured in the hospital’s EHR.

Since HCV appears on Mom’s problem list, an eICR will be sent to public health and/or the clinical registry after the encounter ends. That report includes information on Mom; her HCV infection status (diagnosis and/or test results and date); and her delivery (delivery date and outcome).

The delivery records are also forwarded to Baby’s pediatrician, Dr. P. Since HCV appears on Baby’s problem list, an eICR will be sent to public health and/or the clinical registry after the encounter ends.

NOTE: the hospital “delivery” and pediatrician “exposure” reports triggered under this flow allow for public health follow up to ensure the exposed infant receives appropriate care. In an ideal world, the “infant” flow outlined further below would itself ensure such follow up care. But reality is often far messier, especially when it comes to communication of data across different institutions and providers for different individuals (mom, baby). Adding these reporting steps better positions public health to help ensure those connections are made—and that providers like the pediatrician know what steps to take when caring for an exposed infant.

Post-Partum Treatment Flow for Mother

Mom has a post-delivery visit with Dr. A at 2 weeks, at which time Dr. A makes a referral for Mom to see Dr. Z, an HCV treatment provider.

At her first appointment with Dr. Z, he orders a transient elastrography test (to evaluate the degree of hepatic fibrosis present); HCV genotype; and a series of lab tests, including complete HAV serology, HBV serology, complete blood count (CBC), HIV tests, and a complete metabolic profile including a hepatic function panel (i.e., albumin, total and direct bilirubin, alanine aminotransferase (ALT), aspartate aminotransferase (AST), calculated glomerular filtration rate (eGFR)). The results of these will be used by Dr. Z to inform his recommended HCV treatment strategy. Dr. Z’s office receives the results from these follow up tests.

Since HCV appears on Mom’s problem list, an eICR will be sent to public health and/or the clinical registry after the encounter ends.

Mom has a second appointment with Dr. Z to discuss options. The results, which are shared with Mom, indicate that there is no liver cirrhosis present and Patient X is infected with genotype 1b. Mom indicates that she is breast feeding and would like to continue to do so until Baby is at least 6 months old. Dr. Z and Mom thus decide to defer treatment for several months, until Baby has transitioned to bottle feeding.

Approximately 5 months later, Mom has a follow up visit with Dr. Z. Mom is no longer breast feeding, and she and Dr. Z agree to initiate treatment for her hepatitis C. From here, the flow for Mom is identical to User Story #1 (treatment and cure).

Testing, Diagnosis and Treatment Flow for Infant

Based on the records he received from the hospital, Dr. P knows that Baby was exposed to HCV. During Baby’s follow-up well child check, Dr. P orders an FDA-approved Nucleic Acid Test (NAT) intended for detection of hepatitis C virus (HCV) RNA. An onsite lab tech draws a blood specimen from Baby and sends the specimen to an offsite lab.

The lab performs the recommended test, and the results are reactive. The lab sends results electronically to Dr. P. Receipt of the HCV RNA test result in the EHR automatically triggers an eICR to public health.

Dr. P makes a referral for Baby to see Dr. G, a pediatric gastroenterologist. During Baby's first visit with Dr. G., Dr. G explains to Mom that it is too early to initiate treatment for Baby—and that there is a possibility that Baby’s viremia will prove transient.

Because HCV direct acting antivirals (DAAs) are not approved for use in children as young as Baby, Dr. G does not initiate treatment at this time. Instead, he will continue to monitor Baby’s health until she reaches age 3.

Once Baby is 3 years old, Dr. G will evaluate Baby and make a treatment recommendation. At this point, the flow for Baby is similar to User Story #1 (treatment and cure).

Use Case Actors

Electronic Health Record (EHR)^[7] System:  A system used in care delivery for patients and captures and stores data about patients and makes the information available instantly and securely to authorized users. While an EHR does contain the medical and treatment histories of patients, an EHR system is built to go beyond standard clinical data collected in a provider’s provision of care location and can be inclusive of a broader view of a patient’s care. EHRs are a vital part of health IT and can:

• Contain a patient’s medical history, diagnoses, medications, treatment plans, immunization dates, allergies, radiology images, and laboratory and test results

• Allow access to evidence-based tools that providers can use to make decisions about a patient’s care

• Automate and streamline provider workflow

A FHIR Enabled EHR exposes FHIR APIs for other systems to interact with the EHR and exchange data. FHIR APIs provide well defined mechanisms to read and write data. The FHIR APIs are protected by an Authorization Server which authenticates and authorizes users or systems prior to accessing the data. The EHR in this use case is a FHIR Enabled EHR.

Backend Services App: A system that resides within the clinical care setting and performs the reporting functions to public health and/or research registries. The system uses the information supplied by the PHA to determine when reporting needs to be done, what data needs to be reported, how the data needs to be reported and to whom the data should be reported. The term “Backend Service” is used to refer to the fact that the system does not require user intervention to perform reporting. The term “App” is used to indicate that it is similar to a SMART on FHIR App which can be distributed to clinical care via EHR specified processes. The EHR specified processes are followed to enable the Backend Services App to use the EHR's FHIR APIs to access data. The healthcare organization is the one who is responsible for choosing and maintaining the Backend Services App within the organization.

Data/Trust Services: A set of services that can be used to pseudonymize, anonymize, de-identify, hash, or re-link data that is submitted to public health and/or research. These Data/Trust services are used as appropriate by the Backend Services App.

Trusted Third Party:  A system (e.g., HIE, RCKMS/AIMS Platform) at an intermediary organization that serves as a conduit to exchange data between healthcare organizations and PHAs. Trusted Third Parties perform the intermediary functions (e.g., apply business logic and informs the Reportability Response) using appropriate authorities and policies.

Public Health Authority (PHA) Data Store: A FHIR server or service that receives and stores the hepatitis C data.

Preconditions

Preconditions describe the state of the system, from a technical perspective, that must be true before an operation, process, activity, or task can be executed. Preconditions are what needs to be in place before executing the use case flow.

The preconditions for the hepatitis c use case include:

• Use Case Trigger: a hepatitis C RNA positive test result has been recorded in the EHR

• EHR and public health systems expose HL7 FHIR APIs

• Pertinent data elements are captured discretely in the EHR

• Public Health uses allowed by HIPAA and other statutory authority have been defined and implemented

• Provisioning workflows have been established. The provisioning workflow includes activities that publish the various metadata artifacts required to make EHR data available to public health and/or research. These activities include publishing value sets, trigger codes, reporting timing parameters, survey instruments, structures for reporting etc. These artifacts are used subsequently in data collection and reporting workflows.

• Data use agreements are in place when needed

• All patient encounters required to initiate and move through the care cascade take place (i.e., the patient attends) with authorized providers, and requisite steps (e.g., tests ordered, tests performed, test results received, drug prescribed) are performed and captured in the EHR using approved standards

• Registry and state/local consent protocols are followed when sending supplemental reports for non-reportable conditions

Use Case Flows and Diagrams

The user stories describe the workflow for reporting hepatitis C diagnosis and treatment (eICR). The sections below highlight the abstract model, main flow, activity diagram, and sequence diagram for the workflow.

Hepatitis C electronic Initial Case Reporting (eICR)

The electronic Initial Case Report (eICR) is termed “initial” because the report may be the first report made to public health from the clinical provider, containing just enough pertinent data for PHAs to initiate an investigation or other appropriate public health activities as necessary.

eICR Process Abstract Model

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

eICR Main Flow

The table below illustrates each actor, role, activity, input, and output of each step of the hepatitis C electronic Initial Case Reporting (eICR) workflow.

Table 1. Hepatitis C electronic Initial Case Report (eICR) Main Flow

eICR Activity Diagram

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.

Figure 4. Hepatitis C eICR Sequence Diagram

Postconditions

Postconditions describe the state of the system, from a technical perspective, that will result after the execution of the operation, process activity, or task.

Postconditions for the hepatitis C use case include:

• A hepatitis C case report and longitudinal case information resides in a registry.

Alternate Flow(s)

The hepatitis C use case has identified flows that include alternate pathways for the exchange of hepatitis C data which include:

• Convey care cascade elements to clinical registries and HIEs to support population health management activities by healthcare providers and payer

• Transfer HCV data elements for research, augmented surveillance, and population health management

Data Requirements

The table below includes the data requirements for the hepatitis C use case based on the abstract model and the use case flows^[8].

A link to the detailed data requirements spreadsheet will be provided.

Table 3. Hepatitis C Data Elements

Policy Considerations

The policy considerations for the use case to be implemented in the real-world include:

• MedMorph will use existing frameworks (e.g., FHIR APIs) for the exchange of data.

• When there is a third party, a data use or business use/associate agreement may be needed (e.g., APHL).

• Public Health Agencies may have state-specific restrictions on collecting protected classes of data (e.g., AIDS status, mental health status, SUD/OUD).

  • If the patient gives consent for sharing of AIDs, mental health, etc. data the burden would be on the sending system.

  • For research use cases, there must be consent before the data is sent.

• For jurisdictional restrictions on data that can not be collected, the MedMorph Reference Architecture will make provisions for defining actions (e.g., redaction, filtering, removal, validation) before submission. The actions could be triggered based on the content of specific data elements.

  • The MedMorph Reference Architecture will do an additional validation check on the data before the data leaves the healthcare organization. This is important in cases of a healthcare organization reporting to multiple jurisdictions.

• What if more data is sent that what is requested?

  • —Registries may have restrictions on collecting certain information. For example, cancer registries collect comorbidity information, but some of them are restricted from collecting information about AIDS or mental health conditions as a comorbidity

  • This should be handled by policy and processes around the data received.

  • The data generator should be clear on what data is being requested and the data provided should only be the data requested.

  • The Reference Architecture IG will ask for feedback during the ballot process on if the MedMorph Reference Architecture should define an acknowledgment mechanism for notifications when additional data is received.

Non-Technical Considerations

The non-technical considerations for the use case to be implemented in the real-world include:

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

      • https://www.healthit.gov/topic/leading-edge-acceleration-projects-leap-health-information-technology-health-it

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

Appendices

Related Use Cases and Links

References to Appropriate Documentation

Terms and Definitions

Direct Acting Antiviral (DAA) Therapy: Medications targeted at specific steps within the HCV life cycle.

electronic Case Reporting (eCR): The automated generation and electronic submission of reportable diseases and conditions from an electronic health record (EHR) to public health agencies.

HCV Antibody Test: Determines infection of the hepatitis C virus (HCV). The hepatitis C antibody test looks for antibodies that the body produces in response to the presence of HCV.

HCV Care Cascade: Includes a series of necessary and inter-linked steps including the following: HCV screening by antibody testing, HCV confirmation with HCV RNA testing, linkage to HCV care, retention in care, prescription of HCV therapy, adherence to treatment, and finally achievement of SVR.

HCV RNA Test: A blood test used to diagnose hepatitis C and measure the levels of virus in the bloodstream.

Hepatitis C: Hepatitis C is a liver infection caused by the hepatitis C virus. Hepatitis C can range from a mild illness lasting a few weeks to a serious, lifelong illness. Hepatitis C is often described as “acute,” meaning a new infection or “chronic,” meaning lifelong infection.

• Acute hepatitis C occurs within the first 6 months after someone is exposed to the hepatitis C virus. Hepatitis C can be a short-term illness, but for most people, acute infection leads to chronic infection.

• Chronic hepatitis C can be a lifelong infection with the hepatitis C virus if left untreated. Left untreated, chronic hepatitis C can cause serious health problems, including liver damage, cirrhosis (scarring of the liver), liver cancer, and even death.

Hepatitis C Virus (HCV): Causes hepatitis C.

Nucleic Acid Test (NAT): a technique used to detect a particular nucleic acid sequence and thus usually to detect and identify a particular species or subspecies of organism, often a virus or bacteria that acts as a pathogen in blood, tissue, urine, etc.

Use Case: Document used to capture user (actor) point of view while describing functional requirements of the system. They describe the step by step process a user goes through to complete that goal using a software system. A Use Case is a description of the ways an end-user wants to "use" a system. Use Cases capture ways the user and system can interact that result in the user achieving the goal. (adapted from https://www.visual-paradigm.com/)

User Story: A User Story is a note that captures what a user does or needs to do as part of his/her work. Each User Story consists of a short description written from user's point of view, with natural language. (adapted from: https://www.visual-paradigm.com/)

[1] https://www.cdc.gov/surveillance/projects/bridging-public-health-and-health-care-better-exchange-better-data.html

[2] http://nationalacademies.org/hmd/Reports/2016/Eliminating-the-Public-Health-Problem-of-Hepatitis-B-and-C-in-the-US.aspx

[3] https://www.hcvguidelines.org/evaluate/testing-and-linkage

[4] https://www.hcvguidelines.org/treatment-naive/simplified-treatment

[5] https://www.hcvguidelines.org/evaluate/testing-and-linkage

[6] https://www.healthit.gov/isa/representing-patient-pregnancy-status

[7] Adapted from https://www.healthit.gov/faq/what-electronic-health-record-ehr

[8] An asterisk indicates data element came from https://www.cdc.gov/hepatitis/statistics/surveillanceguidelines.htm