Industry
Industry13 min readBy The Data Workers Team

The agentic data platform for healthcare and life sciences

If you are a data leader at a health system, payer or pharma company, this is your playbook. It covers what your team ships, where its week goes today, the use cases agents take over first, the autonomy you can safely grant in each domain, and what to show leadership after the first quarter.

Key takeaways

  • •Who this is for. Data leaders and teams at health systems, payers, health-data companies and pharma.
  • •The problem today. Most of the data team's week goes to quarter-long onboarding, study-by-study privacy review and request queues.
  • •What changes. Specialised agents take that work over across the systems you already run: they catch bad data where it enters, fix it where it lives and verify the number before anyone reads it.
  • •What stays with your people. Anything regulated or customer-facing waits for a named approver with the full diff, blast radius and rollback plan in front of them.
  • •The result. Data teams that spend their time on faster research, safer launches and payment numbers that are right.

The PRD for agentic data in healthcare and life sciences

This is the requirements document we would write with you. Everything below expands on it.

WhoData leaders and teams at health systems, payers, health-data companies and pharma.
The jobClinical and commercial data that keeps up with care.
EnvironmentEpic Clarity and Caboodle; HL7 and FHIR feeds via an integration engine; Snowflake, Databricks or a research warehouse; OMOP; dbt, and the other platforms your teams run.
ConstraintsRegulated and customer-facing numbers always go to a named approver; agents run in your infrastructure under the roles you already govern.
Success is measured byPHI classification on new tables: from about a week to minutes; Finding the right dataset: from about 8 hours to 30 s; Resent claims file corrected: from about a week to ~1 h; documentation and data dictionary closed autonomously 86% of the time.
Owned byThe head of data or CDO, with domain owners as named approvers.
Pilot scopeOne partner feed or vendor delivery.

What going fully agentic and autonomous means in healthcare and life sciences

  • •Put your data pipelines on autopilot. Agents catch bad data where it enters, fix it where it lives and verify the number before anyone reads it.
  • •Run the data back office without the busywork. The week that goes to quarter-long onboarding, study-by-study privacy review and request queues moves to agents.
  • •Scale data without scaling headcount. New sources, partners and data products are onboarded as missions, not projects.
  • •Get the plumbing off your plate. Data teams spend their time on faster research, safer launches and payment numbers that are right.

The shift

Healthcare data has a usability problem, not a volume problem. EHRs, claims, labs, prescriptions and trial data all exist. Getting them into a state a researcher, an actuary or a brand team can use takes months, because every source is different, every code set changes, and every table carries privacy obligations.

The result is the same in every corner of the industry: researchers wait weeks for a cohort, health plans reconcile partner files by hand, and pharma launch teams get their dashboards after the launch has started.

Our view: the work of making health data usable should be done by agents. Onboarding a new site, mapping codes, classifying PHI, applying access policy and verifying every load is repeatable work. Agents should run it under guardrails, so clinicians, researchers and analysts get governed, trustworthy data in days.

How data work in healthcare got here

The EHR reporting era. Data lived inside the EHR and its reporting databases. Every request went through an analyst who knew the schema.

The research warehouse and RWD era. Health systems built research warehouses on common models such as OMOP, payers built analytics platforms, and an industry of real-world-data companies grew up aggregating across sites. Each built large teams to do mapping, abstraction and quality work by hand.

The agentic back office. Agents onboard feeds, classify PHI on arrival, map codes, write quality rules, keep documentation current and handle access by policy. Experts spend their time on the judgment calls only they can make.

The three eras side by side:

How the data back office works in each era. The dark column is what changes in the agentic back office. A simplified synthesis.
Fig. 1:How the data back office works in each era. The dark column is what changes in the agentic back office. A simplified synthesis.

Each era changed the tools. Only the agentic back office changes who does the work.

A day on a clinical data team today

