Hospitals are not single information systems. They are ecosystems containing electronic health records (EHRs), laboratory systems, radiology information systems, picture archiving and communication systems (PACS), pharmacy systems, billing platforms, public-health registries, patient portals and external health-information exchanges. Each system may represent the same patient, encounter or clinical event differently. A laboratory system may identify a test by a local code, a radiology system may transmit images in a specialized format, and an EHR may store a diagnosis using a national billing classification. Without agreed standards, data can be exchanged syntactically but still be misunderstood.

Interoperability is therefore more than connecting applications. It is the ability of systems and organizations to exchange, interpret and use information consistently. For healthcare managers, interoperability affects patient safety, continuity of care, operational efficiency, regulatory compliance, analytics and the economics of digital transformation.

This chapter examines the standards and governance practices that support interoperability, with particular attention to HL7, FHIR, DICOM, ICD, SNOMED CT and LOINC. It also addresses patient matching, application programming interfaces (APIs), health information exchange (HIE), data quality and contemporary developments.

Learning objectives

1. The layers of interoperability

Layer	Central question	Typical concern
Technical	Can systems connect and transmit data?	Networks, transport, authentication
Syntactic	Is the structure readable by the receiving system?	XML, JSON, message segments, schemas
Semantic	Does the receiver interpret the data in the same way?	Codes, units, value sets, definitions
Organizational	Can workflows and responsibilities operate across institutions?	Referral processes, service agreements
Legal and policy	Is exchange permitted and accountable?	Consent, privacy, retention, liability

Technical interoperability is necessary but insufficient. A message may arrive successfully while the receiving system misinterprets “positive” as a laboratory result rather than a pregnancy status, or treats a medication dose as milligrams when it is micrograms. Semantic interoperability requires shared meaning, including definitions, permissible values, units, context and provenance.

A useful distinction is between data exchange and data use. Exchange concerns movement from one system to another. Use concerns whether the receiving clinician, decision-support tool or analytic model can safely act on the information. High-quality interoperability supports both.

2. Standards, terminologies and classifications

A standard is an agreed specification for representing, exchanging or managing information. A terminology provides concepts and their relationships. A classification groups entities into categories for a defined purpose, often reporting, reimbursement or population statistics. These functions overlap but are not interchangeable.

For example, SNOMED CT can represent the detailed clinical concept “bacterial pneumonia caused by a named organism.” ICD may classify the condition into a category suitable for morbidity statistics or reimbursement. LOINC identifies a laboratory observation, while a local laboratory system may additionally need a code for the specimen, method and reference range.

2.1 HL7

Health Level Seven International develops standards for clinical and administrative data exchange. “HL7” may refer broadly to the organization or to particular standards.

HL7 v2 is a widely implemented message standard. It uses delimited segments such as MSH (message header), PID (patient identification), OBR (observation request) and OBX (observation result). A laboratory result message can be transmitted when a test is completed. Its strengths include maturity, broad deployment and efficient event-based exchange. Its limitations include local variation, optional fields and dependence on implementation guides and interface agreements.

HL7 Clinical Document Architecture (CDA) represents clinical documents such as discharge summaries. CDA combines a machine-readable header with human-readable narrative and coded sections. It is useful where document integrity and clinical readability are important, although extracting discrete data from narrative documents can be difficult.

HL7 FHIR—Fast Healthcare Interoperability Resources—uses modular resources such as Patient, Encounter, Observation, DiagnosticReport, MedicationRequest and AllergyIntolerance. Resources can be exchanged through RESTful APIs using JSON or XML, and can also be represented in documents, messages and subscriptions. FHIR profiles, extensions, implementation guides and value sets adapt the general specification to local or national requirements.

FHIR does not automatically guarantee interoperability. Two organizations may both claim to use FHIR while applying different profiles, code systems, cardinalities or interpretations. Conformance testing, version control and governance remain essential.

2.2 DICOM

Digital Imaging and Communications in Medicine (DICOM) is the principal standard for medical images and related information. It supports image storage, querying, retrieval, worklists and communication between modalities and PACS. DICOM metadata may include patient, study, series, modality and acquisition information.

DICOM is not simply an image-file format. It defines information objects, services and communication behavior. A CT study, for example, may contain multiple series and hundreds of images, each linked to identifiers and acquisition metadata. DICOM also supports structured reports and, through standards such as DICOMweb, web-based access to imaging resources.

A major governance issue is the protection of identifying metadata. De-identification for research must remove or transform identifiers while preserving the attributes necessary for the research question. Re-identification risk can remain because images and unusual combinations of dates, locations or clinical details may be identifying.

