NARRATIVE/SYSTEMATIC REVIEWS/META-ANALYSIS

Pragmatic Approaches to Interoperability in the U.S.: Surmounting Barriers to Healthcare Data and Information Across Organizations

Bharath Perugu, MBA¹, Varun Wadhwa, BS², Jin Kim, ME³, Jenny Cai, BS (Candidate)³, Audrey Shin, BS (Candidate)⁴ and Amar Gupta, MBA, PhD³

¹Information Technology, ULV, Office Practicum, Fort Washington, Pensylvannia, USA; ²Department of Economics, University of California, Berkeley, California, USA; ³Department of Electrical Engineering and Computer Science, Massachusetts Institute of Technology, Cambridge, Massachusetts, USA; ⁴Computer Science and Economics, Wellesley College, Wellesley, Massachusetts, USA

Keywords: digital health, electronic health records, health information exchanges, heterogeneous distributed information systems, interoperability

Abstract

Objective: This article reviews the landscape of interoperability efforts in healthcare from 2010 to 2023 in the U.S. and abroad. Interoperability, in the context of this article, is “the ability to share information across time and space from multiple devices, sources, and organizations,” as defined by the IEEE (Institute of Electrical and Electronic Engineers). The review is followed by recommendations for future work toward improving the standardization of heterogeneous data in the healthcare setting.

Methods: A literature review was conducted on established interoperability standards and systems in healthcare based on information obtained from journal publications, government and academy reports, published materials, and publicly available websites. Emphasis is placed on four interoperability parameters: device/equipment interoperability, compatibility issues, involved organizations, and migration and conversion issues. It evaluates adoption levels for each standard, as well as factors supporting and/or limiting systemic adoption. Estimations on the number of users—medical professionals and patients—for each system were made when verifiable data were available. Examples of specific interoperability efforts and an evaluation of their feasibility were conducted at three levels of healthcare interoperability, as defined by the National Academy of Medicine: Inter-facility interoperability, Intra-facility interoperability, and Point-of-care interoperability.

Results: After reviewing the following interoperability initiatives: Health Level 7 (HL7), Consolidated-Clinical Document Architecture (C-CDA), Digital Imaging and Communications in Medicine (DICOM), Integrating the Healthcare Enterprise International (IHE), Fast Healthcare Interoperability Resources (FHIR), Argonaut, Direct Standard, Validated Healthcare Directory (VHDir), Health Quality Measures Format (HQMF), Health Relationship Trust (HEART), and Prescription Drug Monitoring Program (PDMP) which operate in various clinical domains, it is clear that while progress has been achieved locally, greater semantic understandability during information exchange is necessary. Greater detail is presented in each section.

Conclusions: Despite many parallel ongoing efforts to improve the standardization of healthcare information in the mobile devices, IoT (Internet of Things), and EHR (electronic health records) sectors, there is still space for improvement. The U.S. must develop and implement effective mechanisms to surmount boundaries blocking the transfer of diverse types of healthcare information.

Plain Language Summary

Improving healthcare is a broad challenge where improved standardization and communication are envisioned to gain improved outcomes and value in healthcare investment. Interoperability in healthcare—the ability of two systems to exchange and use health information—is lacking in the United States healthcare system, which has become one of the biggest barriers to enhancing data accessibility and achieving a more significant impact of ongoing parallel efforts to improve patient quality of care.

Recognizing the importance of this issue, governments and health authorities in multiple countries have reported playing a role in promoting standards and interoperability in healthcare. Many of these efforts focus on isolated geographic areas, specific segments, or medical specialties of the healthcare industry, such as billing for healthcare services, medical devices, pharmacies, or medical IoT (Internet of Things—generally associated with data transmission through a communications network).

This paper goes over the history of interoperability efforts undertaken in the United States. Then it provides a systematic literature review of key frameworks developed to improve interoperable workflows in different clinical domains, highlighting each framework’s efficacy and impact. It then suggests policy changes for facilitating improved data exchange between healthcare organizations. These include separating the role of regulators and those who are regulated, allocating more funds to healthcare providers for IT training and installation, mandating standards compliance, and funding projects to build mediation architectures for data exchanges.

In effect, this paper calls attention to the growing need for an overarching vision and mechanism to help unify data assets scattered across heterogeneous health information systems.

 

 

Thirteen years after the Health Information Technology for Economic and Clinical Health (HITECH) Act announced federal use incentives for electronic health records (EHRs), the impact of $36 billion in EHR investments on the U.S. healthcare system remains unsettled.¹ At times, the use of EHRs has been shown to improve public health outcomes: a 2022 study in the Journal of Healthcare Quality found that hospitals that had fully implemented EHR systems had 18% lower mortality rates than those that had not.² Other times, reliance on EHRs has resulted in new medical errors that threaten patient safety.^3,4 Some of these new errors are the downstream result of limited or nonexistent interoperability between EHR systems, most of which were designed for quick deployment to secure financing in the form of federal subsidies.^4,5 Other errors are inherent within the system itself, as the first EHR systems were designed for patient billing.⁶

The interoperability of systems, formally defined as “the ability to share information across time and space from multiple devices, sources, and organizations,” is protected by the Health Insurance Portability and Accountability Act (HIPAA) of 1996, which promotes the secure “exchange and use of electronic health information.”⁷ While the HIPAA rule serves as a federal floor for patient data protection, individual state laws which deal with patient data and health records are preempted by federal law unless specific exceptions apply.⁸ In 2004, the federal government established Regional Health Information Organizations (RHIOs) to reconcile varying state laws, and by 2009, Congress promoted EHR adoption in the HITECH Act. In 2016, Congress passed the 21st Century Cures Act, which mandates specific EHR interoperability efforts.⁹ In addition, non-profit organizations in the U.S. and other countries, have attempted to bring together industry and hospital members to work toward interoperability.

In 2022, the Office of the National Coordinator for Health Information Technology (ONC) published the Trusted Exchange Framework, Common Agreement (TEFCA) – Version 1, and Qualified Health Information Network (QHIN) Technical Framework – Version 1.¹⁰ This framework is to create a common ground for interoperability across healthcare entities. The framework allows different users and disparate systems/networks to securely share data while meeting agreed-upon expectations and rules. The common agreement framework expectation is to leverage existing data formats where possible such as Consolidated Clinical Document Architecture (C-CDA) or via Fast Healthcare Interoperability Resources (FHIR) Application Programming Interfaces (APIs).¹¹ The Cures Act mandated FHIR exchange. However, TEFCA will not be FHIR-ready until at least 2025.¹²

As the use of data-generating devices in healthcare grows, interoperability among systems utilizing similar data, such as EHRs, and systems utilizing different types of data, such as medical devices and EHRs, is critical.

Healthcare organizations that exchange data utilize standards to transfer information from one system to another seamlessly. While laws like HIPAA and the 21st Century CURES Act protect healthcare providers who share patient data for treatment purposes, balancing the sharing of relevant health information with protecting patient privacy rights is a challenge facing the development of effective interoperability standards.¹³ The patient’s medical history would essentially follow them around throughout his or her lifetime. Just as other industries, such as aviation safety, have experienced an international need for standardization, health applications were spurred by the COVID pandemic to realize the need for international cooperation and standardization. It is critical that healthcare system components “have an equivalent understanding of the interactions that occur and the information exchanged to function safely. Differences between the model for the sender and receiver can lead to hazardous situations” for patients.¹⁴

In the U.S., state laws currently specify: (1) what medical information to include in a patient’s health records; (2) the circumstances under which a healthcare provider is permitted to release information; (3) to which organization/individual the provider is allowed to disclose information; and (4) the purpose for which the information may be disclosed. This makes it difficult when a person moves from one state to another. To address this issue, the ONC launched the Interoperability Standards Advisory, which monitors and provides guidance on health information exchange (HIE) standards that ensure interoperability across systems, in 2017.

Providers and vendors have traditionally prohibited other companies from accessing their information, known as “information blocking.”¹⁵ Their noncooperation to share data reduced competition and helped them avoid legal issues with data security. Blocking information exchange consisted of excessive costs for information sharing, a lack of contract transparency for technology buyers, and efforts to convolute the process of receiving and downloading information. Thus, although major EHR vendors may claim information exchange capabilities, these practices discourage actual data exchange. “Although these standards have been available to the Health Information Systems (HIS) vendors for some time, they have not fully adopted them into their products.” Thus, the different HIS are not interoperable, requiring the development of software adapters to be able to exchange information about the patients.¹⁶

Information blocking has proven challenging even for the largest tech giants. Google failed to gain traction with its personal health record in 2008, and Microsoft’s HealthVault was discontinued.¹⁷ In the last couple of years, the largest giants such as Google and Apple have made significant strides to support the community. Apple has made significant progress toward improving the interoperability of EHRs. In 2018, Apple released its Health Records app, which aggregates existing patient-generated data in the Health app with data from a user’s EHR using FHIR. At the time, only patients of participating hospitals and healthcare organizations, such as Epic Systems and Cerner Corporation, could use this feature. As of June 2019, however, Apple’s Health Records feature has allowed all U.S. healthcare organizations with compatible EHRs to self-register into their system, providing access to even more users. Along with providing access to EHRs, Apple introduced the API for Apple Health Records, which allows developers to create apps that can use these patients’ EHRs to help manage medication, nutrition, etc. Apple Health App leverages Substitutable Medical Applications, Reusable Technologies (SMART) on FHIR standard which allows users to easily and safely download and share their health records.¹⁸ Google, with its Google Health initiative, has introduced many tools for consumers, caregivers, researchers, communities and enabling care teams to deliver more connected care.¹⁹

In March 2020, spurred by the COVID-19 pandemic and directed by the 21st Century Cures Act, Centers for Medicare & Medicaid Services (CMS) finalized multiple rules “promoting interoperability” that are currently in effect. These include the following technical standards: FHIR, SMART IG/OAuth 2.0, and OpenID Connect. Guidance for Patient Access APIs, Provider Directory APIs, data exchange, and preventing information blocking was included in the final rule.

Methods

Precedents and Strategy Used Here

A literature review on established interoperability standards with an emphasis on examining four parameters: device/equipment interoperability, compatibility issues, involved organizations, and migration and conversion issues, was conducted by the authors. Among the health IT standards reviewed were those featured on the Office of the National Health IT Coordinator’s “Health IT Standards to Watch” list.²⁰ Adoption levels for each system, as well as factors supporting and/or limiting system adoption, were examined. Information was obtained from journal publications, government and academy reports, published materials, and publicly-available websites. Estimations on the number of users—both medical professionals and patients—for each system were made in instances where verifiable data were available.

When performing the analysis, the definition of interoperability published by the Institute of Electrical and Electronic Engineers (IEEE) was considered: “the ability of two or more systems or components to exchange information to use the information that has been exchanged.”²¹ Interoperability was said to be achieved when “little or no reworking of the software to accommodate the new environment” is required and when the “behavior/benefits in the new setting … are identical to those seen in the original setting.”²²

This review examines specific examples of interoperability efforts and evaluates their feasibility with regard to facilitating interoperability at three levels of healthcare interoperability as illustrated in Figure 1:

Fig. 1. Interoperability in the health ecosystem—inter-facility (macro-), intra-facility (meso-), and point-of-care (micro-) tiers.⁷ National Academy of Medicine.

• Inter-facility (macro-tier) interoperability
• Intra-facility (meso-tier) interoperability
• Point-of-care (micro-tier) interoperability

