Improving Interoperability between Registries and EHRs

Abstract

National performance measurement needs clinical data that track the performance of multi disciplinary teams across episodes of care. Clinical registries are ideal platforms for this work due to their capture of structured, specific data across specialties. Because registries collect data at a national level, and registry data are captured in a consistent structure and format within each registry, registry data are useful for measurement and analysis “out of the box”. Registry business models are hampered by the cost of collecting data from EHRs and other source systems and abstracting or mapping them to fit registry data models. The National Quality Registry Network (NQRN) has launched Registries on FHIR, an initiative to lower barriers to achieving semantic interoperability between registries and source data systems. In 2017 Registries on FHIR conducted an information gathering campaign to learn where registries want better interoperability, and how to go about improving it.

Introduction

PCPI is a Chicago-based, national nonprofit organization focused on performance improvement in the health care delivery system to improve health outcomes. (1) The National Quality Registry Network (NQRN) is a PCPI program that supports clinical registries and promotes their use for performance improvement, measurement and other uses. (2) Clinical registries are organized systems that collect data on patients from pre-determined populations for specific purposes. (3) Registries are important platforms for performance measurement that supports value-based payment programs. (4) A Qualified Clinical Data Registry (QCDR) is an entity that collects clinical data from clinicians participating in the CMS Quality Payment Program, and submits the data to CMS on their behalf for the purpose of program participation. (5) Registries collect data from a number of sources and through a combination of direct, manual and automated input methods. Aside from direct manual clinician input, typically through a secure web interface, common registry source data systems include EHRs, clinical information systems, medical devices and patient portals. The data that registries need to capture from these sources vary in form, structure and meaning, requiring mapping to registry data models, and/or manual clinical chart abstraction into registries. This mapping and chart abstraction work adds to the cost of operating and participating in registries. (6)

In 2016 the registry community through the NQRN program asked for help in improving registry interoperability, primarily to reduce these costs and related burdens, but also to lower barriers to implementing performance measures that span multiple clinical specialties and thus use data from multiple registries. In response, PCPI has launched Registries on FHIR, a registry interoperability initiative and a coalition of society registry stewards, registry and EHR vendors, informaticists and others. The initiative began its work with a fact-finding campaign which resulted in a list of priority areas for potential registry interoperability projects. The campaign also informed the development of an interoperability solution process that begins with a clinical scenario or workflow and results in the generation of technical documentation that supports implementing the interoperability solution in registries and source data systems. The purpose of this paper is to inform the informatics community about what we found. Due to the high cost of obtaining the needed data and the increasing use of registries as measurement platforms that inform value-based payment programs, there is an urgent need to reduce registry data acquisition costs. Improving the ability of registries and source data systems to semantically interoperate is a high priority for these societies and for health care.

Methods

The Registries on FHIR information gathering campaign was designed to increase understanding of registry interoperability needs and understand recommended approaches for developing and testing solutions to interoperability problems. A survey and a set of interview questions were developed for identifying potential interoperability projects. The questions intended for registries and registry vendors asked about problems faced that could potentially be reduced or eliminated with better registry interoperability, the motivations for wanting those problems solved, relevant clinical or operational scenarios, data needs, and barriers that needed to be overcome in order to solve. The interoperability solution process interviews were conducted informally, without working from a set of specific questions.

The registry interoperability needs survey was conducted in June 2017 using SurveyMonkey. The survey was sent to all 2017 QCDRs where a contact email address was found; emails were located for 50 QCDRs. (5) No follow up activities were conducted after the initial survey email was sent. Interviews were conducted in May and June with the registries and registry vendors participating in Registries on FHIR, which were a convenience sample. Four national clinical registries and six registry vendors were interviewed by phone.

Interviews were then conducted with informaticists, including those affiliated with standards-development organizations, industry trade groups and independent consultants in data standards and interoperability. In these interviews, we described the registry interoperability challenge in general and asked for advice on how to solve interoperability problems from a registry perspective.

Results

16% (8/50) of the QCDRs responded to the survey, and an additional 4 were interviewed, for a total of 24% of the 2018 QCDRs. 6 registry vendors were interviewed. Registries reported the greatest level of interest in solving problems related to their specific workflows, and a secondary interest in general interoperability problems. The areas identified are listed in Table 1.

Table 1:

Registry Interoperability Priority Areas

