Healthcare Interoperability in Practice: How Data Moves Across the US Healthcare System

Healthcare organizations generate enormous amounts of information every day. Physicians document encounters, labs produce test results, pharmacies process prescriptions, insurers verify coverage, and care management teams coordinate patient services. 

All of these activities depend on information moving between different people, organizations, and software systems. 

Yet the US healthcare system does not operate on a single technology platform. Hospitals, physician practices, insurers, laboratories, and digital health companies use different applications, often developed by different vendors and designed for different purposes. 

This creates one of healthcare technology's most persistent challenges: interoperability. 

For software developers, interoperability involves much more than connecting two applications through an API. Systems need to exchange information in formats they can process, interpret clinical and administrative data consistently, and preserve the context that makes that information useful. 

Understanding how this works matters especially for digital health companies entering the US market. Even a well-designed healthcare product can struggle to become part of everyday care if it cannot communicate reliably with the systems that healthcare organizations already use. 

Why Healthcare Interoperability Is So Difficult in the US 

The US healthcare system involves many independent organizations that exchange information for different purposes. 

A hospital may need to share laboratory results with a physician practice. A specialist may need access to clinical information another provider recorded. An insurer needs information about the services delivered to a patient. A care management organization may need to know whether a patient has been admitted to a hospital or completed a recommended screening. 

Each exchange supports a different workflow. 

The challenge is that these organizations may use different software systems, data structures, and terminology. Even when they collect similar information, they may represent it differently. 

Consider something as straightforward as recording a diagnosis. 

A clinician needs to understand the patient's medical condition and determine appropriate treatment. The diagnosis may also be needed for billing, quality measurement, reporting or care coordination. 

For these activities to work across different systems, the information must be represented in a way that other applications can interpret. 

The same problem applies to medications, procedures, laboratory results, clinical observations, and patient encounters. 

Healthcare interoperability therefore depends on several capabilities working together. Systems need ways to exchange information, standardized methods to represent healthcare concepts, and reliable processes to link information to the correct patient and clinical activity. 

A successful technical connection does not automatically mean that the receiving system can use the information correctly. 

This distinction is especially important when developing healthcare software that must operate across multiple providers, insurers or care delivery organizations. 

How Healthcare Data Moves Between Different Systems 

To understand healthcare interoperability, it helps to follow the information generated during a typical patient encounter. 

A patient schedules an appointment with a healthcare provider. Before the visit, the provider may need to verify the patient's insurance coverage. During the encounter, a clinician reviews the patient's medical history, documents findings, and potentially orders laboratory tests or medications. 

After the visit, information about the services provided may be used for billing. Laboratory results may arrive later from another system. Relevant information may also need to be shared with another clinician or a care management team. 

Several types of data exchange can take place during this process. 

Clinical Information Exchange 

Clinical information includes diagnoses, medications, allergies, laboratory results, procedures, observations, and other details relevant to patient care. 

This information may move between EHR systems, laboratory applications, specialist practices, hospitals and digital health platforms. 

For example, when a clinician orders a laboratory test, the order needs to reach the appropriate laboratory system. Once the test is completed, the result must be linked to the correct patient and made available to the ordering provider. 

The information needs to retain its meaning throughout the exchange. 

A laboratory result without the relevant test identification, measurement units, or patient context may be difficult to interpret safely. 

Clinical interoperability therefore involves both transmitting information and ensuring the receiving system understands what it represents. 

Administrative and Insurance Data Exchange 

Healthcare organizations also exchange information that supports administrative and financial workflows. 

Before providing a service, a healthcare organization may need to confirm that a patient has active insurance coverage and determine relevant benefit information. 

After providing care, the organization may submit a claim describing the services delivered and the reasons those services were medically necessary. 

The insurer processes the claim and returns information about payment, adjustments or denials. 

These activities use standardized electronic transactions that differ from the formats typically used to exchange clinical records. 

These transactions form part of the broader US healthcare reimbursement system, where clinical services, insurance coverage and payment rules are closely connected. 

