Orchestrating the Patient Journey: The Blueprint for Clinical Data Harmonization

In a previous post, we explored the Tempus Edge Platform and how it has the potential to solve healthcare’s “last mile” problem by moving data securely between partners and Tempus’s cloud. Ingesting data into Tempus is only half the challenge; raw clinical data from disparate sources must be normalized, enriched, and harmonized into a unified representation before it can power AI models, clinical decision support, or research workflows.

This post takes a technical look at how Tempus turns disparate clinical data formats into application-ready data—and the orchestration engine that makes it possible at scale.

Note: This post references a number of healthcare data standards and technical terms. See the Glossary at the end of this post for definitions.

The Challenge: Clinical Data Speaks Many Languages

A single partner integration often will include a variety of data formats capturing clinical data—HL7 v2 messages for real-time events; C-CDA documents for clinical summaries; scanned PDFs of pathology reports; and flat files containing historical records from the EHR system. Each data format captures a piece of the patient’s journey through the health system. Even within a single data standard, variability is the norm: two health systems sending HL7 v2 messages may use different segment structures, local coding conventions, and field-level semantics.

Presenting applications with a unified representation of data sourced from hundreds of partner integrations requires both rigorous standards and a flexible orchestration system that can adapt to variance in partner data formats while preserving the original information.

Standards as the Foundation: HL7, FHIR, and OMOP

HL7 v2 remains the dominant messaging standard in healthcare—pipe-delimited, decades old, and notoriously variable in implementation. C-CDA, based on HL7 v3, is the standard for structured clinical documents in XML. FHIR R4 is the modern resource-based approach; Tempus uses FHIR R4 as the internal canonical representation for all clinical data flowing through the Edge platform. OMOP is the common data model for observational research; Tempus maps normalized data into OMOP-aligned representations downstream to support population-level analytics and life sciences collaboration.

These standards form a layered stack:

As data moves up through the stack, each layer adds standardized terminologies, processing metadata, and explicit relationships to other data sources. The result: application developers and researchers work with data they can immediately understand and use with clear provenance, while the platform handles the hard work of orchestrating transformation pipelines across a wide variety of source standards.

Workflow Orchestration Service

Transforming raw clinical data into a unified schema is not a single operation—it is a multi-step workflow involving parsing, mapping, validation, enrichment, and routing. Managing this choreography across hundreds of partner integrations is the job of a workflow orchestration service.

The workflow is defined as a named pipeline, which is a container of ordered steps, each invoking a downstream target service over HTTPS. The orchestration service holds no business logic—it sequences, routes, and tracks execution of the end to end pipeline to ensure reliable and auditable execution.

Pipelines are triggered by events published to messaging topics. When a new data source is created—a raw HL7 message landing via Edge, for example—the orchestration service evaluates it against subscription filters (attribute-based rules matching on format, message type, and institution) and routes it to the correct workflow.

The figure illustrates the relationships between generic building blocks—event subscriptions, configurations, pipeline definitions, and step configuration—that integrators compose into business-meaningful workflows.

The key insight is that these building blocks let integrators define the business-meaningful dimensions along which pipelines are reusable. For example an EHR vendor and a Lab-based system may both send HL7 v2 messages, but their segment structures will differ. An integrator defines a shared pipeline for the common transformation steps and a vendor-specific filter and mapper configuration for the steps that diverge—without modifying the orchestration engine. Reuse can be sliced along any dimension that matters: EHR vendor, message type, clinical specialty. Sometimes reuse cannot be defined, in which case it is just as natural to create a bespoke pipeline for a partner.

Application Ready Data: Data Transformation Workflows in Practice

The following diagram illustrates a real-world scenario where a Lab Order from an EHR system triggers creation of an order, which in turn triggers a second pipeline responsible for fetching additional data and documents about the patient.

Format Conversion. The first step converts the raw source format into a structured intermediate representation—HL7 v2 into JSON, C-CDA XML into JSON. These conversions are purely lossless structural changes; no clinical mapping occurs yet.