Interoperability is commonly facilitated through the implementation of interoperable frameworks or the use of specific products. This survey reviewed and assessed the syntactic, semantic, and functional interoperability of the most common frameworks used in the U.S. in the past decade. The frameworks include FHIR, C-CDA, the Direct Standard, Validated Healthcare Directory (VHDir), Integrating the Healthcare Enterprise (IHE), Health Level 7 (HL7) version 2.x messaging, Quality Reporting Document Architecture (QRDA), Prescription Drug Monitoring Program (PDMP), Health Quality Measure Format (HQMF), Digital Imaging and Communications in Medicine (DICOM), and the Argonaut Project. Each framework reviewed offered scalable platform interoperability at both the hardware and software levels. Platform interoperability is defined as a framework or product that can run on specified hardware, regardless of the operating system. These applications are also interoperable when run using a web browser, such as Chrome to access patient data through the FHIR API, or using a virtual networking application, such as in the case of accessing Epic patient records via the Citrix Cloud.²³ These “platform-independent [applications] are better at meeting the needs of heterogeneous groups of users because they place fewer restrictions on users’ choices of hardware and software.”²⁴

Frameworks were primarily evaluated based on semantic interoperability to assess the effectiveness of data exchange across systems. Medical terminology, unified under the USCDI (United States Core Data for Interoperability), provides one layer of semantic interoperability when used by frameworks but is not consistent in their terminologies. The structure for information encoding by each framework was also evaluated.

Results

Tabular comparisons of the frameworks covered below are presented in Table 1.

Table 1. Comparison of interoperability frameworks

Framework	Start date	End date	Main sponsor	Location	Device interoperability	Compatibility issues	Migration and conversion issues/APIs
C-CDA	December 2011	December 2018	HL7	Worldwide	EHR document formats	Lacks uniform guidance. Lacks limited encoding options. Limited to small-volume data transactions. Large documents increase latency	Documents often have too much information that is not easily filtered. Limited support for information that is not predefined
FHIR	February 2014		HL7	Worldwide	An API that can be used across standards, devices, and records	Relatively new deployment with limited real-world cases.	Lack of constraints on FHIR’s base specification limits on the type(s) of interoperability supported
Direct	April 2011	2015	Direct Project	U.S.	EHR standard for communication and data sharing	Relatively new deployment with limited real-world cases.	Dependent upon the interoperability of security requirements between parties exchanging data
VHDir	December 2017		HL7, ONC	Pre-release	EHR and Hospital Data	Pre-release phase.	This is in the pre-release phase.
IHE	February 1998		HIMSS, RSNA	Worldwide	EHR and Hospital Data	IHE customizability is time-consuming/error-prone. Limited beyond push transactions. Limited to data input for specific needs, e.g., lab orders and public health. Lacks cross-stakeholder engagement to standardize interoperable use	Some APIs use the standard for unique needs; Lack of semantic realignment when data is collected across systems
HL7 v2	1989		HL7	Worldwide	EHR standard for communication and data sharing	Lacks uniform data model resulting in inconsistencies. Lacks data entry structure beyond simple delimiters. Lmited image transmission capabilities	User roles are vendor-selected, resulting in message variation between systems using the standard
QRDA	April 2009		HL7	U.S.	EHR only	Limited to EHRs for data extraction. Not updated to extract data related to promoting interoperability metrics.
HQMF	March 2010	2017	HL7	U.S.	EHR and Hospital Data	Lacks specifications for EHR data extraction. Computationally complex	Extracts data without parsing; Cannot filter missing or noisy data
HEART	February 2016		Open ID Foundation	U.S.	EHR	Built on non-HIPAA-compliant standards (Oauth 2.0, OIDC, UMA). Limited interoperability among authentication requirements across applications
PDMP	2003	Varies by State	Varies	U.S.: 49 states and D.C.	Varies by State	State create requirements. Lacks single sign-on for providers using EHRs	Each state creates individual requirements
DICOM	1993		ACR, NEMA	Worldwide	EHR	Format includes executable code, which can be corrupted.	Data inconsistencies from the creation of additional fields
Argonaut	December 2014		AthenaHealth Beth Israel Deaconess Medical Center Cerner Epic Intermountain Health Mayo Clinic McKesson, MEDITECH Partners Healthcare System SMART at Boston Children’s Hospital Information System The Advisory Board Company	U.S.	An initiative to use an API across devices and records.	Relatively new deployment with limited real-world cases.
ACR: American College of Radiology; API: Application Programming Interface; C-CDA: Consolidated-Clinical Document Architecture; D.C.: District of Columbia; DICOM: Digital Imaging and Communications in Medicine; FHIR: Fast Healthcare Interoperability Resources; HEART: Health Relationship Trust; HIMSS: Healthcare Information and Management Systems Society; HL7 v2: Health Level 7 (HL7) Version 2.x Messaging; HQMF: Health Quality Measures Format; ID: OpenID; IHE: Integrating the Healthcare Enterprise International; NEMA: National Electrical Manufacturers Association; PDMP: Prescription Drug Monitoring Program; QRDA: Quality Reporting Document Architecture; RSNA: Radiological Society of North America; U.S.: United States; VHDir: Validated Healthcare Directory; ONC: Office of the National Coordinator for Health Information Technology; SMART: Substitutable Medical Applications, Reusable Technologies; HIPAA: Health Insurance Portability and Accountability Act; OIDC: OpenID Connect; UMA: User Managed Access.

Health Level 7 (HL7) Version 2.x Messaging

Health Level 7 (HL7) was launched in 1987 as a standards development organization. Two years later, the first version of the HL7 version 2 (HL7 V2) standard (Figure 2), also known as “Pipehat,” was released, allowing event-based clinical data to be exchanged among systems via TCP/IP, such as ADT (Admit/Discharge/Transfer) and ORM (Order Message).²⁵ The backward-compatible standard has been frequently updated since its debut, with the current version being 2.9; it utilizes a non-XML syntax for messaging.

Fig. 2. HL7 v2 message composition. HL7 v2: Health Level 7 (HL7) Version 2.x Messaging.

More recent versions support a growing number of entry fields for patient data. Each updated version incorporates certain capabilities of previous versions and supports a more robust data model as well as more comprehensive vocabulary standards.²⁶ HL7 version 3 (HL7 V3), the successor of HL7 V2, won’t be discussed due to its multitude of plaguing problems; HL7 V3 is extremely convoluted, with internal inconsistencies even within its documentation, and too expensive to implement in practical systems. HL7 V3 has been criticized heavily, as it has contributed to many failed system implementations.²⁷ The HL7 v2 standard requires that messages consist of segments that are composed of fields that are comprised of components.²⁸ HL7 v2 messaging requires low bandwidth and usually sends unencrypted messaging over TCP/IP with a header and trailer.²⁹

Inter-facility (macro-tier) interoperability

HL7 v2 supports compliance with Meaningful Use requirements as well as public health surveillance.³⁰ The standard facilitates query and response from registries to update EHR. As of 2023, with affiliates in over 30 countries, HL7 is widely implemented by healthcare entities. HL7 standards are expanded to deliver solutions including FHIR, and Clinical Document Architecture (CDA).³¹ As of 2019, the HL7 v2 standard is internationally recognized and “arguably the most widely implemented standard for healthcare in the world.”²⁹ One reason for the widespread adoption of this standard is that it is inherently flexible and open to vague data inputs. The flexibility of HL7 v2 is one of its limitations. Among healthcare providers, HL7 v2 may lack a consistent data model. Thus, the method by which individual clinical applications store data and elements determines which capabilities of the standard can be implemented. Segments in a particular HL7 v2.x message may be specified as required, optional “[],” or repeating “{},” but each organization often adopts a schema to conform to their needs by changing those requirements, eliminating unused segments, and introducing new segments not often used in the particular schema. Furthermore, HL7 defines both PID-18 (account number) and PV1-19 (visit number), which are often interchangeable between systems. This semantic gap can produce errors when a specific provider’s system, for instance, can only accept PID-18. This large variance in how vendors implement HL7 results in “inconsistencies within the standard and difficulties understanding how message elements relate to each other.”³²

To combat these inconsistencies, National Institute of Standards and Technology (NIST) developed a black box testing framework, called conformance testing, to increase the likelihood of implementations interoperating. NIST also released an HL7 v2 Platform for Standards Development and Testing to allow users to define standards and test plans that directly result in machine-processable artifacts; the testing infrastructure and framework use these artifacts to create conformance testing tools automatically. The principle mechanism behind conformance testing is a message profile, an XML representation of the processing rules, and unambiguous descriptions of HL7 messages to constrain the allowed set of options. Similar profiles among vendors are more likely to interoperate. The NIST test system architecture utilizes actors that run on independent threads of executing Java code and can be configured to substitute an arbitrary HL7 application. These actors send messages to one another, and test cases are successful when all actions are complete and all assertions are satisfied. These tests, however, are not comprehensive enough to prove the absence of errors, which suggests that they do not guarantee systems to be interoperable. Still, conformance testing is the only way to ascertain if the system requirements have been correctly implemented, so testing laboratories will correct their implementations until they pass all the tests and receive certification.

Intra-facility (meso-tier) interoperability

Within a healthcare facility, HL7 is easily supported by the majority of health information technology systems, including legacy systems. Migration to a new EHR, however, can result in the loss of legacy data. Due to the sheer volume of information, each facility must prioritize basic essentials such as medications, allergies, and diagnoses; other data may be left behind.

Point-of-care (micro-tier) interoperability

Patients benefit from the data fluidity made possible through HL7 since healthcare providers get direct access to patient information and can store/display it as needed for patient care. Consider the use case of blood work performed for a patient: HL7 can electronically transmit the blood work results to the doctor, and the doctor can synchronously make the results available for patient review. Furthermore, the standard facilitates user-initiated informational updates. Each system using HL7 v2 can be highly variable, with vaguely defined user roles that are subject to vendor choice. This feature allows for variation “on which messages are used for a given set of clinical functions when two applications attempt to use the HL7 v2 standard.”²⁹

Consolidated-Clinical Document Architecture

Developed by Health Level 7 International (HL7), the C-CDA is “an implementation guide that specifies a library of templates and prescribes their use for a set of specific document types.”³³ C-CDA is a proven data exchange method in different forms of interoperability.³⁴

The first version of the C-CDA implementation guide of HL7, introduced in 2011, included “a library of CDA templates, incorporating and harmonizing previous efforts from Health Level Seven (HL7), IHE, and Health Information Technology Standards Panel (HITSP).”³³ C-CDA incorporates both structured and unstructured formats to provide comprehensive patient recordkeeping. Aside from Continuity of Care Document (CCDs), the C-CDA library includes XML templates for the following C-CDA document types: Care Plan, Consultation Note, Diagnostic Imaging Reports, Discharge Summary, History and Physical, Operative Note, Procedure Note, Progress Note, Referral Note, Transfer Summary, Unstructured Document, and Patient-Generated Document.³³ Although consisting of different formats, all these C-CDA documents follow a specific set of principles for consolidation: regulatory requirements prevent document changes for a specific period; organizations must take custody of these documents and handle them with considerable precaution; documents must be legally verified holistically; the default contexts for the documents’ components are required to be instantiated; documents should be readable. These requirements enforce specific guidelines that documents must achieve; these guidelines facilitate transferability and consistency among EHRs.

Inter-facility (macro-tier) interoperability

During Stage 1 of the HITECH Act’s Meaningful use mandate, the CCD and Continuity of Care Record (CCR) were defined as acceptable standards for patient care summaries. To achieve Stage 1 of meaningful use, EHRs were required to include the capability of generating a CCD or CCR with specific patient summary sections as well as “exchange clinical information and patient summary record[s].”³⁵ When the CMS released the Meaningful Use Stage 2 Notice of Proposed Rulemaking (NPRM) in 2012, the ONC defined C-CDA as the electronic transfer standard for clinical information exchange. Before the ONC’s guidance on C-CDA, the healthcare industry had deployed multiple types of CDA standards with conflicting formats.³⁶ To minimize these conflicts, C-CDA was developed based on the most frequently used clinical document templates.³⁶ While CDA is utilized around the world, C-CDA has been implemented across the United States, having been cited in all stages of Meaningful Use 2014 Edition and 2015 Edition.

