EHR Integration Security Review for Healthcare

EHR Integration Security Review for Healthcare

An EHR integration can cross more trust boundaries than its interface suggests. A SMART app may receive launch context and FHIR tokens; an HL7 feed may traverse an interface engine, queue, support console, and downstream store. The security decision belongs to the configured path, not to a product category or vendor questionnaire.

Use this guide before a pilot, at production approval, after material change, and before renewal or exit. It is not medical, clinical, legal, privacy, security, billing, coding, reimbursement, or compliance advice. Qualified local owners decide applicability, acceptable risk, incident classification, and notification.

The method uses eight gates with pass, fail, conditional, or open states. A pass binds evidence to the interface, direction, tenant, environment, software and configuration version, and review date. A missing artifact is open — local owner/evidence required.

What this review owns

This page owns configured security assurance: attack surface, identity, authorization, secrets, protection, integrity, audit, detection, supply chain, negative testing, recovery, evidence expiry, and exit.

Use the workflow implementation guide for authority, mapping, write behavior, reconciliation, and operational correctness. Use the ROI model for baselines, costs, value, attribution, and sensitivity after security and workflow gates are supportable. Projected benefit cannot authorize access or compensate for an unresolved gate.

The vendor security and BAA guide covers enterprise vendor, contract, subprocessor, and data-use diligence. Here, bind that evidence to an EHR interface, launch or backend flow, patient and tenant context, write path, audit trail, stop mechanism, and recovery test. The integration vendor guide and healthcare AI vendor checklist organize broader procurement without replacing these gates.

Related context includes the integration checklist, EHR workflow tools, solution overview, ROI and implementation guide, and HIPAA-oriented research guide. These are handoffs, not endorsements.

How to record a gate decision

Create one row per interface and direction. A SMART launch, backend job, inbound feed, outbound write, and support path remain separate even under one contract.

Record system/module, interface/direction, tenant/environment, software/configuration version, owner, artifact, observation date, limitation, expiry, next action, and buyer-observed result. Separate vendor assertion, authority record, and local observation.

Do not average gates. Encryption cannot balance cross-tenant access, and price cannot balance missing audit evidence. Unknown scope, authority, containment, reconciliation, or exit remains a stop until an authorized owner accepts a bounded, expiring exception.

Gate 1: bind scope, ePHI, and the attack surface

Document information and access across source and destination systems, gateways, interface engines, queues, caches, logs, exports, backups, support tools, identities, vendors, subprocessors, regions, and recovery copies. Record read, create, update, delete, administrative, and support directions.

Identify potential ePHI, where it is created, received, maintained, or transmitted, and by whom. The current HIPAA Security Rule summary supports regulated-entity, ePHI, risk-analysis, and safeguard questions; it does not certify a product or decide local scope.

Keep the current rule separate from the HIPAA Security Rule proposed rule. Proposed provisions are not current requirements. Name the owner who monitors final-rule status and its evidence impact.

Map business associates and subcontractors using HHS guidance. A BAA does not prove the diagram or controls. HHS cloud guidance supports role, availability, recovery, return/deletion, and subprocessor questions; encryption or no-view design does not close them.

The FHIR R4 Security and Privacy module describes building blocks; it does not mandate one architecture or prove local security.

Evidence request: Obtain a versioned data-flow and trust-boundary diagram, interface/dependency inventory, ePHI/store register, identity list, environment/region map, subprocessor chain, retention/deletion path, support path, and exclusions. Reconcile it to configuration and approved observation.

Stop rule: Stop when any flow, store, privileged path, subprocessor, environment, data class, direction, or owner is unknown. Never reuse a narrow approval for a broader scope.

Gate 2: verify identities, authorization, and secrets

Record users, administrators, backend clients, service accounts, interface-engine accounts, support identities, emergency accounts, and jobs. Document registration, authentication, authorization, review, revocation, and ownership.

