EHR Integration Workflow Implementation Guide

EHR Integration Workflow Implementation Guide

An EHR integration is not a feature checkbox. It is a versioned operating path that connects a trigger, patient or business context, source record, interface, transformation, destination, user decision, downstream action, exception queue, and recovery process. A buyer should be able to reconstruct that path before a pilot and after a failed transaction.

This guide is for healthcare technology research and procurement planning. It is not medical, clinical, legal, billing, coding, reimbursement, security, or compliance advice. Local clinical, technical, privacy, security, legal, compliance, and records owners must decide which requirements apply and whether the configured workflow is acceptable.

The method below separates standards claims from configured evidence. It applies whether the transport is FHIR, HL7 v2, C-CDA, a proprietary API, a file feed, an interface engine, or a combination. A standard can make requirements testable, but it does not prove that patient matching, mapping, authorization, write-back, reconciliation, monitoring, or downtime recovery works in the buyer's environment.

Use the EHR integration vendor evaluation guide for vendor-level diligence, the EHR integration checklist for a compact scope review, and AI tools for EHR workflows to identify use cases. The AI for EHR Integration solution page provides cluster context. This page owns implementation evidence, not product ranking.

Each gate records pass, fail, conditional, or open. A missing item stays open — local owner/evidence required. Price, speed, projected savings, a standards label, or a weighted score cannot be used to override a hard-stop failure. Failures involving identity, integrity, write authority, privacy, security, auditability, recovery, legal scope, or exit cannot be offset by commercial benefits.

Gate 1: bind the workflow and decision authority

Start with one narrow use case. Name the initiating event, the actor who initiates it, the patient or operational context, the source system, the destination, and the action that follows. “Integrates with the EHR” is not a workflow description.

Draw both directions of data movement. Mark read points, create or update points, queues, transformations, user review, acknowledgments, downstream notifications, and the system that remains authoritative for each field or decision. If two systems may update the same value, document conflict rules and the person who resolves disagreement.

State what the integration is not allowed to do. Examples include finalizing a note, placing an order, changing a medication, closing a referral, releasing a result, sending a patient message, or creating a billable event without a named human or system authority. Do not infer authority from a screen location or an API permission.

Include facilities, departments, specialties, users, populations, encounter types, record types, environments, and operating hours. A narrow approval for a test tenant or one clinic must not be reused as approval for a different tenant, workflow, or consequence.

Document the approved scope in one version-controlled record that users, support staff, and reviewers can retrieve after the implementation team leaves.

Evidence request: a workflow, authority, and exception map that names the trigger, source of truth, every read and write, decision owner, user acceptance step, exception owner, manual fallback, stop authority, downstream consequence, and explicit exclusions.

Test the map with normal and adverse stories. Use missing context, disputed information, a wrong destination, a delayed event, an unavailable dependency, and a user rejection. Record which owner notices the problem and which record proves it was resolved.

Stop the gate when the authoritative record, decision owner, downstream consequence, stop authority, or exception owner is unknown. A workflow with an unidentified final actor cannot move to configuration testing.

Gate 2: pin versions and applicability

Version evidence has five separate states: current published, regulation-adopted, SVAP-approved, product-implemented, and buyer-deployed. Add claimed and buyer-observed as separate columns when the vendor assertion and configured result differ. Never replace these states with “latest.”

The HL7 FHIR R4 specification provides a stable technical vocabulary for the R4 resource and REST model. A product may use a different FHIR release or a non-FHIR path. Record the exact server and client release, implementation guide, package, profile, operation, and environment rather than assuming the product category determines them.

SMART App Launch 2.2.0 is the current published SMART guide observed for this review. Its publication does not prove that the buyer's endpoint supports that version, that every feature is enabled, or that a granted scope matches local role and purpose rules.

US Core 9.0.0 is the current published US Core guide observed for this review. The guide distinguishes profile-only support from profile plus interaction support. A profile claim therefore needs a CapabilityStatement and configured interaction tests before it becomes an endpoint capability claim.

The ONC 2026 Standards Version Advancement Process permits voluntary use of approved advanced standards, including US Core 9.0.0 and USCDI v6 for the 2026 cycle. Multiple approved versions can coexist unless a later policy supersedes them, so a buyer must identify the version actually provided and used.

