1. Project Overview

The Making EHR Data More Available for Research and Public Health (MedMorph) project seeks to advance public health and patient-centered outcomes by using emerging health data and exchange standards, such as Health Level 7 (HL7) Fast Healthcare Interoperability Resources (FHIR) and Clinical Quality Language (CQL), to develop and implement an interoperable solution that will enable access to clinical data. The MedMorph project fits within the Centers for Disease Control and Prevention (CDC) strategic imperative of transforming how data is collected, used and shared through modern Information Technology (IT) capabilities to save lives and improve health. The MedMorph project is funded by the Health and Human Services (HHS) Assistant Secretary for Planning and Evaluation (ASPE) Patient-Centered Outcomes Research Trust Fund and executed by the Center for Surveillance, Epidemiology, and Laboratory Services (CSELS) to advance research and public health goals.

The project is aiming to leverage the maturation of standards and requirements for certification of health information technology by the Office of the National Coordinator for Health IT (ONC) that underpin many EHRs. Examples such as Fast Healthcare Interoperability Resources (FHIR), the ONC 2015 Edition Common Clinical Data Set (CCDS), 2015 Edition Cures Update - United States Core Data for Interoperability (USCDI) Version 1, February 2020 and standardized application programming interfaces (API) for patient services have created a health IT environment that is ripe for developing standards based scalable and extensible solutions to overcome interoperability challenges.

1.1 Project Execution Approach

The project will create fully modeled use cases across three distinct areas namely hepatitis C virus [HCV], cancer reporting and health care surveys to inform the design of a scalable and extensible reference architecture to facilitate data exchange for both key patient-centered research questions and public health surveillance system requirements. The reference architecture aims to minimize the burden on both the senders and receivers of data by providing a common method for obtaining data for research and public health for multiple conditions or uses, which will be documented in HL7 implementation guides. The project will also develop a reference implementation to pilot and demonstrate a standards-based interoperable solution for data exchange between EHR systems and public health/research systems. The CDC has established a Technical Expert Panel (TEP) to inform and guide the development of the technical approach and the interoperable solution.

1.2 Reference Architecture Work Group (RA WG) Overview

The Reference Architecture Work Group is responsible for developing the reference architecture which can be used to implement the artifacts generated by the other workgroups. These artifacts include the use cases developed by the use case work groups, the workflows developed by the business and clinical flows work group, and the data elements defined by the data standards work group. In addition, the RA WG will take into consideration existing HL7 implementation guides for eICR defined using both CDA standard and FHIR standards.

1.2.1 Guiding Principles

The reference architecture must try to reduce provider burden while making EHR data available to research and public health.
The reference architecture must align with existing standards (HL7 FHIR, CDA ) and regulations (ONC 2015 Edition, 2015 Edition Cures Update, Trusted Exchange Framework and Common Agreement (TEFCA), etc.) while improving the timeliness and completeness of data received by public health and research.
To enable efficient and effective use and reuse of the guideline specification in downstream capabilities; accelerate the development of computable guideline specifications and interventions through an integrated, cross functional, rapid-cycle (Agile) development process (inclusive of local implementation processes).
Promote configurability to allow for customizations in workflows.

1.2.2 In-Scope

The Reference Architecture will

Define the API mechanisms, Inputs and Outputs for each API used to access and exchange data.
Define the mechanisms that will be used to trigger the workflows
Define the provisioning mechanisms that could be used to automate the triggering and reporting of data
Define trust services such as (pseudonymization, anonymization, de-identification, etc) that will be needed for certain use cases
Accommodate Authorities and policies identified by the other WGs and regulations.

1.2.3 Out-of-Scope

The following aspects are out-of-scope for developing the Reference Architecture

Enabling Claims data access to research and public health
Changes to the data capture screens in the EHR and/or changes to clinical workflows are not prescribed as part of the RA. Providers may use their choice of apps/screens/systems to enter the data into the EHR independent of the Reference Architecture.
Any data not accessible by FHIR API.
Clinical care setting policies such as the collection of consent for data sharing

1.3 Technical constraints and/or considerations

