Onboarding Studio: what a zero-copy health data intake actually looks like
Most health data onboarding pipelines copy records into a new environment before scoring them. Onboarding Studio does not. It scores, validates, and governs data at the source, producing a DTI trust score and a hash-chained receipt without ever moving the underlying record. That distinction determines whether your AI pipeline meets regulatory scrutiny or fails it.
Health data onboarding has a dirty secret. Every platform that promises to "integrate" your EHR, claims, or registry data starts by copying it into their environment. The moment that copy exists, you have lost control of provenance, consent enforcement, and chain of custody. Onboarding Studio was built to eliminate that copy.
What zero-copy actually means
Zero-copy is not a marketing term. It is an architectural constraint. When Onboarding Studio connects to a data source, it reads records in place, scores them across all eight DTI dimensions, and writes the trust metadata back to a hash-chained ledger. The underlying record never leaves its origin system.
This matters because every copy of a health record introduces three risks: a new consent surface that may not match the original authorization, a provenance gap where the chain of custody breaks, and a synchronization liability where the copy drifts from the source. Zero-copy eliminates all three by design.
The term "zero-copy" has precedent in database engineering (Apache Iceberg, Snowflake external tables), but health data pipelines have not adopted it. The reason is simple: most vendors need your data in their environment to bill for storage, compute, and query volume. Onboarding Studio bills for the trust score, not the byte.
Why copying health data breaks the trust chain
When a health system exports a C-CDA document to an analytics vendor, that document lands in a new storage bucket with a new access control list. The original consent record, which authorized a specific use at a specific institution, does not travel with it. The vendor assumes the data was "cleared" for use. Nobody checks.
This is not hypothetical. The CCD document quality problem documented across health information exchanges shows that 40% to 60% of care summary documents arrive with incomplete medication lists or missing allergy sections. When those degraded records get copied into a training pipeline, the AI model inherits every gap.
Provenance is the most heavily weighted dimension in the DTI framework at 25%. A record that cannot prove where it came from, who created it, and through which systems it traveled cannot score above Bronze. Copying a record strips the metadata that supports that proof. Onboarding Studio preserves it because it never moves the record in the first place.
How Onboarding Studio connects to source systems
Onboarding Studio supports three connection modes, each designed to read without extracting.
FHIR R4 read-only access. For EHR systems that expose FHIR APIs (Epic, Oracle Health, Cerner, MEDITECH Expanse), Onboarding Studio authenticates via SMART on FHIR, queries the relevant resources, and scores them in a transient compute layer. The scored metadata and DTI receipt are written to the SuperTruth Ledger. The FHIR resources stay on the EHR server.
HL7v2 message interception. For legacy interfaces, Onboarding Studio deploys a lightweight listener on the institution's integration engine (Mirth Connect, Rhapsody, Cloverleaf). The listener reads ADT, ORU, and MDM messages as they flow, scores them, and passes the original message through unmodified. No message is stored, copied, or rerouted.
Flat file scoring with pointer architecture. For bulk data scenarios (claims extracts, registry exports, lab result files), the source system places files in an institution-controlled storage location. Onboarding Studio reads the file via a secure pointer, scores each record, and writes the DTI metadata to the Ledger. The file remains in the institution's storage. Onboarding Studio retains only the pointer and the score.
In every mode, the institution retains physical custody of its data. SuperTruth holds the trust score and the provenance receipt. This separation is not a feature. It is the architecture.
The eight-dimension scoring at intake
Every record that passes through Onboarding Studio receives a DTI score from 0 to 100. The scoring happens at the point of intake, before the record enters any downstream pipeline, model, or analytics layer.
The eight dimensions scored at intake are Provenance (25%), Consent (20%), Recency (15%), Quality (10%), Concordance (10%), Validation (10%), Breadth (5%), and Stability (5%). Each dimension generates a sub-score that feeds the composite.
For health data onboarding specifically, three dimensions carry the most diagnostic weight.
Provenance captures whether the record can trace its origin to a named system, a named author, and a specific timestamp. A lab result from a certified reference laboratory with a CLIA number scores higher than a transcribed result in a progress note.
Consent captures whether the record carries a valid consent authorization for the intended use. Onboarding Studio cross-references the record against the institution's consent registry (or ConsentOS, if deployed) and flags any record where the consent scope does not match the downstream use case.
Recency captures when the record was last updated relative to the current date. A medication list updated three days ago scores differently from one last touched 14 months ago. For AI model training, stale records introduce temporal drift that degrades prediction accuracy within weeks.
Key statistics
The measurable impact of zero-copy health data onboarding is already visible in production deployments.
What the intake pipeline produces
Onboarding Studio does not produce a cleaned dataset. It produces three artifacts.
A DTI score per record. This is the 0-to-100 composite that tells any downstream consumer exactly how much to trust the record. A clinical decision support system can enforce a minimum DTI floor of 70. A research query can filter to Platinum-grade records only. The score travels with the record pointer everywhere it goes.
A provenance receipt on the Ledger. Every scored record generates a hash-chained entry in the SuperTruth Ledger. This receipt records the source system, the scoring timestamp, the DTI sub-scores, the consent status, and a cryptographic hash of the record at the moment of scoring. Nobody can quietly edit this entry. If a regulator or auditor asks "where did this record come from and what was its quality at the time you used it," the receipt answers both questions.
A consent state snapshot. The consent status at intake is frozen in the Ledger entry. If consent changes later (a patient revokes authorization, a use case expands beyond the original scope), the dynamic consent architecture in ConsentOS propagates the change. But the original intake snapshot remains, creating a complete consent timeline for compliance review.
How this differs from every other onboarding approach
The standard health data pipeline looks like this: extract data from source, load into a staging environment, transform and normalize, load into a data warehouse, run quality checks, serve to downstream applications. This is the ELT or ETL pattern that every major health data platform follows.
The problems with this pattern are structural, not operational.
First, the extract step creates a copy. That copy has no provenance link back to the source unless someone manually maintains one. Most do not.
Second, the transform step alters the record. A code mapping from ICD-10 to an internal ontology changes the record's content. A date normalization step changes its format. Each transformation is a trust event that should be logged but almost never is.
Third, the quality checks happen after the data is already in the warehouse. By that point, bad data has been stored, indexed, and potentially served to early queries. Scoring at the point of intake, before any movement or transformation, prevents contaminated records from entering the pipeline at all.
Platforms like Innovaccer, Datavant, and AWS HealthLake all follow the copy-first pattern. They are not solving the data trust problem because their architecture requires them to possess the data before they can analyze it.
The regulatory case for zero-copy intake
FDA's emerging guidance on AI/ML-based Software as a Medical Device (SaMD) increasingly requires documentation of training data provenance. If your model trained on a dataset that was copied, transformed, and re-hosted across three environments before scoring, proving provenance becomes a reconstruction exercise. If your model trained on records scored at the source with a hash-chained receipt, provenance is a lookup.
CMS programs including ACO REACH and the new ACCESS model require data integrity documentation for quality reporting. Health plans submitting HEDIS measures need to demonstrate that the underlying clinical data meets NCQA quality thresholds. A DTI score attached to every record at intake provides that documentation automatically.
For Medicaid managed care organizations, state reporting requirements demand that submitted data can be traced to its clinical origin. Zero-copy architecture makes this trivial because the origin is the only place the data exists.
What the imaware deployment proved
When SuperTruth onboarded 105,000 diagnostic records from imaware, the pipeline demonstrated what zero-copy intake looks like at scale. Records were scored across all eight DTI dimensions. The scoring identified a previously invisible customer segment that was driving 20% of revenue. The entire process that previously took three weeks of manual analyst work completed in two hours.
CEO Brodie Flanders described it directly: "The lab industry has never had a trust standard. DTI created one."
The imaware case is instructive because diagnostic lab data is among the most structurally standardized data in healthcare. It follows LOINC codes, carries CLIA certifications, and flows through established reporting channels. If even this data benefits from trust scoring at intake, the case for scoring less structured data (clinical notes, claims, SDOH records) is stronger by an order of magnitude.
When Onboarding Studio flags a record
Not every record passes intake cleanly. Onboarding Studio generates explicit flags in four scenarios.
Provenance gap. The record cannot identify its source system or authoring clinician. This is common in records that have been through multiple health information exchange hops. The record receives a provenance sub-score below 30 and is flagged for manual review or exclusion from high-trust use cases.
Consent mismatch. The record's consent authorization does not cover the intended downstream use. A record consented for treatment purposes cannot be scored as valid for research use without additional authorization. ConsentOS surfaces the mismatch and blocks the record from entering research pipelines.
Recency failure. The record's last update timestamp exceeds the threshold for the intended use case. A medication list last updated 18 months ago is flagged when the downstream use case is a current drug interaction check.
Concordance conflict. The record contains data that contradicts another record from a different source for the same patient. Two different active medication lists, conflicting allergy entries, or mismatched demographic data all trigger concordance flags. These are not errors to be silently resolved. They are trust events to be documented.
Building a health data pipeline that regulators can audit
The ultimate test of any health data pipeline is whether it can survive an audit. Not a friendly internal review, but a CMS program audit, an FDA pre-market submission review, or a state Medicaid investigation.
Audit survival requires three things: knowing where every record came from, proving that consent covered the actual use, and showing that data quality was assessed before use rather than after failure. Onboarding Studio produces all three as automatic outputs of the intake process.
The explainable data provenance that regulators increasingly demand is not a report you generate after the fact. It is a property of the architecture. Either your pipeline creates provenance records at intake or it reconstructs them under pressure. One of those approaches survives an audit. The other does not.
The trust score as a contract
A DTI score is not a quality indicator. It is a contract. When a record carries a score of 82, that number means specific things: provenance is documented to a named system and author, consent covers the stated use case, the record was updated within the recency threshold, and the data passed validation checks against its declared schema.
Downstream consumers of that record, whether they are AI models, clinical decision support rules, quality reporting pipelines, or research queries, can enforce minimum DTI floors without understanding the underlying data. A model training pipeline that requires DTI >= 75 will automatically exclude records with provenance gaps, consent mismatches, or stale timestamps. The score carries the judgment so the model does not have to.
This is what a health data pipeline trust architecture looks like. Not better ETL. Not faster normalization. A score at the source, a receipt on the ledger, and the record exactly where it started.
The DTI Engine scores every record 0 to 100 across eight dimensions before your AI model sees it. If your team is evaluating data for training, compliance, or clinical use, talk to the SuperTruth commercial team. Schedule a conversation or call (215) 918-4140.
Further reading:
Jason Alan Snyder
Co-founder of SuperTruth and Artists & Robots, and an inventor on the Data Trust Index patents. Twenty-plus years building technology inside Interpublic Group. He writes here nearly every day on data trust, provenance, and what AI should be allowed to act on, and publishes essays on his Substack.
About SuperTruth · LinkedIn · Substack · jasonalansnyder.com
See it in practice
DTI scores the record, not the patient.
8 dimensions. 0–100. Travels with every record permanently.