This distinction matters for healthcare software developers. An application may need to support both clinical interoperability and insurance transactions, but the information exchanged and the standards involved are not identical. 

Care Coordination and Population Health Data 

Healthcare data also needs to move between organizations that coordinate patient care. 

A care management platform may need information about hospital admissions, discharges, diagnoses, completed screenings or changes in a patient's treatment. 

Organizations supporting patients with chronic conditions may collect information over time and use it to identify patients who require additional attention. 

In these situations, interoperability supports a longitudinal understanding of the patient rather than a single encounter. 

The receiving system must determine what information is new, how it relates to existing records, and whether it should trigger action. 

For example, a hospital discharge may be relevant to a care coordination team responsible for arranging follow-up services. 

The value of the exchange depends on whether the receiving organization can incorporate the information into its workflow. 

Reliable data exchange is also essential for value-based care technology, where organizations need information from multiple sources to measure outcomes, coordinate care, and manage patient populations. 

HL7 and FHIR: Standards for Exchanging Healthcare Information 

Healthcare organizations need common approaches for exchanging clinical information. Without standards, every integration would require both systems to agree on a completely custom data format. 

Health Level Seven International (HL7) develops standards for exchanging and representing healthcare information. 

Two important approaches in healthcare interoperability are HL7 Version 2 messaging and Fast Healthcare Interoperability Resources, or FHIR. 

HL7 Version 2 and Established Healthcare Integrations 

HL7 Version 2 has been widely used in healthcare environments to exchange information between clinical systems. 

It supports message-based communication for events and activities such as patient admissions, laboratory orders, and test results. 

For example, a hospital may send an admission, discharge, or transfer message to another system when a patient's status changes. 

A laboratory system may send a message containing test results to the EHR. 

These integrations are often deeply embedded in hospital infrastructure. Healthcare companies integrating with established providers may therefore encounter HL7 Version 2 even when their own applications use more modern architectures. 

One practical challenge is that implementations can differ between organizations. 

Although systems may use the same general standard, they can have different requirements for message fields, optional information, and processing behavior. 

As a result, supporting HL7 messaging often involves mapping data, validating messages, and handling variations across connected systems. 

FHIR and Modern Healthcare APIs 

FHIR provides a different approach to representing and exchanging healthcare information. 

It defines standardized resources for common healthcare concepts, including patients, observations, conditions, medications, and encounters. 

These resources can be exchanged through APIs, making FHIR particularly relevant to modern healthcare applications and integrations. 

For example, a digital health platform may need to retrieve patient demographics, access clinical observations, or exchange information about encounters. 

FHIR provides a standardized structure for representing these concepts. 

However, using FHIR does not eliminate every interoperability challenge. 

A FHIR resource can include different combinations of information, depending on implementation requirements. Organizations may also use different terminology systems or apply different constraints to the data they exchange. 

Developers still need to understand which resources are required, which fields must be populated, and how the receiving system expects the information to be represented. 

This is where implementation guides become important. 

In the US, implementation requirements such as US Core help establish more consistent expectations for exchanging common clinical information using FHIR. 

For digital health companies, FHIR can standardize integration, but successful implementation still requires deep knowledge of healthcare data and the systems involved. 

Healthcare Coding Systems: Why Sharing Data Is Not Enough 

One of the most important aspects of healthcare interoperability is consistently representing medical concepts. 

Sending information from one system to another is only useful if the receiving system can interpret it correctly. 

Consider a patient diagnosed with diabetes. 

A clinician may document the diagnosis in the medical record. The same condition may be relevant to an insurance claim, a quality measure, a care management program or a population health report. 

If different systems represent that diagnosis inconsistently, it becomes more difficult to compare records, generate reports or automate downstream workflows. 

Healthcare organizations therefore use standardized coding systems and clinical terminologies. 

These systems serve different purposes, and software developers need to understand the distinctions. 

ICD-10-CM: Representing Diagnoses 

ICD-10-CM is widely used in the United States to classify diagnoses and medical conditions. 

