Healthcare Integration Due Diligence: Questions to Ask Before Sign-Off

Your team has built the integration. The demos ran clean, the UAT sign-off sheet is full of green ticks, and someone is asking you to approve go-live. This is the moment that separates the CTOs who have been through a HIPAA audit from those who have not.

The following questions are not academic. Each one maps to a failure mode that shows up after launch, not in staging. Work through them before you sign off, not after the first incident report lands on your desk.

TL;DR

• A signed BAA covers your legal relationship with a vendor; it does not verify that the vendor's configuration actually protects PHI. Verify the controls, not just the paper.
• Audit logs that cannot be queried quickly are useless during an OCR investigation. Test the query, not just the existence of the log.
• Message delivery guarantees must be documented with a requeue-and-retry path. "It worked in testing" is not a delivery guarantee.
• The 2026 HIPAA Security Rule mandates MFA, AES-256 encryption at rest, vulnerability scanning, and a 72-hour RTO for all ePHI systems — these are now hard requirements, not addressable safeguards.
• Profile conformance between your FHIR implementation and the target EHR vendor's profile is a separate test from baseline spec conformance. Run both.

Why sign-off is the riskiest moment in a healthcare integration project

Healthcare organizations in 2026 face a convergence of heightened privacy enforcement and expanded interoperability obligations. The enforcement environment has hardened at the same time that the integration surface has grown: FHIR APIs, legacy HL7 v2 feeds, IoT device gateways, and third-party middleware platforms can all carry ePHI, and each one is an audit surface.

Sign-off is the moment your organization formally accepts that surface. Ask the wrong questions — or none at all — and you own whatever the builder left out.

What does the delivery actually guarantee about message delivery?

This is the first question and the one most often skipped. "The integration works" is not a delivery guarantee. You need to know: what happens when the downstream system is unavailable for thirty minutes? What happens when the network drops mid-message?

HL7 v2 validation must be layered across structural validation, business rule validation, and semantic validation. A build that only validates structure will pass malformed clinical messages silently. Ask to see the validation layer and ask what happens to a message that fails each tier.

For FHIR-based builds, test the FHIR implementation mapping logic against real message variability, including missing fields and legacy HL7 v2 formats — integration logic built only against well-structured test data will not survive contact with a live system. Ask whether the integration was tested against messy production-representative data or only against the vendor's sandbox examples.

The HL7 IoT gateway I built for a clinical monitoring environment processes 10,000+ messages a day from 200+ monitors. Message-level retry logic with dead-letter queuing was not optional — it was the difference between a 99% delivery rate and a number I would not want to defend to a clinical informatics team. That work is documented at /work/mirth-connect-dashboard.

The due diligence checklist: ten questions and what a good answer looks like

