LIS interoperability: why data silos stall precision medicine

Yet a substantial share of the information generated by those tests still moves through fragmented workflows: legacy interfaces, scanned documents, static PDF reports, manual transcription, and systems that exchange data without understanding its meaning.

That is the central operational problem behind today’s laboratory information system interoperability challenges. A molecular result can be analytically valid, clinically important, and delivered on time—and still fail to support precision medicine if it cannot be found, queried, compared, or interpreted inside the systems where care decisions are made.

For laboratory directors and hospital administrators, this is not an abstract informatics issue. It is a throughput, compliance, and utilization problem. When genomic data remains trapped in an LIS, a reference laboratory portal, or an EHR attachment, the organization loses the ability to reuse that data efficiently. Every downstream decision becomes more dependent on manual review.

The objective is not to eliminate every legacy interface overnight. That is neither realistic nor financially responsible. The objective is to build a controlled transition from document exchange to computable clinical-genomic data exchange, using the right combination of HL7 v2, HL7 FHIR, LOINC, SNOMED CT, HGNC, and domain-specific models.

The structural failure of PDF-based genomic reporting

Static PDF reporting was a reasonable delivery mechanism when a diagnostic report was treated as the final product. In precision medicine, it is only one representation of the product.

A PDF can communicate a conclusion to a clinician. It cannot reliably support longitudinal querying across thousands of patients. It cannot automatically determine whether a variant was reported previously under a different nomenclature. It cannot consistently trigger a clinical decision-support rule. It does not provide a clean computational pathway for reinterpretation when variant classifications, treatment guidelines, or patient histories change.

This distinction matters most in next-generation sequencing workflows. NGS reports often contain multiple layers of information:

• The ordered test and clinical indication.
• Specimen identity, collection details, and chain-of-custody events.
• Genes, transcripts, variants, and genomic coordinates.
• Variant classifications and evidence statements.
• Tumor or germline context.
• Quality metrics and limitations.
• Therapeutic, prognostic, or diagnostic implications.
• Recommendations for additional testing or specialist review.

When this content is delivered as a document, those fields may be visible to a human reader but unavailable to an LIS, EHR, tumor registry, utilization-management engine, or population health platform. The data exists. Operationally, it is still missing.

This creates predictable waste. A clinician searches for a prior molecular result and finds only an attachment. A molecular tumor board reviews the same case repeatedly because historical findings are not structured for retrieval. A laboratory staff member manually transfers information between systems. A health system cannot reliably distinguish an actionable result from a negative result at scale.

The cost is not limited to labor. Manual handling increases the exposure surface for transcription errors, mismatched patient identifiers, incomplete context, and delayed communication. It also weakens the audit trail. A compliance program can demonstrate that a report was issued. It is harder to demonstrate that the underlying information was consistently available, correctly mapped, and usable throughout the care pathway.

A PDF can finish a reporting workflow. It cannot finish a precision medicine workflow.

The correct response is not to ban PDFs. Clinicians still need readable reports, and document formats remain useful for formal communication and record retention. The problem is treating the PDF as the canonical data object. In a modern diagnostic architecture, the document should be a presentation layer generated from structured source data—not the only durable representation of the result.

HL7 v2 is not the same as semantic interoperability

Many laboratories already exchange data through HL7 v2. That matters, but it does not solve the entire problem.

HL7 v2 is widely deployed across hospital and reference laboratory infrastructure. It is effective for moving messages between systems that have agreed on the basic structure of an exchange. Results, orders, patient identifiers, and status updates can be transmitted through established interface channels.

The limitation is that syntactic exchange does not guarantee semantic agreement. Two systems may successfully transmit a result while using different local codes, different field conventions, or different assumptions about the meaning of a value. The message arrives. The receiving system still may not know how to use it.

This is the difference between moving data and making data operationally interoperable.

