Blueprint for aligned data exchange for research and public health

Abstract

Making EHR Data More Available for Research and Public Health (MedMorph) is a Centers for Disease Control and Prevention-led initiative developing and demonstrating a reference architecture (RA) and implementation, including Health Level Seven International Fast Healthcare Interoperability Resources (HL7 FHIR) implementation guides (IGs), describing how to leverage FHIR for aligned research and public health access to clinical data for automated data exchange. MedMorph engaged a technical expert panel of more than 100 members to model representative use cases, develop IGs (architectural and content), align with existing efforts in the FHIR community, and demonstrate the RA in research and public health uses. The RA IG documents common workflows needed to automatically send research data to Research Patient Data Repositories for multiple use cases. Sharing a common RA and canonical data model will improve data sharing for research and public health needs and generate evidence. MedMorph delivers a robust, reusable method to utilize data from electronic health records addressing multiple research and public health needs.

INTRODUCTION

The need for timely access to real-world data for research and public health surveillance has been magnified due to the COVID-19 pandemic.¹ However, data transfer from electronic health records (EHRs) for use in research and public health uses is labor intensive, with manual steps required both initially for determinations of equivalent terms (eg, between local codes and standardized codes), also known as “mapping,” and periodically to transfer or process the data.² The interoperability challenges stem from variability among EHRs, and among specific implementations of those EHRs, in data models, coding schemes, and tools for extraction and transformation. This results in a burdensome process for clinicians and healthcare provider organizations and causes delays and data quality issues for both researchers and public health agencies (PHAs).

The 21st Century Cures Act³ authorized the Office of the National Coordinator for Health Information Technology (ONC) to mandate interoperability requirements in its certification criteria for health information technology (health IT) through the adoption of standards, such as Fast Healthcare Interoperability Resources (FHIR), that promote the development of scalable, extensible, and interoperable solutions and allow for automated health data exchange. In support, the Centers for Disease Control and Prevention (CDC) established a cross-cutting project, “Making EHR Data More Available for Research and Public Health (MedMorph),”⁴ funded by the Patient-Centered Outcomes Research Trust Fund.

MedMorph brings together multiple FHIR-based and related health IT standards into a common reference architecture (RA) that can be used for both research and public health purposes. This aligned data exchange approach is a key feature of the RA that can help reduce the burden on healthcare providers and organizations in submitting or contributing data for public health reporting or research, a key goal of the 21st Century Cures Act.³

In addition to FHIR, MedMorph has leveraged other existing standards, including the US Core Data for Interoperability (USCDI),⁵ Clinical Quality Language (CQL),⁶ Electronic Case Reporting (eCR) implementation guide (IG),⁷ Data Access Framework (DAF) IG,⁸ and Common Data Model Harmonization (CDMH) IG.⁹ MedMorph was harmonized with other initiatives and builds on, for example, some architectural elements and FHIR profiles from eCR.¹⁰ To ensure complementary rather than duplicative work, MedMorph is coordinating with other initiatives such as Minimal Common Oncology Data Elements (mCODE),¹¹ Common Oncology Data Elements eXtensions (CodeX),¹² Health Level Seven International (HL7) accelerator, Vulcan HL7 accelerator,¹³ and Clinical Registry Extraction and Data Submission (CREDS) IG.¹⁴

The value of the MedMorph approach is the standardization of data extraction and exchange across EHRs, provider organizations, research institutions, and public health entities to improve the simplicity, consistency, and portability of implementing interoperability. MedMorph offers a path, aligned between research and public health, to leverage EHR FHIR implementations for data exchange between EHRs and specific endpoints (eg, Research Patient Data Repositories [RPDRs]).

OBJECTIVE

To help minimize burden by automating data exchange, MedMorph is creating a reliable, scalable, generalizable, configurable, interoperable solution to exchange EHR data from multiple EHR platforms for multiple research and public health use cases. For example, there may be a need to use data that originated in many different EHR systems to answer questions about the course of a specific disease, such as how well patients are completing the care cascade in hepatitis C or long-term effects of COVID-19. This may be to address a research question or monitor a public health program. The objective is to develop and demonstrate an RA and implementation, including HL7 FHIR IGs, that describes how FHIR and related standards can be leveraged for automated data exchange of clinical data to align research and public health needs.