Question	What you are testing for	Red flag answer	Credible answer
Where does PHI travel and which vendors touch it?	BAA coverage gap	"We use a managed service, it's fine"	A named list of vendors, each with a signed BAA on file and a documented data-flow diagram
What is the message retry and dead-letter path?	Delivery guarantee	"We haven't had a drop in testing"	A named queue, a max-retry count, an alert on dead-letter threshold, and a documented recovery procedure
Are audit logs append-only and tamper-evident?	OCR investigation readiness	"Logs go to the application database"	Logs stored separately from application data, append-only, with a documented retention period of at least six years
Can you run a PHI access query for a single patient across the full log in under five minutes?	Audit query operability	"We'd need to write a script for that"	A live demo of the query, not a promise
Is MFA enforced for every human path to ePHI?	2026 Security Rule compliance	"It's on the roadmap" or "admin accounts are exempted"	MFA enforced at the identity provider level with no service-account bypass for interactive sessions
What is the documented RTO for the integration layer?	Resilience under failure	No documented RTO	A tested recovery procedure with a specific time target, matched to the 72-hour regulatory floor
Has the FHIR implementation been tested against the target EHR's actual profile, not just base spec?	Profile conformance	"We passed the FHIR validator"	Touchstone or equivalent conformance testing against the specific vendor profile (Epic, Oracle Health, athenahealth)
What scopes does the SMART on FHIR authorization request?	Minimum-necessary access	Wildcard scopes (patient/*.read)	Resource-level scopes, documented and justified per use case
What triggers a breach notification workflow and who owns it?	Breach Notification Rule readiness	"Legal handles that"	A documented runbook naming a specific person, with a tested 60-day notification path for breaches affecting 500+ individuals
Has a risk analysis covering all ePHI locations been conducted and documented?	Security Rule baseline	"We're HIPAA-compliant" with no document to show	A written risk analysis, updated to reflect the new integration, reviewed within the last twelve months

The BAA problem most CTOs discover too late

A HIPAA-compliant integration platform requires a signed BAA, but also: Security Rule safeguards, a known data location, and correct configuration on your side. A signed BAA is necessary; it is not sufficient.

A signed Business Associate Agreement is no longer sufficient — annual technical verification of your cloud provider is now an explicit obligation. Ask your team to show you the last verification, not just the signed document.

The audit exposure here is specific: BAAs define how vendors that handle PHI can use, disclose, and safeguard that information, and you need to confirm that the services handling PHI fall within the scope of the BAA. A middleware platform that routes HL7 messages is a business associate. A logging service that ingests those messages is a business associate. A monitoring tool with access to the queue is a business associate. Map them all.

Audit logs: the question nobody asks until OCR does

Audit trail architecture requires append-only logging, separate access-controlled storage for audit logs kept apart from application data, and a six-year minimum retention period. Those are the floor. The ceiling is whether you can actually use the logs under pressure.

Audit logging must capture all ePHI access, authentication events, and configuration changes, retained for a minimum of six years in a tamper-evident store. If the integration layer logs to the same database it writes clinical data to, a single compromised credential can alter both. That is an audit finding before it is a breach.

The test I recommend: sit down with the team and ask them to produce every access event for a specific fictional patient ID over the last thirty days. Time it. If it takes more than five minutes or requires a one-off script, the audit logging is not operationally ready. It exists on paper, not in practice.

For more on what an OCR investigation actually examines in your integration layer, see What a HIPAA Audit Actually Checks in Your Integration Layer.

FHIR profile conformance: the test that teams skip

Most organizations should target FHIR R4 as their primary implementation version, as it is the version required by ONC certification and supported by all major EHR vendors. Passing the base FHIR R4 validator is not the same as conforming to the EHR-specific implementation guide your integration will actually face in production.

EHR FHIR APIs often return incomplete or inconsistently coded data — missing fields, unexpected code systems, and pagination edge cases are common in production. An integration that was only tested against the vendor's sandbox will meet these in the first week of production and start producing silent data gaps. Ask to see the test evidence, not the test plan.

Request minimum scopes — resource-level scopes like patient/Patient.read rather than wildcard patient/*.read wherever possible. Wildcard scopes are a minimum-necessary violation waiting to be cited.

What the 2026 Security Rule changes for your sign-off

The mandatory technical safeguards now include encryption of ePHI both in transit and at rest, multi-factor authentication for all systems that access ePHI, documented vulnerability scanning and patch management cycles, and defined recovery time objectives for ePHI systems following a disruption. These were previously "addressable" — meaning a covered entity could document an equivalent alternative. They are no longer addressable. They are required.

For your sign-off, that means the integration cannot go live if any of those four controls are missing, regardless of what the build spec originally said. If the spec was written before the rule hardened, it may not include them.

If you are accepting delivery of a healthcare integration and want an independent read on these controls before you sign, that is the kind of engagement I take on. I am not a compliance officer and I do not issue certifications, but I can tell you whether the technical controls are present and whether the architecture will survive the questions above.

Who does not need this level of scrutiny?

If your integration handles no ePHI — a scheduling widget that stores no patient identifiers, a reporting pipeline that consumes only aggregate counts — most of this checklist does not apply. The HIPAA obligations attach to the PHI, not to the word "healthcare".

If you are integrating with a third-party platform that owns the ePHI layer and you have a BAA in place, your surface is smaller: you still need to verify your side of the access controls and confirm your audit logging captures what crosses the boundary. The full checklist above applies to builds where your team owns or routes ePHI directly.

For the related question of what technical due diligence finds more broadly across backend systems, Technical Due Diligence: The Twelve Things I Check First covers the non-healthcare version of this conversation.

FAQ

Can a vendor's HIPAA certification substitute for these checks?

No certification makes an integration HIPAA-compliant on its own. HIPAA compliance is an organizational obligation, not a product feature. A vendor can be SOC 2 Type II certified and still misconfigure your specific integration. The checks above are about your deployment, not the vendor's platform in the abstract.

How long should a healthcare integration audit log be retained?

HIPAA requires a six-year minimum retention period for audit records, and some states impose longer windows. The retention period applies to the logs themselves, not just the existence of a logging system. Verify that the retention policy is enforced programmatically, not just documented in a policy PDF.

What is the right RTO target for an integration that routes ePHI?

The 2026 HIPAA Security Rule sets a tested 72-hour recovery time objective as a non-negotiable requirement for ePHI systems. For clinical environments where a downed integration affects patient care, you will want a tighter internal target. The 72-hour figure is the regulatory floor, not a recommended design goal.

Do we need a BAA with every third-party service in the integration stack?

Vendors that handle ePHI on behalf of covered entities are business associates and carry direct compliance obligations — cloud platforms, EHR add-ons, billing tools, and telehealth applications must implement Security Rule safeguards, sign BAAs, and support breach response and documentation. If a service receives, stores, processes, or routes a message that contains PHI, it needs a BAA. A monitoring tool that ingests logs containing PHI counts.

What is the first thing to check if a healthcare integration has never been audited?

Start with the PHI data flow diagram. If one does not exist, that is your finding. You cannot audit controls for data flows you have not mapped. Draw the diagram, then apply the checklist above to every node and every edge on it. If that exercise is overdue and you want outside help, the healthcare software page describes how I approach this kind of engagement. Most engagements start around $5K; smaller well-scoped work is considered case-by-case.