FHIR addresses that gap through resource-based exchange, RESTful APIs, and modern data formats such as JSON and XML. More importantly, it creates a framework for representing clinical information in a way that can be retrieved and reused by different applications. FHIR is not a magic conversion layer. It still requires disciplined implementation, terminology governance, identity management, and agreement on profiles.

A practical laboratory strategy should therefore treat HL7 v2 and FHIR as complementary during the transition period.

The executive mistake is to frame the decision as HL7 v2 versus FHIR. The actual decision is whether the organization will preserve reliable current-state operations while building a future-state data model.

A laboratory that replaces interfaces without fixing terminology, identity, or workflow ownership will simply create a newer data silo. The technology will be modern. The operating model will remain broken.

What an interoperability program must control

A high-performing program manages at least five separate layers:

• Transport: How information moves between systems, including v2 interfaces, APIs, and secure exchange services.
• Structure: How orders, observations, specimens, interpretations, and reports are represented.
• Terminology: How tests and findings are identified using standards such as LOINC, SNOMED CT, and HGNC.
• Identity: How the organization matches patients, specimens, providers, and episodes of care across platforms.
• Governance: Who owns mapping decisions, exception handling, version control, and change management.

Most failed programs overinvest in transport. They purchase middleware, establish connectivity, and then discover that the receiving system cannot distinguish local test names or interpret the result context. Middleware is valuable, but it cannot compensate for an unmanaged semantic layer.

The coding gap is a governance problem, not a minor mapping defect

The scale of the terminology challenge is visible in the NIH Genetic Testing Registry. An exploratory analysis of 25,472 genetic tests from 240 laboratories found that all tests mapped to HGNC identifiers, while fewer than half mapped to SNOMED CT codes.

That finding has direct operational significance. Gene identifiers are necessary, but they are not sufficient to describe the full clinical meaning of a diagnostic test. A laboratory may identify the relevant gene accurately while leaving the broader clinical concept—test type, condition, finding, procedure, or interpretation—poorly represented for downstream systems.

This creates a familiar pattern:

1. The laboratory performs a valid test.

2. The LIS generates a result using local terminology.

3. The result is transmitted or attached to the patient record.

4. The receiving system stores the content but cannot reliably classify it.

5. A clinician or analyst must interpret the record manually.

6. The organization loses the ability to automate utilization, follow-up, and longitudinal analysis.

The issue is not solved by mapping every field to a code once. Molecular diagnostics change continuously. Assays evolve. Panels are revised. Laboratories update reporting conventions. Reference databases change. Clinical interpretations are reclassified. A terminology map that is correct today may be incomplete after the next assay revision.

Laboratory leadership needs a terminology operating model, not a one-time cleanup project. That model should define:

• The canonical test catalog.
• Ownership of local-to-standard mappings.
• Versioning for assays, panels, and reporting templates.
• Rules for retired or replaced tests.
• Governance for LOINC and SNOMED CT usage.
• Representation of genes and genomic entities through appropriate identifiers.
• Escalation for concepts that lack a clean standard mapping.
• Auditability of every material mapping decision.

The financial logic is straightforward. A weak mapping program creates recurring manual work. It also reduces the value of every downstream investment in analytics, automation, and clinical decision support. A health system can spend heavily on an API platform and still fail to produce usable diagnostic intelligence if the data entering that platform is semantically inconsistent.

The difference between a test code and a clinical result

A laboratory test is not simply a name in a catalog. It is an event with context.

For molecular diagnostics, useful context may include the specimen source, disease setting, patient status, methodology, target list, result category, variant details, interpretation, and limitations. The receiving system needs to know whether it is handling an order, an observation, a final interpretation, or a narrative explanation.

This is where LOINC, SNOMED CT, HGNC, and other controlled vocabularies perform different functions. They should not be treated as interchangeable labels. A gene identifier does not replace a test identifier. A finding code does not replace the specimen context. A narrative interpretation does not automatically become a computable clinical assertion.