This section identifies any specific technical constraints and/or considerations that should be noted before developing the reference architecture

HL7 FHIR Version: The project will use FHIR Release 4 as the target as it aligns with the 2015 Edition Cures Update and will most likely be the version that would be in production and may serve as the platform that enables MedMorph capabilities.
Reducing Provider Burden: The Reference Architecture will explore options where the access to EHR data is enabled without changes to existing workflows and/or increasing provider burden (for e.g requiring more clicks or data entry). One way to achieve this is for the reference architecture to outline capabilities that can be triggered to perform reporting based on specific events in clinical workflows but are not provider facing.
Impact on EHR systems: The Reference Architecture will outline capabilities that will minimize any additional load on EHR systems due to the reporting function. For example, if the Reference Architecture outlines capabilities that are constantly querying the EHRs during regular business hours it would affect the performance of the EHR system. This would indirectly affect the provider’s efficiency.
Submission of Duplicate Reports: The Reference Architecture will outline capabilities that will minimize sending duplicate reports to public health and/or research for the same patient for the same episode of care from the same clinical care setting.

2. Abstract Model of Actors and Systems

This section covers the Actors and Systems that would be interacting to realize the capabilities of the use cases. The focus of the abstract model is to define the actors/systems and their capabilities, data flows, and interactions.

Figure 1: High Level Model of Actors and Systems

2.1 Actors and Systems Definitions:

The following are the definitions of the actors and systems.

Electronic Health Record (EHR): 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:
1. Contain a patient’s medical history, diagnoses, medications, treatment plans, immunization dates, allergies, radiology images, and laboratory and test results
2. Allow access to evidence-based tools that providers can use to make decisions about a patient’s care
3. 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.

2. Provider: A person who is participating in the care delivery process for a patient. In addition to delivering care, the Provider also updates the EHR with the patient data captured during the workflow and signs off on the content of the patient record once it is updated. The Provider can be the individual doctor, nurse, admin staff or a combination of different people.

3. Knowledge Artifact Repository: Enables the full spectrum of reporting and querying for programs, studies, and initiatives. Knowledge Artifact Repository represents the system that is used to distribute metadata such as surveys, trigger codes, timing constraints, decision support artifacts, knowledge artifacts to:

Identify if reporting needs to be performed for a patient
Identify the timing parameters for the reporting
Identify the data that needs to be collected for reporting
Identify the structure of the report
Identify decision support rules for reporting

Note: Knowledge artifacts do not contain any PHI or PII information.

4. Health Data Exchange App/ 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 metadata repository 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 SMART on FHIR App which can be distributed to clinical care via EHR vendor specified processes. The EHR vendor specified processes are followed to enable the HDEA/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 HDEA/backend services app within the organization.

5. 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 HDEA/backend services app.

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

7. Data Repository: A system that is receiving the data from the clinical care. Data Repository is used to represent systems such as a cancer registry, National Healthcare Survey data store, surveillance systems, and electronic vital records systems. Data Repositories are actively managed and are used to receive data, store data, and perform analysis as appropriate. These data repositories could be operated or accessed by PHA (or their designated organizations), research organizations with appropriate authorities and policies.

8. Public Health Authority (PHA): A government or a government designated organization that may receive the data from Trusted Third Parties or provider organizations using appropriate authorities and policies. PHA may also analyze the data and initiate responses back to clinical care. For more detailed information on PHA please refer to https://www.hhs.gov/hipaa/for-professionals/special-topics/public-health/index.html.

9. Research Organization: An organization that can access the data from clinical care or data repositories for research purposes with appropriate data use agreements, authorities, and policies.

NOTE: The abstract model interactions and capabilities are valid even when the EHR vendor bundles the HDEA/backend services app and Data/Trust Services capabilities within the EHR software.

The abstract model actors and systems will be used to define the various workflows identified in the use cases. The workflows identified in the use cases include

Provisioning workflow
Notification workflow
Data collection and Submission Report creation workflow
Data submission workflow
Receiving response/acknowledgement workflow

The next few sub-sections will flesh out the various interactions between the systems and actors for each of the workflows.