Clinical Mapping to FHIR. The intermediate JSON is mapped to a FHIR R4 Bundle by a modular transformation engine that uses JSONata expressions to define how source fields become FHIR resources. The Mapper’s configuration system supports inheritance: a standard mapping for a source format (e.g., HL7 v2 to FHIR) can be extended with partner-specific overrides where local conventions differ, without duplicating the entire configuration.

Validation and Binary Document Extraction. The FHIR Bundle is validated against a FHIR Implementation Guide. Any embedded documents—base64-encoded PDFs, images, or text files on FHIR DocumentReference resources—are extracted, compressed, and stored as a standalone Binary data source. The Bundle retains a reference pointer to the extracted Binary, keeping structured data lightweight while preserving traceability to the original document. A future post will deep dive into pipelines used to extract additional structured information from PDFs and unstructured text.

Enrichment. Validated FHIR data passes through enrichment services which append standardized codes from Tempus’s Medical Ontology (similar to Unified Medical Language System), ensuring that different representations of the same terms are recognized as equivalent concepts. The dataset is further enriched with reference to master data to associate records from different sources to a unique identifier for a person and institution.

Aggregation into FHIR Bundles. The preceding pipeline steps have produced a FHIR-formatted version of each individual clinical event (e.g. ordering lab tests, administering medications, inpatient room transfers). Processing event-by-event (message-by-message) enables efficient processing, but may result in tens to hundreds of daily events per patient depending on the care setting. Each individual event contains information relevant to the specific event, much of which is redundant (e.g. problems list or active medications list) with other events. To ease consumption by application developers, the individual data sources are deduplicated and merged into a FHIR Bundle, forming a point-in-time snapshot of the complete clinical record for a patient.

Mapping FHIR to OMOP. FHIR data that has been enriched and bundled is flattened into a tabular format. This flattened-FHIR data is then mapped into the OMOP v5.4 Common Data Model. This model is extended with cancer-specific tables and concepts to create the Tempus Data Model. This de-ID data model is used for analytics use cases.

Trust and Transparency

Normalization alone does not make data usable. A perfectly mapped FHIR Bundle is not application-ready if you cannot trace where it came from, trust that it passed quality checks, locate it when needed, or know that its structure meets platform-wide standards. Healthcare application-ready data requires additional capabilities layered on top of normalization.

Lineage. Every message that triggers a workflow orchestration is tracked end to end—including message IDs, trace IDs, execution IDs, step-level outputs, and timestamps. This provides a complete chain of custody from the raw message ingested by the Edge Platform to the final enriched FHIR Bundle. When a step fails, operators can pinpoint the exact failure point and replay from there.

Quality. The FHIR Implementation Guide acts as a structural contract: data that does not conform to the contract is rejected before it can propagate downstream. Built-in retry mechanisms handle transient errors, and step-specific error queues capture persistent failures. Pipeline definitions and mapper configurations are versioned, so updates can be rolled out safely while in-flight messages continue processing on the previous version.

Governance. A Governance Committee reviews and approves which data sources are included in the FHIR bundle, sets platform-wide data source standards, and ensures that new data sources are interoperable with existing consumers. Every data source must meet patient bundle compatibility requirements, such as use of standard terminology codes. This governance layer ensures the platform grows in breadth without sacrificing the quality and usability that application teams depend on.

Conclusion

When clinical data is application-ready it stops being digital exhaust, and starts being actionable information that drives both clinical and research workflows. The downstream impacts are tangible.

Faster partner onboarding. Because integrators compose pipelines from reusable building blocks, new healthcare organization integrations benefit from patterns seen before (such as EHR-vendor variance) enabling integrations to complete in weeks from start to finish.

AI models built on high-fidelity data. Trial matching, care gap identification, and clinical decision support all depend on consistent coding and complete patient context. Normalization and terminology enrichment give these models a reliable feature set across every partner, rather than requiring per-institution data wrangling.

Research at population scale. With data harmonized into FHIR and projected into OMOP, life sciences partners and researchers can run queries across patient populations without reconciling format differences—accelerating real-world evidence generation and biomarker discovery.

The normalization and harmonization layer described in this post is what makes each of these outcomes repeatable and scalable. In future posts, we will go deeper into specific pipeline domains—including how Tempus processes clinical documents at scale, and how normalized data powers downstream AI applications.

Glossary