Your EHR has an API. Why are staff still copying patient records?
The patient lookup works. The referral still needs copying. Verify the task, permissions and destination state before calling an EHR integration complete.
On this page
The short version
- Check the exact task, resource and write operation before calling an EHR integration complete.
- Prove patient and encounter matching, permissions and write-back in the intended environment.
- Measure staff work removed, including exceptions, rather than endpoints connected.
The API works. The receptionist still copies the record.
Your dashboard reads appointments. The demo looks connected. Then a patient reschedules, a referral arrives or a clinician finishes a note, and someone opens two systems to finish the job.
That gap is easy to hide in an integration brief. “Connect the EHR” names a system, not a completed workflow. In a practitioner discussion, a vendor describes teams still copying records because their APIs do not cover the work they need. It is an account to investigate, not evidence that every EHR has the same limits.
Start with one fictional example: a coordinator must file an approved referral against the correct patient and encounter, then see it in the receiving team’s worklist. That is the acceptance target. A successful patient lookup is only one step.
Replace “FHIR-ready” with a capability checklist.
- Name the finished task
Identify who acts, what changes and where the result must appear.
- Map the required operations
List reads, creates, updates and workflow-specific actions.
- Confirm real access
Check vendor support, contracted access, scopes and staff roles.
- Agree acceptance evidence
Show the result in the destination and account for failures.
For each step, record the resource, fields, operation, actor and required destination state. Retrieving an appointment, changing it and notifying the right worklist are different capabilities. Put them on separate lines so a working read endpoint cannot stand in for an unavailable update.
FHIR’s CapabilityStatement describes supported server behavior. Inspect the statement for the actual endpoint and version, then confirm the relevant operations and implementation restrictions with the vendor. A general standards label cannot settle your specific workflow.
Separate capability from permission. SMART App Launch scopes describe requested access; the authorization server decides what is granted. The logged-in user, selected patient context and local policies can constrain that access further. Technical support for an operation is not permission for every app or user to perform it.
Test where the result lands.
Use synthetic patients and the destination system’s test environment. Reproduce the staff task with the intended role, workflow configuration and permissions. A developer account with broad access can hide the exact restriction that will stop reception or care coordination.
- Resolve the patient
Match approved identifiers; route ambiguity to a person.
- Prepare the approved record
Confirm encounter, document type and required fields.
- Submit and verify
Store the destination identifier and inspect the resulting record.
- Check the worklist
Confirm the right team can find it and continue the task.
- Resolve uncertain outcomes
Reconcile a timeout before submitting the same record again.
Check meaning as well as presence. Is the referral attached to the intended encounter? Did the status survive? Can the receiving role see it? Did a document land as an attachment when the workflow needed structured fields? A successful response can still leave the staff task incomplete.
Include a changed appointment, an ambiguous patient match, missing required data, a rejected write and a lost acknowledgment after submission. Record who investigates each exception. Do not automatically repeat a write just because the caller timed out; first establish whether the destination already accepted it.
Choose the connection after measuring the work.
Prefer supported interfaces that cover the required workflow. Depending on the system, that may involve APIs, an existing interface engine, approved messages or a supported document route. Confirm licensing, onboarding, test access and operational ownership before estimating delivery.
Screen automation may fit some permitted, low-volume tasks, but it adds dependencies on layout, session state and UI timing. One vendor account describes recommending an API instead of its own screen-driving agents for a high-volume write request. Volume and required behavior should choose the approach.
Compare the staff’s complete task before and after the pilot, including checks and recovery. If every exception now needs an engineer, the work may simply have moved. Count confirmed completions, unresolved items and staff intervention time; retain an audit trail without exposing patient details in general application logs.
- Each required read and write is supported and authorized.
- Synthetic tests use the intended staff role and workflow.
- Patient, encounter, fields and destination visibility are verified.
- Ambiguous matches and uncertain writes have a named recovery owner.
- Staff can complete the task without an undocumented copying step.
Questions we hear
Does FHIR support guarantee write access?
No. Confirm the server’s supported operations and the access actually granted to your app and user.
Is a sandbox demonstration enough?
It proves that test setup. Recheck approved configuration, permissions and workflow behavior before relying on the live integration.
Should we replace an EHR with limited APIs?
First identify the missing task and supported alternatives. A replacement is a separate operational decision, not the automatic consequence of one unavailable endpoint.
Sources
- API access with incomplete workflow coverageLinkedIn practitioner discussion, 15 September 2026
- CapabilityStatement in FHIR R4HL7
- SMART App Launch scopes and launch contextHL7
- Choosing an API for a high-volume EHR write workloadLinkedIn practitioner discussion, 6 October 2026