To further reduce conflicts, automated tools have been developed to test the quality of CDA documents. ONC, for instance, created One Click Scorecard to help providers validate their C-CDA documents. Providers can send a Direct message with a C-CDA payload to the testing service and receive a PDF report card that includes scoring information about the C-CDA.

Intra-facility (meso-tier) interoperability

The implementation of a rule-based decision-making system to detect sensitive patient data using C-CDA records was proven to be successful in achieving meaningful use objectives while remaining compliant with federal and state laws. In Massachusetts, patient records that contain “sensitive” information, such as HIV test results, cannot be electronically transmitted with specific, pre-existing patient consent. The “Enterprise Clinical Rules System” (ECRS) was implemented using a standardized patient model. The ECRS utilized a Patient Factory service that mapped CCDA data to the normalized patient model. Since CCDA does not limit the narrative text portion of patient records, both coded data and string searches were executed. Four data types were evaluated for sensitive information: problems identified by individual disease codes, the inclusion of medications related to sensitive diagnoses, laboratory results related to sensitive disease tests, and allergies to medications related to sensitive diagnoses. Researchers at Partners HealthCare System prevented the transmission of sensitive C-CDAs 98.4% of the time.³⁷

Point-of-care (micro-tier) interoperability

One provider can use an EHR to generate C-CDA to exchange data with other providers. A study conducted in 2018 discovered that of 401 C-CDA documents, 346 had a total of 1,695 Schematron errors, according to the HL7 Schematron tooling. 77% of the Schematron errors were related to inappropriate methods to encode no information, 10% were related to template issues, and the final 13% lacked proper XML formatting.³⁸ These errors can be categorized as follows: (1) omission or misuse of LOINC in results or vital signs, (2) UCUM in medications, results, or vitals, (3) omission or misuse of RxNorm in allergies and medications, (4) omission or misuse of dose quantity, (5) omission or misuse of an allergic reaction, (6) omission or misuse of allergic severity, (7) omission of dose frequency, (8) omission of result interpretation, and (9) omission or result reference page.³⁹ Furthermore, the researchers found that data optionality is a challenge with C-CDA documents as “variations where the C-CDA specification did not provide uniform guidance” or offer multiple encoding options, such as in the case of telephone numbers, are common.³⁹

Digital Imaging and Communications in Medicine

The DICOM messaging standard, also known as National Electrical Manufacturers Association (NEMA) standard PS3, was released in 1993 by the American College of Radiology (ACR) and the NEMA to enable the exchange and management of medical imaging data.⁴⁰ DICOM facilitates the interoperability of devices related to medical imaging, including but not limited to scanners and Picture Archiving and Communication Systems (PACS). Based on the client-server model, the DICOM standard defines a format for image files and a network communication protocol that uses TCP/IP. The majority of DICOM versions are both forward and backward-compatible.

Inter-facility (macro-tier) interoperability

Each DICOM application utilizes an identical format for file storage. The DICOM data object format is among the most widely used around the world—this format is “interoperable with the variety of tools readily available to the researcher, as well as commercial clinical imaging and analysis systems (which universally support many aspects of the DICOM standard).⁴¹

Since May 2012, DICOM and HL7 have collaborated through the Imaging Integration Working Group to develop use cases and information structures that promote the interoperation of imaging systems, PACS, and associated radiological systems with information systems that use HL7.” Currently, the working group is developing an “imaging implementation guide, profiles, and white papers for FHIR” as well as supporting “FHIR imaging-related resources.”⁴² IHE has developed profiles to layer on top of the DICOM standard to facilitate specific medical imaging use cases across systems.⁴³

DICOM’s final issue occurs when displaying an image on a device from a different manufacturer, as varying imaging apparatuses use different spans of amplitude with an equal number of allocated bits; images, therefore, have worsened contrast and are underexposed or overexposed.⁴⁴

Intra-facility (meso-tier) interoperability

DICOM is a multipurpose standard offering “several levels of support, such as the support for image exchange for both senders and receivers, the underlying information modal and information management services.”⁴⁵ Another issue associated with DICOM is the fact that its format includes executable code; in April 2019, a Cylera Labs analysis found that hackers could inject malware code into DICOM images without detection due to the format’s ability to support hybrid files.⁴⁶

Point-of-care (micro-tier) interoperability

DICOM includes an information model that maps relationships between DICOM objects and clinical terms.⁴⁵ Unlike many standards, DICOM embeds information, such as patient identification information, in data sets that store numerous attributes.⁴⁷ For each data object, only one attribute can store pixel data, i.e. a medical image. One longstanding limitation of the DICOM standard is its flexibility, namely that it offers the option of including additional fields. This leads to inconsistencies in file storage, with some images being complete and others lacking data.⁴⁸

Integrating the Healthcare Enterprise

Launched in 1998, the IHE initiative was a joint collaboration between the Healthcare Information and Management Systems Society (HIMSS) and the Radiological Society of North America (RSNA) to coordinate “the use of many different standards by layering on the context of healthcare delivery.”⁴⁹ The IHE framework utilizes system integration profiles that are based on clinical scenario use cases, considering both the associated actors, i.e., systems, and transaction activities. These profiles outline the pre-existing standards necessary to complete a target use case.

The Radiology Scheduled Workflow (SWF) was the first IHE profile released that integrated the systems utilized during a radiology order.⁵⁰ Since then, IHE has developed profiles that span multiple clinical domains, from cardiology to ophthalmology, and is utilized around the world.⁵¹

Inter-facility (macro-tier) interoperability

When implemented by multiple systems, interoperability is achieved because the standards utilized to complete a clinical process are compatible. “There are many IHE profiles and each user or vendor may support a different set of IHE profiles that fit its business need.”⁵³ Furthermore, the implementation of IHE in the United States is limited by the lack of “sustained collaboration from all stakeholders.”⁵⁴ Another limitation is that individual vendor databases are often “difficult to access and [require] permission or assistance from vendors to discover.” Moreover, “understanding data structures and mapping data tables to workflow timestamps was difficult without vendor guidance.”⁵⁵ The IHE framework does not “provide semantic alignment of data collected in disparate contexts” from different systems.⁵⁶ Along with interoperability shortcomings, Query for existing data (QED) has proven to be a difficult task in a cross-community environment. QED is incompatible with XCA, supports a limited set of data types, forces the requester to learn the capabilities of the responder, and fails to audit exchanges.

Intra-facility (meso-tier) interoperability

One limitation of the IHE framework is its customizability. While vendors and users can select the IHE profiles that fit their needs, the process of selecting each set of profiles for every healthcare or business use case is time-consuming and error-prone.⁵³

Point-of-care (micro-tier) interoperability

According to the ONC, some of the most frequently used profiles are: audit trail and node authentication (ATNA), cross-community access (XCA), cross-community patient discovery (XCPD), cross-community interchange (XDR), cross-community document sharing (XDS), patient demographics query (PDQ), and patient identity cross-references (PIX).²⁰ The option of obtaining these data profiles through IHE queries (Figure 3; QED) can be used to classify information into six categories: vital signs, problems/allergies, diagnostic results, medications, immunizations, and professional services.⁵⁷ Utilizing HL7 V3 messaging to encode the content, QED may retrieve more than one data type in a single query and is intended for use between clinical systems (requesters) and repositories (responders).

Fig. 3. Schema for IHE queries.⁵² IHE: Integrating the Healthcare Enterprise International.

Fast Healthcare Interoperability Resources

Drawing on insights and outcomes from the HL7 v2 messaging standard, the HL7 V3 Reference Information Model, and CDA implementation, HL7 convened the “Fresh Look Task Force” to update interoperability strategies in 2011. Later that year, HL7 released its first draft for the FHIR standard, which represents data as resources. FHIR was specifically developed to provide a resource-oriented RESTful API for health records, “inspired by contemporary Web APIs.”⁵⁸ In 2020, ONC published the final rule for the 21st Century Cures Act announcing FHIR R4 as the standard required for Health IT Certification.⁵⁹ FHIR is currently in release 6.

Inter-facility (macro-tier) interoperability

The FHIR Directory exists to “achieve wide interoperability (Figure 4).”⁶⁰ It consists of a resource database accessible via the FHIR API and stored using Structured Query Language (SQL). The resources are available to represent information and relationships between resources include data similar to those from pre-existing healthcare directories, including Healthcare Service data, medical device data, Organization, Patient, and Practitioner.⁶⁰ These resources are available to all systems and can be queried for only the resources that a provider requests, which improves the reliability and stability of the EHR organization.

Fig. 4. Pictorial representation of the FHIR resource for “condition.”⁷⁰ FHIR: Fast Healthcare Interoperability Resources.

At first, FHIR supported laboratory result data exchange through “defined data models.”⁵⁸ The FHIR resource definitions are well-defined and relevant, including highly-specific resources, such as MedicationPrescription and AdverseReaction, and less specific ones, such as Procedure. Resource definitions span administrative, clinical, financial, and infrastructure domains.⁶¹ Drawing on explicit inter-resource referencing in idiomatic XML and JSON, FHIR generates a data graph of resources.⁵⁸

In the September 2016 Journal of American Medical Informatics Association article “SMART on FHIR: a standards-based, interoperable apps platform for electronic health records,” researchers at Harvard Medical School and Boston Children’s Hospital described the launching a platform development project to “enable medical applications to be written once and run unmodified across different healthcare IT systems.”⁵⁸ Researchers found that FHIR does not implement constraints on resource fields, rendering “almost all data optional and most coding decisions open.” Instead, FHIR requires profiles to constrain resource definition “to enable substitutable apps, providing predictability that may also support non-app-oriented interoperability (e.g., peer-to-peer exchange of clinical records).”⁵⁸ The lack of constraints on FHIR’s base specification limits the degree of interoperability supported by the standard.

In addition, several healthcare informatics companies are exploring the development of FHIR-based tools. Since January 2018, for example, Apple’s iPhone Health app has allowed individual providers to make electronic medical records available for viewing. Health systems across the United States, including NYU-Langone (New York), Johns Hopkins Medicine (Maryland), OhioHealth (Ohio), Ochsner Health System (Louisiana), Dignity Health (Arizona, California, and Nevada), and others, participated in the Apple program.⁶²

At the HIMSS19 Conference, Google Cloud highlighted the role of FHIR in bridging legacy IT systems with analytics and machine learning. The Google Cloud Healthcare API effort is built on aggregating data that is generated using standard frameworks like HL7 v2 and C-CDA, and then translating that data into an interoperable format across systems and devices using FHIR to improve patient information exchange across mobile applications.⁶³

At the HIMSS23 Conference, FHIR HL7 was highlighted and many organizations participated to showcase.⁶⁴ Many organizations like FDA, NIH including AWS, and Microsoft have many initiatives that are contributing to FHIR implementations. Organizations like AWS, Microsoft, Google, and many more are creating connectors, and FHIR servers to contribute to data exchange and to promote interoperability. For instance, NIH is encouraging the development, and implementation of clinical data elements to leverage Health Level Seven International (HL7®) FHIR®.^65–67

Intra-facility (meso-tier) interoperability

FHIR also offers “out-of-the-box” scalability, allowing the system to “be adapted as needed for local requirements using Profiles, Extensions, Terminologies and more.”⁶⁸

Point-of-care (macro-tier) interoperability