For SMART, record discovery, launch/backend pattern, client type/authentication, redirect, scopes, context, token audience/lifetime, refresh/introspection, and revocation. The SMART App Launch specification provides OAuth patterns. SMART scope is not the underlying business authorization, minimum necessary, patient selection, tenant boundary, or role policy.

The ONC authentication, access-control, and authorization criterion has a narrow module boundary. It does not prove external-app, backend-client, interface-engine, or buyer-configured least privilege. Record exact product, module, criterion, version, and configuration.

Use NIST SP 800-207 to challenge implicit trust. A zero-trust label, VPN, or SSO feature does not prove correct identity, patient, tenant, purpose, and policy evaluation.

Inventory tokens, keys, client and webhook secrets, certificates, emergency credentials, and support credentials. Record generation, storage, rotation, expiry, revocation, alerting, recovery, and destruction for the production client.

Test wrong patient, wrong tenant, wrong role, excessive/missing scope, expired or revoked credential, disabled user, stale session, token replay, unregistered redirect, and support access. Record expected and observed results, logs, defect owner, remediation, and retest.

Evidence request: Obtain identity/client registers, role/purpose/context rules, client registration, scope justification, privileged review, credential lifecycle, revocation sample, break-glass design, and configured negative tests for the proposed version and environment.

Stop rule: Stop for ownerless shared accounts, unjustified interactive service access, irrevocable credentials, unauthorized context change, unexplained scope, or failure to observe revoked-identity denial.

Gate 3: protect data and prove integrity

Document data through transit, storage, cache, logs, exports, errors, temporary files, backups, support bundles, recovery copies, and deletion queues. The current HIPAA Security Rule summary supports confidentiality, integrity, availability, access, audit, authentication, transmission, and contingency questions. Record protection, key ownership, rotation, failure behavior, and exceptions per location.

Integrity is separate from confidentiality. Map transformation, truncation, defaults, code translation, identifier matching, patient/encounter context, timestamps, hashes, version conflict, and authoritative source. A secure channel can still deliver duplicate, stale, misrouted, corrupted, or wrong-patient data.

Test each direction for duplicate, replay, ordering, delay, malformed values, partial/rejected writes, lost acknowledgments, concurrent edits, wrong destination, rollback, and recovery replay. Identify and reconcile every affected record.

The HHS cloud guidance supports return, deletion, availability, backup, recovery, and responsibility questions. Deletion evidence should name product, tenant, data, copy, date, exception, method, and residual retention across stores and subprocessors.

Evidence request: Obtain transport/storage configuration, key/certificate ownership, transformation map, integrity and context rules, retry/idempotency/version-conflict handling, retention/deletion/return procedures, and observed duplicate, replay, partial-write, and reconciliation results.

Stop rule: Stop for unknown protection, ownerless keys, silent context drift, unenumerated failures/duplicates, unreconciled writes, or deletion claims that omit copies.

Gate 4: prove audit, monitoring, and detection

Record events for authentication, denial, read/write/delete, export, launch, token and role change, configuration, privileged/support access, log disablement, queue failure, recovery, and administration. Record actor, source, entity, action, outcome, time, patient/tenant context, correlation ID, environment, and version.

FHIR AuditEvent can represent security events and may contain sensitive data. AuditEvent is not proof of complete coverage, tamper resistance, retention, review, cross-system correlation, or response effectiveness.

The ONC auditable-events and tamper-resistance criterion covers narrow module evidence. The ONC audit-reports criterion covers report generation and fields. Neither proves the integration path, external app, interface engine, downstream store, retention, or monitoring.

Demonstrate cross-system correlation through source, gateway, app, interface engine, destination, and recovery. Check time, identifiers, missing events, log access, redaction, export, retention, search, and investigation. One screenshot does not reconstruct a multi-system event.

For each alert, record source, threshold, suppression, owner, schedule, escalation, test event, notification, triage, and retest. Affected-record enumeration must identify users, patients, records, messages, actions, and downstream copies for a credential, interface, or time window.