A research warehouse team at an academic medical center has 140 open data requests. A new partner hospital joined the network three months ago and its data is still not in the warehouse: the ADT feed is live, but lab codes are local, the PHI review is pending, and the one engineer who knows HL7 is on the oncology project.

A cardiology researcher needs a cohort for a grant deadline in three weeks. The request sits in the queue behind 30 others.

That morning is typical, not exceptional. Across a week, this is where the team's time goes, today and with agents on the back office:

Share of the data team's working week by activity, today vs. with Data Workers. Upkeep covers pipelines, incidents and reruns, access requests, and docs and catalog. Illustrative: a modelled example of a typical team, not measured outcomes.
Fig. 2:Share of the data team's working week by activity, today vs. with Data Workers. Upkeep covers pipelines, incidents and reruns, access requests, and docs and catalog. Illustrative: a modelled example of a typical team, not measured outcomes.

Time spent on new data products moves from 15% of the week to 50%. Most of the rest becomes review: people steer and approve agent work instead of doing it by hand.

Then and now

WorkTodayWith Data Workers
Onboarding a new hospital or payer feedOne to three months of mapping, review and testingA mission run in days, with PHI handled first
Local code mappingA permanent backlogMapped with confidence scores; only the uncertain ones go to an informaticist
PHI classificationA review at the end of each projectEvery field classified on arrival, sensitive values scrubbed before context
Cohort and data requestsWeeks in a queueGoverned concepts and policy-based access, answered in days
Vendor restatements in pharmaDiscovered when field dashboards jumpDetected on arrival, reprocessed, verified before the field sees it
Data dictionaryOut of dateKept current by the agents doing the work

These are the impact metrics we move:

  • •PHI classification on new tables: from about a week to minutes
  • •Finding the right dataset: from about 8 hours to 30 s
  • •Resent claims file corrected: from about a week to ~1 h

Across the routine work:

Time to complete 7 routine healthcare tasks, current practice (black) vs. the agent swarm (green). Illustrative.
Fig. 3:Time to complete 7 routine healthcare tasks, current practice (black) vs. the agent swarm (green). Illustrative.

The biggest change is PHI classification on new tables: from about a week to minutes. Work that waited in queues finishes in minutes or hours, because agents detect, fix and verify in one pass.

Use cases, in depth

1. Onboarding a new partner site

Today. Integration engineers stand up HL7 and FHIR connections, privacy reviews each table, analysts map local codes and the warehouse team builds models. It takes a quarter.

With Data Workers. Seven agents run it as one mission: Connectors set up the feeds, Ingestion profiles them, Data Security classifies PHI before anyone opens a row, Data Access & Governance applies policy, Pipeline Building maps into OMOP with tests, Quality Monitoring writes checks and Data Context & Catalog documents lineage. One clinician reviews the codes that could not be mapped with confidence. Read the walkthrough.

What changes. A new site is live in days, and the network grows without growing the team.

The workflow for this use case: Connectors agent (get_connector_status) → Data Ingestion agent (get_connector_status) → Data Security agent (scan_pii) → Data Access & Governance agent (provision_access) → Pipeline Building agent (generate_pipeline).
Fig. 4:The workflow for this use case: Connectors agent (get_connector_status) → Data Ingestion agent (get_connector_status) → Data Security agent (scan_pii) → Data Access & Governance agent (provision_access) → Pipeline Building agent (generate_pipeline).

2. The cohort request queue

Today. Each request is a custom extract written by an analyst who re-interprets what "diabetic patient" means.

With Data Workers. Data Context Wizard holds governed clinical concepts with provenance. Researchers find datasets in Spellbook and request access in plain English; Access & Governance applies IRB and role policy. Pipeline Building produces the extract from governed definitions.

What changes. Cohorts mean the same thing in every study, and the queue stops growing.

The workflow for this use case: Data Context Wizard (define_business_rule) → Spellbook Data Catalog → Data Access & Governance agent (provision_access) → Pipeline Building agent (generate_pipeline).
Fig. 5:The workflow for this use case: Data Context Wizard (define_business_rule) → Spellbook Data Catalog → Data Access & Governance agent (provision_access) → Pipeline Building agent (generate_pipeline).