Diagnosis codes are particularly important for claims processing, reporting, and other administrative activities. 

For example, an insurance claim may include an ICD-10-CM code explaining the medical reason for a service. 

These codes can also support population-level analysis by helping organizations identify patients with particular conditions. 

However, diagnosis classification does not capture every detail of clinical documentation. 

A healthcare application may need to support additional clinical terminology to represent observations, findings, and other information recorded during patient care. 

CPT and HCPCS: Representing Healthcare Services 

CPT and HCPCS codes are used to describe healthcare services, procedures, and certain products or supplies. 

They play an important role in reimbursement because insurers need to know which services a healthcare provider delivered. 

For example, a claim generally needs information about the service performed, the supporting diagnosis, and the responsible healthcare professional or organization. 

From a software perspective, this means clinical documentation and billing information need to be connected. 

A completed encounter may provide the information needed for coding and claims preparation, but the system must preserve the relationship between the service, the patient, the provider, and the relevant diagnosis. 

This is one reason interoperability between clinical systems and billing applications can be more complex than simply transferring a completed medical note. 

SNOMED CT, LOINC and Medication Terminologies 

Other terminology systems support representing clinical information. 

SNOMED CT provides a structured terminology for clinical concepts such as findings, conditions, and procedures. 

LOINC is widely used to identify laboratory tests, measurements, and clinical observations. 

Medication information may use terminology and identifiers such as RxNorm and National Drug Codes, depending on the workflow. 

These systems help healthcare applications communicate more precisely about the information being exchanged. 

For example, two laboratories may use different internal names for a test. Standardized identifiers help receiving systems recognize that the results refer to the same measurement. 

Similarly, consistent medication terminology can support information exchange between prescribing, pharmacy, and clinical applications. 

For healthcare developers, the important point is that a single patient record may contain information represented through several different coding systems. 

An EHR integration or healthcare data platform needs to preserve those distinctions. 

A diagnosis code, procedure code, laboratory identifier, and medication identifier aren't interchangeable just because they are all represented as codes. 

Why Healthcare Data Mapping Is a Major Engineering Challenge 

Healthcare interoperability often requires mapping information between different systems. 

One application may represent a clinical concept using an internal identifier. Another may expect a standardized terminology code. A third may require additional fields or a particular structure. 

The integration needs to translate information while preserving its meaning. 

Consider a digital health platform collecting patient observations. 

The platform may store the measurement, value, unit, timestamp, and patient identifier in its own database. 

When exchanging that observation with an EHR, the receiving system may expect a standardized observation code, an appropriate unit, a reference to the patient, and other contextual information. 

The integration must determine how the source information corresponds to the required destination structure. 

This can involve terminology mapping, field transformations, validation, and handling incomplete information. 

It also requires understanding which differences are technically acceptable and which could change the data's clinical meaning. 

For example, a measurement value without its unit can be misleading. An observation linked to the wrong patient or encounter can cause a more serious problem. 

Healthcare data mapping is therefore not simply an exercise in renaming database fields. 

It requires knowledge of the underlying clinical concepts and the workflows that will use the information. 

This becomes increasingly important when a healthcare product integrates with multiple organizations. 

Each integration may introduce variations in implementation, terminology, or data quality. Without a consistent internal information model, those differences can become difficult to manage as the platform grows. 

How Healthcare Providers and Insurers Exchange Data 

Clinical information exchange is only one part of healthcare interoperability. In the United States, healthcare providers and insurance companies also exchange large volumes of administrative and financial information. 

These transactions support everyday activities such as verifying insurance coverage, submitting claims, and communicating payment decisions. 

Unlike clinical information exchanged through HL7 or FHIR, many of these processes rely on electronic transactions adopted under the HIPAA administrative simplification framework, particularly the ASC X12 standards. 

For healthcare software developers, this creates an important architectural distinction. A platform may need to exchange clinical information with an EHR while simultaneously communicating with insurers, billing companies, or clearinghouses through different technical standards. 

Insurance Eligibility: The 270 and 271 Transactions 