Evidence request: Obtain the event matrix, component samples, logging configuration, disable/tamper controls, correlation design, log-access review, alert test, retention/export proof, review cadence, investigation workflow, and affected-record enumeration exercise.

Stop rule: Stop for absent critical events, undetected logging disablement, failed correlation, excessive ePHI in logs, ownerless alerts, unknown retention, or failed affected-record enumeration.

Gate 5: verify vendors, subprocessors, supply chain, and change

Verify each vendor artifact against product, module, service, region, version, period, scope, method, limitation, exception, and expiry. Confirm whether a corporate report omits a module, preview, buyer component, interface engine, or local configuration.

The HHS healthcare cybersecurity performance goals support voluntary questions about assets, vulnerabilities, third parties, incidents, and recovery. They are not certification, safe harbor, or local proof.

Use NIST SP 800-218 SSDF v1.1 for supplier preparation, software protection, secure releases, and vulnerability response. Policy, mapping, SBOM, scan, or penetration test does not prove execution or deployed security.

For each business associate and subprocessor, record service, data/access, region, role, incident duty, vulnerability contact, evidence access, dates, and exit responsibility. A BAA does not prove chain completeness, enumeration, or deletion.

Define vulnerability intake, validation, severity/exposure, remediation, patch ownership, notification, exception authority, retest, and closure. Track unsupported dependencies even without a full SBOM; never turn an empty search into a “no known risk” claim.

Evidence request: Obtain exact-scope assurance and penetration-test evidence, open findings, development/dependency evidence, disclosure and patch process, exceptions, subprocessor register, change history, regression proof, evidence access, and expiry.

Open rule: Keep open when evidence cannot map to the deployed version, a critical finding lacks bounded remediation, the subprocessor chain is incomplete, patch ownership is unclear, change lacks regression proof, or renewal/incident evidence is unavailable.

Gate 6: run configured negative and adversarial tests

Test the configured diagram, identities, trust boundaries, and failures in a production-like non-PHI environment with synthetic or authorized data. Record tenant, configuration, versions, dependencies, identity, time, expected/observed result, evidence, defect, remediation, and retest.

Test wrong user/tenant/patient/encounter, excessive or missing scope, expired/revoked credentials, disabled accounts, replay, duplicate, malformed input, unauthorized redirect, privilege escalation, dependency failure, partial outage, log gaps, misrouting, support access, and log disablement. Demonstrate denial, detection, containment, and recovery within an approved boundary.

Include user rejection, correction, downtime resume, and wrong-queue discovery. Connect each denial or correction to logs, alerts, downstream effects, and reconciliation.

The 2025 SAFER Guides provide self-assessment prompts for resilience, contingency, systems, APIs, and patient identity. They are not certification or test proof.

Separate vendor and buyer testing. A penetration test can inform attack classes and findings but cannot prove buyer identity, EHR roles, tenant, interface engine, logs, support, or recovery. A happy-path demo cannot replace negative observation.

Evidence request: Obtain approved scenarios, environment/synthetic-data record, configuration, expected/observed results, logs/alerts, affected-record search, defect/severity, owner, retest, limitation, and decision link. Preserve reproducibility without credentials or PHI.

Stop rule: Stop for unsafe testing, material environment mismatch, failed critical denial/detection, ownerless defect, missing retest, or evidence that cannot distinguish vendor assertion from buyer observation.

Gate 7: contain incidents and recover the workflow

Document detection, triage, command authority, vendor contact, evidence preservation, containment, rotation, isolation, stop-write-back, communication, manual work, restore, replay, reconciliation, and improvement. Name who stops each direction and informs users.

A security incident is not automatically a breach. The HHS breach-notification overview supports assessment, notification, and documentation questions; qualified privacy and legal owners determine the local branch.

The HHS cloud-service security-incident FAQ supports reporting-detail questions. Vendor notice does not prove enumeration of affected identities, records, actions, subprocessors, and copies.

