Digital Health Compliance Beyond HIPAA: FDA, HL7/FHIR and GDPR Requirements That Change Your Build

Digital health compliance is the set of regulations a health software product must meet, and for most products that set is larger than HIPAA alone. HIPAA governs how you protect and disclose identifiable health data. It says nothing about whether your software is a medical device the FDA reviews, whether you are legally obliged to expose patient data through a FHIR R4 API, or what happens when a European user signs up.

I spend a lot of my time on scoping calls with teams who budgeted for HIPAA and nothing else. The conversation usually starts the same way. The build is underway, someone in legal has asked a question, and now there is a second regime in play that changes the architecture.

HIPAA applies to covered entities; providers, health plans, clearinghouses, and to the business associates who handle protected health information on their behalf. A Business Associate Agreement is the contract that makes that relationship lawful. That is the whole of HIPAA’s job. It is a data-protection statute.

Four things sit outside it. Whether your software performs a medical function is an FDA question. Whether you must make data available through a standards-based API is an ONC question. Whether European users bring European obligations is a GDPR and Medical Device Regulation question. And whether consumer health data outside a covered-entity relationship is regulated at all is increasingly a state-law question.

The last one catches people out most often. A direct-to-consumer symptom tracker may sit entirely outside HIPAA because there is no covered entity in the picture. It can still be caught by the Washington My Health My Data Act, by similar statutes in other states, and by FTC health breach notification rules. Falling outside HIPAA is not the same as falling outside regulation.

The Four-Regime Digital Health Compliance Matrix: which rules apply to your product

Rather than describe each regime and leave you to work out which apply, start from what your product actually does. Five product attributes decide almost every case I see.

Two or more rows returning “triggered” is the signal to stop and scope properly. Each additional regime brings its own documentation set, its own evidence requirements, and in the FDA’s case its own quality system.

The reason this matters early is that these are architecture decisions. Consent capture, role separation, audit logging and data residency all reach into the data model. They are cheap to design and expensive to retrofit.

When health software becomes an FDA medical device: SaMD and clinical decision support

Software as a Medical Device, usually shortened to SaMD, is software that performs a medical function on its own, without being part of a piece of hardware. An algorithm that reads a retinal scan and flags diabetic retinopathy is SaMD. A patient portal that displays the same scan is not.

The boundary turns on what the software concludes. Storing, displaying, transmitting and formatting clinical data generally stays outside device regulation. Analysing that data and producing a clinical conclusion generally moves inside it.

Clinical Decision Support software sits in the contested middle. Where a clinician can independently review the basis for a recommendation, where they can see the inputs and the reasoning and form their own judgement, the software may fall outside device regulation. Where the recommendation is effectively a black box the clinician has to trust, it usually does not.

If you land inside, one of three pathways applies.

Two engineering standards do most of the work underneath. IEC 62304 defines the software lifecycle processes the FDA expects — planning, requirements, architecture, verification, maintenance and problem resolution, all documented as you go. ISO 13485 defines the quality management system around it. As of 2 February 2026, the FDA’s Quality Management System Regulation aligned 21 CFR Part 820 with ISO 13485, so the two now point in the same direction.

The teams that lose the least time here are the ones producing IEC 62304 records during development. Reconstructing a design history file after the fact is the most painful remediation work I have watched a team go through.

 AI features and FDA: predetermined change control plans explained

A model that retrains is a regulatory problem, because the device the FDA reviewed is not the device in the clinician’s hands six months later. Historically that meant a new marketing submission for every meaningful change.

The Predetermined Change Control Plan, or PCCP, is the mechanism that fixes this. You describe your intended future modifications up front, the FDA authorises the plan alongside the original submission, and changes made inside the plan do not require a new submission.

A PCCP has exactly three components:

1. Description of Modifications: what will change, how often, and to which parts of the device.
2. Modification Protocol: how each change will be developed, validated and tested before release.
3. Impact Assessment: what each change does to risk, performance and the benefit-risk balance.

The FDA issued its final guidance on PCCPs for AI-enabled device software functions in December 2024 and reissued it with updates in August 2025. It applies across 510(k), De Novo and PMA submissions, and it uses the term AI-DSF, AI-enabled device software function, which is deliberately broader than machine learning. Labelling matters too: a device authorized with a PCCP has to tell users that it has one and describe what may change.

The practical consequence for a build is that your release process becomes part of your regulatory submission. Version control, release notes, bias monitoring and retraining triggers stop being internal engineering hygiene and start being evidence.

HL7, FHIR and information blocking: interoperability as a legal obligation

Most teams treat interoperability as a feature request. In US healthcare it is closer to a legal duty.

HL7 v2 is the older messaging standard, still running quietly underneath a great deal of hospital infrastructure. FHIR, people say it like “fire”, is the modern standard, and FHIR R4 is the version that matters. SMART on FHIR is the authorisation layer that lets an external app connect to an EHR with proper permissions. USCDI is the agreed minimum set of data elements that has to be available.

Information blocking is the part people underestimate. Under the 21st Century Cures Act, knowingly interfering with the access, exchange or use of electronic health information is prohibited, with defined exceptions. It is enforced separately from HIPAA, with its own penalties, and it applies to health IT developers, health information networks and providers.

The regulatory ground here moved recently. The HTI-1 final rule, published in January 2024, updated certification criteria and information-blocking provisions, with compliance dates landing through early 2026. Then on 29 December 2025, ASTP/ONC published the HTI-5 proposed rule, which would eliminate or revise more than half of the existing certification criteria and re-centre the programme on FHIR-based APIs.