Before providing a healthcare service, a medical practice may need to verify whether a patient has active insurance coverage. 

The provider's administrative system can send an electronic eligibility inquiry using an X12 270 transaction. 

The insurer or its intermediary responds with a 271 transaction containing available eligibility and benefit information. 

Depending on the inquiry and the insurer's response, this information may include whether the patient has active coverage, relevant benefits, copayment information, and deductible details. 

Consider a patient arriving for a specialist appointment. 

The receptionist enters or confirms the patient's insurance information. The practice management system sends an eligibility inquiry and receives a response that helps staff determine whether the patient's coverage is active and what financial information is available for the planned service. 

This process may seem simple to the user, but it involves communication between the provider's system and external insurance infrastructure. 

The application must generate the appropriate request, process the response, and present the relevant information in a format administrative staff can understand. 

It must also handle situations where information is unavailable, incomplete, or inconsistent. 

An eligibility response does not guarantee that a future claim will be paid. Coverage and payment can depend on additional requirements, including the specific service and the patient's benefits. 

Claims Submission: The 837 Transaction 

After providing healthcare services, the organization must communicate relevant billing information to the insurer. 

The X12 837 transaction is used to submit healthcare claims electronically. 

A claim typically includes information identifying the patient, the healthcare provider, the services performed, and the diagnoses associated with those services. 

For example, a claim may contain ICD-10-CM diagnosis codes, CPT or HCPCS service codes, the date of service, and the National Provider Identifier of the relevant healthcare professional or organization. 

The information may come from clinical documentation and administrative records, but it must be transformed into a format suitable for claims processing. 

Some healthcare organizations submit claims through billing companies or clearinghouses rather than directly from their EHR. 

In these arrangements, the integration between clinical software and billing infrastructure becomes especially important. 

The billing system needs sufficient information to prepare the claim accurately, while the healthcare organization needs to maintain visibility into what was submitted. 

Payment Information: The 835 Transaction 

After processing a claim, the insurer may communicate payment and adjustment information through an X12 835 electronic remittance advice transaction. 

The response can indicate which services were paid, which amounts were adjusted, and whether particular claim lines were denied. 

It may also communicate relevant patient responsibility amounts. 

The healthcare organization's billing system uses this information to reconcile payments and determine whether additional action is required. 

For software developers, the challenge is maintaining the relationship between the original clinical activity, the submitted claim, and the subsequent financial response. 

A healthcare organization needs to understand not only whether it received payment, but also which services the payment relates to and why any differences occurred. 

These transactions show why interoperability between healthcare providers and insurers differs fundamentally from exchanging clinical observations or medical records. 

Both are essential to healthcare operations, but they involve different information models, standards, and workflows. 

Patient Identification Is Essential for Reliable Data Exchange 

Even when two healthcare systems use compatible standards, exchanging information accurately depends on identifying the correct patient. 

This is particularly challenging in the United States because healthcare organizations do not share a universal national patient identifier used consistently across all systems. 

A hospital, primary care practice, insurer, and digital health platform may each maintain a different internal identifier for the same individual. 

When information moves between these organizations, the receiving system needs to determine which existing patient record it belongs to. 

Patient matching may involve demographic information such as names, dates of birth, addresses, and other identifiers, depending on the systems and applicable requirements. 

However, demographic information can contain inconsistencies. 

A patient may change their surname or address. Names may be entered differently across organizations. Records may contain missing information or typing errors. 

These differences create risks when matching incoming information with existing records. 

If the system fails to recognize an existing patient, it may create a duplicate record. If it incorrectly associates information with another person, the consequences can be more serious. 

For healthcare software companies, patient identification should therefore be treated as a core integration requirement rather than an administrative detail. 

Applications need appropriate mechanisms for matching records, detecting potential duplicates and handling cases where the correct patient cannot be established confidently. 

The same principle applies to clinical context. 

Identifying the patient is necessary, but an incoming laboratory result may also need to be associated with the correct order or encounter. 

Reliable interoperability depends on preserving these relationships throughout the exchange. 