Use NIST SP 800-61 Rev. 3 to connect preparation, detection, response, recovery, and improvement. A mapped playbook is not execution evidence; preserve exercise results for the integration boundary.

Predefine which tokens, keys, clients, accounts, queues, writes, exports, and support paths can be disabled without destroying evidence. ROI assumptions never justify keeping a compromised path active.

Recovery requires validated configuration, credential rotation, safe backlog handling, duplicate prevention, authoritative/downstream reconciliation, audit continuity, limitation communication, and corrective action. HTTP success is not recovery proof.

Evidence request: Obtain contacts, escalation, preservation, containment, breach-assessment handoff, manual work, affected-record enumeration, RTO/RPO assumptions, restore evidence, replay/reconciliation result, communication, defects, and exercise date.

Stop rule: Stop when risky paths cannot be disabled, credentials cannot rotate, evidence will be lost, escalation is undefined, manual work is unsafe, or recovery cannot prevent and reconcile missing/duplicate actions.

Gate 8: expire decisions, control expansion, and prove exit

Record approved interfaces, directions, data, sites, workflows, roles, tenant, environment, version, dependencies, exceptions, controls, owners, dates, expiry, triggers, and prohibited uses. “Approved vendor” is too broad.

Use NIST CSF 2.0 to organize outcomes and NIST SP 800-66 Rev. 2 for HIPAA Security Rule program questions. Neither certifies products, supplies legal opinions, or proves local controls.

Expire evidence by risk and change. Reopen gates for product/module/interface changes, expanded roles/scopes/sites/workflows, identity/logging changes, new subprocessors, material vulnerabilities/incidents, expired controls, or failed recovery exercises.

Expansion reuses the method, not the conclusion. Read-only does not authorize write-back; one tenant, population, facility, role, environment, or region does not authorize another. Require a boundary diff and configured evidence.

Plan exit before approval: access/credential revocation, data return/deletion, retention exceptions, backup/log handling, subprocessor confirmation, queue and record reconciliation, decommissioning, dependency removal, evidence retention, and communication.

Evidence request: Obtain signed scope, gate states, residual risks, exceptions/controls, authorized approvers, expiry/reset triggers, expansion/renewal rules, return/deletion method, revocation proof, queue/record reconciliation, retained logs, and decommission checklist.

Open rule: Keep open for unauthorized approval, ownerless or permanent exceptions, untested change, expansion without a boundary diff, or unproved revocation, data disposition, queue closure, and reconciliation. These failures cannot be offset by price, speed, ROI, contract, or executive preference.

Procurement questions by accountable owner

The buyer, not the vendor presentation, owns the question record. Save each answer with its source, scope, date, limitation, owner, and follow-up.

Integration architecture and API owners

• Which exact systems, interfaces, directions, resources or messages, transformations, environments, versions, and support paths are in scope?
• How do read, create, update, delete, subscription, batch, replay, administrative, and support paths authenticate, authorize, stop, and recover?
• How are partial failure, timeout, duplicate, out-of-order, wrong destination, and recovery replay enumerated and reconciled across every affected record?

Security architecture, IAM, and secrets owners

• How are user, backend client, service account, privileged administrator, support, and break-glass identities registered, reviewed, revoked, and attributed?
• Which role, purpose, scope, patient, encounter, tenant, device, and environment signals constrain each request, and which negative tests prove denial?
• Where are tokens, refresh tokens, keys, certificates, webhook secrets, and emergency credentials generated, stored, rotated, monitored, revoked, and destroyed?

Privacy, HIM, legal, and compliance owners

• Who creates, receives, maintains, or transmits ePHI in each flow, and who records covered-entity, business-associate, subprocessor, permitted-use, and minimum-necessary decisions?
• How do contracts and operating evidence bind retention, return, deletion, secondary use, data residency, individual rights, legal hold, and exit to the exact scope?
• Who owns security-incident and breach assessment, affected-person enumeration, notification decisions, documentation, and evidence preservation?