MATERIALS AND METHODS

Rather than starting with a single use case and trying to generalize to additional needs, MedMorph modeled 3 diverse and representative use cases (ie, infectious disease—Hepatitis C reporting; noncommunicable disease—Reporting to Cancer Registries; healthcare utilization—Health Care Surveys), working to ensure that the RA satisfied all 3. A diverse and representative technical expert panel (TEP) incorporates perspectives from a variety of partners (eg, researchers, clinicians/healthcare organizations, public health organizations, health IT standards experts, health IT developers, federal agencies). Additional use cases (eg, eCR, eCare Plans for multiple chronic conditions, chronic kidney disease, cardiovascular disease, diabetes, birth and death reporting, occupational data for health) were represented and provided broader perspective into the development of the RA. The TEP included 3 workgroups (RA, consolidated use case, and evaluation) with over 100 individuals actively participating in at least one workgroup since October 2019. The RA is documented in an FHIR IG,¹⁵ which underwent balloting through HL7 in January 2021 as a Standard for Trial Use.¹⁶

Requirements gathering employed a template for each use case to document the problem statement, goals, scope, actors, abstract model, user stories and diagrams (including steps in the workflow), preconditions, postconditions, and data requirements. For the research use case, data requirements, which initially focused on the Patient-Centered Outcomes Research Network (PCORnet) Common Data Model (CDM),¹⁷ were mapped to FHIR US Core,¹⁸ and USCDI.⁵

By comparing requirements across a breadth of use cases, the commonalities were identified by the consolidated use case workgroup, which focused on subject matter. The technically focused RA workgroup shaped the commonalities into the requirements for the RA, ultimately resulting in the balloted MedMorph RA IG. Content IGs, which apply the RA to specific use cases, are under development for balloting and include profile constraints, special considerations, and other related data needs. For research, we focused on PCORnet as an exemplar to help further define requirements needed to populate RPDRs from EHRs.¹⁹

The MedMorph RA IG broadly defines these requirements and provides an aligned data exchange approach with public health reporting. The research-specific requirements are being further specified in a “research data exchange content IG.”²⁰ Content IGs are also being developed in parallel for public health reporting use cases using the same approach but are not described in this paper. With input from the TEP, each of the research use cases will leverage the same architecture as the public health use cases and will specify additional requirements for research that are not already represented in the RA IG. While initially documenting those specifications to work with PCORnet needs, the intent is that these specifications will be documented in a way that makes them applicable more broadly in research.

To test the MedMorph approach, a pilot was initiated in May 2021. Results from this pilot will be disseminated but are not part of this paper.

RESULTS

The RA focuses on a common set of actors and systems that can accommodate public health and research needs (Figure 1). The RA IG documents the common workflows,²¹ needed to automatically send research data to RPDRs, also called data marts, across multiple research use cases: (1) populating an RPDR from an EHR within an organization’s firewall and (2) populating an externally hosted RPDR from an EHR.

Figure 1.

MedMorph abstract model of actors and systems. Step 1: A Public Health Agency (PHA) or a Research Organization (RO) creates a Knowledge Artifact (KA) and makes it available via the Knowledge Artifact Repository (KAR). Step 1a: KARs, which implement notifications, can optionally notify the subscribers (EHRs, Backend System App, Administrators) of changes in the KAs. Step 2: Backend Service App (BSA) queries the KAR to retrieve a KA. Step 2a: BSA receives the KA as a response to the query in Step 2. Step 3: BSA processes the KA and creates subscriptions in the EHR’s FHIR Server so that it can be notified when specific events occur in clinical workflows. Step 4: Providers, as part of their clinical workflows, update the data in the EHR patient chart. Step 5: EHR notifies the BSA based on subscriptions that have been created in Step 3. Step 6: BSA queries the EHR for patient’s data. Step 6a: BSA receives the response from the EHR with the patient’s data. Step 7: After the creation of the report with identifiable data that needs to be submitted, the BSA invokes Data/Trust Services (DTS) to deidentify, anonymize, and pseudonymize the report as needed (Note: DTS are not invoked if the data must remain identifiable, as with most public health use cases). Step 7a: BSA receives the deidentified, anonymized, or pseudonymized report (only if DTS have been invoked). Step 8: The BSA submits the created report in Step 7 to the PHA/RO directly without any Trusted Third Parties (TTPs) acting as intermediaries. Step 8a: PHAs/ROs can require TTPs to act as intermediaries to receive reports from clinical organizations. For these scenarios, the BSA submits the created report to the TTP. Step 8b: The TTP receives a submitted report from the BSA and forwards the report to the PHA/RO. Step 9: The PHA/RO submits a response back to the healthcare organization based on the submitted report. The response transaction can be synchronous (immediately w.r.t. Step 8) or asynchronous (after a period of time). Step 9a: The PHA/RO can require TTP to act as intermediaries to submit reports to clinical organizations. For these scenarios, the PHA/RO submits a response to the TTP. Step 9b: The TTP receives the submitted response from the PHA/RO and forwards the response to the BSA, which is part of the healthcare organization. Step 10: The BSA writes back the response from the PHA/Research Organization to the EHR as appropriate (Note: The response may have to be re-identified in some scenarios using Data/Trust Services before it is written back to the EHR).

