The feed is live. The files are stored. Yet the dashboard, AI project or dataset is still waiting on local codes, embedded data, jumbled fields and gaps. Orchestral sells pre-built health data ingest pipelines: a new source is configuration, not an engineering project, and the work stays visible, managed and testable.
Moving the data was necessary. It was not the end of the work.
Interface engines move messages. Lakehouses store and compute. Standards support exchange. All are doing important jobs. But health data arrives with local structure, source-specific meaning, embedded documents, corrections and failures that the next layer cannot safely guess at.
When that work stays scattered across scripts, tickets and people, you feel it as a question: your team has onboarded dozens of feeds, so why does source number 47 still cost what source number 3 did? And why does the dashboard keep slipping while the connection shows green?
Medicaid raises the stakes. Encounter, eligibility and provider data arrive from every managed care plan in a different shape, while federal reporting and modernisation programmes wait on data the state can stand behind.
WHAT ORCHESTRAL CHANGES
Give the difficult healthcare-data work one visible path.
Orchestral keeps the original source and supported files available, checks what arrived, exposes failures, applies reviewed mappings, creates healthcare-specific records and delivers a configured output for the job in scope. The result stays connected to its source and transformation context, so the people responsible can inspect what happened.
Orchestral performs the configured processing. Your stewards govern local meaning. The team receiving the output decides whether it fits the job.
Six jobs. No black-box leap in the middle.
Keep the source
Any standard, any cadence. HL7, C-Retain the original message and supported embedded content, so the modeled result is not the only account of what arrived.
Check what arrived
Validate structure and critical identifiers.
Failed data is surfaced to your data team.
Make the local decisions visible
Apply reviewed mappings and terminology (LOINC, SNOMED CT, ICD-10-CM) while retaining source values for inspection.
Shape the data
Create healthcare-specific records in a maintained canonical health data model that accommodates local requirements.
Deliver for review
Produce the configured output for the dashboard, registry, dataset or workflow in scope. Its owner judges whether it fits.
Keep the tools your team are familiar with
Or use ours. Your interface engine, warehouse and analytics stack stay in place.
ONE DIFFICULT RESULT. NO HAND-WAVING.
A green tick tells you the message moved. It does not tell you what survived.
In the supplied de-identified example, an HL7 result contains an encoded clinical document. Follow Orchestral as it detects the supported embedded content, decodes the document, stores it as a file object and keeps it linked to the originating result. Then follow the less convenient path: what happens when input fails validation.
What to inspect: the original source message, the report inside it, the modeled output, the source trace, and the explicit failed-message path.
Built for the work between arrival and use.
Standards-aware by design
Pipelines for HL7 v2, C-CDA, FHIR and flat files understand structure and clinical semantics, so mapping starts from a working baseline, not a blank page.
One clinical model in scope
Downstream teams build against one maintained model for the sources in scope, not per-source schemas.
Exceptions with a reason
Failed and unmappable input is quarantined and flagged for review with a stated reason. Nothing disappears silently.
Versioned, inspectable configuration
Mappings, vocabularies and validation rules are configuration your team can read, review and own.
Lineage and governance built in
Role-based access, masking, audit logging. Deployed in your jurisdiction, your cloud, with read-only source access.
Coexists with your stack
Your interface engine keeps moving messages. Your warehouse or lakehouse stays the destination. Orchestral does the clinical work between them.
What teams ask first.
Can't we build this on Snowflake or Databricks?
Does this replace our integration engine?
What about our custom and legacy feeds?
Where does our data live?
What if the evaluation shows we don't need this?
Bring one blocked health-data problem into focus.
Start with one source, one important output and the people who need to stand behind it. In a 30-minute working session we frame the normal cases, the difficult cases and the evidence a fair test would need. Bring the feed that hurts the most. Not patient data.