The governance team must define what each terminology is responsible for representing. Without that discipline, mapping becomes an exercise in finding the closest-looking code. That approach produces apparent completeness and operational ambiguity.

Precision-DM shows the scale of the modeling problem

Molecular tumor boards expose the limitations of document-centric reporting quickly. These teams need to combine pathology, imaging, clinical history, genomic findings, treatment history, and evidence review. The decision is rarely based on one isolated result.

The Precision Oncology Core Data Model, or Precision-DM, was developed for molecular tumor board use. It defined 16 profiles and 355 data elements, with 61% of those elements mapped to HL7 FHIR.

The value of this model is not that it provides a universal replacement for every laboratory data structure. Its value is that it makes the operational complexity visible. Precision oncology requires more than a single variant field. It requires a coherent set of profiles and data elements that can represent the patient, specimen, observation, interpretation, clinical context, and decision process.

A laboratory beginning an interoperability program should adopt the same discipline. Start with the decisions the data must support. Then define the minimum information required to make those decisions reliably.

For a molecular tumor board, that may include:

• Patient and encounter identity.
• Tumor type and disease stage.
• Specimen source and collection date.
• Test performed and version of the assay.
• Genes or genomic regions evaluated.
• Detected variants and their classifications.
• Evidence supporting the interpretation.
• Prior molecular results.
• Treatment history and current therapy.
• Relevant clinical trials or therapeutic options.
• Limitations, coverage gaps, and recommended follow-up.
• Date of interpretation and responsible laboratory or clinical service.

The operational point is critical: not every data element needs to be exposed to every user in the same way. A pathologist, oncologist, data analyst, utilization-management team, and compliance officer have different requirements. The architecture must support role-appropriate access without destroying the underlying consistency of the record.

A structured model also improves reinterpretation. Genomic knowledge changes. A result that was not actionable at the time of initial reporting may become relevant later. If the original finding is stored as structured data with stable identifiers and provenance, the laboratory can reassess it more efficiently. If it exists only as a PDF, reinterpretation becomes a document review exercise.

The business case for structured genomic data is not better formatting. It is controlled reuse.

Building the integration architecture without creating another silo

Many organizations approach interoperability by purchasing middleware. That is often necessary. It is never sufficient.

Middleware solutions for diagnostic labs can normalize messages, route data, transform formats, manage interface queues, and connect systems that were not designed to communicate directly. They can reduce point-to-point complexity and provide operational visibility. But middleware should sit inside an architecture with clear ownership and defined source-of-truth rules.

A practical target architecture usually includes:

1. The LIS as the operational system of record for laboratory workflow.

It manages accessioning, specimen processing, technical work, result review, and release. It should not be forced to become the enterprise-wide clinical data warehouse.

2. An integration layer for transport and transformation.

This layer manages HL7 v2 messages, FHIR APIs, routing, validation, retries, acknowledgements, and exception queues. It should expose interface health as an operational metric, not hide it from laboratory leadership.

3. A terminology service or controlled mapping repository.

Local test codes, standard codes, gene identifiers, specimen concepts, and result categories require versioned governance. Mapping logic should not be buried inside undocumented interface scripts.

4. A structured clinical-genomic repository.

This may be part of an enterprise data platform or a specialized molecular data store. Its purpose is to support longitudinal retrieval, analytics, reinterpretation, tumor board review, and clinical decision support.

5. The EHR as the point of care.

Clinicians need concise, usable results in the workflow where decisions occur. They should not be required to navigate multiple portals to reconstruct a patient’s molecular history.

6. Monitoring and audit controls.

The organization needs evidence that messages were received, records were matched, terminology was applied, and exceptions were resolved.

This model avoids a common failure: treating the EHR, LIS, and molecular platform as competing owners of the same information. Each system should have a defined responsibility. The integration layer should make those responsibilities visible and enforceable.

Metrics that belong in the executive dashboard

Interoperability programs often report technical activity rather than operational performance. Counting interfaces and API calls is not enough. Leadership should track measures that connect data exchange to laboratory throughput and clinical utility.