Why Healthcare Integrations Are Difficult in Practice 

Healthcare interoperability standards make data exchange more consistent, but they do not eliminate the practical challenges of connecting different organizations. 

An integration that works with one hospital or EHR vendor may require additional configuration when deployed elsewhere. 

The difficulty often comes from implementation differences rather than a lack of a recognized standard. 

Different Systems Implement Standards Differently 

Two healthcare systems may support FHIR but expose different resources, require different fields or apply different authorization and implementation requirements. 

Similarly, organizations using HL7 Version 2 may configure their messages differently. 

An integration therefore needs to account for each connected system's specific requirements. 

Developers may need to transform fields, validate required information, and handle variations in how particular clinical concepts are represented. 

This can become a significant engineering challenge for digital health companies expanding from one healthcare customer to several. 

Healthcare Data Is Often Incomplete or Inconsistent 

Not every system contains the same patient information. 

A hospital may have detailed admission records but limited information about the patient's care outside the hospital. A care management platform may have extensive information about patient engagement but only selected clinical data. 

Even when information is available, its quality can vary. 

Records may contain outdated demographics, missing values, inconsistent terminology or incomplete clinical documentation. 

Integration software needs to account for these conditions. 

For example, a receiving application should not assume that every incoming observation includes all the information needed for its intended use. 

Data validation, error handling, and clear rules for processing incomplete information are essential. 

Integrations Need to Handle Operational Failures 

Healthcare data exchange also involves operational reliability. 

External systems may be temporarily unavailable. A message may fail validation. An API request may time out. The receiving system may reject information because a required field is missing. 

Handle these situations without silently losing important information. 

Depending on the workflow, an integration may require retry mechanisms, error queues, processing logs or notifications that allow staff to investigate unsuccessful exchanges. 

It is also important to prevent unintended duplicate processing when a request or message is submitted more than once. 

The appropriate approach depends on the clinical or administrative process involved. 

For example, a temporary failure when retrieving historical information has different implications from a failed exchange involving a time-sensitive clinical result. 

This is why reliable healthcare integrations require understanding both the technical interface and the operational importance of the information being exchanged. 

Interoperability Between Healthcare and Social Care Organizations 

Healthcare interoperability is increasingly relevant beyond hospitals, physician practices, and insurance companies. 

In the United States, healthcare organizations are paying greater attention to social factors that affect patients' health, including housing instability, food insecurity, and transportation barriers. 

These needs can influence whether patients can follow treatment plans, attend appointments, or manage chronic conditions. 

Addressing them may require collaboration between healthcare providers, care management teams, and community-based organizations. 

However, social care organizations often operate outside traditional healthcare technology infrastructure. 

A community organization providing food assistance or housing support may use different software than a hospital or medical practice. 

This creates a challenge when healthcare organizations need to coordinate services and understand whether patients actually received the assistance they were referred for. 

Connecting Social Needs Screening With Referrals 

A healthcare organization may identify a social need during a patient assessment. 

For example, a patient with diabetes may report difficulty accessing sufficient food. 

The healthcare team may document the need and refer the patient to an organization that provides food assistance. 

From a technology perspective, several activities may need to be connected. 

The healthcare system records the identified need, creates a referral, sends the relevant information to the community organization, and communicates the referral outcome back to the care team. 

This process is often described as a closed-loop referral. 

The objective is to determine whether the referral resulted in the intended service, not simply to record that a referral was sent. 

For healthcare software developers, supporting this workflow requires exchanging information between systems with very different capabilities. 

Standardized Codes for Social Needs 

Standardized coding is also becoming important for representing social needs. 

In the United States, ICD-10-CM includes Z codes that can describe certain social circumstances and factors influencing health. 

These codes help healthcare organizations document relevant social risks and use the information for reporting or care-coordination workflows. 

For example, housing instability information may be recorded in a structured form to support referrals or population health analysis. 

Initiatives such as the Gravity Project have worked to standardize social determinants of health information, including terminology and data-exchange approaches. 

