Healthcare & Life Sciences
Healthcare AI agents, with PHI and clinical-safety controls designed in.
We'd design PHI safeguards and clinician review into an agent before it's built, then test and deploy it with them in place: a unique identity for every user and agent, every read of patient data recorded, and a clinician approving anything that touches care.
For Athlinks we stitched together more than 400 million athlete records from sources that had no reason to agree on identity. Volume was never the hard part. A run that fails halfway can't start again from the beginning, so the pipeline resumes from the step that died, with retries and real-time visibility.
The engineer who agrees the matching rules with your data team is the one who'd write them, in your repository, with no handoff to a delivery team you haven't met. Our published work in this sector is health and wellness data unification, on Databricks and Temporal.
HIPAA Security Rule technical safeguards
The technical safeguards in the HIPAA Security Rule, 45 CFR 164.312, read like a design brief for a data platform. Every user needs a unique identifier, activity on any system holding electronic protected health information has to be recorded and examined, and you need a way to show that patient data hasn't been altered or destroyed without authorisation.
Encryption is "addressable", so the choice you make about it gets written down and defended. We'd make those the platform's defaults from the first sprint.
Grants go to named people and service principals in Unity Catalog instead of shared logins, access to tagged columns is queried from the audit tables, and table history is kept long enough to answer an auditor. The written policies are covered by 164.316, which says to keep them for six years.
Sources: 45 CFR 164.312, technical safeguards, 45 CFR 164.316, documentation
FHIR APIs and the CMS interoperability rule
CMS's Interoperability and Prior Authorization Final Rule, CMS-0057-F, has Medicare Advantage organizations, Medicaid and CHIP programs and certain exchange plans running HL7 FHIR APIs, with the API requirements generally due by January 1, 2027.
Its operational rules started a year earlier. Outside the exchange plans, a payer now owes a prior authorization decision within 72 hours on an urgent request and seven calendar days on a standard one.
Providers and certified health IT developers sit under the information blocking rules that came from the 21st Century Cures Act, which treat interfering with access to electronic health information as a violation unless an exception applies.
We'd treat the FHIR endpoint as a product with its own tests and uptime target, and we'd put the clock on each prior authorization request into the data model, so a breach of the 72 hours shows up in a morning query.
21 CFR Part 11 audit trails in life sciences
Life sciences adds the FDA's 21 CFR Part 11 for electronic records and signatures. It asks for secure, computer-generated, time-stamped audit trails of who created, changed or deleted a record and when, and a change may not obscure what was recorded before it.
A signed record has to carry the signer's printed name, the date and time, and what the signature meant, such as review or approval, and the systems themselves have to be validated.
We'd keep those records append-only, with every change written as a new row, and store the meaning of a signature as data a query can filter on. Validation goes faster when the test evidence comes out of the pipeline's own CI run, so we'd set that up before the first regulated record lands.
Sources: 21 CFR Part 11
Clients in this sector
Blog
From our engineers
- Oct 7, 2026 · Sushruth Aeluguri
Unity Catalog for AI agents in practice: four FHIR scenarios
An AI agent can show records a person isn't cleared to see with every row filter working. Four FHIR scenarios on Databricks, with the performance tradeoffs.
Read the article - Oct 10, 2026 · TechFabric
What Databricks' Funke changes for HL7v2 pipelines
Funke, announced by Databricks on 8 October, parses HL7v2 into Unity Catalog intact. What it changes for clinical pipelines, and what it leaves alone.
Read the article
The lines that do this work
Data engineering
Pipelines that hold, tables people trust, and a bill that stops surprising you.
APIs & durable systems
Long-running operations that survive restarts and partial failure. Temporal under the lakehouse jobs, agent runs and approvals that must not half-complete.
Migrations to Databricks
Off Snowflake, Synapse, Teradata and SQL Server, onto Lakehouse and Lakebase, with a cutover you can reverse.
FAQ
Healthcare & Life Sciences: questions we get asked
How would you govern an AI agent that touches patient data?
We'd design the safeguards in before the agent is built. The HIPAA technical safeguards become its defaults: its own identity rather than a shared login, Unity Catalog grants on the PHI it may read, and every read recorded in the audit tables.
Anything it proposes that touches care is checked against policy and waits for a clinician to approve, and the same checks run in testing as in production. Our AI agent services would build it that way, on the pattern in the Field Guide's chapter on governed actions.
Have you worked with HIPAA or clinical data?
Our published work in this sector is health and wellness data at scale rather than regulated clinical systems.
What transfers is the governance: designing Unity Catalog so grants hold, keeping lineage intact through a refactor, and making applications and agents inherit permissions rather than route around them. That is at /services/data-ai-governance, and it is the same substrate a regulated estate is built on.
What made 400 million records hard?
Identity across sources that never agreed, and failure partway through a long run. Athlinks at /case-studies/unlocking-big-data-projects-with-temporal-orchestration uses Temporal so a step that dies mid-flight resumes from where it stopped, with retries and real-time visibility, instead of replaying the whole pipeline.
Do healthcare payer and provider integrations have to use FHIR?
The payers CMS-0057-F covers do, generally from January 1, 2027, for the APIs that share claims and patient data with in-network providers and with the patient's next plan. A hospital or clinic isn't the target of that rule, but once its payers expose FHIR endpoints, that's the interface it will be calling.
We'd build the integration against the payer's test environment first and move real patient data only after the mappings have been checked field by field with your clinical and billing teams.
Talk to someone who has built this.
A technical conversation with a senior engineer who has shipped in this sector, about what you are trying to build.