2.3 ICD

The International Classification of Diseases (ICD), maintained by the World Health Organization, is primarily a classification for diseases, injuries, causes of death and health reporting. National modifications may add detail for reimbursement and administrative purposes. ICD coding is generally performed after clinical documentation and is influenced by coding rules, encounter context and national policy.

ICD is valuable for reporting, case-mix analysis, utilization management and population surveillance. It is not designed to express every clinically relevant nuance at the point of care. A diagnosis recorded in ICD should not automatically be treated as a complete clinical problem list without examining status, certainty, timing and documentation.

2.4 SNOMED CT

SNOMED CT is a multilingual, concept-based clinical terminology. It provides concepts, descriptions, relationships and reference sets. Its compositional structure can represent clinical findings, procedures, body structures, organisms and situations with greater clinical detail than many classifications.

SNOMED CT supports problem lists, clinical documentation, decision support and data reuse. Its expressive power creates implementation responsibilities: organizations need authorized editions, release management, terminology services, mapping policies and training. A SNOMED CT code should be stored with its code system and version context where required.

2.5 LOINC

Logical Observation Identifiers Names and Codes (LOINC) identifies measurements, observations, documents and some survey instruments. A laboratory concept is characterized by dimensions such as component, property, timing, system, scale and method. LOINC identifies what was observed; it does not normally provide the result value, reference interval or interpretation.

The distinction between the test identity and the result is essential. “Hemoglobin concentration” and “12.5 g/dL” are different data elements.

2.6 Relationship among standards

Standards are complementary rather than competing. FHIR may carry a DiagnosticReport; the report may refer to an Observation coded in LOINC; a diagnosis may use SNOMED CT or ICD depending on purpose; an imaging study may point to DICOM objects. A terminology service may provide mappings and value-set expansion used by all of these exchanges.

Need	Common standard or terminology	Primary role
Event-based clinical messaging	HL7 v2	Admission, discharge, laboratory and scheduling messages
Clinical documents	HL7 CDA	Structured, human-readable documents
API-based exchange	HL7 FHIR	Modular resources and modern interoperability
Medical imaging	DICOM	Images, metadata and imaging services
Statistical and administrative classification	ICD	Disease and cause classification
Detailed clinical concepts	SNOMED CT	Findings, disorders, procedures and problems
Laboratory and observation identification	LOINC	Tests, measurements and observations

3. Coding and terminology governance

Coding is not merely a technical mapping exercise. It is a socio-technical process involving clinicians, coders, informaticians, vendors, compliance officers and managers. Governance should define who may create local codes, how codes are retired, how mappings are validated and how changes are communicated.

Mappings are often directional and imperfect. A detailed SNOMED CT concept may map to several ICD codes depending on context. Conversely, one broad ICD category may correspond to many clinical concepts. A map should therefore record equivalence, broader-than, narrower-than or related-to relationships, and should not imply clinical equivalence when none exists.

Terminology servers can provide lookup, translation, validation and value-set expansion. They reduce duplication but do not remove the need for clinical review.

4. APIs and health information exchange

An API is a defined interface through which software requests or submits data. A FHIR REST API commonly uses HTTP methods: GET to retrieve, POST to create, PUT or PATCH to update, and DELETE where permitted. In healthcare, authorization, auditability and minimum-necessary access are as important as technical functionality.

An API should specify resource profiles, search behavior, pagination, error responses, versioning and terminology expectations. “FHIR-enabled” is not a complete design specification.

HIE models

Each model involves trade-offs in governance, latency, availability, duplication, consent and operational cost. A centralized repository may support analytics but create a high-value security target. A federated model may preserve local control but make identity resolution and query performance more difficult.

5. Patient matching and identity management

Patient matching links records that refer to the same person; it must not be confused with authentication, which verifies a person’s claim about identity. A master patient index (MPI) stores or references demographic and identity attributes and supports matching across systems.

Deterministic matching uses exact or rule-based agreement on identifiers such as a trusted national identifier, medical record number, date of birth and surname. Probabilistic matching calculates or assigns a likelihood based on several fields, accounting for spelling variation, missing data and conflicting evidence. Both approaches require thresholds and human review for uncertain cases.

where S is the match score, m_i represents agreement on field i, w_i is the weight assigned to that agreement, c_j represents a contradiction on field j, and v_j is the penalty for that contradiction. This is a governance model rather than a universal formula; weights, thresholds and fields must be validated against local data. The score has no inherent probability interpretation unless calibrated against labelled records.