The goal is to make information about social needs more consistent across healthcare and social care systems. 

However, standardized codes do not mean every community organization has the technology to exchange information electronically. 

Practical interoperability also depends on infrastructure, funding, organizational processes, and participating organizations' ability to adopt compatible systems. 

Why Closed Loop Referrals Matter 

Consider a healthcare organization that identifies a patient who needs transportation assistance to attend medical appointments. 

The care team creates a referral to a community organization. 

If the systems are disconnected, the healthcare provider may have no reliable way to determine whether the patient received the service. 

Staff may need to contact the organization manually or rely on the patient to provide an update. 

With an integrated referral workflow, the community organization can potentially communicate the referral status or service outcome back to the healthcare platform. 

The care team can then see whether the need was addressed and decide whether further intervention is required. 

This illustrates how interoperability can support care coordination beyond exchanging traditional clinical records. 

It also introduces additional requirements around permissions, privacy, consent where applicable, and the appropriate sharing of sensitive personal information. 

For digital health companies developing care management or patient engagement platforms, these capabilities can become important as healthcare organizations expand their coordination activities beyond clinical settings. 

What Digital Health Companies Should Consider Before Building Healthcare Integrations 

Healthcare companies entering the US market often need to integrate with existing systems before their products can become part of routine healthcare operations. 

The integration requirements depend heavily on what the product does. 

A remote patient monitoring platform may need to exchange observations with an EHR. A telehealth application may need patient demographics, encounter data, and clinical documentation. A care management platform may need information about diagnoses, admissions, discharges, and care plans. 

A billing application may require entirely different transactions and coding structures. 

Before selecting an integration approach, companies should understand the specific workflow they need to support. 

Several questions are particularly important. 

Which systems need to exchange information? 

Connecting a digital health application to an EHR is different from integrating with an insurance clearinghouse or a community referral platform. 

Each environment may involve different technical interfaces and organizational requirements. 

What information is actually required? 

An application may not need access to a patient's entire medical record. 

It may only require selected observations, medication information, encounter details or administrative data. 

Defining the minimum necessary information for the intended workflow can reduce integration complexity and unnecessary data exposure. 

Which standards and implementation requirements apply? 

FHIR may suit certain clinical API integrations, while established hospital systems may rely on HL7 Version 2 messaging. 

Insurance eligibility and claims workflows commonly involve X12 transactions. 

Selecting the correct approach requires understanding the receiving system and the business process. 

How will information be mapped and validated? 

The development team needs to understand the source data, the destination requirements, and the terminology used by both systems. 

It should also define how to handle incomplete, inconsistent, or unexpected information. 

What happens when the integration fails? 

Healthcare integrations need appropriate monitoring and operational procedures. 

Teams should know whether information was successfully delivered, whether it was accepted, and what action is required when processing fails. 

These considerations matter most for products expected to operate across multiple healthcare organizations. 

An integration designed around the assumptions of a single customer can become difficult to maintain as the company expands. 

Designing Healthcare Software for Long-Term Interoperability 

For digital health companies, interoperability should influence software architecture from the beginning. 

A product that initially operates independently may eventually need to connect with several EHR vendors, healthcare providers, insurers or other platforms. 

If the application's internal data structures are closely tied to one external system, supporting additional integrations can become difficult. 

A more sustainable approach is to define a consistent internal representation of the healthcare information the product needs. 

External integrations can then translate between that internal model and each connected system's requirements. 

This does not eliminate the need for integration-specific development, but it can help prevent differences between external systems from spreading throughout the application. 

The architecture should also preserve important healthcare relationships. 

Patients, encounters, observations, diagnoses, orders, and results represent different concepts. Their identifiers, timestamps, and associations must remain reliable as information moves between systems. 

Initiatives such as the United States Core Data for Interoperability (USCDI) help establish common expectations for the healthcare information that systems should be able to exchange. 

Security and access management are equally important. 

Healthcare integrations may involve protected health information, so developers need to consider appropriate authentication, authorization, encryption, auditability, and applicable regulatory requirements. 