The RA IG uses FHIR R4,²² as the canonical data model, leveraging existing FHIR profiles whenever possible (eg, profiles in FHIR US Core),²³ and creating common, reusable FHIR profiles when they did not already exist as FHIR-related standards (eg, US Public Health Profiles).^24,25 The Bulk Data IG²⁶ and SMART on FHIR Backend Services Authorization²⁷ specifications were also reused . Additional functionality, such as an automated way to establish appropriate authorization to collect or query the data (eg, institutional review board [IRB] approval, informed consent) prior to executing those actions, is desired.

For any use case, both the PHAs and research organizations (ROs) would author knowledge artifacts (KAs) in the knowledge artifact repository (KAR) based on the respective FHIR content IGs for the use case(s) of interest. KAs can include rules, value sets (eg, required in a case report or for limited data sets), triggers (eg, specific diagnosis or lab codes, encounter close, etc.), etc. Once the KAs are updated in the KAR, the KAR notifies the backend services app, which begins the cascade of events described in Figure 1. The data required for public health reporting and for research data collection would flow in parallel to the respective endpoints at the PHA and RO.

One goal with any FHIR content IG is to reuse as much content (eg, FHIR profiles) as possible and only create new content when there is a critical need that cannot be represented by existing content. The hierarchy of reuse for a US-based use case would begin with using FHIR US Core profiles,²³ then other common profiles, such as those that will be part of a national US Public Health Library,^24,25 then a multiuse content IG such as eCR IG,⁷ or research data exchange IG.¹⁹ If none of these existing content IGs have reusable profiles for specific concepts that must be part of the content for the use case, then and only then should new extensions or profiles be created and included in a separate use case-specific FHIR content IG. This “hierarchy of reuse” approach creates efficiencies of scale as more and more use cases leverage it for data requirements, which should help reduce the burden on both the senders and receivers of data.

FHIR content IGs can also be shared among multiple use cases. For example, the hepatitis C use case can leverage the eCR IG,⁷ which supports 108 (and counting) public health reporting use cases. It can also leverage the research data exchange IG,²⁰ which includes the PCORnet limited data set as the example content (based on the PCORnet common data model mapped to FHIR) and can be used across the PCORnet networks as well as leveraged by other research uses cases with minimal additional effort needed. For instance, a medical specialty society could reference both the MedMorph RA IG and research data exchange IG as the basis of their requirements for populating a repository and develop a simple FHIR content IG to identify any specific content (eg, value sets, triggers, etc.) that is not in the PCORnet limited data set. Similarly, public health reporting use cases such as cancer can partially leverage shared content IGs like eCR, then add cancer-specific content that is not otherwise specified. For a healthcare utilization use case, such as healthcare surveys, this same pattern could be used, though in this case, the primary shared content IG is the FHIR US Core IG.²⁸

DISCUSSION