SOC, monitoring, and incident-response owners

• Which authentication, authorization, read, write, export, configuration, support, and recovery events must appear across the EHR, app, interface, cloud, and vendor systems?
• Which rules and thresholds trigger review, containment, rotation, stop-write-back, escalation, and affected-record search, and who covers each schedule?
• What did the most recent tabletop, alert, restore, replay, and reconciliation exercise observe, what failed, and where is the retest evidence?

EHR and application administration owners

• Which product module, role, client, launch context, patient selection, service account, write permission, audit setting, and emergency-access configuration is actually deployed?
• How can administrators export configuration and prove that vendor updates or local changes trigger review and regression testing?
• What do users see when access is revoked, the integration is paused, a queue is delayed, or a dependency fails, and how are silent actions prevented?

Clinical operations, safety, and downtime owners

• Which integration actions can alter a record, queue, task, order, note, schedule, or user decision, and who may accept, reject, correct, or pause them?
• What manual workflow applies to unavailable, stale, misrouted, duplicate, wrong-patient, partial-write, or delayed-replay scenarios?
• After recovery, who proves backlog completeness, ordering, mapping, manual-period capture, discrepancy resolution, and downstream communication?

Vendor management, procurement, and supply-chain owners

• Which exact product, version, service, region, date, control scope, test method, and exclusion does each assurance, penetration-test, SBOM, or security artifact cover?
• What duties govern subprocessor changes, vulnerability disclosure, patching, incident cooperation, support access, material changes, evidence delivery, and termination?
• Can the buyer retain logs, configuration, affected-record lists, open findings, and exit evidence, and who accepts a bounded exception if only a vendor summary is available?

Internal assurance, continuity, and decision owners

• Which gates and scenarios are non-compensating hard stops, and who can approve, condition, except, pause, resume, expand, renew, or terminate the integration?
• When does each evidence item expire, and which product, configuration, interface, workflow, site, subprocessor, rule, vulnerability, or incident change resets the decision?
• At exit, who proves access revocation, credential rotation, data disposition, queue closure, record reconciliation, log retention, dependency removal, and decommissioning?

Buyer-owned security artifacts

These seven buyer records retain scope, gaps, observation, decision, and expiry. Use pass, fail, conditional, or open, with no default numeric weight that can average away a hard stop.

Separate vendor assertion, authority, standard, or certification evidence, and buyer-observed configured result. Record product/configuration, environment, owner, date, limitation, expiry, and action. Missing evidence is open — local owner/evidence required.

Integration security boundary and data-flow inventory

Record systems, interfaces, directions, ePHI, identities, environments, stores, logs, backups, exports, vendors, subprocessors, support paths, boundaries, owners, and exclusions. Link elements to configuration or observation.

Identity, authorization, and credential register

Record clients and identities; registration; authentication; role, purpose, patient, tenant, and scope; approver; credential lifecycle; review; revocation; privileged access; and break-glass use.

Use the SMART App Launch specification and the ONC authentication criterion only to label their respective protocol and certified-module evidence. Preserve the buyer’s configured authorization and revocation result separately.

Data protection, integrity, and audit matrix

For each flow, record protection/key ownership, mapping/version, context, retention/deletion, duplicate/replay, failure/reconciliation, required events, tamper signal, correlation, alert, review, export, and affected-record enumeration.

Use FHIR AuditEvent as a versioned event model where applicable, not as a claim that coverage, tamper resistance, correlation, review, or retention has passed.

Vendor assurance, vulnerability, and change register

Bind BAA/subprocessor, assurance, penetration-test, development, dependency, vulnerability, patch, finding, release, change, regression, access, owner, date, limitation, expiry, and retest evidence to deployed scope.

Map supplier evidence to NIST SSDF v1.1 only when the exact practice, product scope, evidence date, limitation, and buyer dependency are recorded. Framework mapping alone remains an assertion.