FHIR resource definitions can be modified to facilitate data transfer from different devices and sources, from EHRs to wearable monitors, using “specific data payloads with distinct terminologies.”⁵⁸ In addition to these and other benefits, FHIR is a composable standard, which means that its “resources can be selected and assembled in various combinations.”⁶⁹

FHIR supports different types of applications, including those that work in an EHR-agnostic manner in any healthcare organization. For example, SMART on FHIR applications leverages the FHIR standard to integrate SMART with existing EHR systems and web portals.

Argonaut

The Argonaut project was launched in 2014 as a joint project of private sector vendors and organizations to “accelerate the use of FHIR and OAuth in health care information exchange.”⁷¹ While groups like HL7 and IHE had already initiated FHIR development projects, Argonaut’s chief goal was to optimize the FHIR development process, including the work undertaken by other standards development groups, and the adoption of the FHIR standard. Argonaut would rapidly develop highly focused FHIR Profiles and a complementary security implementation guide to make available to the industry in the spring of 2015.⁷² The sponsors selected the Massachusetts eHealth Collaborative as the program’s Project Manager to coordinate its activities.

Inter-facility (macro-tier) interoperability

Argonaut was established in response to a report by the October 2014 JASON Task Force, of the HIT Standards and Policy Committees, that analyzed the state of health IT interoperability in the United States. In the report, the task force recommended that the ONC prioritized the development of public APIs for the FHIR standard as well as a software architecture “to migrate data from legacy systems to a new centrally orchestrated architecture.”⁷³ With Argonaut, the implementation of new solutions could be faster and executed more efficiently.

Intra-facility (meso-tier) interoperability

In October 2015, the ONC also released a final rule which mandated an API requirement for EHR certification.⁷⁴ By December 2016, Argonaut released the Argonaut Data Query Implementation Guide, which facilitated access to the data elements of the Common Clinical Data Set and the CCD storing the Common Clinical Data Set elements. The guide also integrated OAuth 2.0 security features.⁷⁵ In June of 2017, Argonaut released the Provider Directory Implementation Guide. Argonaut also released a Scheduling Implementation Guide and a CDS (Clinical Decision Support) Hooks Implementation Guide in the spring of 2018. Argonaut projects initiated in 2018 focus on enhancing the Argonaut Data Query Implementation Guide, the Clinical Notes and Bulk Data Access of Clinical Data projects, and the Simple Assessment Questionnaires.⁷¹ Current projects as of 2021 focus on writing and updating USCDI data, and promoting the adoption of a subscription framework, where clients are actively notified when data changes.⁷⁶

In the case of CDS hooks, FHIR promotes interoperability in the utilization of CDS rules and services.⁷⁷ For example, within the EHR, a CDS hook can be triggered. In real-time, clinical data can be retrieved from FHIR-enabled servers, and rules or any third-party CDS services can be executed in the background. The outputs are returned as CDS cards that can be embedded within the EHR, meaning clinicians can stay within their established workflow.

Point-of-care (micro-tier) interoperability

Argonaut’s recommendations have been quickly adopted. In January 2018, Carequality adopted the Argonaut Provider Directory specifications and CommonWell integrated Argonaut specifications into their core services. At the same time, the ONC announced that over 55% of certified EHR vendors were using FHIR APIs.⁷⁸ In February 2018, Apple integrated the Argonaut recommendations for FHIR in its iPhone health records app.⁷¹

Direct

Published in the April 2011 report “Applicability Statement for Secure Health Transport,” the Direct Standard was developed as a “simple, secure, scalable, standards-based way for participants to send authenticated, encrypted health information directly to known, trusted recipients over the internet as part of what was known as the Nationwide Health Information Network,” a set of HIE standards that prioritized information security.⁷⁹ The Direct Standard aims to replace mail, e-mail, and fax communications with secure, electronic data transmission and to ensure interoperability between systems when pre-existing records are not interoperable.

The standard emerged as a public-private collaborative effort of the Direct Project, which was launched in March of 2010 to develop a consensus-based HIE standard with the purpose of “establish[ing] universal health addressing and transport for participants (including providers, laboratories, hospitals, pharmacies, and patients) to send encrypted health information directly to cryptographically validated recipients over the internet.”⁸⁰ Led by the ONC, the project received support from the Department of Health and Human Services (HHS) and consisted of over 200 participants from 60 individual organizations, including federal organizations, state organizations, and EHR vendors.⁸¹ The standard was updated in 2012 and again in 2015. From 2011 to 2017, the ONC maintained the Direct Standard; by 2017, DirectTrust Standards, an independent organization, accepted the role of maintaining the standard. In March 2019, DirectTrust was granted American National Standards Institute (ANSI) accreditation, and the Direct Standard was announced as an ANSI-approved nationwide standard. Today, DirectTrust Standards promote the development of “standards that enhance healthcare interoperability and identity.”⁸²

The Direct Standard is built upon the underlying Simple Mail Transfer Protocol (SMTP) standard and relies on the Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification (RFC 5751), using end-to-end encryption.⁸³

Inter-facility (macro-tier) interoperability

Two recent pilot projects for the Direct Standard deserve mention here. The first, in Minnesota, involves public health reporting of immunization records from the Hennepin County Medical Center Level 1 Adult and Pediatric Trauma Center to the Minnesota Department of Health. The second, in Rhode Island, involves the exchange of patient data between providers and the direct messaging of clinical information from practice-based EHRs to the Rhode Island HIE for care quality analysis and coordination across care sites.⁸⁴ Although recent pilots have proven to be successful, the interoperability of the Direct Standard relies on the establishment of a secure connection, i.e., trust between a sender and a receiver. The ability to secure a “trusted” connection between two parties can vary based on the security requirements of either party.⁸³ The Direct Standard is also largely unscalable, preventing its use with larger HIEs.

Validated Healthcare Directory

The launch of the VHDir Implementation Guide was spearheaded by HL7 and ONC in 2017. Based on FHIR Version 4.0, the guide facilitates the exchange of healthcare directory information between local directories and a national reference directory. Specifically, the VHDir Implementation Guide incorporates the “architectural considerations for attesting to, validating, and exchanging data from a central source of validated provider data (i.e. a Validated Healthcare Directory or VHDir), as well as a RESTful FHIR API for accessing data from VHDir.’⁸⁵

According to the HL7 website, the VHDir Guide project is currently in the design phase. The VHDir Guide will integrate and update, as necessary, resources, extensions, profiles, vocabularies, value sets, and operations associated with the FHIR standard; the Argonaut Provider Directory will also be considered. Subsequently, FHIR standards may be modified to support any resulting new requirements, particularly with regard to information exchange methods like pull, push, and publish/subscribe. The validation structure will integrate a variety of metadata, including dates, frequency, methods, source details, and status. This guide will include at least the following information for each entity: (1) care teams, (2) contact information, (3) credentials, (4) demographics, (5) electronic endpoints, (6) groups, (7) health plans, products, and networks, (8) indication of incomplete records due to policy or other reasons, (9) locations, (10) relationships between individual providers and each of the above, (11) relationships between organizations, other organizations and locations, and (12) proxies for individuals and groups of individuals.

The VHDir offers enhanced scalability for local health organizations to tailor their systems to meet specific needs. The VHDir is designed to be a “‘floor’ for the exchange of validated provider data while describing additional data elements and capabilities that support more robust implementations.”⁸⁵ Currently, the VHDir consists of the following Validated Healthcare Directory Profiles: VhDir Care Team, VhDir Endpoint, VhDir Healthcare Service, VhDir Insurance Plan, VhDir Location, VhDir Network, VhDir Organization, VhDir Organization Affiliation, VhDir Practitioner, VhDir Practitioner Role, VhDir Restriction, and VhDir Validation. For a given profile to be supported, the mandatory elements, extensions, and terminology are outlined for each profile.⁸⁵

Quality Reporting Document Architecture

Originally, HL7 v2 was proposed to be the standard for quality reporting; however, a new standard was necessary to overcome the limitations of HL7 v2.⁸⁶ Released in 2009 by HL7, the QRDA standard is used to transfer health information, specifically electronic Clinical Quality Measure (eCQM) data, between systems by constraining CDA.⁸⁷ QRDA documents are constrained within CDA documents, with included data organized according to QRDA category type.⁸⁸ The QRDA is XML-based and utilizes the Quality Data Mode (QDM), which is a standard with an “information model that clearly defines concepts used in quality measures and clinical care and is intended to enable” automated data extraction from EHRs.⁸⁹ The process by which data is filtered and used to generate QRDA reports is outlined in Figure 5.⁹⁰

Fig. 5. Example QRDA schema.⁹⁰ EHR: electronic health records; HQMF: Health Quality Measures Format; QRDA: Quality Reporting Document Architecture;

Inter-facility (macro-tier) interoperability

QRDA reports offer a standardized way for health payers and the government to compare the quality of administered care across organizations. While the standard is maintained and updated by an HL7 working group, CMS develops implementation guides for QRDA compliance.⁷² QRDA documents contain de-identified EHR data for various quality measurement and reporting initiatives, particularly for Meaningful Use compliance.⁷² There are three categories (I–III) of QRDA reports. Category I reports deal with data from a single patient for one or more quality reporting metrics. Category II reports involve data from a group of patients for one or more quality reporting metrics. Category III reports rely on data from a single provider, whether that be an individual physician or a hospital system, for one or more quality reporting metrics.⁹¹ The ONC adopted QRDA as the standard of choice for QRDA Categories I and III data reporting.⁹² The CMS also adopted QRDA as their standard for the Physician Quality Reporting Initiative (PQRI).⁸⁶

Hospitals and other group providers that use QRDA-compliant EHRs, such as the Epic EMR and other certified vendors, can generate QRDA I documents that contain patient-specific information that is directly related to quality measure reporting for programs such as Core Measures, Physician Quality Reporting Systems, and Inpatient Quality Reporting. Similarly, QRDA III documents, which contain aggregated quality measure data, can be generated and can include eligible provider performance rates to satisfy Meaningful Use reporting requirements.⁹³

Intra-facility (meso-tier) interoperability

One limitation of QRDA III is that it does not extract data related to the Promoting Interoperability (PI) metric for some programs.⁹⁴

Point-of-care (micro-tier) interoperability

Another challenge is the fact that, unlike HL7 V2, the standard is inherently “complex, verbose, and difficult.” In addition to these limitations, QRDA is also designed with only EHRs as the source from which to extract data.⁹⁵

Health Quality Measures Format

Meaningful Use Stages 2 and 3 prioritize a dynamic health system that promotes learning from data to improve population health through Clinical Quality Measures (CQMs).⁹⁶ In response, HL7 proposed the XML-based HQMF in 2010.⁹⁷ A year later, the ONC launched the Query Health Initiative to develop standards that support distributed access for population health queries; HQMF was adopted as the premier standard for defining population health queries. The electronic specifications for CQM reporting from EHRs include “a measure’s structure, metadata, definitions and logic” in the HQMF format.⁹⁸

Also, in 2011, the National Quality Forum (HQF) converted 113 CQMs to eMeasure, or HQMF, format.⁹⁸ Together with CMS, the NQF later published the 93 CQMs for Stage 2 of the EHR incentive program reporting as eMeasures.⁹⁹ Today, the HQMF standard includes the XML format as well as an HTML and associated value sets.¹⁰⁰

Inter-facility (macro-tier) interoperability

The HQMF supports population health queries for QRDA responses and formats the vague Quality Data Model (QDA) standard to be interpretable by a computer. The QRDA patient data stored in the EHR is compared to the HQMF criteria, sometimes called eMeasures, to determine whether reporting minimums have been achieved.¹⁰⁰