ONC's Standards Bulletin 2026-2 records the publication of USCDI v7. Publication of USCDI v7 is not the same as 2026 SVAP approval, a universal certification baseline, a completed US Core mapping, or proof that a local EHR exchanges every v7 data element.

Verify the production endpoint and its advertised capabilities after every material platform or interface upgrade.

Evidence request: a version, capability, and applicability register containing the vendor, product, module, build, tenant, endpoint, FHIR release, implementation guide, profile package, SMART version, USCDI version, terminology version, certification criterion, SVAP basis, CapabilityStatement, environment, observation date, limitation, and next review date.

Open rule: keep the gate open — local owner/evidence required when the production endpoint cannot be mapped to exact versions and configuration. Do not use a roadmap, marketing page, test environment, or product year as a substitute.

Gate 3: map data, identity, terminology, and provenance

Build a field-level map before testing the user interface. Record each source field, destination field, identifier, profile element, data type, required/optional behavior, default, transformation, truncation risk, and the owner of the authoritative value. A successful transport can still deliver the wrong meaning.

The FHIR R4 terminology module separates code systems, value sets, concept maps, and terminology operations. The ValueSet resource supports versioned expansion and validation questions. Neither source proves that two local fields are semantically equivalent or that a mapping is lossless.

For every coded field, preserve the code system, value set, version, display, mapping rule, unmapped behavior, and terminology-service response. Decide what happens to deprecated, local, unknown, or out-of-range codes. Do not silently coerce an unsupported code into a convenient default.

Test at least one unmapped, deprecated, and ambiguous code before expanding the workflow beyond the approved cohort.

Patient identity deserves its own test plan. ONC describes patient identity and patient record matching as a core interoperability concern. Record the demographic inputs, match thresholds, duplicate handling, merge and unmerge behavior, overlay detection, manual review, and audit trail used by the deployed workflow.

Provenance is not one field called “source.” FHIR R4 Provenance can describe an activity, agent, entity, target, and resource version. US Core Basic Provenance explains last-hop and authorship patterns, but a last-hop record does not automatically provide full lineage through every intermediary and transformation.

Record both lineage and operational audit evidence. Lineage answers where a value came from and how it changed. Event evidence answers who or what performed an action, when it occurred, and what outcome was recorded. The buyer must verify that the relevant record can be retrieved and reconciled, not merely that a resource type exists.

Evidence request: a data, identity, terminology, and lineage map for every decision-relevant field, including source, identifiers, match rule, profile, code/value-set version, mapping, transform, null/unknown behavior, author or transmitter, provenance, audit event, retention, data owner, and downstream correction path.

Stop the gate when a wrong-patient or duplicate-record condition is not detectable, a lossy mapping lacks an approved exception, terminology is unversioned, a required source or transformation is missing, or a correction cannot propagate to affected downstream copies.

Gate 4: verify authorization, privacy, and security

Separate user-facing launch, standalone launch, backend service, interface-engine credential, and non-FHIR authentication paths. For each, record client type, registration, authentication method, requested and granted scopes, launch context, user context, token lifetime, refresh behavior, revocation, and the resource server that accepts the token.

SMART scopes communicate delegated access requirements, but they do not model every underlying permission. A granted scope can still be restricted by local policy, and a broad scope does not prove the workflow is authorized to use every accessible resource. Test the actual role, patient context, purpose, and denied path.

Map where electronic protected health information is created, received, maintained, transmitted, cached, logged, backed up, supported, and deleted. The HHS HIPAA Security Rule summary supports questions about risk analysis, access control, audit controls, integrity, authentication, transmission security, contingency planning, and evaluation for regulated entities. It does not certify an interface or decide applicability for every data flow.

The HHS HIPAA and cloud computing guidance supports business-associate, BAA, service-level, backup, recovery, return-or-destroy, and subcontractor questions. A BAA, encryption, cloud label, or inability to view encrypted data does not by itself prove compliance or control effectiveness.

NIST SP 800-66 Rev. 2 can help a regulated entity organize Security Rule risk-management activities and mappings. It is not a certification, legal opinion, mandatory one-size control list, or proof that a configured connection is secure.