Area	Reporter
Develop common data element standards for data that are used in many registries e.g., demographics, vitals, pain, Activities of Daily Living (ADL) score	Registries and registry vendors
Develop standardized information models that support needs common across many registries e.g., QCDR measures, measure sets needing harmonization, cross-cutting measures	Registries and registry vendors
Develop nationally-accepted specialty-specific data standards e.g., for pathology specimen collection, and make them generally available	Registries
Develop Health Level Seven International (HL7) Fast Healthcare Interoperability Resources (FHIR) implementation guides that incorporate existing data standards i.e., American College of Cardiology data standards	Registries
Improve patient matching; particularly useful in specialties that have a lot of overlap i.e., anesthesia	Registry vendors
Identifyspecific instances of concepts in registries e.g., a system to standardize the way anything is tagged or identified in registries	Registry vendors
Develop technical interoperability standards or guidance for registries	Registry vendors

In interviews with informaticists, a number of steps were consistently identified. The first step is to identify the clinical or operational scenario that may benefit from improved interoperability. This could be expressed in the form of a case or user story, a clinical pathway, or other similar descriptive format. Regardless of the format used, in this step the information needs and flows should be identified and documented. Next an information model should be identified or created that documents and abstracts the data and information needs at a level that allows the needed information to be stored and communicated. Information models capture the semantics of the scenario, and are technology-agnostic. (7) In order for information models to be created that are generalizable, the data elements or concepts they represent need to be agreed upon. As an example, an information model involving smoking cessation will use or define the needed concepts in a consistent manner, so that the same basic data elements are used in a way that preserves meaning across implementations. Depending on the relevant clinical or technology domains involved in the scenario, an HL7 Domain Analysis Model (DAM) may be available or need to be created or updated. DAMs provide a detailed definition of a subject of interest, such as a particular clinical process, at a level of detail useful to domain experts and non-technical stakeholders who have an interest in seeing that domain’s semantics expressed in a standardized way in technology implementations. (8) Additionally, HL7 is collaborating with the Healthcare Services Platform Consortium (HSPC) and other organizations in launching the Clinical Information Interoperability Council (CIIC). The CIIC intends to create an information model repository and setup a governance and support structure for the development and maintenance of clinical information models. (9)

Once the needed information models are identified or created, then technology-specific implementation guidance can be created i.e., in the form of a FHIR Implementation Guide or an Integrating the Healthcare Enterprise (IHE) profile. (10) (11) With this guidance available at least in draft form, an interoperability demonstration can be conducted. In this case, with a registry interoperability problem under investigation, the implementation guide would be used to update the registry, source data systems and possibly also other systems and processes used to support information exchange. The performance of the systems in question may then be measured before and after the change to hopefully demonstrate that the improved performance justifies the work performed. The demonstration work will also provide feedback that can be used to enhance the draft implementation guides as they are made available for general use in their respective standards-development organizations’ standards libraries.

Discussion

Interoperability, even that focused on registries covers a wide area and it is not realistic to expect that a single methodology or set of specific steps can be used to solve registry interoperability problems in general. However, a number of themes came out of the interviews, from which a broad outline of a process could be constructed. Fundamentally, any interoperability in health care is important because of the use of health information technology in most clinical or administrative workflows.

Value-based payment models are driving an increasing need for measurement and comparative analytics that cross multiple clinical specialty or organization boundaries. The current lack of interoperability of health care data and content impairs the industry’s ability to realize better value (decreased costs and increased benefits) for populations and individual patients. To achieve better value, we need to realize the following experiences related to interoperability. Anyone taking care of a patient, including the patient, must have appropriate access to all pertinent data from all sources to make the best-informed decisions. Technical interoperability allows access to data. To deal with the complexity, volume, and velocity of health data, patients, providers, and population health practitioners need decision support from health information technology to understand and intervene in patient care and population health. Semantic interoperability allows health IT to reliably understand the meaning of the information contained in the data, and thus to reliably use them in decision-support algorithms. (12)

In addition to access to data and understanding of the information contained within the data, we need health information technology to capture and facilitate the pertinent health care processes. In order to manage health care services at the individual and organizational levels, an understanding is needed of which processes are effective or wasteful. Process interoperability exists when information systems can make useful recommendations as to the processes to recommend for patients, and thus assist healthcare providers in reliably understanding and implementing a collaborative plan of care.

The health care industry has so far mostly focused on technical interoperability, also known as syntactic or structural interoperability. Health information exchanges and standards such as FHIR are enabling systems to exchange data to support data access. Adoption of standards for technical interoperability is increasing, but the infrastructure that supports data liquidity lags.

Standards that allow meaningful semantic and process interoperability either do not yet exist or are not yet feasible to apply and thus have not been widely adopted in health IT. Almost every provider organization has a different (and largely incompatible) approach to semantic interoperability. Almost no healthcare institution uses standards to represent processes. The lack of interoperability on these levels is a serious problem, as other industries derive most of their value from managing standardized decisions and processes. Robust semantic and process interoperability is critical in medicine, as cooperative care is increasingly the norm, and no one organization can create content for decision and process support that accounts for the best clinical evidence. Semantic and process interoperability is required for robust markets for content and cooperative care that improves health outcomes.