3. Payer partner files that resend and restate

Today. A provider group resends a month of claims. Duplicates flow into risk adjustment until an actuary spots the paid amounts.

With Data Workers. Ingestion fingerprints every file and flags the resend, Incident Debugging finds every downstream table that loaded the first version, Pipeline Building swaps in the corrected data, Quality Monitoring confirms paid amounts tie, and Conductor holds the risk-adjustment refresh for one approval.

What changes. Payment-affecting numbers are corrected before anyone uses them.

The workflow for this use case: Data Ingestion agent (get_connector_status) → Incident Debugging agent (diagnose_incident) → Pipeline Building agent (generate_pipeline) → Quality Monitoring agent (set_sla) → Autonomous Data-Conductor (verify_data).
Fig. 6:The workflow for this use case: Data Ingestion agent (get_connector_status) → Incident Debugging agent (diagnose_incident) → Pipeline Building agent (generate_pipeline) → Quality Monitoring agent (set_sla) → Autonomous Data-Conductor (verify_data).

4. A pharma launch that has its data on day one

Today. The launch data product is built in the weeks after launch, from licensed prescription and HCP data that arrives in a dozen formats with licensing limits nobody tracks in the data.

With Data Workers. The launch data product is built as a mission ahead of launch. Ingestion and Schema Evolution handle vendor formats and restatements, Access & Governance enforces licensing terms on every join and share, and Context Wizard holds one definition of NBRx, TRx and treated patient across brands.

What changes. Field and brand teams see consistent numbers from the first week.

The workflow for this use case: Data Ingestion agent (get_connector_status) → Schema Evolution agent (detect_schema_change) → Data Access & Governance agent (provision_access) → Data Context Wizard (define_business_rule).
Fig. 7:The workflow for this use case: Data Ingestion agent (get_connector_status) → Schema Evolution agent (detect_schema_change) → Data Access & Governance agent (provision_access) → Data Context Wizard (define_business_rule).

Agents working together: A new partner hospital, live in a week

How the swarm hands one problem from agent to agent: a new partner hospital, live in a week. Each step leaves a signed receipt.
Fig. 8:How the swarm hands one problem from agent to agent: a new partner hospital, live in a week. Each step leaves a signed receipt.

Onboarding a new partner site as one mission. Seven agents do the work in order, PHI handled first, and one clinician reviews only the codes that need clinical judgment. The clinical and EHR playbook walks through it day by day.

Minute by minute

This is an illustrative example. A partner health system sends ADT over HL7 and nightly FHIR bulk exports; the research warehouse runs OMOP on Databricks. PHI-touching work starts at L1.

TimeWhoWhat happens
Mon 09:00AutopilotOnboarding mission stated; token estimate shown
09:20Data Ingestion agentConnectors set up the HL7 listener and FHIR pull
11:00Data Ingestion agentFirst export profiled; local lab codes found
11:30Data Security agentscan_pii classifies PHI before anyone opens a row
TueData Access & Governance agentprovision_access applies IRB and role policy
WedPipeline Building agentOMOP mappings with tests; 3% of lab codes flagged
ThuSpellbook Data CatalogClinician reviews uncertain codes
FriResearch warehousePartner live; lineage documented

How it fits your stack

Data Workers connects to what you already run: Epic Clarity and Caboodle; HL7 and FHIR feeds via an integration engine; Snowflake, Databricks or a research warehouse; OMOP; dbt. Each agent is an MCP server, so the same agents work inside Claude Code, Cursor or Codex and in Slack or Teams through Spellbook. Nothing migrates.

  • •Runs in your infrastructure with your credentials and your model key. The hosted Autonomous Data-Conductor sees workflow metadata only, never rows.
  • •Uses the access you already govern. Agents act under scoped service identities and your existing roles; every grant goes through provision_access and is logged.
  • •Proposes changes as diffs in your dbt project, orchestrator and warehouse, with blast radius, tests and a rollback point, and applies them only at the autonomy level you set for that domain.
  • •Open-source core. The Apache-2.0 community edition ships 11 agents and 160+ MCP tools, so your engineers can read exactly what the agents call.

