The Compliance Surface of FHIR

Why US HealthTech Companies Are About to Fail Their First Real Audit — and What a Production-Grade Implementation Actually Documents

Most HealthTech founders think of FHIR compliance as a technical milestone. The auditors, payers, and enterprise security teams now reviewing their integrations think of it as evidence.

In our previous article, we argued that the gap between “FHIR-compliant” and “production-ready” is where most healthtech engineering actually lives. This piece extends that argument into the regulatory layer, because in 2026, that gap is no longer just an engineering risk. It is a contractual one. The companies signing your enterprise deals are now asking for evidence your integration would survive an OIG inquiry, a TEFCA participant review, or a CMS prior authorization audit. If your team cannot produce that evidence in days, the deal stalls. If it cannot produce it at all, the deal dies in security review.

The Regulatory Stack Has Quietly Tripled in Depth

Three years ago, a US HealthTech company shipping a FHIR integration needed to demonstrate conformance to one or two specifications. Today, the regulatory surface for any production integration touches at least six distinct frameworks, each with its own audit posture and its own evidentiary requirements.

The 21st Century Cures Act, Information Blocking Rules

The information blocking provisions are now actively enforced. The OIG has published its civil monetary penalty framework, and the first enforcement actions have established that “interference with the access, exchange, or use of electronic health information” is read broadly. A poorly designed FHIR integration that delays, restricts, or fails to surface required data elements is no longer just a product defect — it is a regulatory exposure with documented penalty schedules.

ONC HTI-1 and HTI-2 Final Rules

The Health Data, Technology, and Interoperability rules expanded the certification criteria for health IT and tightened requirements around USCDI versions, decision support interventions, and real-world testing. HealthTech products that surface or modify clinical data are increasingly being asked to demonstrate alignment with these criteria even when not directly certified — because their enterprise customers are.

TEFCA and the QHIN Framework

The Trusted Exchange Framework and Common Agreement is now operational, with multiple Qualified Health Information Networks live. Participation — directly or through a participating sub-network — is becoming a de facto requirement for any HealthTech product that exchanges clinical data across organizational boundaries. TEFCA imposes identity assurance, consent management, and audit logging requirements that go meaningfully beyond base FHIR.

CMS Interoperability and Prior Authorization Final Rule

The CMS-0057-F rule mandates Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs built on FHIR and the Da Vinci implementation guides. The compliance dates are not abstract — they are now active for impacted payers, and any HealthTech product in the prior authorization, utilization management, or coverage decision space is being pulled into the regulatory perimeter through its customers.

HIPAA, Reinterpreted Through a FHIR Lens

The HIPAA Security Rule update proposed in late 2024 raises the floor on technical safeguards: explicit encryption requirements, mandatory multi-factor authentication, formal asset inventories, and, critically, detailed audit log requirements that map naturally onto FHIR AuditEvent resources but only if those resources are instrumented from day one.

State-Level Privacy Statutes

Washington’s My Health My Data Act, the California consumer health data provisions, and a growing list of state laws now impose consent, deletion, and disclosure obligations on health data that sit alongside HIPAA rather than within it. A FHIR integration that satisfies HIPAA without addressing these layered statutes is incomplete.

What this means in practice

An enterprise client’s security review is no longer one checklist. It is a stack of overlapping ones — and your integration has to produce evidence against each.

“We’re HIPAA compliant” is no longer a sufficient answer to the question being asked.

The teams winning enterprise deals are the ones whose integrations were engineered with this evidentiary burden in mind from the start.

The Five Audit Surfaces, and What Each One Actually Wants to See

When we map a HealthTech client’s FHIR integration against the regulatory frameworks above, the requirements collapse into five concrete audit surfaces. Each one is a distinct evidentiary demand. Each one is something an auditor, a QHIN onboarding reviewer, or an enterprise security team will request — in writing, with timestamps.

Audit Surface 1: Access Logging

What’s asked: A complete log of every read, write, and search operation against patient data, with sufficient detail to reconstruct who accessed what, when, and on what authorization basis.

What production-grade looks like: FHIR AuditEvent resources generated for every interaction, indexed for query performance, retained per HIPAA’s six-year requirement and any longer state requirement, and structured to support the Right of Access response timeline. Logs are written synchronously with the operation — not best-effort, not batched in a way that loses entries on failure.

Where teams fail: Logging implemented as application-level analytics rather than as compliance artifacts. The data exists, but it cannot be assembled into the format an auditor requests within the response window.

Audit Surface 2: Data Provenance

What’s asked: For any clinical data element surfaced in your product, the ability to trace it back to a specific FHIR resource version in a specific source system at a specific point in time.

What production-grade looks like: FHIR Provenance resources attached to ingested data, version IDs and ETags preserved through the data pipeline, and an internal data model that retains the source resource reference rather than collapsing it during normalization.

Where teams fail: ETL pipelines that flatten FHIR resources into application tables and discard the source metadata. When a clinician disputes a data point in a chart, the team cannot answer “where did this come from” without a forensic database query.

Audit Surface 3: Consent and Authorization

What’s asked: Evidence that every disclosure of patient data was authorized at the time it occurred, by the patient, by a treating relationship, or by a permitted regulatory exception.

What production-grade looks like: FHIR Consent resources modeled against the applicable framework (TEFCA, state law, organizational policy), evaluated at the time of data access rather than at onboarding, and linked to the AuditEvent record for the corresponding operation.

