Most healthcare AI programs stall not on the model but on the data. Patient information is scattered across EHR silos, imaging archives, lab systems, and claims, much of it locked in unstructured clinical notes. Even inside one health system, records rarely speak a common language. HL7 FHIR is the interoperability standard now mandated for patient data exchange, but adopting the standard is not the same as having clean, connected, AI-ready data. De-identifying protected health information for model training adds another layer. Data readiness is the unglamorous foundation that determines whether every downstream use case succeeds or fails.
The model is easy; the data is the hard part
A typical US health system runs dozens of clinical applications, and patient data is fragmented across the EHR, radiology PACS, laboratory systems, pharmacy, and payer claims. Roughly 80 percent of clinical information lives in unstructured form: free-text progress notes, discharge summaries, and dictated reports that a model cannot use without extraction. The result is that even organizations with rich data cannot easily assemble a clean, longitudinal patient record.
Regulation has forced a floor. The HL7 FHIR standard is now the required format for patient data exchange under federal interoperability rules, and USCDI defines a common baseline of data elements. But mandated interoperability moves data between systems; it does not make that data complete, consistent, or trustworthy for training. Missing values, inconsistent coding, and duplicate patient records all survive a FHIR exchange. Data readiness is a distinct, deliberate program.
The practical consequence is that the data work, not the modeling, is where most of the effort and most of the risk live. A model trained on records that fragment one patient into several, or that never sees the free-text note where the real clinical detail lives, will underperform no matter how sophisticated the algorithm. Leaders who fund the model and starve the data foundation get pilots that dazzle in a demo and disappoint in production. The organizations that win invest first in accessibility, structure, identity, and de-identification, because every downstream use case inherits the quality of that foundation.
Assess readiness across five data dimensions
Score each data source you intend to feed an AI use case against these dimensions. A low score anywhere is a direct constraint on what you can build.
| Dimension | What good looks like | Common gap |
|---|---|---|
| Accessibility | Data reachable via FHIR APIs, not manual extracts | Point-to-point interfaces, no standard API layer |
| Structure | Notes processed into coded, queryable fields | 80 percent unstructured free text unusable as-is |
| Interoperability | Consistent FHIR resources and USCDI elements | Local coding variants that break cross-system joins |
| Identity | Reliable patient matching across systems | Duplicate and fragmented records for one patient |
| Privacy readiness | De-identified datasets available for training | PHI blocks safe model development |
Build the data foundation deliberately
- Stand up a FHIR-based data access layer so use cases pull from a consistent API rather than bespoke extracts per project.
- Deploy clinical natural language processing to convert unstructured notes into coded, queryable data, unlocking the 80 percent that is otherwise dark.
- Invest in enterprise master patient index and data-quality tooling so a patient is one record, not five, across systems.
- Create governed, de-identified datasets for model development using expert-determination or safe-harbor methods so teams can build without touching live PHI.
- Adopt USCDI and FHIR resource conventions as the internal standard so new data lands clean rather than requiring later remediation.
- Assign a data steward and a documented lineage for each priority dataset, so every use case knows the source, transformation, and quality of the data it consumes and can defend it in a validation review.
Where data readiness breaks down
- Assuming a FHIR mandate means the data is AI-ready, when interoperability moves data without cleaning or completing it.
- Ignoring unstructured notes, which leaves the richest clinical signal outside the model entirely.
- Building use cases on data with unresolved patient-matching, producing recommendations tied to the wrong or partial record.
- Training on live PHI without a de-identification pipeline, creating privacy exposure that governance will eventually halt.
- Treating data readiness as a one-time project rather than an ongoing capability, so quality erodes as new source systems and coding changes accumulate over time.
Measure the foundation, not just the model
- Share of required data elements available via FHIR API versus manual extract for each priority use case.
- Percentage of clinical notes successfully structured into coded fields by your NLP pipeline.
- Patient-matching accuracy and duplicate-record rate in the master patient index.
- Volume of governed, de-identified data available for model training and iteration.
Frequently asked questions
Does adopting FHIR make our data ready for AI?
No. FHIR standardizes how data moves between systems, which is necessary but not sufficient. You still have to resolve missing values, inconsistent coding, duplicate patient records, and unstructured notes before the data is usable for reliable models.
Why do unstructured clinical notes matter so much?
Around 80 percent of clinical information lives in free-text notes and reports. Without natural language processing to extract and code that content, your models see only a fraction of the real clinical picture, which caps their accuracy and value.
How do we train models without exposing protected health information?
Build a de-identification pipeline using safe-harbor or expert-determination methods to create governed training datasets. This lets data science teams develop and iterate without handling live PHI, keeping you inside HIPAA obligations.
Related reading
Go deeper on this sector and topic.