Evidence request: an authorization, privacy, and security packet containing flow diagrams, clients, registration, scopes, context, token and revocation tests, roles and purposes, ePHI locations, business-associate and subprocessor records, access/audit/integrity/transmission controls, secrets ownership, vulnerability and patch evidence, incident duties, backups, restore evidence, and reviewer dates.

Test least-privileged users, denied access, expired credentials, revoked access, wrong tenant, changed roles, unavailable authorization services, key rotation, and incident containment. Preserve observed logs and the owner who reviewed them.

Record the exact denial, revocation, and recovery evidence rather than accepting a policy statement as the observed result.

Stop the gate when a data recipient, purpose, subprocessor, secondary use, access owner, audit owner, credential owner, incident duty, or recovery path is unknown. A security label cannot compensate for an unbounded data flow.

Gate 5: separate read, write, and reconciliation

Read capability and write capability are different approvals. List every read, search, create, update, delete, conditional operation, subscription, message, batch, transaction, and non-FHIR action separately. Record which actions are forbidden even if the technical credential could perform them.

The ONC standardized API test method for § 170.315(g)(10) covers patient and population read services and does not cover create or modify write-back. A (g)(10) certification claim therefore does not prove write-back, order entry, document creation, reconciliation, or downstream action.

FHIR R4 RESTful API and transaction processing defines interactions, status handling, OperationOutcome, batch responses, and transaction behavior. A transaction can provide all-or-nothing server processing while still leaving patient matching, mapping, human authority, downstream use, duplicate prevention, and business reconciliation unproven. Batch must not be described as atomic transaction behavior.

Test duplicate retry, conditional create, update conflict, stale version, partial payload, timeout before response, timeout after commit, out-of-order delivery, wrong-patient context, missing required data, rejected human review, corrected data, reversal, and replay after recovery. For each case, compare the source, target, queue, audit record, user-visible status, and downstream copy.

Idempotency is an observed workflow property, not a vendor adjective. Document the key or condition that prevents duplicate action, how long it remains effective, what happens after a retry window, and how staff find and correct a duplicate that still occurs.

Evidence request: a versioned read/write contract and scenario log containing request, expected response, actual response, HTTP status, OperationOutcome, resource/version identifier, queue event, target record, user decision, downstream effect, duplicate behavior, rollback action, and affected-record reconciliation.

Reconciliation must enumerate affected records. A support ticket stating “resolved” is not enough. The buyer needs a reproducible list of records, the expected final state, the observed final state, corrections made, owner signoff, and evidence that downstream copies are aligned.

Stop the gate when write authority is ambiguous, wrong-patient or duplicate action is not detectable, a failed or timed-out write cannot be enumerated, rollback is undefined, or affected-record reconciliation cannot be demonstrated.

Gate 6: prove conformance and end-to-end behavior

Keep validation, conformance, contract, integration, workflow, recovery, load, and user-acceptance tests in separate rows. A validator pass is not end-to-end proof. It can identify specific structural problems without proving semantic correctness, local authorization, patient matching, workflow completion, or safe downstream use.

The FHIR R4 validation guidance describes structure, cardinality, value domain, binding, invariant, and profile validation. It also explains that static resource testing cannot cover every narrative and business rule. Save the validator, package, profile, terminology dependencies, input, output, warnings, and unresolved exceptions.

A FHIR R4 CapabilityStatement records claimed server or software capabilities, interactions, operations, profiles, and versions. It does not prove that a production endpoint is configured accordingly, that required data is present, or that a particular request will succeed for a user and patient context.

The ONC Inferno test-kit catalog provides an approved (g)(10) test method and other executable conformance suites. The public host is a demonstration environment and must not receive PHI. A test-kit result only supports the tested criterion, suite, version, endpoint, data, and run; it does not prove write-back, local workflow safety, performance, or security posture.

For every test, preserve the vendor assertion, authority or certification record, and buyer-observed result as separate evidence. A vendor screenshot or pass badge is not a buyer-observed configured result. Repeat critical cases in the buyer's non-production configuration and confirm the target record and downstream consequence.

Negative tests should include missing and extra fields, unsupported codes, wrong and merged patients, insufficient scope, expired token, denied access, stale version, conflicting update, unavailable dependency, partial payload, slow response, duplicate event, reordered event, and replay. Define the expected failure state before running the test.