Point-of-care (micro-tier) interoperability

One challenge when using HQMF is that the standard provides the syntax, or document structure, “but does not specify where in the EHR the data must be found, so an EHR vendor must map the measure specifications to the data elements in the her.”¹⁰¹ Thus, it is a time-consuming process to parse HQMF criteria into a database-ready query.¹⁰² Furthermore, HQMF is inherently challenging and open-ended. These features have historically allowed computationally difficult and unrealistic query constructions. Other HQMF challenges include “[m]ultiple time relationships on a single criterion, the possibility of nesting time relationships and excerpts, arbitrarily deep nesting of population criteria groups, and the fact that not all population criteria operators are equivalent to logical operators.” Another critical limitation of HQMF is that data that is missing or noisy negatively impacts the standard’s ability to specify behavior.¹⁰³

Health Relationship Trust

The HEART standards group was launched to support security and privacy around HIE and promote patient control of health data. Supported by the Open ID Foundation, HEART examines issues related to patient digital rights, data security, authorization, and authentication. With the expansion of data-sharing APIs, the possibility for patient data sharing across systems exists; however, the necessary patient consent for optimized data sharing does not. Thus, HEART was tasked with developing “profiles of commonly used identity standards for health care and other ‘high trust’ use cases.”¹⁰⁴

Inter-facility (macro-tier) interoperability

Another challenge is the arrival of the Internet of Medical Things (IoMT), which requires a different set of use cases and solutions to facilitate privacy and security standardization with regard to patient data exchange.104

Intra-facility (meso-tier) interoperability

Another challenge for identity solutions is claims-gathering, which varies by application and has different authentication requirements. Chain-link confidentiality and “downstream” resource access have been considered by User Managed Access (UMA).¹⁰⁵

Point-of-care (micro-tier) interoperability

One of its first efforts was “defining a set of security profiles that focus on securing patient/consumer RESTful health-related data sharing APIs, such as FHIR.”¹⁰⁴

In addition to considering the FHIR standard, HEART profiles build on the following pre-existing security and privacy standards: OpenID Connect (OIDC), 0AUTH 2.0, and UMA 1.0. HEART profiles allow patients to enable clinical data access permissions and organizations to validate data access requests. HEART profiles also facilitate a protocol for permissions management. There are two types of HEART specifications: mechanical profiles and semantic profiles. Mechanical profiles are designed to “specify and tighten security parameters for using OAuth 2.0, OpenID Connect, and UMA, respectively, in the context of patient-controlled health data exchange. Semantic profiles “prescribe the usage of OAuth and UMA (for example, defining scopes and flows) in combination with health industry-specific APIs.”¹⁰⁶

As of March 2019, four HEART specifications have been approved: the HEART Profile for OAuth 2.0, the HEART Profile for FHIR OAuth 2.0 Scopes, the HEART Profile for User-Managed Access 2.0, and the HEART Profile for FHIR UMA 2 Resources.¹⁰⁶

One challenge associated with developing HEART profiles, standards, and specifications is that digital patient consent rests on the OAuth 2.0, OIDC, and UMA standards. None of these standards are health IT-specific, which means that the development of profiles that meet health IT requirements for each of these standards is critical. With help from the MIT Consortium for Kerberos and Internet Trust, the ONC, NIST, and the OpenID Foundation, HEART aims to address these issues.¹⁰⁴

Prescription Drug Monitoring Program

The PDMP is “an electronic database that tracks controlled substance prescriptions in a state. PDMPs can provide health authorities with timely information about prescribing and patient behaviors that contribute to the epidemic and facilitate a nimble and targeted response.” These are individual state programs that collect and share prescription and use data on federally-controlled substances; states can also elect to track specific prescription drugs, particularly those that are frequently abused.

Inter-facility (macro-tier) interoperability

The PMP Interconnect, an interstate program that allows PDMPs to exchange prescription data securely, currently includes the participation of 48 states, the District of Columbia, and St. Louis County in Missouri.¹⁰⁷

New York launched the original PDMP in 1918 for monitoring opium, morphine, heroin, cocaine, and codeine prescriptions. In 1939, California adopted a PDMP. Until 1989, when Oklahoma mandated electronic data communication, PDMPs were paper-based. Through the federal Harold Rogers Prescription Drug Monitoring Grant in 2003, the majority of today’s PDMPs were established.¹⁰⁸ Currently, all 50 United States, the District of Columbia, and Guam have PDMPs. Although there’s no evidence to suggest the adoption of PDMPs reduces overall opioid-related harms or crime rates,¹⁰⁹ the Centers for Disease Control and Prevention (CDC) states that “evaluations of PDMPs have illustrated changes in prescribing behaviors, use of multiple providers by patients, and decreased substance abuse treatment admissions.”¹⁰⁷

Intra-facility (meso-tier) interoperability

One critical issue limiting PDMP interoperability is that each state creates specific requirements for its individual PDMP. For instance, in Nebraska, the PDMP is voluntary and only includes information from ER consultations. Pennsylvania, on the other hand, mandates PDMP registration for all prescribers and reporting on Schedule II–V controlled substances.¹¹⁰

From 2011 to 2013, the ONC oversaw the Enhancing Access to PDMPs using the Health IT project to research and propose new methods for EHR and PDMP interoperability.¹¹¹ Research suggests that integrating EHRs with PDMPs could increase the frequency of PDMP system use among physicians.¹¹² In 2017, HL7 released the U.S. Meds PDMP FHIR Implementation Guide to provide documentation for how providers can use the FHIR standard to access a patient’s data from a state PDMP.¹¹³ In 2018, CMS recommended that single sign-on solutions integrate EHRs with PDMPs. CMS also informed states that this EHR project would be eligible for federal funding under rule 42 CFR for EHR Incentive Programs.¹¹⁴ One recent success attributable to EHR-PDMP integration was reported in April 2019: Henry Ford Health System reported that the utilization of the Epic integration with Michigan’s PDMP saved roughly 250 h of physician time.¹¹⁵

Point-of-care (micro-tier) interoperability

Another issue surrounding PDMP interoperability is the restricted integration with EHRs because PDMPs require providers to log in via a separate access point.¹¹⁶ Moreover, although PDMP reporting is often required, the ONC reported in 2021 that only 62% of controlled substance-prescribing physicians report accessing the PDMP via EHR.¹¹⁷ Regular use of PDMP within the provider community has not been widely adopted, rendering the collected data to be variable.^118,119 To expand the use of PDMPs, CMS included PDMP utilization under the Improvement Activities section of the Merit-based Incentive Payment System (MIPS), a section that composes 15% of an individual provider’s MIPS score.¹²⁰

Policy Changes and Suggestions

The 21st Century Cures Act mandates access and exchange to electronic health information (EHI) to avoid information blocking that continues to comply with HIPAA rules.¹²¹

With many technical frameworks already established to achieve interoperability, and ONC’s information blocking regulations promoting patient access and data exchange; and with TEFCA now live, the U.S. government ought to move forward to mandate and introduce policies to advance interoperability and data exchange.

TEFCA has taken center stage at HIMSS23 with many panel discussions. The TEFCA framework can be expanded to many use cases to reduce friction around data exchange to achieve interoperability. The federal government should consider initiating the following policy responses:

1. Ensure that the roles of regulator and regulated are delineated, so there do not exist any entrenched interests through information blocking
2. Allocate more funds to healthcare providers for system installation and employee training
3. Mandate providers, EHR Vendors, and other healthcare entities that are entitled to EHI data exchange to stay in compliance, and to exchange data using developed standards
4. Funding open architecture middleware development programs that will help EHR vendors to easily integrate with disparate systems

Response 3 will be difficult to implement because EHR vendors’ resistance to interoperability has significantly delayed HIE progress in the past few years. The upfront cost of purchasing and installing EHR data systems typically ranges from $15,000 to $70,000 per provider and can thus be in the hundreds of millions of dollars for a large hospital system. Paying these installation fees, along with added operational fees, puts a disproportionate burden on smaller providers. In small multi-physician practices, it’s estimated that the EHR installation team will require more than 600 h to build the system and each physician will need an average of 134 h to familiarize themselves. During this implementation period, which can last longer than a year, it is generally anticipated that the practice will see up to 50% fewer patients. These factors dissuade smaller clinics from adopting interoperable EHR systems. The government’s allocation of ‘wasteful spending’ towards EHR implementation and employee training would allow these clinics to adopt these interoperable systems.

ICD-10-CM was adopted by the U.S. 25 years after its release in 1990. This delay was caused by technical and cost concerns, politics, and opposition from the American Medical Association (AMA). Many WHO member states, however, adopted ICD-10 in 1994, only 4 years after its release. ICD-10 was a necessary update from ICD-9 due to the large increase in different codes and new diagnoses, as well as the added specificity regarding cause, manifestation, location, severity, and type of injury/disease. With gradual adoption over 25 years, larger clinics may adopt these standards before others. By mandating a window of five years for providers and EHR vendors to update their standards to meet new medical classifications, systems across the U.S. will interoperate much faster.

Consolidating power at the federal level on HIEs and establishing government-owned EHR vendors would be an obvious solution to force interoperability by disempowering state regulations and private EHR vendors; however, the necessary infrastructure and resulting resistance make this solution infeasible.

An alternative would be providing government funding for open architecture middleware development programs to allow different systems to interoperate, and improve the scalability of interoperability operations. Open architecture middleware refers to “a data exchange framework composed of open and standard components and interfaces” that allows new and legacy EHR systems to communicate with each other. Middleware has been successful in other industries, as proven by credit card point-of-sale terminals that can be connected across global retail chains and banks. This technology can also be extended to make disparate EHR systems interoperable.

Current Trends, Options, and Conclusion

In the US, large government healthcare providers, such as the Department of Defense (DoD), Department of Veterans Affairs (VA), Indian Health Services (IHS), and the Department of Justice’s Bureau of Prisons (BOP) provide direct health care to tens of millions of patients but still lack interoperable EHRs. While the VA previously utilized its own EHR system which was the sole system to continue to function properly at the time of Hurricane Katrina, it is transitioning to a commercial EHR system (Oracle CERNER). While the decision was announced to migrate to the new EHR recently in October 2022, Department of Veteran Affairs announced it was delaying EHE deployments of Oracle EHR until June 2023.¹²²

Health IT standards have been historically developed in parallel; many standards development efforts have been isolated and inconsistent.¹²³ EHR vendors have constructed their business plans based on the intellectual property prospects of these systems, namely proprietary software systems, that “manage the data for insurance reimbursement and care delivery purposes.” Cloud EHR APIs are also proprietary. As such, EHR companies have implemented unique versions of the FHIR API.¹²⁴ EHR vendors “can keep clients they might otherwise lose if they make it difficult to move data to another vendor’s system.”¹²⁵ The 21st Century Cures Act mandates that all EHR vendors meet the new EHI criteria to prevent information blocking and encourage the access, exchange, and use of EHI.¹²⁶ EHR vendors must meet the full scope of EHI criteria by the end of 2023,¹²⁷ with some criteria mandated by the end of 2022. Allowing EHI export capabilities will enable healthcare providers to migrate to their preferred EHR and choose an interoperable EHR for easy and seamless access to EHI. HL7 FHIR APIs will create a complete interoperability solution for healthcare by using standard and widespread technologies, increasing access to meaningful information, reducing information blocking, and making it easier to implement solutions quickly.

Interoperability initiatives must not be one-time efforts; they must be dynamic and collaborative.⁶⁹ While government, industry, and academic efforts are becoming increasingly collaborative, there is still no central organization or platform for best-practice interoperability standards to be established and implemented by all participating bodies.