Configured security scenario record

Start with wrong-user and wrong-tenant access, wrong patient or encounter, excessive and missing scope, expired or revoked credential, replay and duplicate delivery, malformed input, privilege escalation, attempted log disablement, silent log gap, misrouting, partial outage, unauthorized support access, dependency failure, and stop-write-back and restore-replay-reconcile. Store expected and observed behavior, synthetic data, environment, version, logs, alerts, affected-record search, defect, remediation, retest, limitation, and decision state.

Incident, downtime, and recovery packet

Store contacts, authority, containment, rotation, preservation, incident/breach handoff, manual work, affected-record enumeration, restore/replay, reconciliation, RTO/RPO observation, communication, exercise, correction, and retest.

Use NIST SP 800-61 Rev. 3 to organize incident-response outcomes and the HHS breach overview to route qualified assessment questions. Neither link records a local exercise or legal determination.

Security decision, residual-risk, and exit dossier

Summarize gate states, hard stops, exceptions, controls, risks, approvers, expiry, change/expansion triggers, renewal, offboarding, revocation, data disposition, logs, queues, reconciliation, dependencies, and decommission proof.

FAQs

Does a BAA make an EHR integration HIPAA compliant?

No. HHS business-associate guidance can support role, contract, subprocessor, and reporting questions, but a BAA does not prove that the data-flow inventory is complete, configured controls are effective, access is appropriate, incidents can be handled, or the buyer has met its own obligations. Applicability and compliance require qualified local review of the actual entity, data, workflow, contract, and safeguards.

Do SMART and FHIR prove secure authorization?

No. The FHIR security module supplies security vocabulary, and SMART App Launch supplies OAuth-based launch and backend patterns. A granted scope does not by itself prove local role, purpose, patient, encounter, tenant, minimum-necessary, token, redirect, or revocation policy. Test the deployed client and environment, including denied and revoked cases.

Does ONC certification cover the full integration?

No. Certification applies to an exact Health IT Module and criterion. The ONC pages for authentication and authorization, auditable events and tamper resistance, and audit reports define narrower test boundaries. They do not automatically cover an external app, backend service, interface engine, local configuration, downstream system, support process, detection practice, incident response, or recovery path.

Are AuditEvent records or audit reports enough?

No. The FHIR AuditEvent specification can support event-model questions, but the buyer must also prove required-event coverage, accurate identity and context, tamper signals, time and cross-system correlation, sensitive-log protection, retention, export, alerts, human review, affected-record search, investigation access, and use during containment and recovery.

Is every security incident a breach?

No. The HHS cloud-service incident FAQ distinguishes reporting questions from the later breach-assessment branch. Preserve evidence, contain the event, enumerate affected identities and records, and escalate promptly. Qualified privacy and legal owners determine whether the facts meet an applicable breach definition and what notification or documentation is required.

When should the review stop or reopen?

Use NIST Cybersecurity Framework 2.0 to keep governance, identification, protection, detection, response, and recovery outcomes connected. Stop when a critical flow or owner is unknown, access is excessive, cross-patient or cross-tenant denial fails, ePHI protection is unknown, critical audit evidence is missing, containment is unavailable, recovery is unreconciled, or exit is unverifiable. Reopen when the product, module, interface, direction, site, workflow, role, scope, identity, logging, subprocessor, vulnerability, incident, rule, or evidence validity changes.

Evidence boundary

These official sources define summaries, proposals, standard building blocks, certification criteria, frameworks, and practices. They do not establish product security, local control effectiveness, clinical safety, compliance, breach status, or approval.

No vendor rating, test result, vulnerability or incident rate, interview, local result, clinical outcome, SLA, cost, or ROI is claimed. These artifacts are scaffolding, not completed evidence. Generic author/reviewer fields are not named professional signoff.

Hand verified workflow assumptions to implementation and verified cost/utilization inputs to ROI. If configured evidence cannot support an independent security decision, keep the outcome open.