Where teams fail: Consent treated as a one-time onboarding flag rather than a queryable resource evaluated per disclosure. When a patient revokes consent, the system has no mechanism to enforce the revocation across downstream caches and integrations.

Audit Surface 4: Conformance Evidence

What’s asked: Demonstration that the integration conforms not just to base FHIR but to the specific implementation guides applicable to its domain — US Core, Da Vinci PAS/CRD/DTR, USCDI+, IPA, or the relevant TEFCA Standard Operating Procedures.

What production-grade looks like: A maintained CI pipeline running the HL7 FHIR validator against current profile versions, regression tests covering known edge cases for each EHR vendor in scope, and a published conformance statement that is regenerated on every release.

Where teams fail: Conformance verified once at launch, then not re-verified as profile versions evolve. The integration drifts out of conformance silently between certification and the next audit.

Audit Surface 5: Security Posture

What’s asked: Evidence of encryption at rest and in transit, multi-factor authentication for privileged access, key rotation, vulnerability management, and incident response — all mapped specifically to the systems handling FHIR data.

What production-grade looks like: SMART on FHIR with proper scope enforcement, mTLS or signed JWT authentication on server-to-server flows, a documented key management lifecycle, and a security incident response plan that includes specific procedures for FHIR resource exposure.

Where teams fail: Generic SaaS security posture that doesn’t address the specific surface FHIR integrations expose, token leakage, scope escalation, replay attacks against subscription endpoints, and data exposure through poorly bounded search parameters.

The Evidence Package, What Mature HealthTech Companies Maintain

The pattern we see across HealthTech companies that win enterprise deals quickly: they do not assemble compliance evidence reactively when a security review arrives. They maintain it continuously, as a deliverable artifact set that ships alongside the product.

A mature evidence package contains, at minimum:

• A current Conformance Statement generated from the running system, not authored manually — listing supported resources, profiles, search parameters, and operations.
• A profile validation report from the most recent CI run, with explicit pass/fail status against each implementation guide in scope.
• An AuditEvent schema and retention policy document describing what is logged, where it is stored, how it is queried, and how long it is retained.
• A consent and authorization model description explaining how Consent resources are evaluated, how revocation propagates, and how cross-organizational disclosures are governed.
• A data provenance map showing how each clinical data element in the product traces back to a source FHIR resource.
• A SMART on FHIR scope and authorization design document covering token issuance, refresh, revocation, and scope enforcement.
• A security control mapping from the HIPAA Security Rule, NIST 800–66, and any applicable HITRUST or SOC 2 controls to the specific implementation in the FHIR layer.
• An incident response runbook specific to FHIR data exposure scenarios.

The package is not large. Assembled deliberately during the build, it is roughly 40 to 60 pages of structured documentation. Assembled reactively during a security review, it is six to twelve weeks of senior engineering time and a stalled deal.

How We Engineer for the Audit Before It Happens

Our engagements with US HealthTech clients now treat compliance evidence as a first-class build artifact, generated by the system rather than authored about it. This shifts the work from documentation to instrumentation, and it changes which engineering decisions get made.

Compliance is instrumented, not documented

Every required artifact — audit logs, provenance records, conformance statements, consent evaluations — is produced by the running system. The evidence package is generated, not written. This means the documentation never drifts out of sync with the implementation, because the implementation is the source.

Profile drift is monitored, not periodically reviewed

The CI pipeline tracks the publication cadence of every implementation guide in scope. When HL7 publishes a new US Core ballot, when ONC updates USCDI, when CMS releases a new Da Vinci version — the validator updates, the regression suite runs, and any new failures surface as engineering tickets within the same cycle.

The evidence package is part of the release artifact

Every product release produces, alongside the binary or container image, a versioned evidence package. When an enterprise client requests compliance documentation, the response is a current artifact — not a six-week scramble through git history and Slack archives.

Consent and audit are architectural primitives, not features

These are not bolted onto the product layer. They sit in the integration layer, where they belong, and every higher-layer feature inherits them by construction. A new feature cannot ship without producing the appropriate audit and consent records, because the integration layer rejects operations that fail to provide them.

The Closing Argument

The HealthTech companies that closed enterprise deals in 2023 sold on product capability. The HealthTech companies closing enterprise deals in 2026 are selling on demonstrable compliance maturity, and the ones that cannot demonstrate it are losing those deals to competitors who can.

The shift is not subtle. CISO offices at health systems and payers have learned, often through painful incidents, that a vendor’s claim of compliance and a vendor’s ability to produce evidence of compliance are different categories of fact. They are now writing contracts that require the latter.

The engineering work to support that requirement is not enormous, if it is built in from the start. It is, however, prohibitively expensive to retrofit. The HealthTech companies that win the next two years of enterprise procurement are the ones whose engineering teams understood this before the security questionnaire arrived.

That understanding is what we sell. The integration layer is the deliverable.

Download the FHIR Readiness Checklist, Self-Assessment for FHIR Compliance

We’ve created a focused checklist to help you quickly evaluate how prepared your systems are for FHIR-based integrations. Download the checklist and, if needed, request a short walkthrough with our integration team to understand your results and next steps.

Discover how our expertise in healthcare software development and healthcare software product engineering can transform your medical solutions.

P.S. If you have any questions or comments about HealthTech, or Healthcare Software Development feel free to leave a comment below or reach out to me directly.

Originally published at https://www.linkedin.com.