The information on symptoms, diseases, drugs, remedies, and other aspects of healthcare should be available to relevant organizations and not be constrained by organizational or political boundaries. To address an increasing need for accessing and researching data from diverse sources and environments, the U.S. must develop and implement effective mechanisms to surmount organizational, national, and other political boundaries concerning diverse types of healthcare information.

Contributors

Bharath Perugu provided guidance during the rework phase of the original manuscript; took part in the overall editing process for the manuscript; and contributed to the policy sections of the articles, adding information on current interoperability frameworks such as TEFCA. Varun Wadhwa and Jin Kim participated in drafting the initial copy of the manuscript, involving conducting a literature review of interoperability frameworks in the U.S. and abroad. Jenny Cai edited the original draft under the guidance of Bharath Perugu, Amar Gupta, and Bruce Allen Hecht, designed original figures for the paper, and conducted and drafted a literature review of semantic mediation architectures for interoperability. She was also responsible for correspondence during the review and copyediting process, involving splitting up the original manuscript into a series of three articles and drafting any incomplete sections. Audrey Shin aided in conducting a systematic literature review of semantic mediation architectures for interoperability. Amar Gupta conceived the importance of this topic and the paper, supervised the entire process of research and writing of this manuscript, and contributed to the technical, strategic, and policy aspects. He first wrote a proposal on the critical need to address Healthcare Interoperability issues in 1992 based on his work on the Integration of Heterogeneous Distributed Information Systems for a major agency of the US Government and his IEEE book on this topic.

Acknowledgments

This article incorporates input from over 100 persons in industry, academia, government, and other relevant constituencies. The authors would like to acknowledge Stephanie Zawada (Ph.D. @ Mayo Clinic Graduate School of Biomedical Sciences), Kelly Zhang (MD @ Stanford University School of Medicine), and Bruce Allen Hecht (Master of Science @MIT, VG2PLAY, IEEE Standards Association) for their contributions to this paper. The authors are very grateful to their professional colleagues with whom discussions have been held on the topic of this topic. These colleagues come from many countries. The list for the U.S. includes Micky Tripathi, John Halamka, and (Late) Gio Wiederhold. We would like to thank them all for their interest in this important field and their inputs, comments, and suggestions over several years.

Chatgpt and Chatbots

There was no use of ChatGPT or Chatbots during the drafting of this manuscript.

References