How autonomy expands over the first year

Autonomy is earned per task class. In a mature deployment, it looks like this:

Autonomous resolution by healthcare task class. Share of each task class closed autonomously, escalated for approval, or handled by a person. Identified-data access sit at L2 by design: always proposed, never applied without a named approver. Illustrative.
Fig. 9:Autonomous resolution by healthcare task class. Share of each task class closed autonomously, escalated for approval, or handled by a person. Identified-data access sit at L2 by design: always proposed, never applied without a named approver. Illustrative.

Documentation and data dictionary closes autonomously 86% of the time. For Identified data and certified cohorts, autonomous closure is 0% by design: every change is proposed with a full diff and approved by a named person.

A typical path to get there:

  • •Month 1, L1 with PHI classification first. Agents map the estate and classify every sensitive field.
  • •Months 2 to 3. Documentation, catalog upkeep and cleanup at L4. Reruns, restatements, quality rules and PHI tagging at L3.
  • •Months 4 to 6. New sites and vendor feeds onboard as missions. Cohort and data requests run through governed concepts.
  • •Months 6 to 12. Mapping classes with a clean record move up. Identified-data access, certified cohorts and KPIs stay at L2. Clinical judgment, IRB and promotional decisions stay with people.

The same path as a curve, month by month:

Share of agent actions by autonomy rung over the first twelve months for a health system, payer or pharma data team. Every deployment starts at L1 and moves up only on evidence. Illustrative.
Fig. 10:Share of agent actions by autonomy rung over the first twelve months for a health system, payer or pharma data team. Every deployment starts at L1 and moves up only on evidence. Illustrative.

By month 12, more than 36% of agent actions run fully autonomously and manual work falls below 10%, while identified-data access stay with a named approver.

What happens when an agent is wrong

  • •At L2 propose, nothing changes until a named person approves. The proposal shows the full diff, the blast radius and how to roll it back. Unanswered requests expire and escalate.
  • •At L3 act, reversibly, every change keeps a rollback point, and Conductor verifies the downstream number after the change. If verification fails, the change is reversed and the domain drops a level.
  • •No agent approves or promotes its own work. Autonomy only grows on evidence, per repair class, and repeated errors shrink scope automatically.
  • •One org-wide stop halts all autonomous dispatch, and every action lands in a hash-chained audit trail you can export with generate_audit_report.

Governance and regulation

HIPAA governs PHI, IRB approvals govern research use, and licensed commercial data carries contract terms. Data Workers classifies PHI on arrival, applies role and purpose policy, enforces license terms and logs every access.

Data Workers doesn't make you compliant; your controls, people and assessors do. It supplies controls and evidence wherever agents touch data. Not legal advice.

The alternatives healthcare and life sciences data teams weigh

Build it yourselves. A strong team can wire a coding agent to MCP servers for the warehouse and dbt. The work is everything around it: routing approvals to the right owner, blast radius, rollback, receipts, and current context about every other system.

Observability, catalogs and point tools. Observability alerts, catalogs document, and quality tools test. Data Workers takes their signals, diagnoses, proposes the fix, verifies it and leaves the receipt.

Platform-native agents. Snowflake made its managed MCP server and Cortex Agents generally available on Nov 4, 2025, and Databricks made Genie One generally available on Jun 16, 2026. They are excellent inside their platform; this work crosses the source systems, orchestrator, warehouse and BI, and Data Workers works across all of them.

In this space specifically. EHR vendors, integration engines and RWD platforms each own a slice; Data Workers does the onboarding, mapping, privacy and governance work across them.

The case for your CTO

What this replaces. The week spent on quarter-long onboarding, study-by-study privacy review and request queues.

