How American Hospitals Break Down Data Silos to Share Information Across Systems, Organizations, and Communities |
Short Executive Summary |
This chapter explores Interoperability---the ability of different health information systems, devices, and applications to access, exchange, integrate, and cooperatively use data in a coordinated manner, within and across organizational boundaries. In the fragmented U.S. healthcare landscape, where patients frequently receive care from multiple providers and institutions, interoperability is the essential foundation for continuity, safety, and efficiency. Through detailed U.S. case studies---from a regional health information exchange connecting dozens of hospitals to a national interoperability network using FHIR and a large integrated health system's internal data-sharing platform---we examine how standards like HL7, FHIR, and CDA enable the seamless flow of patient information. The chapter covers the four levels of interoperability (foundational, structural, semantic, and organizational), the key standards and technologies, the role of the federal government (ONC, CMS, TEFCA), the challenges of data governance and patient matching, and the emerging use of APIs to enable patient-mediated exchange. It concludes that interoperability is not merely a technical goal; it is the essential communication infrastructure that transforms healthcare from a collection of isolated data islands into a connected, coordinated, and patient-centered ecosystem. |
|
Interoperability - Speaking a Common Language |
A Detailed Popular-Science Exploration |
1. The Tower of Babel in Healthcare |
Imagine a patient---let us call her Mrs. Garcia---who lives in a suburban community. She receives her primary care from a clinic that uses one EHR vendor. She is admitted to a community hospital that uses a different EHR vendor. She sees a cardiologist in a private practice that uses yet another system. She has lab work done at an independent laboratory. And she fills her prescriptions at a retail pharmacy. |
In a fully interoperable world, all of these organizations would seamlessly share her health information. The cardiologist would see her lab results from the hospital. The primary care physician would receive the discharge summary from the hospital. The pharmacy would be notified of the new prescriptions. |
In the real world, until very recently, this data sharing was difficult, slow, and often impossible. Each system spoke its own language, used its own data formats, and stored data in its own proprietary databases. Sharing information required faxing paper records, burning CDs, or mailing printouts. This fragmentation---the 'Tower of Babel' of healthcare data---was a major source of inefficiency, waste, and patient harm. |
Interoperability is the solution to this problem. It is the ability of different health information systems to communicate, exchange data, and use the data that has been exchanged. It is the 'common language' that allows the HIS to talk to the EHR, the pharmacy system, the lab system, the imaging system, and to systems at other hospitals and clinics. |
Interoperability is not a single technology; it is a set of standards, policies, and practices that enable data sharing. It is essential for patient safety (ensuring that clinicians have a complete picture of the patient's health), for quality of care (reducing redundant tests and improving care coordination), for patient engagement (giving patients access to their own data), and for public health (tracking and reporting diseases). |
This chapter will take you inside the world of interoperability in U.S. healthcare. We will explore the standards that make it possible (HL7, FHIR, CDA), the federal policies that drive it (ONC, CMS, TEFCA), the challenges that remain (data governance, patient matching), and the future of a truly connected healthcare system. |
|
2. The Evolution of Health Information Exchange in the U.S. |
The journey toward interoperability in the U.S. has been a long and gradual one. |
The pre-standards era (pre-1980s): Health data was stored on paper. Exchange was done by mail, fax, or courier. There were no electronic standards. |
The HL7 era (1980s-2000s): HL7 (Health Level Seven) was founded in 1987. It developed the first standards for electronic health data exchange. The early HL7 standards (HL7 v2) used a simple, 'pipe-delimited' format for sending messages (e.g., ADT messages for admission/discharge, ORM messages for orders, ORU messages for results). HL7 v2 was a major step forward, but it had limitations---it was not very flexible, and it did not support complex data structures. |
The CDA era (2000s-2010s): The Clinical Document Architecture (CDA) was developed to address some of the limitations of HL7 v2. CDA is a standard for the exchange of clinical documents (e.g., discharge summaries, progress notes). It allows the documents to be both human-readable and machine-processable. |
The HITECH era (2009-2015): The HITECH Act of 2009 provided funding for the development of Health Information Exchanges (HIEs) and set 'meaningful use' requirements for EHRs, which included the ability to exchange data. This accelerated the adoption of interoperability standards. |
The FHIR era (2010s-present): FHIR (Fast Healthcare Interoperability Resources) is the latest and most transformative standard. It is a RESTful API (web-based) standard that is easier to implement, more flexible, and more powerful than previous standards. It represents a paradigm shift from document-centric exchange (CDA) to data-centric exchange (APIs). |
The TEFCA era (2020s-present): The Trusted Exchange Framework and Common Agreement (TEFCA) is a federal initiative that aims to create a national network of health information exchange, connecting all the regional HIEs into a single, nationwide network. |
|
3. The Four Levels of Interoperability |
Interoperability is not a binary state (on/off). It is a spectrum, with four distinct levels. |
Level 1 - Foundational Interoperability: |
This is the most basic level. It allows one system to receive data from another system, but the data may not be interpretable. For example, System A sends a PDF to System B. System B can receive the PDF and display it to the user, but it cannot extract the data from the PDF. This is like sending a document via email---you can read it, but you cannot automatically process it. |
Level 2 - Structural Interoperability: |
This level defines the structure of the data---the format and syntax. The data is structured so that it can be parsed and understood by the receiving system. For example, a lab result is sent as a structured message with a defined format (e.g., HL7 v2). The receiving system can extract the individual data elements (e.g., the patient's name, the test name, the test result). The data is 'machine-readable.' |
Level 3 - Semantic Interoperability: |
This is the highest level of interoperability. It ensures that the data has a shared meaning---the receiving system understands the clinical context and the semantics of the data. For example, a lab result for 'sodium' is sent using a standard code (LOINC code 2951-2). The receiving system understands that this code means 'sodium' and can interpret the result correctly. This prevents the 'apples and oranges' problem---where one system calls a test 'Na' and another calls it 'Sodium,' causing confusion. |
Level 4 - Organizational Interoperability: |
This level addresses the legal, policy, and governance aspects of data sharing. It ensures that data can be shared across different organizations in a way that is compliant with privacy laws, security regulations, and business agreements. This is the level that addresses the 'trust' and 'policy' aspects of data exchange. |
|
4. The Key Standards: HL7, CDA, FHIR, and More |
Several key standards are the building blocks of interoperability. |
HL7 v2: |
This is the 'grandfather' of healthcare interoperability standards. It is still widely used, particularly for hospital-to-lab and hospital-to-pharmacy interfaces. It uses a simple, message-based format. However, it is less flexible and less powerful than FHIR. |
HL7 v3: |
This is a more complex, object-oriented standard that was developed as a successor to HL7 v2. However, it was very complex and difficult to implement, and it was never widely adopted. |
CDA (Clinical Document Architecture): |
This is a standard for the exchange of clinical documents. It is used for discharge summaries, progress notes, and other documents. CDA documents are both human-readable and machine-processable. |
CCDA (Consolidated CDA): |
This is a specific implementation of CDA that is used for many common clinical document types (e.g., Continuity of Care Document, Discharge Summary, Progress Note). It is the standard that is used for many HIE exchanges. |
FHIR (Fast Healthcare Interoperability Resources): |
This is the modern standard. It is based on RESTful APIs (the same technology that powers the web) and uses JSON or XML for data exchange. FHIR resources are modular 'building blocks' that represent different healthcare data types (e.g., Patient, Encounter, Observation, Medication, Condition). FHIR is much easier to implement than previous standards, and it is more flexible and powerful. |
Key FHIR resources: |
Patient: Demographic information, MRN, contact details. |
Encounter: A visit or episode of care. |
Observation: A lab result, vital sign, or other observation. |
Medication: A medication order or administration. |
Condition: A diagnosis or problem. |
Procedure: A surgical or other procedure. |
CarePlan: A care plan. |
DiagnosticReport: A radiology report or other diagnostic report. |
DocumentReference: A reference to a clinical document (e.g., a CDA document). |
DICOM (Digital Imaging and Communications in Medicine): |
This is the standard for medical imaging (X-rays, CT scans, MRIs). It defines the file format for images and the network protocol for transmitting them. |
LOINC (Logical Observation Identifiers Names and Codes): |
This is a standard for identifying lab tests and other clinical observations. For example, a 'serum sodium' test has the LOINC code 2951-2. |
SNOMED CT (Systematized Nomenclature of Medicine - Clinical Terms): |
This is a standard for clinical terminology. It provides codes for diagnoses, symptoms, procedures, and other clinical concepts. |
RxNorm: |
This is a standard for medication terminology. It provides normalized names and codes for clinical drugs. |
|
5. The Role of the Federal Government |
The U.S. federal government has played a crucial role in driving interoperability. |
The Office of the National Coordinator for Health Information Technology (ONC): |
The ONC is the primary federal agency responsible for health IT. It sets standards, certifies EHR systems, and develops policies. |
The 21st Century Cures Act (2016): |
This landmark legislation included several key interoperability provisions: |
Information blocking: It prohibited 'information blocking'---the practice of interfering with the exchange of electronic health information. This was a major step toward forcing vendors and providers to share data. |
FHIR API requirement: It mandated that certified EHRs must have a FHIR-based API. |
Open Notes: It mandated that patients must have access to their clinical notes. |
CMS (Centers for Medicare & Medicaid Services): |
CMS has also been a driver of interoperability. |
Medicare and Medicaid Promoting Interoperability Program (formerly Meaningful Use): This program provides financial incentives for providers who adopt certified EHRs and demonstrate interoperability. |
Interoperability and Patient Access Rule: This rule, finalized in 2020, requires certain payers (including Medicare Advantage plans, Medicaid managed care plans, and Qualified Health Plans) to provide patients with access to their data via FHIR APIs. |
TEFCA (Trusted Exchange Framework and Common Agreement): |
This is a recent initiative that aims to create a national network of health information exchange. Under TEFCA, multiple HIEs can connect to each other, using a common set of policies and standards. This will make it easier for data to follow the patient across state lines and across different networks. |
|
6. Health Information Exchanges (HIEs) |
Health Information Exchanges (HIEs) are organizations that facilitate the exchange of health information between different healthcare providers. They are the 'regional hubs' of interoperability. |
Types of HIEs: |
Regional HIEs: These are the most common type. They serve a specific geographic region (e.g., a state or a metropolitan area). |
Statewide HIEs: Some states have a single HIE that covers the entire state. |
Enterprise HIEs: These are operated by a single healthcare system and facilitate data sharing within that system. |
Vendor-based HIEs: Some EHR vendors offer their own exchange services (e.g., Epic's Care Everywhere). |
How HIEs work: |
1. A patient is admitted to a hospital that is connected to the HIE. |
2. The hospital queries the HIE for the patient's existing records. |
3. The HIE retrieves the records from other connected providers (e.g., the patient's primary care physician, other hospitals, labs). |
4. The hospital receives the records and incorporates them into the patient's EHR. |
The benefits of HIEs: |
Improved care coordination: Clinicians have access to a more complete patient record. |
Reduced redundant testing: Clinicians can see if a test has already been done. |
Improved patient safety: Clinicians have access to allergy information and medication lists. |
Public health reporting: HIEs can be used to report communicable diseases. |
The challenges of HIEs: |
Funding: HIEs have struggled to find a sustainable business model. |
Governance: Who decides what data is shared and how it is used |
Patient matching: How do you ensure that the data is linked to the correct patient |
Privacy: How do you protect patient privacy in a shared environment |
|
7. Patient Matching: The Persistent Challenge |
One of the most persistent challenges in interoperability is patient matching---ensuring that the data being exchanged is linked to the correct patient. |
The problem: There is no national patient identifier in the U.S. (due to privacy concerns). This means that each hospital and HIE must use its own system for patient identification. This can lead to duplicate records (the same patient has multiple records in different systems) and overlays (the records of two different patients are merged). |
The consequences: Patient matching errors can have serious consequences. A clinician might prescribe a medication based on an incorrect allergy history, or they might miss a critical lab result. |
Solutions: |
Probabilistic matching: The use of statistical algorithms to match patients based on multiple demographic fields (name, date of birth, address, phone number, etc.). This is the most common approach. |
Deterministic matching: The use of exact matches on specific fields (e.g., social security number). |
Biometric matching: The use of biometric data (e.g., fingerprints, facial recognition). |
Patient-verified identity: The patient verifies their identity (e.g., using a patient portal). |
National patient identifier: Some advocates argue for a national patient identifier, but this has been politically controversial. |
|
8. Information Blocking: The Dark Side of Interoperability |
Information blocking is the practice of intentionally interfering with the exchange of electronic health information. It has been a major barrier to interoperability. |
Examples of information blocking: |
Excessive fees: Charging high fees for data exchange. |
Contractual barriers: Including restrictive clauses in contracts that limit data sharing. |
Technical barriers: Making it difficult for other systems to connect to the EHR. |
Delays: Deliberately delaying the exchange of data. |
Refusal to share: Refusing to share data with a patient or with another provider. |
The 21st Century Cures Act prohibited information blocking and gave the ONC the authority to enforce the prohibition. Violators can be penalized. |
The impact of the information blocking rule: The rule has been a major driver of interoperability. It has forced EHR vendors and providers to open up their systems and to share data more freely. |
|
9. API-Based Exchange: The FHIR Revolution |
The advent of FHIR APIs has been a transformative development in interoperability. It moves the focus from exchanging 'documents' (CDA) to exchanging 'data' (FHIR). |
The benefits of APIs: |
Real-time access: APIs allow for real-time access to data, rather than batch transfers. |
Granular access: APIs allow for access to specific data elements (e.g., a specific lab result), rather than entire documents. |
Flexibility: APIs are flexible and can be adapted to many different use cases. |
Developer-friendly: APIs are easier for developers to use than previous standards. |
Use cases for FHIR APIs: |
Patient access (via patient portals): Patients can use a FHIR API to access their own data through a third-party app. |
Provider-to-provider exchange: Clinicians can use a FHIR API to query other providers' systems for patient data. |
Public health reporting: Public health agencies can use a FHIR API to receive data from hospitals. |
Research: Researchers can use a FHIR API to query data from multiple healthcare organizations. |
Smart on FHIR: This is a framework that allows apps to be launched from within an EHR. The app runs in a sandbox and can access the patient's data via the FHIR API. |
|
10. U.S. Case Study: The Indiana Health Information Exchange |
The Indiana Health Information Exchange (IHIE) is one of the oldest and most successful HIEs in the United States. |
Scale: IHIE serves over 100 hospitals, 20,000 providers, and millions of patients in Indiana and surrounding states. |
Services: |
Clinical data exchange: It provides a platform for exchanging clinical data (labs, radiology reports, discharge summaries, etc.) between providers. |
Public health reporting: It provides a platform for public health reporting. |
Quality improvement: It provides data analytics for quality improvement. |
Technology: IHIE uses a combination of HL7 v2, CDA, and FHIR for data exchange. |
Funding: IHIE is a non-profit organization. It is funded by its members and by grants. |
Outcomes: IHIE has been shown to improve care coordination, reduce redundant testing, and improve public health reporting. |
|
11. U.S. Case Study: Epic's Care Everywhere |
Care Everywhere is Epic's interoperability network. It allows Epic users to share patient data with other Epic users, and also with non-Epic systems (via FHIR). |
Scale: Care Everywhere connects thousands of hospitals and clinics that use Epic. |
Features: |
Patient data access: Clinicians can query Care Everywhere for a patient's records from other Epic sites. |
Clinical document exchange: It supports the exchange of CDA documents. |
Record location: It can locate the patient's records at other Epic sites. |
Impact: Care Everywhere has been a major driver of interoperability, particularly among hospitals that use Epic. It has made it much easier for patients to have their data shared across different Epic sites. |
|
12. U.S. Case Study: The CommonWell Health Alliance |
CommonWell Health Alliance is a cross-vendor interoperability network that includes multiple EHR vendors (including Cerner, MEDITECH, and others). |
Goal: CommonWell's goal is to create a national network of health information exchange that is independent of any single EHR vendor. |
Features: |
Patient data access: Providers can query CommonWell for a patient's records from other CommonWell-participating providers. |
Clinical document exchange: It supports the exchange of CDA documents. |
Record location: It can locate the patient's records at other CommonWell sites. |
Impact: CommonWell has been a significant step toward vendor-neutral interoperability. |
|
13. The Future of Interoperability: A Connected Healthcare Ecosystem |
The future of interoperability is a fully connected healthcare ecosystem. |
TEFCA as the backbone: TEFCA will provide the common agreement and trust framework that connects all the regional HIEs and vendor networks into a single, national network. |
API-first architectures: All systems will have FHIR APIs, enabling seamless data access. |
Patient-mediated exchange: Patients will be the 'hub' of their own data. They will be able to grant access to their data to different providers and apps, and they will be able to revoke access at any time. |
Automated data exchange: Data will be exchanged automatically, without the need for manual intervention. For example, when a patient is admitted to a hospital, the hospital will automatically query the HIE for the patient's records. |
AI-powered data integration: AI will be used to integrate and normalize data from different sources, creating a unified view of the patient. |
Blockchain for trust and security: Blockchain may be used to provide a secure, tamper-proof record of data exchanges. |
|
14. The Challenges That Remain |
Despite significant progress, several challenges remain. |
The cost of implementation: Implementing interoperability standards can be expensive, particularly for smaller providers. |
The complexity of data governance: Decisions about who can access data, for what purpose, and under what conditions, are complex. |
Patient matching: Patient matching remains a persistent challenge. |
Privacy and security: Sharing data across multiple organizations creates new privacy and security risks. |
The 'last mile' problem: Even if the technical infrastructure is in place, data may not be integrated into the clinician's workflow in a way that is useful. |
|
Detailed Concluding Summary |
This chapter has provided a comprehensive, plain-English exploration of Interoperability---the common language that enables health information systems to communicate, exchange data, and use the data that has been exchanged. We began by framing interoperability as the essential communication infrastructure that breaks down data silos and transforms healthcare from a collection of isolated data islands into a connected, coordinated, and patient-centered ecosystem. |
We traced the evolution of health information exchange in the U.S., from the pre-standards era of paper and fax, through the HL7 era, the CDA era, and the HITECH era, to the transformative FHIR era and the emerging TEFCA era. We defined the four levels of interoperability---foundational, structural, semantic, and organizational---and described the key standards that enable each level: HL7 v2, CDA, CCDA, FHIR, DICOM, LOINC, SNOMED CT, and RxNorm. |
We explored the critical role of the federal government in driving interoperability through the ONC, the 21st Century Cures Act (with its information blocking prohibition and FHIR API requirement), CMS's Promoting Interoperability Program and Patient Access Rule, and the Trusted Exchange Framework and Common Agreement (TEFCA), which aims to create a nationwide interoperability network. |
We examined Health Information Exchanges (HIEs) as the regional hubs of interoperability, their role in facilitating data sharing, and the challenges of funding, governance, patient matching, and privacy. We delved deeply into the persistent challenge of patient matching, describing probabilistic and deterministic approaches, biometrics, and the ongoing debate over a national patient identifier. |
We addressed the dark side of interoperability---information blocking---and how the 21st Century Cures Act has prohibited it and created enforcement mechanisms. We then celebrated the FHIR revolution, describing API-based exchange as a paradigm shift from document-centric to data-centric interoperability, with real-time access, granular data sharing, and developer-friendly interfaces. We discussed 'Smart on FHIR' and the potential for third-party apps to integrate with EHRs. |
We presented three U.S. case studies: the Indiana Health Information Exchange, one of the oldest and most successful HIEs, serving over 100 hospitals and 20,000 providers; Epic's Care Everywhere, the vendor-based interoperability network that connects thousands of Epic sites; and the CommonWell Health Alliance, a cross-vendor network that promotes vendor-neutral data sharing. |
We looked to the future of interoperability: TEFCA as the backbone of a national network, API-first architectures, patient-mediated exchange (where patients control access to their data), automated data exchange, AI-powered data integration, and blockchain for security and trust. We acknowledged the challenges that remain---cost, complexity of data governance, patient matching, privacy, and the 'last mile' problem of integrating data into clinical workflows. |
|
In conclusion, interoperability is not merely a technical goal; it is the essential communication infrastructure for a healthcare system that is safe, efficient, and patient-centered. In a U.S. healthcare system that is fragmented, costly, and burdened by redundant testing and poor care coordination, interoperability is the key to unlocking value. It gives clinicians a complete picture of the patient, enabling them to make better decisions. It empowers patients with access to their own data, enabling them to be active partners in their care. It enables public health surveillance, research, and quality improvement. And it reduces waste by eliminating redundant tests and procedures. Interoperability is not a destination; it is a journey. It is a journey from isolated data silos to a connected ecosystem, from a Tower of Babel to a common language, and from fragmented care to coordinated, patient-centered care. In that journey, every standard adopted, every API opened, and every record shared brings us one step closer to a healthcare system that truly works for everyone. |
cs@easiersoft.com