Sharing a common RA, canonical data model, and data exchange standards (ie, FHIR) between research and public health is an important step toward more quickly generating evidence and tracking public health conditions, especially in times of emergency response such as with the COVID-19 pandemic.²⁹ Being able to populate and query RPDRs with a common approach for EHR extraction and exchange provides the ability to more easily share, compare, or combine data between ROs, even if each organization chooses to use different data models internally. Sharing a common architecture with public health, again using common data models for EHR extraction and exchange, etc., allows for data to be more easily reported, compared, or combined with other public health data.³⁰ The next step toward this goal is to develop a “research data exchange” content FHIR IG, which mirrors the approach in public health of developing content IGs that provide use case-specific content requirements while using the architectural elements and common profiles provided in the MedMorph RA IG.

Automation is key to attaining real-time data exchange. This is facilitated by local mappings of data to standards-based, open application programming interfaces (APIs; eg, FHIR APIs specified in the RA IG), which are complete, accurate, and consistent between systems.³¹ To date, this has been a major technological hurdle and must be addressed by working toward complete coverage of data needed by multiple use cases. The MedMorph RA will be initially tested in a real-world pilot with a variety of clinical sites (eg, academic medical centers, rural hospitals, federally qualified health centers, etc.), each using different EHR systems, sending automated reports to a PHA and an RO. Among the areas to be evaluated are differences in level of effort or resources required by each type of organization to implement the MedMorph RA, including efficiencies gained, to help characterize the anticipated impact for each type of organization concurrently sending data to a PHA and an RO. The HL7 research data exchange content IG, and potentially the RA IG, will be updated based on findings during the pilot.

Another key to fully automating data exchange is the ability to check for appropriate authorization to collect or query the data and verify that only the authorized data are exchanged in a given transaction. In public health, this is largely based on federal and state laws and legal agreements (eg, data use agreements)³²; in research, this is based on compliance with IRB approvals, which may mandate obtaining and retaining informed consent from individuals. Currently, there is no published FHIR standard for IRB approvals and informed consents, though there is an IG being developed for single IRB for multisite research studies.³³

Important challenges include variable local mappings, lack of maturity of some FHIR functionality, and the partial rollout of FHIR Release 4 (R4). Differing ways of documenting data are part of the challenge with variable local mappings. For example, in some systems, a medication is documented with its component parts (medication name, dose, route, frequency); in some systems, it is all in one field; and in others, it is documented with the ingredients of the medication rather than the medication name. This may be magnified when the same information is preferred in different formats or levels of detail for research and public health. Some functionality required for the MedMorph RA is still being developed at HL7, such as FHIR Subscriptions.³⁴ Workarounds (eg, local system-dependent app launch) are needed in the meantime. FHIR R4 is still being rolled out, which would initially limit the ability to scale MedMorph. Once these rollouts are complete (eg, based on timelines and regulatory requirements in ONC’s health IT certification criteria³⁵), this will no longer be a limitation.

For EHRs that are cloud-based or centrally hosted, the rollout of or updates to the MedMorph RA and content IGs to multiple healthcare organizations could be done simultaneously. For healthcare organizations, such as community or rural hospitals, that may lack sufficient technology or access to broadband, MedMorph’s standardization of the content potentially provides some efficiencies of scale. Those organizations may not have access to all the tools (eg, APIs) described in the MedMorph IGs, but they could benefit from having parsimonious and harmonized data across multiple use cases. Preventing the need to manually support different data requirements for many different programs, therefore, could help reduce the burden even without the full complement of technology specified.

CONCLUSION

The MedMorph RA IG will provide a tested, robust FHIR-based solution for automated data exchange from EHRs to RPDRs using an approach that shares an architecture with public health reporting. Having multiple use cases supported by the FHIR standard and represented in a common architecture further facilitates the holistic approach needed for full automation. The additional implementation details that are being documented in a research data exchange content IG will be important for operationalization as will the learnings from the real-world pilot.

FUNDING

This work was supported by the Office of the Secretary Patient-Centered Outcomes Research Trust Fund under Interagency Agreement #750119PE090047.

AUTHOR CONTRIBUTIONS

All 3 authors (MM, SS, and WBL) met all 4 of the following authorship criteria and are listed in order based on the amount contributed:

• Substantial contributions to the conception or design of the work; or the acquisition, analysis, or interpretation of data for the work;

• Drafting the work or revising it critically for important intellectual content;

• Final approval of the version to be published; and

• Agreement to be accountable for all aspects of the work in ensuring that questions related to the accuracy or integrity of any part of the work are appropriately investigated and resolved.