What your teams get back. Time for faster research, safer launches and payment numbers that are right, on data that is verified before anyone reads it.

Integration effort. Connecting is configuration, not a migration. The agents attach over MCP to the platforms you already run, under the roles you already govern, inside your own infrastructure.

Risk and control. Autonomy is set per domain, starts at L1 and rises only on evidence. Regulated and customer-facing numbers stay at L2 with a named approver, and one org-wide stop halts all autonomous work.

Why now. Research networks, AI pilots and launches multiply data demand.

The first win. One partner feed or vendor delivery. The pilot below lays out the scope, what you see each week and the cost.

The climb: from assisted to autonomous to agentic

Our thesis is that the data platform climbs the way analytics did, in stages. In healthcare and life sciences, that climb looks like this:

  • •Assisted. Agents work alongside each data team, read the whole stack and propose every fix with a receipt. Regulated and customer-facing numbers always go to a named approver.
  • •Autonomous, under your governance. The upkeep behind quarter-long onboarding, study-by-study privacy review and request queues runs on its own, domain by domain, as the receipts earn it.
  • •The agentic enterprise. The platform largely runs itself. People set direction and standards, and the teams spend their time on faster research, safer launches and payment numbers that are right.

You choose the altitude, every step is visible and reversible, and the pilot below is the first rung.

The pilot: how healthcare and life sciences data teams start

The pilot is how a team proves the value on its own data before committing.

  • •What we connect. Epic Clarity and Caboodle; HL7 and FHIR feeds via an integration engine; Snowflake, Databricks or a research warehouse; OMOP; dbt, over MCP, inside your infrastructure. Nothing migrates.
  • •Scope. One partner feed or vendor delivery.
  • •First week. Agents run at L1 and show the fixes they would have made, with receipts.
  • •By week two. Reversible upkeep (reruns, staging fixes, documentation, cleanup) runs on its own; regulated and customer-facing numbers stay at L2 with a named approver.
  • •At day 30. We review the impact metrics against your baseline:
  • •PHI classification on new tables: from about a week to minutes
  • •Finding the right dataset: from about 8 hours to 30 s
  • •Resent claims file corrected: from about a week to ~1 h
  • •the share of documentation and data dictionary closed autonomously, targeting 86%
  • •What you decide. Which domain or team goes next. The pilot fee is credited in full against the first year.
  • •Cost. Start with a pilot ($7,500 one-time, credited in full against the first year). Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing.

Use-case guides

  • •Health plans and payors: payment integrity, cost of care, Stars, risk adjustment, network performance, utilization management and member experience.
  • •Health systems and providers: revenue cycle, population health, cost intelligence, capacity, clinical quality, workforce and value-based care.

Teams we work with in healthcare and life sciences

FAQ

Does PHI leave our environment? No.

Does it work with Epic? Yes, through Clarity, Caboodle and feeds.

Who approves identified-data access? A named approver.

Where do the agents run? In your infrastructure, with your credentials and model key. The hosted Conductor sees workflow metadata only.

Do we have to migrate anything? No. Your warehouse, dbt project, orchestrator, catalog and BI stay where they are.

Sources

  • •Epic Cosmos coverage, Fierce Healthcare: https://www.fiercehealthcare.com/health-tech/epic-expands-ai-ambitions-agent-platform-cosmos-powered-predictions-and-deeper-workflow
  • •Data Workers pricing: https://dataworkers.io/pricing/
  • •Data Workers open-source repository (tool registrations): https://github.com/DataWorkersProject/dataworkers-claw-community
  • •Snowflake, managed MCP server and Cortex Agents GA release note (Nov 4, 2025): https://docs.snowflake.com/en/release-notes/2025/other/2025-11-04-cortex-agents-mcp
  • •Databricks, Genie One launch (Jun 16, 2026): https://www.databricks.com/company/newsroom/press-releases/databricks-launches-genie-one-all-new-agentic-coworker-every-team