1. NHE fact sheet [Internet]. CMS. Available from: https://www.cms.gov/research-statistics-data-and-systems/statistics-trends-and-reports/nationalhealthexpenddata/nhe-fact-sheet [cited 26 April 2023].
2. Trout KE, Chen LW, Wilson FA, Tak HJ, Palm D. The impact of electronic health records and meaningful use on inpatient quality. J Healthc Qual Off Publ Natl Assoc Healthc Qual. 2022 Apr 1;44(2):e15–23. doi: 10.1097/JHQ.0000000000000314
3. Fry E. Death by a thousand clicks: where electronic health records went wrong [Internet]. Fortune. Available from: https://fortune.com/longform/medical-records/ [cited 26 April 2023].
4. Hanna-Attisha M. Opinion | how a pediatrician became a detective [Internet]. The New York Times. 2018. Available from: https://www.nytimes.com/2018/06/09/opinion/sunday/flint-water-pediatrician-detective.html [cited 26 April 2023].
5. Pennsylvania Patient Safety Authority. Identifying and learning from events involving diagnostic error: it’s a process [Internet]. Advisory. Pennsylvania Patient Safety Authority. Available from: http://patientsafety.pa.gov:80/ADVISORIES/Pages/201810_IdentifyingandLearning.aspx [cited 26 April 2023].
6. Balgrosky JA. Essentials of health information systems and technology [Internet]. Burlington, MA: Jones & Bartlett Learning, 2015; p. 152 (Essential public health). Available from: http://www.r2library.com/Resource/Title/1284036111 [cited 26 April 2023].
7. Pronovost PJ, National Academy of Medicine (U.S.), editors. Procuring interoperability: achieving high-quality, connected, and person-centered care. Washington, DC: NAM.EDU, 2018; 1 p. (Learning health system series).
8. Office for Civil Rights (OCR). Does the HIPAA privacy rule preempt state laws? [Internet]. HHS.gov.; 2007. Available from: https://www.hhs.gov/hipaa/for-professionals/faq/399/does-hipaa-preempt-state-laws/index.html [cited 26 April 2023].
9. hitechact.pdf [Internet]. Available from: https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/understanding/coveredentities/hitechact.pdf [cited 26 April 2023].
10. Trusted Exchange Framework and Common Agreement (TEFCA) [Internet]. HealthIT.gov. Available from: https://www.healthit.gov/topic/interoperability/policy/trusted-exchange-framework-and-common-agreement-tefca [cited 26 April 2023].
11. The Trusted Exchange Framework (TEF): Principles for Trusted Exchange. U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology. January, 2022. Available at: https://www.healthit.gov/sites/default/files/page/2022- [cited 01 May 2023].
12. Harrington A. TEFCA: how it works in tandem with your HIE – contexture [Internet]. Available from: https://contexture.org/tefca-how-it-works-in-tandem-with-your-hie/ [cited 26 April 2023].
13. Benaloh J. Patient controlled encryption. In: Proceedings of the 2009 ACM Workshop on Cloud Computing Security [Internet]. Available from: https://dl.acm.org/doi/10.1145/1655008.1655024 [cited 26 April 2023].
14. Weininger S. The importance of state and context in safe interoperable medical systems [Internet]. IEEE Journals & Magazine. IEEE Xplore. Available from: https://ieeexplore.ieee.org/document/7536138 [cited 26 April 2023].
15. Report to Congress, April 2015 – report on health information blocking. The Office of the National Coordinator for Health Information Technology (ONC) Department of Health and Human Services. 2015. Available at: https://www.healthit.gov/sites/default/files/reports/info_blocking_040915.pdf [cited 01 May 2023].
16. Walderhaug S, Mikalsen M, Hartvigsen G, Stav E, Aagedal J. Improving systems interoperability with model-driven software development for healthcare. Stud Health Technol Inform. 2007;129(Pt 1):122–6. Available from: https://ebooks.iospress.nl/publication/10947 [cited 26 April 2023].
17. Spil T, Klein R. Personal health records success: why Google health failed and what does that mean for microsoft healthvault? In: Proceedings of the 2014 47th Hawaii International Conference on System Sciences, 2014; p. 2818–27.
18. Healthcare – health records [Internet]. Apple. Available from: https://www.apple.com/healthcare/health-records/ [cited 26 April 2023].
19. What is Google health? – Google health [Internet]. Available from: https://health.google/ [cited 22 May 2023].
20. Standards and technology [Internet]. HealthIT.gov. Available from: https://www.healthit.gov/topic/interoperability/standards-and-technology [cited 26 April 2023].
21. Interoperability [Internet]. Available from: https://www.fcc.gov/general/interoperability [cited 26 April 2023].
22. Haug PJ, Narus SP, Bledsoe J, Huff S. Promoting national and international standards to build interoperable clinical applications. AMIA Annu Symp Proc. 2018 Dec 5;2018:555–63.
23. Boucher C. Citrix cloud services & the healthcare EHR market – citrix blogs [Internet]. Citrix; 2018. Available from: https://www.citrix.com/blogs/2018/08/27/citrix-cloud-services-and-the-healthcare-ehr-market/ [cited 26 April 2023].
24. Gaynor M, Myung D, Gupta A, Rawn J, Moulton S. Interoperability of medical applications and devices. In: Proceedings of the 41st Annual Hawaii International Conference on System Sciences [Internet]. IEEE Computer Society, 2008; p. 240. (HICSS ’08). Available from: https://doi.org/10.1109/HICSS.2008.217 [cited 26 April 2023].
25. HL7 V2.6_Appendix_A.pdf [Internet]. Available from: https://www.hl7.org/special/committees/vocab/V26_Appendix_A.pdf [cited 26 April 2023].
26. Dolin RH, Alschuler L, Beebe C, Biron PV, Boyer SL, Essin D, et al. The HL7 clinical socument architecture. J Am Med Inform Assoc JAMIA. 2001;8(6):552–69. doi: 10.1136/jamia.2001.0080552
27. Bender D, Sartipi K. HL7 FHIR: an agile and RESTful approach to healthcare information exchange. In: Proceedings. of the 26th IEEE International Symposium on Computer-Based Medical Systems. June 20-22, 2013; p. 326–31. doi: 10.1109/CBMS31545.2013
28. HL7 v2 messages [Internet]. Public Health Informatics Institute. Available from: https://www.phii.org/sites/www.phii.org/files/resource/files/HL7%20CDA%20Introduction.pdf [cited 01 May 2023]
29. HL7 standards product brief – HL7 version 2 product suite [Internet]. HL7 International. Available from: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=185 [cited 26 April 2023].
30. Improving public health surveillance through interoperability, data standards, and legislation [Internet]. Astho; 2019. Available from: https://www.astho.org/communications/blog/improving-ph-surveillance-through-interoperability-data-standards-legislation/ [cited 26 April 2023].
31. Manos D. Da Vinci submits comments on Interop 3 proposed rule [Internet]. HL7 International; 2023. Available from: https://blog.hl7.org/topic/cms [cited 10 May 2023].
32. Brenda Courtney. An investigation into the use of HL7 clinical document architecture as a standard for discharge summaries in Ireland [Internet]. 2011. Available from: https://www.scss.tcd.ie/postgraduate/health-informatics/assets/pdfs/An%20investigation%20into%20the%20use%20of%20HL7%20Clinical_BC.pdf [cited 01 May 2023].
33. HL7 standards product brief – HL7 CDA® R2 IG: C-CDA templates for clinical notes R2.1 companion guide, release 3 – US Realm [Internet]. HL7 International. Available from: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=447 [cited 27 April 2023].
34. What is the C-CDA healthcare data format? [Internet]. Particle; 2022. Available from: https://www.particlehealth.com/blog/what-is-ccda-consolidated-clinical-document-architecture [cited 27 April 2023].
35. Blumenthal D, Tavenner M. The “meaningful use” regulation for electronic health records. N Engl J Med. 2010 Aug 5; 363(6):501–4. doi: 10.1056/NEJMp1006114
36. What is clinical document architecture (CDA)? [Internet]. Definition from TechTarget. Health IT. Available from: https://www.techtarget.com/searchhealthit/definition/Clinical-Document-Architecture-CDA [cited 01 May 2023].
37. Rocha BH, Pabbathi D, Schaeffer M, Goldberg HS. Screening consolidated clinical document architecture (CCDA) documents for sensitive data using a rule-based decision support system. Appl Clin Inform. 2017 Feb 8;8(1):137–48. doi: 10.4338/ACI-2016-07-RA-0120
38. D’Amore J, Bouhaddou O, Mitchell S, Li C, Leftwich R, Turner T, et al. Interoperability progress and remaining data quality barriers of certified health information technologies. AMIA Annu Symp Proc. 2018 Dec 5;2018:358–67.
39. D’Amore J. Are meaningful use stage 2 certified EHRs ready for interoperability? Findings from the SMART C-CDA collaborative – PMC [Internet]. NIH; 2014. Available from: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4215060/ [cited 01 May 2023].
40. DICOM PS3.1 2023b. [Internet]. Available from: https://dicom.nema.org/medical/dicom/current/output/chtml/part01/ [cited 01 May 2023].
41. Fedorov A, Clunie D, Ulrich E, Bauer C, Wahle A, Brown B, et al. DICOM for quantitative imaging biomarker development: a standards based approach to sharing clinical data and structured PET/CT analysis results in head and neck cancer research. PeerJ [Internet]. 2016, p. 4. Available from: https://peerj.com/articles/2057 [cited 01 May 2023].
42. Imaging integration WG. HL7 Wiki [Internet]. Available from: https://wiki.hl7.org/index.php?title=Imaging_Integration_WG [cited 01 May 2023]
43. Profiles – IHE wiki [Internet]. Available from: https://wiki.ihe.net/index.php/Profiles [cited 01 May 2023].
44. Gupta. Significance of digital imaging and communication in medicine in digital imaging [Internet]. Available from: https://www.digitmedicine.com/article.asp?issn=2542-629X;year=2015;volume=1;issue=2;spage=63;epage=66;aulast=Gupta [cited 01 May 2023].
45. Oosterwijk H. The DICOM standard, overview and characteristics: a whitepaper [Internet]. 2004. Available from: http://www.ringholm.com/docs/02010_en.htm [cited 01 May 2023].
46. Cyleralabs. HIPAA-protected malware? Exploiting DICOM flaw to embed malware in CT/MRI imagery [Internet]. Cylera Labs; 2019. Available from: https://researchcylera.wpcomstaging.com/2019/04/16/pe-dicom-medical-malware/ [cited 01 May 2023].
47. Varma DR. Managing DICOM images: tips and tricks for the radiologist. Indian J Radiol Imaging. 2012 Jan;22(1):4–13. doi: 10.4103/0971-3026.95396
48. Bhartiya S, Mehrotra D. Electronic journal of health informatics challenges and recommendations to healthcare data exchange in an interoperable environment. Electron J Health Inform. 2014 Jan 1;8(2): 25–50. doi: 10.1504/IJEH.2015.071638
49. open.epic. Explore by interface type [Internet]. Available from: https://open.epic.com/Interface/IHE [cited 01 May 2023].
50. Siegel EL, Channin DS. Integrating the healthcare enterprise: a primer. Part 1. Introduction. Radiogr Rev Publ Radiol Soc N Am Inc. 2001;21(5):1339–41. doi: 10.1007/978-1-4613-0115-8_1
51. Noumeir R, Renaud B. IHE cross-enterprise document sharing for imaging: interoperability testing software. Sour Code Biol Med. 2010 Sep 21;5:9. doi: 10.1186/1751-0473-5-9
52. Query for existing data for mobile (QEDm) – IHE wiki [Internet]. Available from: https://wiki.ihe.net/index.php/Query_for_Existing_Data_for_Mobile_(QEDm) [cited 26 May 2023].
53. Dogac A, Kabak Y, Namli T, Okcan A. Collaborative business process support in eHealth: integrating IHE profiles through ebXML business process specification language. IEEE Trans Inf Technol Biomed. 2008 Nov;12(6):754–62. doi: 10.1109/TITB.2008.926465
54. Windle JR, Katz AS, Dow JP, Fry ETA, Keller AM, Lamp T, et al. 2016 ACC/ASE/ASNC/HRS/SCAI health policy statement on integrating the healthcare enterprise. J Am Coll Cardiol. 2016 Sep 20;68(12):1348–64. doi: 10.1016/j.jacc.2016.04.017
55. Meenan C, Erickson B, Knight N, Fossett J, Olsen E, Mohod P, et al. Workflow lexicons in healthcare: validation of the SWIM lexicon. J Digit Imaging. 2017 Jun;30(3):255–66. doi: 10.1007/s10278-016-9935-4
56. Daniel C, Ouagne D, Sadou E, Forsberg K, Gilchrist MM, Zapletal E, et al. Cross border semantic interoperability for clinical research: the EHR4CR semantic resources and services. AMIA Summits Transl Sci Proc. 2016 Jul 20;2016:51–9. doi: 10.1002/lrh2.10014
57. Witting K. Integrating the Healthcare Enterprise. IHE IT Infrastructure (ITI). Cross-Community Dynamic Data. [Internet]. Available from: https://www.ihe.net/Technical_Framework/upload/IHE_ITI_WhitePaper_XC_Dynamic_Data_2009-09-28.pdf [cited 01 May 2023].
58. Mandel J. SMART on FHIR: a standards-based, interoperable apps platform for electronic health records. J Am Med Inform Assoc. 2016 Sep 5;23(5):899–908. doi: 10.1093/jamia/ocv189
59. FHIR® Version History and Maturity. Office of the National Coordinator for Health Information Technology. 2020. Available at: https://www.healthit.gov/sites/default/files/page/2021-04/FHIR%20Version%20History%20Fact%20Sheet.pdf [cited 01 May 2023].
60. Blobel B. PHealth 2018: Proceedings of the 15th International Conference on Wearable Micro and Nano Technologies for Personalized Health 12–14 June 2018, Gjøvik, Norway in SearchWorks catalog. In IOS Press, 2018; p. 182–5. Available from: https://searchworks.stanford.edu/view/13658292 [cited 01 May 2023].
61. Richer J. Health relationship trust profile for fast healthcare interoperability resources (FHIR) UMA resources [Internet]. 2017. Available from: https://openid.net/specs/openid-heart-fhir-uma-1_0-ID1.html [cited 01 May 2023].
62. Apple announces solution bringing health records to iPhone – Apple [Internet]. Available from: https://www.apple.com/newsroom/2018/01/apple-announces-effortless-solution-bringing-health-records-to-iPhone/ [cited 01 May 2023].
63. Tulchinsky I. Behind the scenes of cloud healthcare API. (handout). Available from: https://365.himss.org/sites/himss365/files/365/handouts/553172794/handout-HIMS19%20DL9%20Handout.pdf. [cited 01 May 2023].
64. himss23 [Internet]. Available from: https://info.hl7.org/himss23 [cited 10 May 2023].
65. C for DE and Research. PQ/CMC and HL7 FHIR. FDA [Internet]. 2023. Available from: https://www.fda.gov/industry/pharmaceutical-quality-chemistry-manufacturing-controls-pqcmc/pqcmc-and-hl7-fhir [cited 10 May 2023].
66. EXPEkesheth. SMART on FHIR – azure API for FHIR [Internet]. 2023. Available from: https://learn.microsoft.com/en-us/azure/healthcare-apis/azure-api-for-fhir/smart-on-fhir [cited 10 May 2023].
67. Introducing FHIR works on AWS [Internet]. Amazon Web Services, Inc.; 2020. Available from: https://aws.amazon.com/about-aws/whats-new/2020/12/introducing-fhir-works-on-aws/ [cited 10 May 2023].
68. Summary – FHIR v5.0.0 [Internet]. Available from: http://www.hl7.org/fhir/summary.html [cited 01 May 2023].
69. Braunstein M. Epic on EHR interoperability: not a “1-time project” [Internet]. InformationWeek; 2015. Available from: https://www.informationweek.com/executive-insights-and-innovation/epic-on-ehr-interoperability-not-a-1-time-project- [cited 01 May 2023].
70. Hay D. Pictorial representation of FHIR resources [Internet]. Hay on FHIR; 2014. Available from: https://fhirblog.com/2014/03/28/pictorial-representation-of-fhir-resouces/ [cited 26 May 2023].
71. The Argonaut project: accelerating FHIR [Internet]. 2018. Available from: https://www.hl7.org/documentcenter/public/calendarofevents/himss/2018/The%20Argonaut%20Project%20and%20HL7%20FHIR.pdf [cited 01 May 2023].
72. Halamka J. Dispatch from the digital health frontier: the Argonaut project charter [Internet]. Dispatch from the Digital Health Frontier; 2014. Available from: http://geekdoctor.blogspot.com/2014/12/the-argonaut-project-charter.html [cited 01 May 2023].
73. “Argonaut project” to build on JASON Task Force’s FHIR recommendations [Internet]. Healthcare Innovation. Available from: https://www.hcinnovationgroup.com/interoperability-hie/article/13024324/argonaut-project-to-build-on-jason-task-forces-fhir-recommendations [cited 01 May 2023].
74. Federal Register. 2015 Edition health information technology (Health IT) certification criteria, 2015 edition base electronic health record (EHR) definition, and ONC health IT certification program modifications [Internet]. Available from: https://www.federalregister.gov/documents/2015/10/16/2015-25597/2015-edition-health-information-technology-health-it-certification-criteria-2015-edition-base [cited 01 May 2023].
75. Argonaut data query IG [Internet]. Available from: https://www.fhir.org/guides/argonaut/r2/ [cited 01 May 2023].
76. Marquard B. Overview of argonaut initiatives. Office of the National Coordinator for Health Information Technology. June 2021. Available from: https://www.devdays.com/wp-content/uploads/2021/12/DD21US_20210608_Brett_Marquard_Overview_of_Argonaut_Initiatives.pdf. [cited 01 May 2023].
77. Chaput D. FHIR®: Advancing interoperability standards in the API economy. Office of the National Coordinator for Health Information Technology. 2020. (handout). Available from: https://www.healthit.gov/sites/default/files/page/2020-03/FHIRAdvancingInteroperabilityStandardsintheAPI.pdf. [cited 01 May 2023].
78. CDS hooks [Internet]. Available from: https://cds-hooks.org/ [cited 01 May 2023].
79. Applicability statement for secure health transport [Internet]. Available from: https://wiki.directproject.org/w/images/5/5e/2011-04-28_PDF_-_Applicability_Statement_for_Secure_Health_Transport_FINAL.pdf [cited 01 May 2023].
80. Parmar A. Celebrating and highlighting digital health innovation in the Midwest [Internet]. MedCity News. 2017. Available from: https://medcitynews.com/2017/10/celebrating-highlighting-digital-health-innovation-midwest/ [cited 01 May 2023].
81. The direct project [Internet]. ONC. Available from: https://www.healthit.gov/sites/default/files/factsheets/the-direct-project.pdf [cited 01 May 2023].
82. Home » DirectTrust [Internet]. Available from: https://directtrust.org/ [cited 01 May 2023].
83. An unsolicited “push” of clinical health information to a known destination and information system user. Interoperability Standards Advisory (ISA) [Internet]. Available from: https://www.healthit.gov/isa/unsolicited-push-clinical-health-information-a-known-destination-and-information-system-user [cited 01 May 2023].
84. Abstract model examples – direct project [Internet]. Available from: https://wiki.directproject.org/Abstract_Model_Examples [cited 01 May 2023].
85. HL7.FHIR.UV.VHDIR\Home – FHIR v4.0.1 [Internet]. Available from: http://build.fhir.org/ig/HL7/VhDir/ [cited 01 May 2023].
86. Velamuri S. QRDA—technology overview and lessons learned. J Healthc Inf Manag. 2010;24(3):41–8.
87. Quality Reporting Document Architecture. Informative Document. Version: 2.0 01/15/2014. Available from: https://www.cms.gov/regulations-and-guidance/legislation/ehrincentiveprograms/downloads/guide_qrda_2014ecqm.pdf [cited 01 May 2023]
88. Health information exchange—2nd edition [Internet]. Available from: https://www.elsevier.com/books/health-information-exchange/dixon/978-0-323-90802-3 [cited 01 May 2023].
89. McBridge S. Nursing informatics for the advanced practice nurse [Internet]. 3rd ed. Springer Publishing; 2022. Available from: https://connect.springerpub.com/content/book/978-0-8261-8526-6 [cited 01 May 2023].
90. Moesel C. eCQI 101: Standards for Representing eCQMs. The MITRE Corporation. 2015. (handout). Available from: https://ecqi.healthit.gov/sites/default/files/2019-06/ecqi-101_standards_508.pdf. [cited 01 May 2023].
91. Braunstein M. Health informatics on FHIR: how HL7’s new API is transforming healthcare [Internet]. SpringerLink, 2018; 314 p. Available from: https://link.springer.com/book/10.1007/978-3-319-93414-3 [cited 01 May 2023].
92. CMS implementation guide for quality reporting document architecture category III [Internet]. CMS; 2022. Available from: https://ecqi.healthit.gov/sites/default/files/2023-CMS-QRDA-III-Eligible-Clinicians-IG-v1.1-508.pdf [cited 01 May 2023].
93. open.epic. Exchanging clinical findings [Internet]. Available from: https://open.epic.com/Clinical/HL7v3 [cited 02 May 2023].
94. Promoting interoperability: traditional MIPS requirements [Internet]. Available from: https://qpp.cms.gov/mips/promoting-interoperability [cited 02 May 2023].
95. Dixon B. Health information exchange: navigating and managing a network of health information systems [Internet]. 1st ed. Available from: https://www.elsevier.com/books/health-information-exchange-navigating-and-managing-a-network-of-health-information-systems/dixon/978-0-12-803135-3 [cited 02 May 2023].
96. Blumenthal D. Launching HITECH. N Engl J Med. 2010 Feb 4;362(5):382–5. doi: 10.1056/NEJMp0912825
97. HL7 standards product brief—HL7 version 3 standard: representation of the health quality measure format (eMeasure) release 1 [Internet]. HL7 International. Available from: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=97 [cited 02 May 2023].
98. Automating performance measurement using electronic health records [Internet]. Available from: http://www.hl7.org/documentcenter/public/pressreleases/HL7_PRESS_20090827.pdf [cited 02 May 2023].
99. Quality reporting document architecture (QRDA) overview of category I and III reports [Internet]. CMS; 2013. Available from: https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Downloads/VendorWorkgroupCall_April16.pdf [cited 02 May 2023].
100. Dolin RH, Goodrich K, Kallem C, Alschuler L, Holtz P. Setting the standard: EHR quality reporting rises in prominence due to meaningful use. J AHIMA. 2014 Jan;85(1):42–8.
101. Javellana M. Developing electronic clinical quality measures (eCQMs) for use in CMS programs [Internet]. 2014. Available from: https://www.powershow.com/view4/705fbf-MmQzM/Developing_Electronic_Clinical_Quality_Measures_eCQMs_for_use_in_CMS_Programs_powerpoint_ppt_presentation [cited 02 May 2023].
102. A new era for measure development: clinical quality language is here! [Internet]. Able Health; 2017. Available from: ablehealth.com/2017/11/17/a-new-era-for-measure-development-clinical-quality-language-is-here/ [cited 02 May 2023]
103. Electronic specifications for clinical quality measures [Internet]. CMS. Available from: https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Electronic_Reporting_Spec [cited 02 May 2023].
104. Identity is the great enabler: putting patients at the center of health IT [Internet]. NIST. Available from: https://www.nist.gov/blogs/cybersecurity-insights/identity-great-enabler-putting-patients-center-health-it [cited 02 May 2023].
105. Maler E. Extending the power of consent with user-managed access: a standard architecture for asynchronous, centralizable, Internet-scalable consent. In: 2015 IEEE Security and Privacy Workshops, 2015; p. 175–9.
106. HEART WG [Internet]. OpenID; 2014. Available from: https://openid.net/wg/heart/ [cited 02 May 2023].
107. Opioid overdose [Internet]. Centers for Disease Control and Prevention; 2017. Available from: http://www.cdc.gov/drugoverdose/pdmp/states.html [cited 01 May 2023]
108. History of prescription drug monitoring programs [Internet]. Brandeis University; 2018. Available from: https://www.pdmpassist.org/pdf/PDMP_admin/TAG_History_PDMPs_final_20180314.pdf [cited 02 May 2023].
109. Rhodes E, Wilson M, Robinson A, Hayden JA, Asbridge M. The effectiveness of prescription drug monitoring programs at reducing opioid-related harms and consequences: a systematic review. BMC Health Serv Res. 2019 Nov 1;19(1):784. doi: 10.1186/s12913-019-4642-8
110. Boyles O. What is PDMP? | PDMP medical meaning [Internet]. ICANotes; 2019. Available from: https://www.icanotes.com/2019/01/21/what-is-pdmp-and-what-does-it-mean-for-clinicians/ [cited 02 May 2023].
111. Connecting for impact: linking potential prescription drug monitoring programs (PDMPs) to patient care using health IT [Internet]. Available from: https://www.healthit.gov/sites/default/files/connecting_for_impact-final-508.pdf [cited 02 May 2023].
112. Deyo RA, Irvine JM, Millet LM, Beran T, O’Kane N, Wright DA, et al. Measures such as interstate cooperation would improve the efficacy of programs to track controlled drug prescriptions. Health Aff (Millwood). 2013 Mar;32(3):603–13. doi: 10.1377/hlthaff.2012.0945
113. US Meds [Internet]. Available from: http://hl7.org/fhir/us/meds/2018May/pdmp.html [cited 02 May 2023].
114. Wen H, Schackman BR, Aden B, Bao Y. States with prescription drug monitoring mandates saw a reduction in opioids prescribed to medicaid enrollees. Health Aff (Millwood). 2017 Apr;36(4):733–41. doi: 10.1377/hlthaff.2016.1141
115. Henry Ford’s PDMP-epic integration saves 250 clinician hours a month [Internet]. 2019. Available from: https://www.epic.com/epic/post/henry-fords-pdmp-epic-integration-saves-250-clinician-hours-month [cited 02 May 2023].
116. Griggs C. Prescription drug monitoring programs: examining limitations and future approaches—PMC. Natl Libr Med. 2015 Jan 5;67–70. doi: 10.5811/westjem.2014.10.24197
117. Richwine C, Barker W. Physicians have widespread access to state PDMP data, but data sharing varies across states [Internet]. Health IT Buzz; 2023. Available from: https://www.healthit.gov/buzz-blog/health-it/physicians-have-widespread-access-to-state-pdmp-data-but-data-sharing-varies-across-states [cited 15 May 2023].
118. Haffajee R. Mandatory use of prescription drug monitoring programs [Internet]. Law and Medicine, JAMA, JAMA Network; 2015. Available from: https://jamanetwork.com/journals/jama/article-abstract/2107540 [cited 02 May 2023].
119. Rutkow L, Turner L, Lucas E, Hwang C, Alexander GC. Most primary care physicians are aware of prescription drug monitoring programs, but many find the data difficult to access. Health Aff (Millwood). 2015 Mar;34(3):484–92. doi: 10.1377/hlthaff.2014.1085
120. Lutz J. MIPS and PDMP usage: how they work together [Internet]. Available from: http://www.affirmhealth.com blog mips-and-pdmp.-how-they-work-together [cited 01 May 2023]
121. 45 CFR 171.103—information blocking [Internet]. Available from: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-171/subpart-A/section-171.103 [cited 15 May 2023].
122. New electronic health record system update [Internet]. VA Saginaw Health Care, US Department of Veterans Affairs; 2022. Available from: https://www.va.gov/saginaw-health-care/news-releases/vas-new-electronic-health-record-system-update/ [cited 22 May 2023].
123. Caldwell P. We’ve spent billions to fix our medical records, and they’re still a mess. Here’s why [Internet]. Mother Jones; 2015. Available from: https://www.motherjones.com/politics/2015/10/epic-systems-judith-faulkner-hitech-ehr-interoperability/ [cited 08 May 2023].
124. FastStats electronic medical records [Internet]. 2023. Available from: https://www.cdc.gov/nchs/fastats/electronic-medical-records.htm [cited 08 May 2023].
125. Alder-Mildstein J. Moving past the EHR interoperability blame game [Internet]. Catalyst Carryover, NEJM Catal; 2017. Available from: https://catalyst.nejm.org/doi/full/10.1056/CAT.17.0448 [cited 08 May 2023].
126. Understanding Electronic Health Information (EHI). Office of the National Coordinator for Health Information Technology. November 2, 2022. Available from: https://www.healthit.gov/topic/information-blocking/understanding-electronic-health-information-ehi [cited 01 May 2023].
127. HighlightedRegulatoryDates.pdf [Internet]. ONC. Available from: https://www.healthit.gov/sites/default/files/page2/2020-03/HighlightedRegulatoryDates.pdf [cited 22 May 2023].