Evidence request: a conformance and scenario test record containing build, tenant, configuration, environment, tool and version, profiles and terminology, test data, case, expected result, observed result, request/response/log, patient and encounter context, write effect, downstream copy, negative and recovery behavior, defect, owner, retest, limitation, and date.

Stop the gate when only happy paths were tested, the target record or downstream effect was not inspected, production-relevant configuration differs without analysis, warnings were discarded, critical defects remain open, or affected records cannot be listed after failure.

Gate 7: operate through change and downtime

An integration becomes an operational dependency after go-live. Define service indicators for availability, latency, data freshness, completeness, accepted and rejected volume, queue age, mapping errors, identity exceptions, duplicate or replay events, credential expiry, and downstream reconciliation. Each metric needs a numerator, denominator, exclusions, source query, owner, threshold, and response.

The ONC 2025 SAFER Guides support self-assessment questions for system management, contingency planning, patient identification, orders, test-result follow-up, communication, and organizational responsibility. SAFER is not certification or proof that a local control operated.

The ONC API service-base URL availability resource supports endpoint inventory and availability-monitoring questions for certified APIs. Public URL availability does not prove buyer-specific connectivity, authorized access, complete data, latency, SLA performance, disaster recovery, or end-to-end workflow availability.

Write a downtime procedure for source outage, destination outage, interface-engine outage, authorization failure, certificate expiry, network partition, and vendor outage. Define what staff record manually, where the backlog is held, how duplicate action is prevented, who authorizes replay, and how restored records are reconciled.

Treat version, profile, mapping, terminology, identity logic, scope, credential, routing, user permission, EHR upgrade, interface-engine upgrade, subprocessor, retention, and write behavior as change-controlled inputs. Classify changes as non-material, review-required, or approval-resetting. Preserve the version responsible for historical actions.

Evidence request: an operations, change, renewal, and exit dossier containing metric definitions, dashboards, alerts, queues, on-call and vendor duties, downtime/manual workflow, RTO/RPO, restore and replay test, reconciliation record, change notice, regression scope, approval reset, rollback, incident history, configuration export, data return/delete, open-queue transfer, and evidence-retention plan.

Test an alert from generation to accountable response. Test recovery from a known backlog and compare every affected record with its expected state. A recovery time without reconciliation evidence is incomplete.

Stop the gate when production health is not observable, an alert has no accountable owner, a backlog cannot be enumerated, recovery does not reconcile downstream copies, a material change bypasses regression, rollback is unavailable, or termination cannot preserve records and verify deletion.

Gate 8: verify certification, legal, and information-access scope

Certification applies to specific developers, products, versions, modules, and criteria. Use the ONC Certification Program and Certified Health IT Product List to capture the exact CHPL ID, product/version, certified criteria, status, SVAP record, corrective action, and observation date. “ONC certified” must not be expanded to an entire suite or an unlisted integration function.

Separate certified and non-certified modules in the proposed workflow. Note which capability comes from the EHR, interface engine, app, service, local configuration, or custom code. A certified read API does not certify a separate write path, mapping layer, identity process, or operational runbook.

The ONC § 170.401 Information Blocking CCG points implementers to actor, practice, and exception requirements and explains the certified-developer condition. It does not decide whether every party is an actor or whether a specific practice constitutes information blocking.

ONC's EHI explainer describes the designated-record-set-aligned scope of electronic health information and explains that the post-2022 scope is not limited to USCDI v1. It does not make the current USCDI publication the full definition of EHI or decide the status of each local record.

Document the actor, practice, request, information, applicable knowledge standard, required-by-law branch, restriction, fee, and potential exception. Security concern, downtime, format limitation, or contractual term does not automatically qualify for an exception. Local legal and compliance owners must record the conclusion and facts.

Evidence request: an applicability record containing exact product/module/version/criterion, CHPL and SVAP evidence, certified/non-certified boundary, service documentation, actor and EHI analysis, request and practice, required-by-law and exception analysis, HIPAA role, contracts, reviewer, date, limitations, and expiry.

No certification, legal, privacy, or information-access result should be inherited from a different version, module, entity, actor, or workflow. Reopen the gate when those facts change.