Clinical Registries

Clinical registries collect clinical and administrative data on patients and the care they receive. The primary focus of registry data collection is capturing information about clinical treatment and related patient health outcomes. The resulting registry datasets then support treatment, payment, quality improvement, benchmarking and research, as well as other uses.

Registries specialize in collecting specific data elements of importance to the clinical domains in which they focus. However, certain types of data e.g., demographics are likely collected in all or most registries. Other data such as cardiology clinical data may be collected not only in cardiology-specific registries, but also in other registries capturing data on patients undergoing treatment in other clinical domains for which cardiovascular disease is a factor e.g., cardiology data elements. These may exist in registries focused on surgery, endocrinology and other clinical domains, and despite the commonality of data, most registries are not using a common format for these data elements. There is currently no standard that defines how common data elements should be defined and captured in registries. Some registry stewards have published standards for their specialty-specific data elements, but those standards have not been widely adopted.

EHRs are a common data source for registries. Individual EHR implementations are typically contained within a single health system or provider organization. There are over 1,000 health systems in the United States, and health systems use a number of different vendors for their EHRs. (13) (14) EHR data vary in content, form and structure across EHR implementations, even those from the same vendor. (15) In response, some institutions have implemented data warehouses that provide a single place in which to store data from the multiple data systems that are independently capturing, measuring clinician performance and reporting to evaluating organizations on behalf of the institution. But in looking at data nationally, even health system data warehouses are still very numerous and their data are also not standardized from one data warehouse to another.

Although there is tremendous value contained within individual registry data, the cost of collecting the data and capturing them in registries in a way that preserves the meaning of the information contained within the data i.e., semantic interoperability, continues to be high. The current work required to extract data from EHRs is one-to-one, duplicative and not scalable. This drives up cost, which is high even when looking at data across multiple clinical domains, and thus across multiple registries is even feasible.

Registries capture data in highly structured formats, with a high level of standardization between different patients, case reports and participating clinicians within a single registry, but there is a broad lack of standardization, at all levels of conceptualization, across registries. Registries do not report uniform data (in structure or semantics) so anyone taking a broad look at health outcomes e.g., health systems using analytics platforms, and CMS, must harmonize and normalize the registry information they use at a semantic level to accurately and fairly measure and report on the results of clinical processes and patient health outcomes.

The work required to achieve data liquidity across registries, EHRs and other systems is considerable. Due to the lack of structure and standardization of EHR data, a significant percentage of the data required to calculate performance i.e., performance measures for CMS reporting programs, must be entered in registries via manual clinical chart abstraction. In order to extract data automatically from EHRs, warehouses and other source data systems into registries, custom interfaces between the registry and each individual source data system implementation must be created. These interfaces map the source data into the format and structure required to perform the measure calculations in a way that clinician comparisons on a national level can be made with accuracy and validity. These interfaces add cost and must be implemented for each organization that participates in the registry.

Conclusion

With the continued emphasis in value-based payment, and on measuring health outcomes across organizational boundaries over varying periods of time, demand for information from registries is increasing. But due to the high cost, it is often not feasible to capture all of the data registries need. Additionally, despite the benefits for national performance measurement provided by registries, it is difficult to aggregate data across multiple registries to come up with uniform data that are valid for measuring and improving performance and health outcomes across a wide variety of patient populations, diseases and conditions and the clinical specialties that provide care for those patients.

These and other factors have created a burning platform for increased semantic interoperability between registries and the health IT they exchange data with, so that our return on investment in data collection, measurement and improvement is maximized.

Registries on FHIR is an initiative that aims to improve registry interoperability, in particular interoperability between registries and source data systems such as EHRs. The initiative will begin by examining the current state, and then identifying registry interoperability problems to solve. The scope from which initial projects will be identified includes technical and semantic interoperability between registries and EHRs, and may include work on any relevant level of abstraction from data transport standards down to individual data element standardization. In later phases, the initiative may expand to include other areas such as linking between registries and utilizing semantic web platforms to standardize the way registries, EHRs and clinical applications interoperate.

For each project that Registries on FHIR takes on, the goal will be to demonstrate increased data liquidity within a test group; to show that a state of lower effort or cost to operate registries or capture high-priority data has been achieved by using the infrastructure that has been developed in this project. If applicable the project will then make the infrastructure available for use through NQRN guidance and/or nationally- or internationally-accepted bodies such as standards development organizations.

We will promote any success achieved, and then attempt to use the output each project as a catalyst for further work to affect broader adoption of these and other data standards among clinical registries and other clinical information systems that serve as data sources for or users of registry data.