Copyright Ownership: This is an open-access article distributed in accordance with the Creative Commons Attribution Non Commercial (CC BY-NC 4.0) license, which permits others to distribute, adapt, enhance this work non-commercially, and license their derivative works on different terms, provided the original work is properly cited and the use is non-commercial. See: http://creativecommons.org/licenses/by-nc/

Appendix 1: Acronyms

Organizational Bodies

• ACR: American College of Radiology, https://www.acr.org/
• CIMI Clinical Information Modeling Initiative, https://www.hl7.org/Special/Committees/cimi/index.cfm
• CLSI Clinical & Laboratory Standards Institute, https://clsi.org/
• CMS Centers for Medicare & Medicaid Services, https://www.cms.gov/
• HEART: Health Relationship Trust Working Group, https://openid.net/wg/heart/
• HIMSS: Health Information and Management Systems Society, www.himss.org/
• HIMSS Health Information and Management Systems Society www.himss.org
• HIS Health Information System
• HL7 Health Level Seven, www.hl7.org
• ICD International Classification of Diseases by the WHO, https://www.who.int/standards/classifications/classification-of-diseases
• ICTs Innovations in Information and Communication Technologies
• IEEE Institute of Electrical and Electronics Engineers, www.ieee.org
• IHE Integrating the Healthcare Enterprise International, www.ihe.net
• IICC The IVD Industry Connectivity Consortium, https://ivdconnectivity.org/
• ISO International Organization for Standardization
• NEMA: National Electrical Manufacturers Association, https://www.nema.org/
• NIST National Institute of Standards and Technology
• ONC Office of the National Coordinator for Health Information Technology, https://www.healthit.gov/
• PDMP: Prescription Drug Monitoring Program, www.cdc.gov/drugoverdose/pdmp/index.html
• RSNA: Radiological Society of North America, https://www.rsna.org/
• SDO Standards Developing Organisations, https://www.nist.gov/
• SHIELD Systemic Harmonization and Interoperability Enhancement for Lab Data, https://mdic.org/program/systemic-harmonization-and-interoperability-enhancement-for-lab-data-shield/#toggle-id-2

Data-related Terminology

• API: Application Programming Interface
• CDA Clinical Document Architecture
• EHR Electronic Health Record
• HQMF Health Quality Measure Format

Nomenclatures

• ICD-10 International Classification of Diseases
• LOINC Logical ObservationIdentifiers Names and Codes
• SNOMED CT “Systematized Nomenclature of Medicine,” www.snomed.org
• UCUM Unified Code for Units of Measure
• USCDI United States Core Date Interoperaiblity

Legal Initiatives

• HIPAA 1996 Health Insurance Portability and Accountability Act to promote the secure “exchange and use of electronic health information,” https://www.hhs.gov/hipaa/index.html
• HITECH 2009 Health Information Technology for Economic and Clinical Health to promote health IT adoption, https://www.hhs.gov/hipaa/for-professionals/special-topics/hitech-act-enforcement-interim-final-rule/index.html
• HIE 2010 State Health Information Exchange Cooperative Agreement Program to promote interoperability amongst states, https://www.healthit.gov/topic/onc-hitech-programs/state-health-information-exchange
• CURES 2016 accelerates medical product development and mandates specific EHR interoperability efforts, https://www.fda.gov/regulatory-information/selected-amendments-fdc-act/21st-century-cures-act
• TEFCA Trusted Exchange Framework and Common Agreement to establish a universal floor for interoperability across the US. https://www.healthit.gov/topic/interoperability/policy/trusted-exchange-framework-and-common-agreement-tefca