3. Workflows and Models

3.1 Provisioning workflow

The provisioning workflow includes activities that publish the various knowledge 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. The interactions between the various abstract model actors and systems to achieve the provisioning activities are identified in Figure 2 below.

Figure 2: Provisioning workflow

Note: If the EHR implements the HDEA/backend services app functionality within the EHR, then steps P2, P3 and P4 will be executed within the EHR.

3.1.1 Architecture Decisions

Decision 1: 

Authenticate and authorize artifact consumers.
- Validate that only authorized users/systems are accessing the artifacts and use them.

Decision 2:

Verifying that the Knowledge Artifacts are not tampered with since they have been published.
Validate the publisher to be a Trusted Publisher.
- Maintaining of the integrity of the artifacts and mechanisms to verify the integrity is required.

Security Mechanism Chosen for IG:

Decision 3:

Healthcare Organizations will determine when to operationalize (Activate/De-activate) a particular set of Knowledge Artifacts (Queries that may be requesting data).
- Best Practices can be documented in the IG to achieve this.
Healthcare Organizations will independently determine if the scope of the data being requested is appropriate and if the artifacts are error free from a logic standpoint.

IG Material to be included: Need Help from WG members to draft a set of guidelines that we can publish in the IG

For example: Operationalize new artifacts within 60 days of publishing.
For example: Review the query results and the data accessed and verify consent is being collected to release the data elements being requested under the appropriate authority.

Decision 4:

Knowledge Artifacts can implement different mechanisms to allow authorized users from PHA/RO to submit Knowledge Artifacts
- We can point to specific best practices for implementing authentication and authorization mechanisms for the users to submit the artifacts.

IG Material to be included: Need Help from WG members to draft a set of guidelines that we can publish in the IG

For example: PHA/RO users will be authenticated and authorized before submission.
For example: Artifacts will be validated to meet mandatory requirements according to the profiles.

3.2 Notification workflow

The notification workflow includes the activities whereby a provider performing care delivery updates a patient’s data in the EHR. The data update should trigger notifications to other systems to initiate downstream processing without provider involvement. The interactions between the various abstract model actors and systems for the notification workflow are identified in Figure 3 below. In the figure below the EHR is assumed to be a FHIR enabled EHR which does not implement the HDEA/backend services app and Data/Trust Services capabilities as part of its delivered product.

Figure 3: Notification workflow

Note: If the EHR implements the HDEA/backend services app functionality within the EHR, then steps N1, N2, N3, N4 and N5 will be executed within the EHR.

3.2.1 Notification Event Types:

For the MedMorph project, the notification event types that need to be considered

Addition of data (Entering new data into the EHR) - Create
- Examples: Adding new diagnosis, medications, filling in the Encounter end time
  - The specific data elements have to be documented for each use case in consultation with the SMEs.
Modification of data (Changing existing data in the EHR) - Update
- Examples: Updating existing medication information
  - The specific data elements have to be documented for each use case in consultation with the SMEs.
Workflow
- Examples: Closing discharge diagnosis or closing the encounter.
Timing
- Examples: Time factor may be operated in the app to wait 48 hours, after the start of the encounter, after the end of the encounter.

Should the following event types be considered for MedMorph ?

Removal of data (Removing data from EHR) ??
- Examples: Not sure whether we should consider this .. ? Patient Merges ?
Data Access (Someone accessing the data for any purpose)
- Examples: Someone accessing the data for printing, sending to PCP ?

3.3 Data collection and Submission Report creation workflow

The Data collection and Submission Report workflow includes includes the activities that collect the necessary data from the EHR and create the reports for submission to the PHA and/or Research Organizations. The interactions between the various abstract model actors and systems for the data collection and submission report creation workflow are identified in Figure 4 below.

Figure 4: Data collection and Submission Report creation workflow

Note 1: If the EHR implements the HDEA/backend services app functionality and Data/Trust Services within the EHR, then steps D1, D2, D3, D4, D5, D6, and D7 will be executed within the EHR.