Useful measures include:

• Percentage of molecular results delivered as structured data rather than document-only output.
• Percentage of test concepts mapped to approved standard terminologies.
• Rate of unmatched patient or specimen identifiers.
• Interface rejection and retry rates.
• Time from result verification to availability in the clinical workflow.
• Percentage of results requiring manual transcription or reconciliation.
• Number of unresolved terminology exceptions by age.
• Frequency of duplicate testing associated with inaccessible prior results.
• Percentage of amended or reinterpreted results successfully propagated.
• Availability of specimen provenance and chain-of-custody events across systems.
• User access time for prior molecular findings during tumor board review.
• Number of critical results delivered without complete clinical context.

These measures should be segmented by assay class. A basic chemistry result and a comprehensive genomic profile do not carry the same data complexity or failure modes. Aggregated metrics can conceal the exact workflows creating the highest compliance and margin risk.

Sync for Genes demonstrates the need for coordinated standards

The ONC and NIH All of Us Research Program collaborated through the Sync for Genes initiative to pilot FHIR-based clinical genomic data exchange. The initiative is important because it recognizes a basic limitation of isolated implementation: no single laboratory can establish interoperability by itself.

Genomic information moves through a chain that includes ordering clinicians, laboratory systems, reference laboratories, EHRs, research programs, registries, and decision-support tools. If each participant implements a different representation, the burden moves to manual reconciliation.

A standards-based exchange model creates a common direction. It does not remove local implementation work. Organizations still need to determine which FHIR resources and profiles they will support, how they will represent genomic observations, how they will manage provenance, and how they will protect sensitive information.

The strategic lesson is to avoid waiting for a perfect national endpoint. Standards mature through controlled deployment. A laboratory can begin with a narrow, high-value use case:

• Structured delivery of finalized molecular results to the EHR.
• Retrieval of prior genomic findings for tumor board review.
• Automated notification of amended interpretations.
• Exchange of test catalogs and orderable concepts.
• Standardized representation of specimen provenance.
• Data feeds for utilization review and duplicate-test prevention.

Each use case should have a defined owner, measurable service level, and exception process. A broad interoperability program without a prioritized use case will become an indefinite architecture exercise.

FHIR implementation still requires operational discipline

FHIR creates a modern exchange mechanism. It does not decide whether the laboratory’s result is complete, whether the patient match is correct, or whether a local test code has been mapped appropriately.

Before implementation, the organization should settle several practical questions:

• Which system is authoritative for each data element?
• Which results must be structured at launch?
• Which narrative content remains necessary for clinical interpretation?
• How will amended reports be linked to original results?
• How will the organization represent negative, indeterminate, failed, and cancelled tests?
• How will variant identifiers remain stable across reinterpretation?
• How will consent, access control, and sensitive genomic information be handled?
• What happens when the receiving EHR cannot support the full data model?
• Which failures require immediate escalation?
• How will new assays enter the terminology and interface governance process?

The answer to these questions belongs in operating policy, not only in technical documentation. If the laboratory cannot explain who owns a failed message or an incorrect mapping, the architecture is not production-ready.

A phased operating plan for laboratory leaders

The most efficient path is a staged program tied to business and clinical priorities. The sequence below is deliberately practical.

Phase one: inventory the data silos

Map every system that creates, receives, stores, or transforms diagnostic information. Include the LIS, EHR, pathology systems, molecular platforms, reference laboratory portals, tumor registries, data warehouses, payer-facing systems, and manual work queues.

For each flow, document:

• Data owner.
• Transport method.
• Data format.
• Local terminology.
• Patient and specimen identifiers.
• Manual intervention points.
• Failure handling.
• Retention and audit requirements.
• Clinical or financial consequence of delay.

Do not begin with the most technically interesting assay. Begin with the workflow where inaccessible data creates the greatest operational exposure.