Callout 3: HTI-5 is deregulatory on certification and tighter on data access. It proposes cutting over half the certification criteria while revising the information-blocking definitions of “access” and “use” to cover automated means, including AI systems. Fewer boxes to tick, more scrutiny on whether data actually flows. Source: Federal Register, 29 December 2025.

For your build this means two things. If you are connecting to a certified EHR, standards-based API support is something that vendor owes you, and a flat refusal is worth documenting. If you are the one holding the data, “our API does not do that” is not a safe answer.

GDPR, EU MDR and the AI Act: what changes when you have European users

European exposure does not depend on where you are incorporated. It depends on whether you offer services to people in the EU or monitor their behaviour.

GDPR treats health data as special category data under Article 9. That requires an explicit lawful basis beyond ordinary consent, and it brings data minimisation, purpose limitation and the right to erasure into your data model rather than your privacy policy.

EU MDR is the device regime. Software that performs a medical function needs CE marking, a notified body assessment for most classes, and a technical file. It runs parallel to the FDA pathway rather than replacing it, and clearance in one market does not carry into the other.

The EU AI Act adds a third layer. AI systems already regulated as medical devices under MDR or IVDR are automatically classified as high-risk, which brings conformity assessment, data governance, record keeping, transparency and human oversight obligations on top of what MDR already requires. The Medical Device Coordination Group’s MDCG 2025-6 guidance addresses how to align the two.

The timeline is genuinely unsettled. The AI Act entered into force on 1 August 2024, with high-risk obligations originally applying from 2 August 2026 and AI inside CE-marked devices from 2 August 2027. More recent commentary reports those dates being extended to 2 December 2027 and 2 August 2028 respectively.

Writer: verify these dates against the Official Journal on the day of publish and state the position taken. Sources currently conflict, and this is a blocking item.

The practical advice does not change either way. If you are building AI into a device destined for Europe, the conformity work is long, notified body capacity is constrained, and an extension is breathing room rather than a reprieve.

Settled law vs proposed rules: what you actually have to comply with today

This is where I see the most confusion, and some of it is actively harmful. A proposed rule is not law. It signals direction, and it is worth designing towards, but you cannot be cited for failing to meet it.

Digital health compliance cost: what each regime adds to your build

Two notes on reading this table. The percentages compound rather than add cleanly, because the same audit architecture serves several regimes at once. And the FDA range is the widest for a reason, a Class II device with a clean predicate and a Class III device supporting life are different projects.

The HIPAA band of 20–30% is already published on the healthcare app development cost post and should be held consistent. The ONC band needs cross-checking against the EHR integration cost post before locking.

No annual maintenance percentage appears here. That figure is unresolved site-wide (15–20% versus 15–25%) and must not be introduced in this post until it is settled. If the writer needs one, escalate rather than pick.

When regimes stack: where HIPAA, FDA and GDPR requirements conflict

Multiple regimes do not merge into one larger checklist. In three places they pull against each other, and you have to design a position.

Erasure against retention. GDPR gives data subjects a right to erasure. HIPAA and FDA record-keeping obligations require you to retain records, including audit trails, for defined periods. You cannot honour both by default. The usual resolution is a documented lawful basis for retention plus a data model that can separate erasable personal data from non-erasable audit records, which is a schema decision made at the start.

Minimisation against audit depth. GDPR pushes you to collect and keep as little as possible. Audit logging obligations push you to record who accessed what, when. The resolution is logging identifiers rather than payloads, which only works if you designed the identifiers.

PCCP against conformity assessment. An FDA-authorized PCCP lets you ship model changes without a new submission. The EU AI Act has no equivalent mechanism. A model update that is routine in the US may require reassessment in Europe, so your release process has to fork by market.

None of these is unsolvable. All three are much harder to solve after the data model is in production.

Designing compliance into the architecture: what we built for CPCG

CPCG came to us running remote healthcare operations across five disconnected tools. Session management lived in one place, scheduling in another, monitoring somewhere else, and the audit trail was assembled by hand whenever somebody asked for it.

The requirement that shaped the architecture was not a feature request. It was the need to show, reliably, who did what and when, across four different levels of user, and to show it without exposing one role’s data to another.

That pushed two decisions to the front of the build. Role separation was designed into the permission model rather than layered on as a settings screen, so each of the four role levels sees a different slice of the same data by construction. And compliance auditing was built as a first-class part of the platform, writing as the work happens, rather than as a reporting job that reconstructs history afterwards.

Callout 5: the transferable lesson from CPCG is that audit logging and role separation are architecture. Retrofitting them means rebuilding the permission model, not adding a feature.

Sourcing instruction, do not fabricate. Confirm with Muhammad Arif, PM of record, which compliance requirement specifically drove the role-separation design, and what would have broken had audit logging been added post-launch. Do not reuse CPCG adoption metrics here; they measure operational uptake, not compliance, and repurposing them as compliance proof would be a fabricated claim. Confirm client naming clearance, and confirm this angle does not collide with CPCG’s use elsewhere in the cluster.

Conclusion

The teams that get this right do one thing early. They work out which regimes apply before the architecture is locked, and they treat the answer as a design input rather than a launch checklist.

Run your product through the matrix in this guide. If two or more regimes come back triggered, that is worth a scoping conversation before the next sprint, because the decisions that get expensive later are the ones being made right now, how you model consent, how you separate roles, and where the audit trail lives.

We have built in this space for providers, digital health products and healthcare operations platforms. If you want a second read on which regimes your product triggers, we can walk through it with you.