The model is the easy part
A health system asks for readmission risk. A state public-health office asks for case-report deduplication. A federal health program asks for a documentation-gap flag. In every one of those, the supervised learning problem is well understood, and on clean data a competent team gets to a defensible first model in about six weeks. What takes the other twenty weeks is everything that has to happen before a single row of real patient data reaches a machine allowed to train on it. Programs that plan around that ship. Programs that plan around the model slip two quarters and then blame the data.
Three separate bodies of rule govern the work, and teams routinely collapse them into one word, "HIPAA," which causes most of the confusion. The interoperability rules govern how data moves and in what shape. The HIPAA Privacy Rule (45 CFR Part 164, Subpart E) governs what may be used and disclosed, and by whom. The HIPAA Security Rule (Subpart C) governs how electronic protected health information is protected once it lands. A project can be perfectly compliant with one and blocked by another. Our engineers work all three in parallel from week one, because serialized handling of them is what produces the six-month stall.
Schedule risk by phase in health-data AI programs
Editorial weighting from public sources and practitioner reading — illustrative, not a measured statistic.
What interoperability means once you are inside the building
FHIR gets the attention. HL7 v2 still carries the traffic. Admission and transfer messages, lab results, and orders move through pipe-delimited v2 interfaces that were configured by someone who left in 2014, with site-specific segments that appear in no published specification. Clinical summaries move as Consolidated CDA documents. Any team that assumes a modern API surface on day one and discovers v2 in week nine has already lost a month.
The regulated surface is real and it is FHIR Release 4. The ONC certification criterion at 45 CFR §170.315(g)(10) required certified health IT to expose a standardized FHIR R4 API conforming to the US Core implementation guide, SMART App Launch for user-facing access, and the Bulk Data Access guide for population-level export, with a compliance deadline of December 31, 2022. The HTI-1 final rule (89 FR 1192, published January 9, 2024) moved the underlying data floor from USCDI v1 to USCDI v3 effective January 1, 2026, which widened the required elements to include, among others, clinical notes, encounter information, and expanded social determinants data. On the payer side, CMS-0057-F (89 FR 8758, published February 8, 2024) obligates Medicare Advantage organizations, Medicaid and CHIP programs, and qualified health plan issuers on the federal exchanges to stand up Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization FHIR APIs by January 1, 2027, with the shortened prior-authorization decision timeframes of 72 hours expedited and seven calendar days standard beginning January 1, 2026.
Cross-organization exchange runs on TEFCA, whose Common Agreement version 2.0 (April 2024) added FHIR-based exchange between designated Qualified Health Information Networks. And the information-blocking rules at 45 CFR Part 171 sit underneath all of it, with civil money penalties of up to $1 million per violation available against developers and networks since September 1, 2023. When a data holder tells a project team that a request is "not allowed," it is worth asking which of the eight Part 171 exceptions they are relying on. Often the answer is none, and the request moves.
FHIR is a wire format. Your feature table is a different problem.
A bulk export gives you newline-delimited JSON, one file per resource type, with every field optional until an implementation guide says otherwise. Observation carries a value that may be a quantity, a coded concept, a string, or a set of components. Condition carries onset in one of six data types. Cardinality is mostly zero-to-many. That is the cost of a specification that must describe every health system in the country, and it means the gap between "we received FHIR" and "we have a modeling table" is measured in weeks of engineering, not days.
Most research-grade sites solve this by landing FHIR or raw source extracts into a common data model first. The OMOP common data model maintained by the OHDSI community and the older i2b2 star schema are the two that appear most often in federal and academic settings, and both come with vocabulary services that carry the mappings. That is where the terminology work lives: SNOMED CT for problems, LOINC for laboratory observations, RxNorm for medications, ICD-10-CM and CPT for billing-derived signals, CVX for immunizations, UCUM for units. A mid-sized health system will have thousands of local lab codes with partial LOINC mappings and a long tail that has never been mapped at all. Our data engineers budget explicit weeks for this and validate the mapping against a clinician, because a silent unit mismatch on creatinine or a mis-mapped potassium assay does not throw an error. It quietly poisons a model.
The Privacy Rule where it touches model development
Two provisions do most of the work. Minimum necessary, at 45 CFR §164.502(b) and §164.514(d), requires that uses, disclosures, and requests be limited to what is reasonably needed for the purpose. It does not apply to treatment disclosures to a provider, to disclosures to the individual, or to uses made under a valid authorization. It does apply to a data science team asking for the whole warehouse. The practical answer is a written, role-based specification of the fields and the population, which §164.514(d)(2) effectively asks for anyway, and which has the side benefit of forcing the cohort definition to exist before the extract is built.
The second provision is the purpose classification. If the model supports quality improvement inside the covered entity, it usually sits under health care operations. If the intent is generalizable knowledge, it is research, which pulls in the Common Rule at 45 CFR Part 46 and requires either individual authorization under §164.508 or a waiver granted by an IRB or privacy board under §164.512(i)(2)(ii), on findings that the risk is minimal and the research could not practicably be done without the waiver. Teams get this call wrong late, usually when someone proposes a conference paper in month eight, and the rework is expensive.
One more point that surprises people. A model trained on protected health information is not automatically de-identified by the act of training. Large models memorize, embeddings are invertible to a degree that is still being characterized, and a retrieval index built over clinical notes holds the note text outright. Whether weights, embeddings, error-analysis outputs, and evaluation artifacts may leave the secured environment is a question to settle in writing at kickoff, not in the week you want to demo.
Three ways to make the data usable, and what each costs
| Method | What survives | What it costs you | Use it when |
|---|---|---|---|
| Safe Harbor §164.514(b)(2) | Everything except the 18 listed identifiers | Dates collapse to year, ages over 89 collapse to a single 90+ bucket, ZIP truncates to three digits and zeroes out where the three-digit area holds 20,000 people or fewer | Cross-sectional models, low re-identification tolerance, no statistician on the team |
| Expert Determination §164.514(b)(1) | Whatever the documented analysis supports, including date offsets that preserve intervals | A qualified expert, a written determination, and a defensible record of the risk and the population it was measured against | Time-to-event models, longitudinal risk, anything where intervals carry the signal |
| Limited data set §164.514(e) | Full dates, city, state, five-digit ZIP | It is still PHI. A data use agreement is required, and it is limited to research, public health, and health care operations | Research cohorts where dates matter and a full de-identification is not practical |
| Identified PHI under a BAA | Everything | The full Security Rule, minimum necessary, breach exposure, and an approval chain measured in months | Operational deployment, clinical validation, and anything scored against the live record |
| Synthetic derivative | Schema, joins, distributions, code sets | No real signal. Never a substitute for evaluation on real data | Pipeline build and interface testing while approvals run |
Safe Harbor is the default and it is often the wrong default for machine learning. Collapsing every date to a year destroys the interval structure that time-to-event and sequence models depend on. The standard alternative is a per-patient random date offset that preserves within-patient intervals while breaking the link to real calendar time, which is an Expert Determination question because it is not one of the enumerated Safe Harbor treatments. The public MIMIC-IV critical care database from Beth Israel Deaconess, distributed through PhysioNet under credentialed access and a data use agreement, is built that way and is a reasonable pattern to point a privacy officer at.
Free text is the other trap. Safe Harbor applies to narrative notes exactly as it applies to structured fields, and a discharge summary contains names, dates, facility identifiers, and phone numbers in running prose. Automated scrubbing is a mature area with a public benchmark lineage going back to the 2014 i2b2 and n2c2 de-identification challenges, and modern transformer-based scrubbers perform well. They do not perform perfectly. The residual error rate belongs in the Expert Determination, along with the manual review sample that measured it.
What a business associate agreement lets you do, and what it quietly forbids
A firm that creates, receives, maintains, or transmits PHI on behalf of a covered entity is a business associate under 45 CFR §160.103, and the required contract provisions live at §164.504(e)(2). Since the 2013 Omnibus Rule (78 FR 5566), business associates are directly liable for the Security Rule and for the use and disclosure limits, and the obligation flows down: a subcontractor that touches PHI is itself a business associate and needs its own agreement. That includes the cloud provider. OCR's October 2016 cloud computing guidance is explicit that a service provider storing encrypted PHI it cannot read is still a business associate, and the major providers publish HIPAA-eligible service lists. A service that is not on that list is out of scope even under a signed agreement, which is how teams discover in month four that the managed feature store or the hosted model endpoint they designed around cannot hold the data.
Four clauses decide whether an AI engagement is actually workable. First, whether de-identification is permitted, because creating a de-identified set is itself a use of PHI and a business associate may only do it if the agreement says so. Second, whether data aggregation across covered entities is permitted under §164.504(e)(2)(i)(B), which is what a multi-site model needs. Third, what happens to the data and the derived artifacts at termination. Fourth, and the one that kills the most deals: whether PHI may be used to improve the vendor's own product. The standard permission for a business associate's proper management and administration at §164.504(e)(4) is not a license to train a general-purpose commercial model on a customer's patient data. If that is the business model, it has to be negotiated explicitly and in most health systems it will not be. Our team reads for that clause before scoping, because the answer changes the architecture.
The Security Rule, the enclave, and the artifacts nobody inventories
The Security Rule splits into required and addressable implementation specifications, and "addressable" does not mean optional. It means implement it, or document why it is not reasonable and appropriate and what compensating control you used instead. Encryption at rest sits at §164.312(a)(2)(iv) and encryption in transit at §164.312(e)(2)(ii), both addressable. Risk analysis at §164.308(a)(1)(ii)(A) and audit controls at §164.312(b) are required, full stop. Documentation retention is six years from creation or last effective date under §164.316(b)(2)(i), which includes the risk analysis a project team would rather not write.
That balance is moving. OCR published a proposed rule on January 6, 2025 (90 FR 898) that would remove the addressable and required distinction entirely and make encryption, multi-factor authentication, asset inventory, network segmentation, and annual technical testing mandatory. Any architecture being designed now should assume that direction and be built to it, because retrofitting network segmentation into a running analytics enclave is a project of its own.
The artifact inventory is where health-data AI work differs from ordinary application security. PHI does not stay in the database. It ends up in training checkpoints, feature stores, cached dataframes in notebooks, experiment-tracking artifacts, prompt and completion logs, error-analysis spreadsheets, and the screenshots in a slide deck. Every one of those is electronic PHI subject to the same controls as the source table. A written artifact inventory, produced in week one and enforced by where the compute runs, is the single control that keeps a health-data build defensible under audit.
The approval chain is the schedule
Kickoff to first defensible model: typical elapsed schedule
Twenty-six weeks from kickoff to a first model that a clinical reviewer will defend. About six of those weeks are modeling. In federal settings the front half stretches further, because each program runs its own queue. VA research data flows through the VA Informatics and Computing Infrastructure, and access requires an approved study plus a data access request tracked through the VA's own system. Medicare research identifiable files run through ResDAC with a signed data use agreement, and CMS has moved that access into its Virtual Research Data Center rather than shipping files, which changes both the timeline and the compute architecture. State Medicaid agencies have their own data governance boards with their own meeting cadence, and a board that meets monthly sets a floor on the schedule that no amount of engineering removes.
Three things compress the calendar and nothing else does. Start the agreements in week one, in parallel with scoping, and accept that the scope statement attached to the BAA will be amended. Build the entire pipeline against synthetic or public data while the approvals run, using Synthea from MITRE for FHIR-shaped synthetic records or MIMIC-IV for realistic clinical structure, so that the day access opens the code is already written and the only remaining work is fitting the real schema. And get the data dictionary and a sample extract, even a de-identified 100-row one, before the full request is finalized, because the first extract is wrong roughly every time and the rework cycle is where the second month disappears.
The rules that attach to the model, not to the data
A separate set of obligations lands on the output. Under the HTI-1 final rule, the decision support intervention criterion at 45 CFR §170.315(b)(11) requires certified health IT that supplies predictive decision support to surface a defined set of source attributes covering development data, intended use, cautioned out-of-scope use, external validation, quantitative performance measures, and ongoing maintenance, and requires developers to apply intervention risk management practices addressing validity, reliability, robustness, fairness, intelligibility, safety, security, and privacy. The compliance date was January 1, 2025. A model that ships inside a certified product inherits that documentation burden, and the practical answer is to produce those attributes as part of the build rather than reconstructing them a year later.
The Section 1557 nondiscrimination final rule (89 FR 37522, published May 6, 2024) adds §92.210, which requires covered entities to make reasonable efforts to identify patient care decision support tools that use race, color, national origin, sex, age, or disability as input variables and to mitigate the resulting discrimination risk, with a compliance date of May 1, 2025. That obligation reaches the buyer, which means the buyer will ask the builder. Subgroup performance tables and a written record of which variables were considered and why belong in the deliverable.
On the FDA side, the question is whether the software is a device. Section 3060 of the 21st Century Cures Act amended the FD&C Act at §520(o) to exclude certain clinical decision support from the device definition, and FDA's September 2022 final guidance on Clinical Decision Support Software walks the four criteria. The one that decides most cases is whether the clinician can independently review the basis for the recommendation. A risk score with no reviewable basis is generally a device. FDA's December 2024 final guidance on predetermined change control plans is the mechanism for updating a cleared model without a new submission, and designing to it early is far cheaper than retrofitting.
42 CFR Part 2 alignment takes effect February 16, 2026
The final rule published February 16, 2024 (89 FR 12472) aligns substance use disorder record confidentiality with HIPAA on consent, breach notification, and enforcement, with a compliance date of February 16, 2026. Part 2 records still require segmentation and a redisclosure notice, and they do not travel like ordinary PHI. Any warehouse that mixes them into a general clinical mart without segmentation has a problem that no de-identification step fixes.
Answer these before anyone writes code
- Which entity holds the data, and does a signed BAA name model development as a permitted use
- Does the record set include 42 CFR Part 2 substance use disorder records, and are they segmented
- Which de-identification method applies, and who signs the Expert Determination if it is that one
- May model weights, embeddings, and evaluation artifacts leave the secured environment
- Which cloud services are on the provider's HIPAA-eligible list for this account and region
- Who is the clinical adjudicator for the cohort definition and the outcome labels
- Is the purpose health care operations or research, and who made that determination in writing
- Is the output a decision support intervention under §170.315(b)(11), a device under §520(o), or neither
Bottom line
Health-data AI is a data engineering and governance problem with a modeling step at the end. The teams that deliver treat the approval chain as the critical path, run the legal and security work in parallel with the engineering, build the pipeline against synthetic data while access is pending, and put a clinician on the cohort definition before anyone tunes a hyperparameter. That is how a twenty-six week schedule holds. Precision Federal builds these systems for health-system, state public-health, and federal health customers, and we scope them against the approval chain the customer actually has, not the one a proposal wishes for.
Frequently asked questions
Data de-identified under 45 CFR §164.514(b) is no longer protected health information, so the Privacy Rule does not reach it and no BAA is required for the de-identified set. The step that creates it is a different matter. De-identification is itself a use of PHI, so whoever performs it needs a BAA that permits it. Limited data sets are not de-identified and always require a data use agreement.
Usually not well. Safe Harbor strips all date elements more precise than year and collapses ages over 89, which removes the interval structure those models depend on. The common alternative is a per-patient date offset that preserves within-patient intervals, which requires the Expert Determination method under §164.514(b)(1) and a written determination on file.
FHIR is a wire format with optional fields, multiple permitted data types per element, and mostly zero-to-many cardinality. Turning it into a modeling table means resolving resource references, choosing among value representations, and mapping local codes to SNOMED CT, LOINC, and RxNorm. Most sites land the data into a common data model such as OMOP first, and that work runs weeks, not days.
About six months on a well-run commercial or health-system program, with roughly six weeks of that spent on modeling. Federal data sources with their own request queues, such as VA research infrastructure or CMS research identifiable files, extend the front half. Running the legal, security, and engineering tracks in parallel is what keeps it at six months instead of nine.
It depends on whether it meets the clinical decision support exclusion in FD&C Act §520(o), which FDA's September 2022 final guidance interprets. The decisive criterion is usually whether the clinician can independently review the basis for the recommendation. A score presented without a reviewable basis, or software that drives time-critical action, generally falls inside the device definition.