Phase two: establish the canonical model

Define the minimum structured dataset required for priority use cases. Separate required fields from optional narrative. Assign an authoritative source to each field.

At this stage, leaders should resist overengineering. A model that cannot be implemented consistently is not a strategic asset. It is a new source of variation.

Phase three: prioritize terminology and identity

Resolve the most consequential local codes first. Establish rules for LOINC, SNOMED CT, HGNC, and any genomic-specific identifiers used by the organization. Implement patient and specimen matching controls before expanding the number of destinations.

A wrong result delivered quickly is a compliance incident. Speed has no value when identity controls are weak.

Phase four: modernize exchange selectively

Maintain HL7 v2 where it provides reliable continuity. Add FHIR capabilities for use cases that require queryable, reusable, and longitudinal data. Use the integration layer to manage both rather than forcing an abrupt replacement.

The target is controlled coexistence. The laboratory should know exactly which workflows remain message-based and which are moving to API-enabled exchange.

Phase five: measure adoption and retire manual work

Track whether clinicians and laboratory staff are actually using the structured pathway. A technically successful interface may still fail if users continue downloading PDFs, rekeying results, or relying on separate portals.

Retire redundant manual steps only after the structured workflow is stable, monitored, and auditable. Otherwise, the organization risks removing a flawed control before the replacement has earned operational trust.

The compliance and margin implications

Interoperability is often funded as an information technology project. Its consequences belong to laboratory operations.

Poor exchange increases the chance of incomplete records, delayed communication, duplicate testing, and inconsistent follow-up. It complicates internal audits and external accreditation reviews. It can undermine utilization management because the organization cannot reliably determine what testing has already occurred. It also creates friction in the revenue cycle when orders, medical necessity documentation, results, and clinical context are distributed across disconnected systems.

The exact financial loss from unintegrated LIS platforms varies by organization and should not be invented. The operational exposure is nevertheless clear. Manual reconciliation consumes skilled staff time. Repeated testing consumes capacity and materials. Delayed result availability can slow treatment decisions. Unresolved interface exceptions accumulate as hidden backlog.

Laboratory directors should treat interoperability exceptions like any other production constraint. They need owners, service levels, escalation rules, and trend reporting. An exception queue that grows quietly is not an IT inconvenience. It is a control failure.

The same applies to supply chain and staffing. Molecular diagnostics already depend on specialized personnel, constrained reagents, instrument availability, and complex accessioning. Adding manual data handling to every result multiplies the burden without improving analytical quality. Automation must remove work from the process, not merely move it from one department to another.

The decision standard is simple: can the result be used twice?

A mature laboratory does not measure success by whether a report was issued. It measures whether the information can support the next legitimate task without being reconstructed manually.

Can the oncologist retrieve the finding during a treatment decision? Can the tumor board see prior results without opening multiple documents? Can the laboratory identify amended reports that require follow-up? Can the utilization team recognize a recent equivalent test? Can the analyst query a patient cohort without reading thousands of PDFs? Can the compliance team trace who changed, transmitted, or acknowledged the result?

If the answer is no, the organization has document delivery, not interoperability.

The transition will take time. HL7 v2 remains embedded in legacy EHR and LIS environments. FHIR adoption is not uniform. Terminology mapping requires ongoing governance. Genomic data carries additional privacy and access requirements. None of these facts justify inaction.

The responsible strategy is controlled modernization: preserve the interfaces that keep today’s laboratory running, standardize the concepts that make data reusable, and move priority workflows toward structured clinical-genomic exchange.

Laboratory information system interoperability challenges are ultimately management challenges. Technology provides the transport. Leadership must define the model, enforce ownership, fund the governance, and measure the result.

A laboratory that continues to treat molecular diagnostics as static documents will eventually pay for that decision through manual labor, duplicated capacity, delayed clinical use, and rising compliance exposure. The mandatory next step is not another disconnected interface. It is an enterprise data strategy with operational accountability.