Open rule: keep the decision open — local owner/evidence required when the exact module, criterion, actor, EHI scope, contract role, or legal analysis is missing. Do not let a weighted vendor score fill the gap.

Procurement questions by accountable owner

Use these questions in owner interviews and write every answer into a buyer-owned artifact. A verbal answer without versioned evidence remains open.

Clinical and operational workflow owners

• Which event triggers the integration, who accepts or corrects the result, which record is authoritative, and what downstream action follows?
• How do normal, wrong-patient, duplicate, incomplete, disputed, delayed, and outage cases move to a named stop, fallback, and reconciliation owner?
• Which sites, specialties, populations, encounter types, record types, users, and actions are explicitly outside the approved scope?

Integration architecture and vendor engineering

• What exact FHIR, US Core, SMART, USCDI, other implementation-guide, product, tenant, endpoint, and CapabilityStatement versions are deployed?
• Which read, search, create, update, delete, subscription, message, batch, transaction, and non-FHIR actions are supported, and how are retries, idempotency, conflicts, and partial failures handled?
• Can the buyer independently export interface configuration, mapping, terminology, queues, logs, certificates, dependencies, and vendor-managed evidence?

HIM, patient identity, and data governance

• How are patient, encounter, provider, organization, and location identities matched, and how are duplicate, overlay, merge, unmerge, and wrong-record events detected and audited?
• For every decision-relevant field, what are the source, profile, terminology version, mapping, null behavior, provenance, author or transmitter, and authoritative owner?
• After transformation, source correction, human correction, or reconciliation, who is accountable for the local authoritative record and every downstream copy?

Security and identity-access management

• Which user, backend, interface-engine, or other authorization flow is used, and how are client registration, authentication, scope, context, token refresh, revocation, and emergency access controlled?
• How are least privilege, roles, purposes, tenant boundaries, secrets, audit, integrity, transmission, vulnerabilities, patches, and denied paths observed in the configured environment?
• If access is revoked, a credential expires, a vendor is unavailable, or compromise is suspected, who can stop, contain, rotate, recover, and enumerate affected access and events?

Privacy, legal, and compliance

• Which entities create, receive, maintain, transmit, cache, support, back up, or delete ePHI, and what HIPAA role, agreement, subprocessor, use, retention, and exit evidence applies?
• Which exact product, module, function, version, and CHPL criteria are certified, and which proposed capabilities are outside that certified scope?
• Who records the actor, practice, EHI, request, restriction, fee, required-by-law, and exception analysis for information-access decisions?

Clinical safety, quality, and testing

• Which failures could affect identity, orders, results, medications, documentation, care transitions, referrals, communication, or follow-up, and what threshold pauses the workflow?
• How do conformance and end-to-end suites cover negative, boundary, out-of-order, duplicate, downtime, replay, recovery, rollback, and downstream reconciliation cases?
• How do defects, near misses, data-quality drift, user corrections, and unresolved warnings enter corrective action and change approval rather than end at ticket closure?

Operations, procurement, and vendor management

• What observable availability, freshness, completeness, latency, queue, error, retry, support, and incident-notification commitments have named owners and reproducible definitions?
• Which standard, profile, vendor, configuration, mapping, terminology, credential, or subprocessor changes require notice, regression, approval reset, and rollback evidence?
• At renewal or termination, how will the buyer export configurations, mappings, logs, records, provenance, and open queues, verify deletion, and complete transition without losing accountability?

Buyer-owned implementation artifacts

The buyer, not only the vendor, should retain these six artifacts. Every evidence row records pass, fail, conditional, or open, plus owner, environment, product/configuration/version, source, observed date, limitation, expiry, and next action.

The vendor assertion, authority or certification record, and buyer-observed configured result must remain separate. Document existence is not control effectiveness. There is no default numeric weight, and hard-stop evidence cannot be averaged away.

Workflow, authority, and exception map

Record the use-case ID, trigger, actor, patient/context, source and target, authoritative record, read/write action, decision and consequence, human acceptance, exception, fallback, stop owner, reconciliation owner, and exclusions.

The map fails when it says only “bidirectional integration,” when no one can name the authoritative record, or when a downstream consequence can occur without explicit authority.

Version, capability, and applicability register