A false positive merges two people’s records and can cause serious clinical harm. A false negative fragments one person’s history and may lead to duplicated testing or incomplete risk assessment. Controls include:

Biometrics may strengthen matching in some settings but introduce privacy, accessibility, false-match and governance risks. No matching method should be treated as infallible.

6. Data quality for interoperability

Dimension	Meaning	Example control
Completeness	Required values are present	Mandatory specimen and collection time
Validity	Values conform to permitted formats or codes	Validate against a FHIR profile
Accuracy	Data represent the real-world fact	Reconcile medication list with pharmacy data
Consistency	Related representations do not conflict	Same date of birth across systems
Timeliness	Data are available when needed	Monitor result transmission delay
Uniqueness	One real-world entity is not duplicated	MPI duplicate review
Provenance	Origin and transformation are known	Record source, author and timestamp

Quality should be measured at the point of capture and after exchange. For example, a laboratory interface may validate that a numeric result has a permitted unit, but clinical review is still needed to identify implausible values. Data quality dashboards should report trends by department, interface, code set and error type rather than only a hospital-wide average.

A useful management principle is that quality is contextual. A missing apartment number may be critical for home care but irrelevant to a pathology trend analysis. Quality requirements should therefore be linked to clinical, operational, financial or research use cases.

7. Implementation framework for hospitals

A practical interoperability programme can proceed through the following stages.

Stage 1: Establish the use case

Define the clinical or operational problem, participating organizations, data users, safety risks and success criteria. “Improve interoperability” is too broad; “deliver a complete discharge summary and medication list to the receiving clinic within one hour” is testable.

Stage 2: Map the information flow

Document source systems, data elements, identifiers, transformations, destinations, timing and failure points. Include manual workarounds and paper processes, which often reveal hidden dependencies.

Stage 3: Select standards and profiles

Choose the standard appropriate to the exchange. Use DICOM for imaging objects, FHIR for API-accessible resources, HL7 v2 for established event interfaces, and suitable terminologies for clinical meaning. Specify profiles, value sets, units, cardinalities and error handling.

Stage 4: Design identity, consent and security

Define patient identity processes, organizational identifiers, user roles, authorization, consent rules, audit requirements, breach response and retention. Security must be designed into the architecture rather than added after deployment.

Stage 5: Build and test

Testing should include structural validation, terminology validation, workflow testing, negative cases, performance, downtime recovery and user acceptance. Test realistic data, including missing names, duplicate patients, amended results, corrected diagnoses and late-arriving documents.

Stage 6: Deploy incrementally

Pilot with a limited service, monitor safety and usability, train staff, and establish support procedures. Avoid assuming that a technically successful interface is operationally successful.

Stage 7: Monitor and improve

Track delivery rates, rejected messages, terminology errors, duplicate identities, response times, data completeness, user-reported incidents and patient outcomes. Governance should include a process for changing profiles and retiring obsolete interfaces.

8. Illustrative case: regional emergency and laboratory exchange

Background. A regional hospital receives emergency patients from three community clinics. Each clinic uses a different EHR. Laboratory results are sent by fax or manually re-entered, and duplicate patient records are common.

Problem. Clinicians experience delays, repeated tests and uncertainty about whether an imported result belongs to the correct patient. Managers want a scalable exchange rather than another point-to-point interface.

Analysis. The project team identifies four separate problems: inconsistent identity data, absence of a shared laboratory vocabulary, insecure document transmission and unclear responsibility for correcting errors. It also finds that the clinics use different local codes for the same potassium test and do not consistently transmit units or collection times.

Approach. The organizations create a shared governance agreement and a regional MPI. Registration staff standardize demographic capture and use a manual review queue for uncertain matches. Laboratory observations are mapped to approved LOINC concepts, with units, specimen, reference intervals, result status and timestamps. A FHIR API exposes Patient, Encounter, Observation and DiagnosticReport resources. Imaging remains accessible through the PACS using DICOM services. Access is protected through organizational trust agreements, role-based authorization, audit logs and defined emergency-access procedures.

The implementation guide specifies required fields, value sets, error responses, amendment handling and downtime procedures. A pilot begins with emergency laboratory results. Clinicians validate that imported results display source, time, status and reference range clearly.

Outcome. The pilot reduces manual transcription and makes recent results available during emergency assessment. However, the team discovers that some clinic addresses are outdated and that a result-status value is interpreted differently by two systems. The project therefore adds data-quality monitoring and revises the implementation guide before expansion.