Note 2: If the EHR implements the HDEA/backend services app functionality within the EHR, then steps D1, D2, D3, D4 will be executed within the EHR and D5, D6, D7 will be executed outside of the EHR.

3.3.1 Architecture Decisions

Decision 5:

Ultimate recipient will not be authenticated by the HDEA/backend services app but the address is expected to be valid per the Knowledge Artifact.
HDEA/backend services app will need to authenticate and get authorized with the TTP which is the immediate next hop.
- Will need to maintain the Confidentiality and Integrity of the data transmitted.
TTP will authenticate and get authorized with the PHA/RO for its immediate hop.
- Will need to maintain the Confidentiality and Integrity of the data transmitted.

Decision 6:

6A) TTP will need to provide
- Basic Routing Services without examining the content of the message/payload.
6B) TTP may need to provide
- Content Based validation and routing services.

Security Mechanisms to be used in IG - Discussion:

6A Requirements:
- End to End encryption of the payload requires knowing some kind of secret/algorithm/certificate exchange used between the sender and receiver.
Solution Options:
- Knowledge Artifact can indicate if end-to-end encryption is required
  - When it is desired, can publish a URL for the public key that can be used for encryption.
- Other Certificate discovery kind of options ?
- Using Secrets and algorithms known only to the sender/receiver may not be interoperable and will introduce tight dependencies or security vulnerabilities.
6B Requirements:
- No additional requirements beyond Decision 5

Security Mechanism Chosen for IG: Same as Decision 5

Decision 7:

When Legacy Transport (Existing transport mechanisms such as Direct, XDR) are used to transmit FHIR content, the security models of the Legacy Transport mechanisms will be used.

IG Material to be included:

Point to the security models and artifacts for implementing Legacy Transport.

3.4 Data Submission workflow

The Data Submission workflow includes the activities that route the data from the healthcare organization to the PHA/Research Organization. Figure 5 below shows the data submission workflow with and without Trusted Third Party Intermediaries.

Figure 5: Data Submission workflow with Intermediaries

Note: If the EHR implements the HDEA/backend services app functionality, then the steps S1 and S2 will be executed within the EHR.

3.5 Receiving Response/Acknowledgement workflow

The Receiving Response/Acknowledgement workflow includes activities that create responses for received submissions and are routed back from the PHA/Research Organization to healthcare. This workflow is optional and may not be executed as part of all use cases. The Reference Architecture should be able to function with or without this workflow. Figure 6 below shows the workflow details.

Figure 6: Receiving Response/Acknowledgement workflow

Note: If the EHR implements the HDEA/backend services app functionality, then steps R4, R5, and R6 will be executed within the EHR.

3.5.1 Architecture Decisions

Decision 8:

Ultimate recipient will not be authenticated by the PHA/RO but the address is expected to be valid based on the messages received (Message-ReplyTo).
PHA/RO will need to authenticate and get authorized with the TTP which is the immediate next hop.
- Will need to maintain the Confidentiality and Integrity of the data transmitted.
TTP will authenticate and get authorized with the HDEA/backend services app for its immediate hop.
- Will need to maintain the Confidentiality and Integrity of the data transmitted.

Decision 9:

9A) TTP will need to provide
- Basic Routing Services without examining the content of the message/payload.
9B) TTP may need to provide
- Content Based validation and routing services

Security Mechanisms to be used in IG - Discussion:

9A Requirements:
- End to End encryption requires knowing some kind of secret/algorithm/certificate exchange used between the sender and receiver.
Solution Options:
- Each Client can publish its public key and that can be used by Sender to encrypt the payload end to end.
  - When it is desired, can publish a URL for the public key that can be used for encryption.
- Other Certificate discovery kind of options ?
- Using Secrets and algorithms known only to the sender/receiver may not be interoperable and will introduce tight dependencies or security vulnerabilities.
9B Requirements:
- No additional requirements beyond Decision 8

Security Mechanism Chosen for IG: Same as Decision 8

Decision 10:

When Legacy Transport (Existing transport mechanisms such as Direct, XDR) are used to transmit FHIR content, the security models of the Legacy Transport mechanisms will be used.