The goal is to build a platform that can exchange information reliably while remaining adaptable as healthcare customers, workflows, and integration requirements evolve. 

Final Thoughts 

Healthcare interoperability is a foundation of modern healthcare technology in the United States. 

Clinical systems need to exchange patient information. Healthcare providers and insurers communicate through standardized administrative transactions. Care management platforms rely on information from multiple organizations, while social care integrations are expanding the range of services that can be coordinated electronically. 

These activities depend on different standards, coding systems, and technical approaches. 

HL7 and FHIR support clinical information exchange. X12 transactions support important insurance and billing processes. Clinical terminologies help systems represent diagnoses, procedures, observations and medications consistently. 

Yet standards alone do not guarantee successful interoperability. 

Healthcare software must also handle patient identification, clinical context, data mapping, incomplete records, implementation differences, and operational failures. 

For digital health companies, these challenges can determine how easily a product integrates into existing healthcare workflows and how effectively it can scale across organizations. 

Understanding interoperability at both the technical and operational levels is therefore essential when building software for the US healthcare market. 

Building Healthcare Software That Needs to Integrate With US Healthcare Systems? 

Touch4IT has more than six years of experience developing healthcare technology for the US market, including our long-term engineering partnership with BigHeart, a healthcare platform supporting large Medicaid populations. 

Our healthcare engineering work includes EHR functionality, telehealth, remote patient monitoring, care management, patient engagement, healthcare data infrastructure, and integrations. 

We understand the importance of connecting clinical workflows, patient information, and administrative processes within healthcare platforms that need to operate in complex environments. 

Whether you are building a digital health product, extending an existing healthcare platform, or developing integrations with US healthcare systems, talk to Jan, our healthcare lead. 

Frequently Asked Questions (FAQs) 

1. What is healthcare interoperability? 

Healthcare interoperability is the ability of different healthcare information systems to exchange, interpret, and use patient, clinical, and administrative data. It allows EHRs, laboratories, insurers, pharmacies, and digital health platforms to communicate, even when they use different software. Effective interoperability requires compatible technical standards, consistent healthcare terminology, and accurate patient identification. 

2. What is the difference between HL7 and FHIR? 

HL7 is an organization that develops healthcare information exchange standards, while FHIR is one of those standards. HL7 Version 2 is commonly used for message-based communication between established hospital systems, including laboratory results and patient admission notifications. FHIR uses standardized healthcare resources and modern API approaches to support information exchange between applications. Both remain relevant in US healthcare interoperability. 

3. Which healthcare data standards are used in the United States? 

Common standards include HL7 Version 2 and FHIR for clinical information exchange, ASC X12 for insurance eligibility and claims transactions, and clinical terminology systems such as ICD-10-CM, CPT, HCPCS, SNOMED CT, LOINC, and RxNorm. Each serves a different purpose, from representing diagnoses and laboratory observations to communicating services performed and insurance payment information. 

4. Why is EHR integration so challenging? 

EHR integration is challenging because healthcare systems may implement standards differently, use inconsistent terminology and store information in different structures. Developers must also address patient matching, data validation, access permissions, incomplete records, and failed transactions. Even when two applications support FHIR or HL7, they may still need additional mapping and configuration to exchange information reliably. 

5. How do healthcare providers and insurers exchange data electronically? 

US healthcare providers and insurers commonly use standardized X12 transactions. The 270 transaction requests insurance eligibility information, while the 271 provides the response. Healthcare claims are submitted using the 837 transaction, and insurers communicate payment and adjustment information through the 835 transaction. These administrative exchanges are distinct from clinical information exchanged through HL7 or FHIR. 

6. How does healthcare interoperability support care coordination? 

Healthcare interoperability helps care teams access relevant information from different providers and organizations. This may include diagnoses, laboratory results, hospital admissions, discharges, and completed services. It can also support referrals to community organizations addressing social needs such as food insecurity or transportation. When referral outcomes are communicated back to the healthcare provider, care teams can better understand whether the patient received the intended assistance.