Data Science in Healthcare

What does data science involve in healthcare?

Data science in healthcare is the practice of using statistics, machine learning and domain knowledge on patient, claims and operational data to answer a defined question or support a decision. A working project covers lawful data access, cohort and label definitions, feature engineering, validation across sites and patient groups, deployment into a workflow and monitoring after release.

Not every project needs a model. Many useful outputs are descriptive: a readmission dashboard, a cohort count for a trial feasibility check or a cost breakdown by service line. Predictive models earn their place when a decision repeats often enough that a score would change who acts and when.

The data rarely sits in one place. EHR reporting databases, claims feeds, lab systems, device data and patient-reported outcomes each have their own identifiers, time stamps and gaps, so integration work comes before analysis.

Which data can a team use, and on what terms?

A team can use PHI only under a HIPAA permission, or it can use data de-identified under the HIPAA Privacy Rule. The route chosen decides who can see the data, where it can be processed and what has to be documented.

• Safe Harbor de-identification: 164.514(b)(2) removes 18 listed identifiers, including names, most geographic detail smaller than a state, all elements of dates except the year, and ages over 89. The covered entity must also have no actual knowledge that the remaining data could identify someone.
• Expert Determination: 164.514(b)(1) lets a qualified expert apply statistical methods and document that the risk of re-identification is very small. It keeps more detail, such as exact dates, at the cost of the expert's analysis.
• Limited data set: Dates, city, state and ZIP code may remain, but only under a data use agreement and only for research, public health or health care operations.
• Identified data for operations: A provider may use PHI internally for health care operations, subject to the minimum necessary standard, so extracts carry only the fields the question needs.
• Research with identifiers: Identified PHI used for research needs the patient's authorization or a waiver from an IRB or privacy board.

Any outside vendor that receives PHI for this work, a cloud platform included, counts as a business associate, so a business associate agreement must be in place before any PHI moves. AWS, Google Cloud and Microsoft Azure each publish which services their BAA covers, so check notebooks, storage and training services against that list before data lands.

How does a project move from question to production?

A healthcare data science project runs in eight steps, and the early ones decide whether the later ones are worth doing.

• 1. Frame the decision: Name the person who will act on the output, the action they will take and how often. A score nobody acts on is just a report.
• 2. Settle data access: Choose de-identified, limited or identified data, sign the agreements and set up an analysis environment inside the BAA scope.
• 3. Define the cohort and label: Write inclusion rules and the outcome in code, with the time window, so a reviewer can check them against charts.
• 4. Build features: Turn raw events into model inputs using only data available at the moment the prediction would be made.
• 5. Train a baseline first: Fit a simple model such as logistic regression before anything complex, so later gains can be measured.
• 6. Validate: Test on a later time period and, where possible, another site, and check calibration and subgroup performance.
• 7. Deploy into the workflow: Score in batch or in real time, show the result where the user already works, and run in shadow mode first.
• 8. Monitor: Track input drift, outcome rates and user overrides, and set a threshold that triggers retraining or retirement.

Shadow mode is the cheapest safety step in the list. The model scores live data for an agreed period while nobody sees the output, and the team compares those scores with what actually happened. It exposes feature bugs, missing feeds and threshold problems before a clinician or analyst has changed any decision because of a score.

Feature work on clinical data

Feature work on clinical data is mostly about time. Every input has to be something the system would actually know at the prediction moment, recorded in units and codes that stay stable.

• Leakage: Discharge diagnoses, final billing codes and notes written after the event can predict the outcome perfectly in training and are absent in production.
• Units and codes: Lab results arrive in different units and local codes. Mapping them to LOINC and normalizing units before modeling avoids features that mean different things at each site.
• Missingness: A test that was never ordered says something about the clinician's suspicion. Encode it explicitly instead of filling it with an average.
• Grain: Decide whether a row is a patient, an encounter or a day, and keep that grain the same in training and scoring.
• Coding changes: Code set updates and documentation changes shift feature values over time, which later shows up as drift.

Common data models help here. OHDSI's OMOP Common Data Model gives every site the same tables and standard vocabularies, so a feature definition written once can run at several sites.

The feature code itself should be one package shared by training and scoring. When features are computed once in a notebook and again in a production service, small differences in rounding, time zones or code mappings make live scores diverge from the validated ones.

How should a model be validated before anyone relies on it?

A model should be validated on data it never saw, from a later period and ideally another site, with results broken down by patient group. A single accuracy figure from a random split is not enough.

• Discrimination: Report AUROC and, for rare outcomes, precision and recall at the threshold the workflow will actually use.
• Calibration: Check that predicted risks match observed outcome rates across the range, since users read scores as probabilities.
• Subgroups: Compare performance by age, sex, race, ethnicity, payer and site to find groups where the model underperforms.
• Clinical utility: Estimate how many alerts or reviews the threshold creates per day and whether staff can act on them.
• Reporting: Document the model with a published reporting checklist such as TRIPOD+AI, so reviewers can see how the data, the outcome and the validation were defined.

Which rules and frameworks shape the work?

Healthcare data science sits under privacy law, anti-discrimination rules and, for some models, FDA device policy. Three rules carry dates and duties, and the rest is governance practice.

• De-identification route: Agree early whether the project uses Safe Harbor, Expert Determination or a limited data set, because each one changes which fields the team can keep and which agreements it needs.
• Decision support tools: Since 1 May 2025, 45 CFR 92.210 has required covered entities to take reasonable steps to find the patient care decision support tools they use that rely on race, color, national origin, sex, age or disability, and to reduce the discrimination risk each one creates.
• Device status: FDA finalized its Clinical Decision Support Software guidance on 6 January 2026 and re-issued it on 29 January 2026. Under its first criterion, software that analyzes a medical image or a signal from a signal acquisition system, such as an ECG, remains a device function.
• Device-grade records: If a model may become part of a device, the manufacturer's quality system will govern data management, training and change control, so keep engineering records from the first experiment.
• Model ownership: Name an owner for each model, record its intended use and known limits, and review it on a schedule the governance group sets.

Where data science projects stall

Data science projects usually stall between a promising notebook and a tool people use. These failure points show up at that boundary.

• No owner for the decision: The model works, but no team agreed to change its workflow around the score.
• Access arrives late: Data agreements and de-identification take longer than modeling, and the team builds on a sample that differs from production data.
• Labels nobody agreed on: Two departments define readmission or no-show differently, so the model is accurate against a label one of them rejects.
• Random splits only: Validation on a random split hides the drop that appears on next year's patients.
• Default thresholds: A 0.5 cutoff creates more alerts than staff can handle, and users stop looking.
• No monitoring: A coding change or a new lab assay shifts inputs, and nobody notices until outcomes are reviewed.

How Agnotic can help

Healthcare data science pays off when the data pipeline, the model and the workflow are built as one system. Agnotic Technologies builds that system for health systems, payers and digital health companies: BAA-scoped data environments, de-identified extracts, feature pipelines shared by training and scoring, validation reports and monitored deployment.

The client's clinicians and analysts own the question and the decision. Agnotic builds the extracts, code, tests and infrastructure that make the answer repeatable.

Sources

• HHS: Guidance on de-identification of PHI under the HIPAA Privacy Rule
• 45 CFR 92.210: Patient care decision support tools
• FDA: Clinical Decision Support Software guidance