Record product, module, build, configuration, tenant, endpoint, FHIR/US Core/SMART/USCDI/other guide versions, CapabilityStatement, CHPL criterion/status, SVAP basis, claimed/configured/observed state, observation date, and limitation.

Keep the register open when the production endpoint cannot be mapped to an exact stack or when publication, certification, product support, and deployment are collapsed into one claim.

Data, identity, terminology, and lineage map

Record every critical resource and field, source, identifier, matching rule, profile element, code system, value-set version, mapping, transformation, null/unknown behavior, author/transmitter, provenance, audit event, retention, correction, and data owner.

The map fails when identity exceptions are invisible, a mapping is lossy without review, terminology is unversioned, or historical values cannot be connected to their source and transformation.

Authorization, privacy, and security evidence packet

Record clients, flows, registration, scopes, context, token and revocation behavior, role and purpose, ePHI path, business associates and subprocessors, access/audit/integrity/transmission controls, secrets, incidents, backup and recovery, reviewer, and date.

A SMART label, BAA, encryption statement, security badge, or NIST mapping is not a certification and cannot replace configured control evidence.

Conformance and scenario test record

Record build, tenant, configuration, environment, tool/profile/terminology version, test data, case, expected and observed results, request/response/log, identity, write effect, downstream copy, retry, conflict, outage, replay, rollback, and reconciliation, defect, owner, and retest.

The record fails when it contains only a screenshot or pass badge, tests only a happy path, omits the target record and downstream effect, or cannot enumerate affected records.

Operations, change, renewal, and exit dossier

Record SLO definitions, monitors, alerts, queues, downtime procedure, manual capture, RTO/RPO, restore and replay test, release and dependency notice, regression, approval reset, rollback, incidents, renewal decision, configuration/data export, deletion verification, transition, and evidence retention.

The dossier fails when health is not observable, major change needs no retest, backlog is not reconcilable, exit cannot preserve accountability, or historical actions cannot be tied to their versions.

FAQs

Does FHIR support prove local interoperability?

No. FHIR provides versioned technical contracts and testable interactions. It does not prove local interoperability across configuration, data availability, identity, semantics, authorization, workflow, performance, and recovery. Those claims require buyer-observed evidence for the deployed stack.

Does ONC certification prove write-back?

No. The cited (g)(10) criterion covers read services and does not prove write-back. Verify the exact module and criterion, then test create, update, conflict, retry, rollback, and reconciliation separately when the workflow writes data.

Is the newest published standard always required?

No. Current publication, regulation, SVAP approval, product implementation, and buyer deployment follow different timelines. Preserve the exact version and basis for each; if the deployed version is unknown, record open — local owner/evidence required.

Does a transaction or HTTP success prove workflow success?

No. Transaction semantics and HTTP results describe server processing within a defined boundary. They do not prove patient identity, semantic accuracy, human authority, downstream completion, duplicate prevention, or affected-record reconciliation.

Does a BAA make the interface HIPAA compliant?

No. A BAA can be an important agreement for an applicable relationship, but it does not decide every role or data flow and does not prove that required safeguards operate. Local privacy, security, legal, and compliance owners must review applicability and configured evidence.

When should implementation stop?

Stop when a critical owner or version is unknown; identity, integrity, or write authority is unproven; privacy or security scope is unresolved; configured negative testing is missing; failures cannot be detected and reconciled; downtime recovery is untested; or legal, audit, provenance, change, rollback, and exit evidence is insufficient.

Evidence boundary

This page uses official HL7, ONC, HHS OCR, and NIST materials to define questions and evidence boundaries. It does not claim that HealthAIdir tested a product, inspected a buyer deployment, measured performance, interviewed customers, approved an interface, or made a legal or compliance determination.

The implementation decision and the financial decision remain connected but separate. Send verified transaction volume, exception labor, maintenance effort, adoption, downtime, risk controls, and operating cost to the EHR integration ROI model. Until the workflow evidence is versioned and buyer-observed, any financial input remains an unverified assumption and cannot prove that the integration is ready.

For adjacent diligence, use the healthcare AI vendor evaluation checklist, security and BAA review guide, healthcare AI ROI and implementation guide, and HIPAA-compliant AI tools research guide. These pages provide supporting questions; none replaces the versioned artifacts and local acceptance required here.