Skip to content
All services
Industry · HealthTech

PHI does not move until every environment in the path has a BAA.

HIPAA compliance posture, PHI data perimeter design, FHIR and HL7 normalization across source systems, claims-data reconciliation, and lineage proof for regulatory audit. Platform migrations for HealthTech companies are designed around the compliance surface first — the data engineering follows.

What is different about HealthTech platform migrations

The defining constraint is PHI. Any dataset that contains protected health information travels through the migration with a compliance obligation attached — BAA coverage on every environment in the data-flow path, encryption in transit and at rest, access controls documented and verified, and a complete lineage record at cutover. That is not a checklist appended to the technical work; it is the architecture the technical work is built on.

The second structural difference is clinical data semantics. FHIR and HL7 data from different source systems is not interchangeable without normalization. Discovery audits the normalization logic applied to each source and produces a target-state specification before any pipeline migration begins.

The migration shapes that appear most often

  • PHI-scoped data perimeters. The target architecture separates PHI into a dedicated dataset or schema with access controls limited to the minimum necessary personnel and systems. De-identified and aggregated data lives in a separate analytics zone with broader access. Migration does not consolidate PHI and non-PHI even if the source warehouse stored them together. Discovery maps every dataset's classification and produces the target-state access topology before DDL generation begins.
  • FHIR/HL7 normalization migration. Where normalization logic lives in ETL pipelines, those pipelines migrate as named objects with before/after output verification. Where it lives in warehouse views or dbt models, it translates through the rule library with a dialect-specific review for FHIR resource handling. The normalization specification produced in Discovery is the acceptance criterion for the migration.
  • Claims-data reconciliation harnesses. Claims migration is verified at the business metric level, not just the row level: total claim amounts and counts by payer and period must match within defined tolerances on both source and target before any claims workload is cut over. These checks run continuously through the parallel-run window and are archived as engagement evidence.
  • BAA-gated migration data flow. Every environment PHI touches during migration — export storage, transformation pipeline, load target — requires a signed BAA before data moves. Discovery produces the full migration data-flow diagram and a BAA coverage map. Execution does not begin until every gap in that map is closed.
  • De-identified ML dataset creation. Where a migration goal is enabling ML on de-identified data, the de-identification pipeline is designed as a named component of the target architecture in Discovery. The transformation logic and de-identification method are documented and the PHI-free dataset is verified before the ML pipeline is pointed at it.

What a HealthTech Discovery Sprint surfaces

  • PHI classification for every dataset, with the target-state access topology for the PHI perimeter and the analytics zone.
  • BAA coverage map for the full migration data-flow path, with gaps identified.
  • FHIR/HL7 normalization audit: every source system's normalization logic, with the target-state specification.
  • Claims reconciliation design: settlement periods, payer breakdowns, tolerance thresholds, and the harness structure.
  • Lineage evidence design: the record structure that will satisfy a regulatory audit at cutover.
  • Execution scope and fixed-fee quote.

Related reading

How to start

The fast path is a Cloud Cost X-Ray — 5 business days, names the top-20 cost and compliance surface items before any commitment. The fee credits 100% against Execution signed within 60 days. If the situation is past the diagnostic phase, book a 30-minute call and we will quote the Discovery Sprint directly.

Questions buyers actually ask

Before you book a call.

What is the core HIPAA risk in a data platform migration? ▾
The primary risk is PHI landing in an environment that is not covered under a signed Business Associate Agreement, or transiting a path that is not encrypted and access-controlled to HIPAA standards. A migration where PHI data is exported to a staging bucket, processed through a pipeline, and loaded to the target creates at least three distinct environments where PHI could be exposed — each needs a BAA in place and documented access controls before any data moves. Discovery produces a data-flow diagram for the full migration path, and every environment in that path is verified for BAA coverage before the first data export.
How is PHI segregated from de-identified data in the target architecture? ▾
The target architecture separates PHI into a scoped data perimeter — a dedicated dataset, schema, or storage bucket with access controls limited to the minimum necessary personnel and systems. De-identified or aggregated data lives in a separate zone with broader access. The migration does not consolidate PHI and non-PHI into a single zone even if the source warehouse stored them together. Discovery maps the classification of every dataset and produces the target-state access topology before any DDL is written.
We process FHIR and HL7 data from multiple source systems. How does normalization work across a migration? ▾
FHIR and HL7 normalization is treated as a data pipeline problem, not just a schema translation problem. Different source systems emit subtly different interpretations of the same FHIR resource or HL7 message segment. Discovery audits the normalization logic currently applied to each source and produces a target-state normalization specification. Where normalization logic lives in ETL pipelines rather than warehouse views, those pipelines are migrated and verified as named objects in the execution plan.
What does claims-data reconciliation look like in a migration context? ▾
Claims data has strict financial and regulatory reconciliation requirements — total claim amounts, denial rates, and remittance totals per period must match between source and target within defined tolerances. The reconciliation harness for claims data runs per settlement period, not just per table: it sums claim amounts and counts by payer and period on both source and target and flags any discrepancy above the defined threshold. These checks are deterministic code, archived as part of the engagement evidence, and co-signed at cutover.
We need lineage proof for a regulatory audit. How is that produced? ▾
The engagement evidence package includes: a data-flow diagram of the full migration path, a per-table record of source and target checksums at cutover, a row-count parity report per table per wave, and the co-signed cutover document with timestamps. For clinical or claims tables with specific audit requirements, we add a record-level sample comparison that demonstrates the migrated data matches the source for a stratified sample. All evidence is produced by deterministic code, not manual inspection, so it can be reproduced on demand.
Can we run ML on de-identified data in the new platform while keeping PHI in the scoped perimeter? ▾
Yes, and that separation is typically one of the migration goals rather than a constraint. The target architecture creates a de-identification pipeline that produces a PHI-free dataset in the analytics zone, with the transformation logic and de-identification method documented. ML training and inference pipelines run against the de-identified dataset. The PHI perimeter remains accessible only for the minimum necessary operational purposes. Discovery designs the de-identification pipeline as a named component of the target architecture.
How long does the Discovery Sprint take for a HealthTech company? ▾
The Discovery Sprint is 10 business days fixed. For HealthTech, the Sprint output includes a PHI classification for every dataset, a BAA coverage map for the migration data-flow path, a target-state access topology, a FHIR/HL7 normalization specification, and the execution scope and fixed-fee quote. The compliance documentation is produced within the Sprint window.