Learning points. The case demonstrates that interoperability is simultaneously a standards, identity, workflow, governance and change-management problem. FHIR enabled exchange, but terminology mapping, patient matching, testing and accountability determined whether the exchange was safe.

9. Ethical, regulatory and managerial considerations

Health data exchange involves confidentiality, autonomy, equity and institutional accountability. Managers must distinguish legitimate use from convenient access. Consent requirements vary by jurisdiction and use case, but even where consent is not the legal basis, transparency, purpose limitation and access control remain important.

Important controls include data minimization, encryption, least-privilege access, segregation of duties, audit review, breach response and vendor due diligence. APIs increase the number of possible access points; therefore, an API strategy must include lifecycle management, security testing and revocation of obsolete applications.

Interoperability can produce inequity when patients lack digital access, have unstable addresses, use different names or speak languages poorly supported by systems. Matching algorithms may perform differently across demographic groups. Organizations should evaluate error rates and access outcomes, not merely technical performance.

Artificial intelligence increases the value of standardized data for prediction, documentation and decision support, but it also magnifies coding errors, missingness and bias. AI systems should receive provenance-rich data, versioned terminology and clear uncertainty indicators. Interoperability does not make an algorithm clinically valid; local validation, monitoring and human accountability remain necessary.

10. Contemporary developments and future direction

Current development is moving toward API-based exchange, patient-mediated access, event notifications, computable clinical knowledge and national interoperability networks. FHIR subscriptions can support notification when relevant resources change. Bulk-data approaches can support population analytics, subject to privacy and governance controls. DICOMweb facilitates web-based imaging workflows, while structured reporting improves machine use of imaging findings.

The future challenge is not simply more data. It is trustworthy, computable and context-preserving data. Systems must communicate uncertainty, provenance, correction history and clinical intent. Organizations should resist the assumption that one universal format will eliminate local governance. Sustainable interoperability requires shared institutions, maintained implementation guides, skilled professionals and continuous measurement.

Chapter Summary

Interoperability enables healthcare systems to exchange and use information safely. It has technical, syntactic, semantic, organizational and legal dimensions. HL7 v2 supports established event messaging; CDA supports structured clinical documents; FHIR supports resource-based APIs; and DICOM supports medical imaging and its metadata. ICD is primarily a classification for reporting and administrative purposes, SNOMED CT provides detailed clinical concepts, and LOINC identifies observations and tests.

Safe exchange depends on terminology governance, validated mappings, patient matching, consent, security, provenance and data-quality management. APIs and HIE models provide different ways to connect organizations, each with operational and governance trade-offs. Patient matching requires strong registration, thresholds, human review and auditable correction processes. A successful interoperability programme begins with a specific use case, defines information flows, selects appropriate standards, tests realistic failure cases and monitors performance after deployment. Standardization is therefore a continuing organizational capability, not a one-time technology purchase.

Key Terms

Interoperability: The ability of systems or organizations to exchange and use information consistently.

Technical interoperability: The capacity of systems to connect and transmit data.

Semantic interoperability: The ability to preserve and interpret meaning across systems.

CDA: HL7 Clinical Document Architecture for structured, human-readable clinical documents.

DICOM: Standard for medical images, metadata and imaging communication services.

ICD: International classification used for diseases, injuries and health reporting.

Value set: An authorized collection of codes permitted for a particular data element.

Terminology service: A service that supports code lookup, validation, mapping and value-set operations.

API: An application programming interface through which software exchanges data or services.

Health information exchange: Organized electronic exchange of health information among authorized participants.

Data provenance: Information about the origin, author, time and transformations of data.

Implementation guide: A specification explaining how a standard is constrained and used for a particular context.

Review Questions

Short Answer Questions

Long Answer Questions

Analytical / Application Questions

Multiple Choice Questions with Answers

Question 1

Which standard is primarily designed for medical images and related imaging communication services?

Question 2

Question 3

Correct Answer: C. The receiving system interprets exchanged data with the intended meaning

Question 4

Question 5

Question 6

Which terminology is primarily a detailed clinical terminology rather than a disease classification?

Question 7

Which item is essential when transmitting a laboratory result for safe interpretation?

Question 8

Question 9

Which HIE model allows an authorized participant to search for information held by another organization?

Question 10

Correct Answer: B. They define local constraints, profiles, value sets and exchange behavior

Chapter 7 Health Data Standards, Coding and Interoperability

Health Data Standards, Coding and Interoperability

Introduction and context