Buying Clinical Data for AI: The Legal Basis Question Most Teams Miss

Teams building AI products on top of health data tend to start with a technical question: which EHRs do we connect to, and how. That's the wrong first question. The answer that actually determines what you can do with the data downstream is a legal one, and it gets decided before a single API call is made.

Under TEFCA (the Trusted Exchange Framework and Common Agreement, the US national framework for health data exchange), there are six recognized purposes for exchanging data: treatment, payment, healthcare operations, individual access, public health, and government benefits determination. For AI product teams, two of these matter far more than the rest, and the difference between them decides whether the data you've collected can be used to train a commercial model at all.

This is also where HIPAA and AI training requirements actually intersect. TEFCA governs how the data moves; HIPAA governs what can be done with it once it arrives, and the two rulesets have to be satisfied together, not treated as separate checklists.

The purpose you invoke, not the tool you use

It's tempting to think of this as a tooling decision: an aggregator connection means treatment-purpose data, a patient-facing gateway means individual access. That's a useful simplification, but it isn't quite right. A network aggregator can operate under either purpose depending on how the connection is set up. The constraint that actually matters is which purpose the data is pulled under, not which technical path delivered it.

Data obtained under a treatment purpose, the mode most provider-facing tools run in, is tied to that purpose. It's well suited to supporting care and difficult to repurpose. Using treatment-obtained data to train a commercial AI model is exactly where legal exposure shows up, because the purpose the data was collected under and the purpose it's now being used for no longer match.

Why a doctor in the loop doesn't fix this

A pattern we see often: a team building a commercial AI product proposes routing their data connection through a clinician, reasoning that a treatment relationship unlocks broader access to records. It can, technically. What it doesn't do is change the underlying purpose of the data once collected.

If the real goal is training a model for commercial use, framing the connection as treatment because a doctor happens to be involved doesn't change what the data can legally be used for afterward. It just obscures the actual purpose being invoked, which is the riskier part of that approach, not a workaround for it.

The cleaner path: individual access

Individual Access Services, the TEFCA purpose covering a patient obtaining their own records, requires strict identity proofing but offers a materially cleaner legal basis for commercial use. When a patient consents to their own data being used for a specific purpose, including AI training, and that use is otherwise legally permitted, the basis is the patient's own consent rather than a borrowed treatment relationship.

This is also why patient-facing connectivity, whether through direct FHIR integrations or a patient-mediated gateway, tends to be the right architecture for AI products that need clinical data specifically for training or product features, rather than for supporting an active episode of care. The connection method matters less here than the purpose the resulting data carries with it.

When de-identification actually helps

If a use case genuinely needs identified data and the underlying purpose doesn't support that use, de-identification is a real option, not a workaround to avoid the purpose question. HIPAA offers two routes: Safe Harbor, which means removing eighteen specified identifiers, and Expert Determination, where a qualified statistician certifies that re-identification risk is very small.

Safe Harbor is mechanically simpler but blunt, and it runs into trouble fast with free-text clinical notes, where names and dates hide inside narrative text rather than sitting in structured fields. De-identifying notes at scale in practice means OCR on scanned documents plus natural-language processing to scrub free text, which is a meaningfully larger engineering lift than redacting structured fields. For most consumer-facing data products, explicit user consent to a clearly stated use, where legally permitted, is the more practical route than building a full de-identification pipeline, though that call ultimately sits with the client's own counsel.

What this means for scoping an AI data pipeline

Before any technical scoping starts, three questions settle the legal foundation the rest of the project sits on: who authorizes the data connection, what purpose it's being obtained under, and whether that purpose actually supports the intended AI use. Teams that answer these upfront avoid discovering, mid-build, that the data they've spent months connecting can't legally be used for what they built the pipeline for.

This is also where readying healthcare data for AI use goes beyond data quality and normalization. A technically perfect, well-structured dataset pulled under the wrong purpose is still the wrong dataset for training a commercial model. The purpose question comes first, and it shapes every architecture decision that follows, including how AI models get built securely around that data once it's in hand.

Momentum scopes the legal-basis question as part of every EHR and clinical-data integration engagement, alongside the technical architecture. If you're building an AI product on clinical data and haven't yet mapped which purpose your data connection runs under, that's the conversation worth having before the integration work starts.