EHR Write-Back: Why Reading Data Is Easy and Writing Is Hard

The ONC API Resource Guide says that certified services "specifically exclude write capabilities." We build the HL7 and FHIR integrations, Medplum platforms, and EHR-connected products this asymmetry lives inside, so this is the version of the story we’d give a technical co-founder.

In this article, we’ll discuss why reading is solved, and writing is not, as well as which write paths actually exist today. You’ll also see how authorization changes once you start writing, what breaks once a write pipeline hits production, and how to ship a product while write-back is still being negotiated with the health system.

Key Takeaways

• The certified EHR API covers read-only. Writing back is never part of that mandate, so every write surface is a vendor decision, and usually a per-customer one too.
• At the same time, improved care coordination results from multiple specialists writing data into a centralized EHR.
• At least six write paths exist today: FHIR create/update, HL7 v2 interfaces (as HL7 standards ensure accurate patient information exchange between systems), document attachment, in-workflow apps, vendor-proprietary APIs, and a human-in-the-loop task.
• Writing needs a named actor, a separate write scope, and usually a different authorization context than reading does. Order entry capabilities are unsupported by most AI scribes.
• Most write failures are engineering-discipline problems: idempotency, reconciliation, and provenance. EHR write-back often lacks structured problem list updates.
• No certified write mandate exists today, but ASTP/ONC has said future FHIR API work should move beyond read-only interactions.

What Is EHR Write-Back?

EHR write-back is the process of sending data from an external application into the Electronic Health Record. It becomes part of the patient’s record, instead of only being read out of it. Done well, it supports real-time data exchange between your app and the chart, not a nightly batch job. You’ll see it written both ways, EHR write-back and EHR write back; this piece uses the hyphen, but they mean the same thing.

EHR write back data exchange is just the return half of integration: data moving from your application back into the chart, not only out of it. Teams typically want to write:

• vital signs and Remote Patient Monitoring (RPM) readings, such as blood pressure readings from a connected device;
• questionnaire and assessment results;
• notes and clinical summaries;
• documents, such as a PDF report;
• orders and referrals;
• appointments;
• care plans and task updates, plus billing or practice-management line items;
• coded lab results.

Three things get confused here, and they are not the same. Writing into the chart means the value becomes a structured part of the patient’s record. Attaching a document is different: a PDF or CDA sits alongside the record without turning into a discrete data element, which is lower fidelity but far lower friction. Sending a message to a human, an inbox item, or a task someone accepts is not write-back at all; it’s a notification with a person doing the actual data entry.

Why this matters commercially: healthcare organizations don’t buy write-back for its own sake. EHR integration reduces manual entry and clinical errors. That is the actual economic case for building this instead of asking healthcare professionals to re-type patient data by hand.

Without it, the product creates work instead of removing it, and the buyer feels that in the first week of using it. The point is better patient outcomes. Nobody wants a second screen they have to double-check against the real chart. Improve patient outcomes first, and the efficiency case follows on its own.

Across the healthcare industry and the healthcare sector generally, the pattern repeats: providers want data moving both ways, not just out to the app and never back into the record.

Let's discuss your EHR needs

Contact us

Why Is Reading Data From an EHR Easy Now?

Reading is easy now because it was standardized and certified, so every certified EHR exposes the same shape of Application Programming Interface (API).

That stack is Fast Healthcare Interoperability Resources (FHIR) Release 4.0.1, the US Core Implementation Guide, SMART App Launch for authorization, and Bulk Data for population-level access. All of it is required under the ONC certification criterion at 170.315(g)(10). HealthIT.gov names this the Standardized API for patient and population services.

Newer versions are allowed in through the Standards Version Advancement Process. In the field, you may meet US Core 7.0.0 or SMART App Launch 2.0.0 instead of the original 1.0.0 baseline.

Certification also means testability: a documented CapabilityStatement, a sandbox to test against, and a predictable set of resources before you write a line of integration code.

Why Is Writing Back to an EHR Hard?

Writing is hard because nothing standardizes it. The certified API deliberately leaves write out, so every write surface is a vendor decision, and usually a per-customer decision on top of that. EHR systems from different companies rarely agree on the same write surface for the same data type. That is exactly why moving data across different healthcare systems, or even just between two systems inside the same hospital, needs a plan instead of an assumption.

No certification mandate

ONC’s API Resource Guide is explicit: certified services “specifically exclude write capabilities, where authenticated and authorized third-party applications would be able to create or modify EHI,” electronic health information. No certification criterion requires a vendor to accept writes at all.

Vendor-specific write surfaces

What one vendor accepts as a FHIR create, another only accepts as an HL7 v2 message, and a third does not accept over an API at all. EHR configurations vary, complicating write-back processes. Even within the same vendor’s own product line, one deployment’s accepted write surface can differ from another’s.

Per-customer approval

The health system decides too, not just the vendor. Epic’s own developer documentation notes that write generally needs the customer’s explicit approval before your app can use it in production.

Clinical accountability

A read has no author. A write does. Someone, a person or a named application acting for one, has to be recorded as responsible for data entering the legal record.

Reconciliation and trust

Clinicians will not accept unreviewed external data sitting in the chart next to their own notes. A write usually needs a human acceptance step designed around it from day one, not bolted on after a complaint.

Terminology and validation

Data accuracy depends on more than a valid API call. The receiving system’s data formats, units, and required fields have to match before a value is trustworthy. It enforces its own value sets to ensure compliance with its own data model, not yours. Send an unmapped Logical Observation Identifiers Names and Codes (LOINC) or Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT) code, and the write gets rejected outright.

Workflow placement

Where a value lands in the chart is a clinical design decision, and no API parameter can make that call for you. Get it wrong, and even the right data becomes invisible to the person who needed it.

Risk and the legal record

The chart is a legal document. Vendors and health systems are cautious about who can touch it, for reasons that will not be argued away by good API design.

None of this is static. The HTI-2 proposed rule was withdrawn on December 29, 2025, taking its patient-engagement and API proposals with it. A week earlier, the HTI-5 proposed rule of December 22, 2025 suggested removing 34 of the 60 certification criteria in the ONC Health IT Certification Program, while stating that future FHIR API work should “move beyond read-only interactions.” As of this writing, HTI-5 is still a proposed rule, not a final one. There is no write mandate today. The stated direction just points that way.

Which EHR Write-Back Paths Actually Exist?

Most of what teams search for as EHR write back integration comes down to one of six paths that repeat across different systems, and the honest answer to “which one” is usually two or three of them, layered.

Epic is a useful worked example because its documentation is public. It documents an Observation create for patient-facing apps, which needs OAuth authorization tied to an active portal account. For backend systems filing multiple readings, it recommends an incoming flowsheet interface instead, with no separate patient login involved.

If your first serious write path is Epic integration, expect the approval sequence described later in this piece to run in full. Epic is one of the more documented EHR vendors but still requires the customer’s own sign-off. Other vendors draw these lines differently, and you should check each one’s current documentation rather than assume.

If you’re building the HL7 v2 side of this from scratch, we cover the messaging patterns in more depth elsewhere.

For each path, weigh what it’s good for against what it costs you in approval time and portability. You’re choosing one of these for a specific customer, not browsing a menu.

How Does Authorization Change When You Write?

Reading can happen on behalf of a patient or a system with a read scope, no named human required. Writing needs a named actor, a separate write scope, and usually a different launch context altogether, and a write scope is never granted just because a read scope was.

Three contexts cover almost every write:

• Patient-facing. The person authorizes the write with their own OAuth login, and the data is marked patient-entered. Epic requires an active patient-portal account for this.
• Provider-facing, or user context. The clinician is logged in, acting inside their own session and the provider’s workflow, and is the author of record. This is the cleanest case for authorship and accountability.
• Backend, system-to-system. No human is in the loop at the moment of the write, which is why it gets the most scrutiny from the health system’s security review.

Data security here is all about who allowed to assert a new value at all, and that question sits underneath every patient engagement feature you build on top of the record. SMART on FHIR (Substitutable Medical Applications, Reusable Technologies) scopes can be resource-level or sub-resource-level. You ask for a write scope separately from a read scope; nobody grants it as a bonus.

Provenance answers who wrote a value, from which application, and when, and that record is what shows up if anyone ever has to explain how something got into the chart.

Epic draws the line concretely. A patient-facing write needs patient OAuth plus an active portal account. A backend system filing multiple readings at once uses an incoming flowsheet interface instead, with no separate patient login involved. Other vendors draw that same line in a different place, so check the vendor’s current documentation before you design around it.

Who Accepts the Data Once You Have Written It?

Usually a clinician, and the acceptance step is part of the product, not an afterthought bolted on after launch. Healthcare providers won’t trust a write they can’t see reviewed.

Where external data lands

External writes usually land in a patient-entered or unverified area of the chart first, not straight into the clinical flowsheet a clinician trusts by default.

The reconciliation step

Someone compares the new value against what’s already there, whether that’s a person clicking accept or a rules engine flagging outliers for review.

Signing and authorship

An accepted value gets signed, and that signature is what turns “data we received” into “data the record now asserts.” Skip this step, and you have a data dump, not a chart entry.

What shows in chart review

A clinician scanning the chart needs to see where a value came from at a glance, without opening a separate audit log to find out.

The risk of adding noise

Every write you enable is one more thing a clinician has to clear. The value of a write is realized when someone trusts it enough to act on clinical decision-making, not when your system gets a 201 response back.

Care teams built around real clinical workflows don’t want more patient records to check by hand. Manual data entry crept in exactly because nobody trusted the alternative, and none of this saves time if the reconciliation step is an afterthought.

Authorship is the critical role no one can skip: it’s what lets a clinician reach informed decisions instead of guessing where a number came from. A clinical notes entry written by an app carries the same trust problem as a vitals reading: something has to vouch for it before anyone treats it as fact. Write-back exists to serve care coordination, and coordinated care only works when every clinician is looking at the same record, with patient care decisions made on data someone actually reviewed.

Before you build, ask the customer’s clinical informatics team:

• Where in the chart should this data type land, and who reviews it before it’s part of the record?
• What counts as an outlier that needs a human look first?
• Who is the author of record when the source is a device or an app, not a person?
• What happens to a rejected or unreconciled value: does it disappear, or does someone see it later?

What Breaks in Production?

The predictable failures, and they are predictable, come from treating a write pipeline like a read pipeline with the arrow reversed, even though it now carries critical data instead of a read-only copy.

Good data integration work assumes that from day one, instead of hoping operational data and patient information stay in sync on their own. The fix for all ten failure modes above is the same discipline a payment pipeline already needs. Write an audit record for every attempt, and reconcile what you sent against what actually shows up. Alert on the difference instead of waiting for someone to notice a missing value.

In our own delivery work, we built a Medplum-based preventive-care platform for early cancer detection. It integrates bi-directionally with Health Gorilla, retrieving external records and placing lab orders rather than only reading a feed.

Two-way exchange like that only stays trustworthy with the same discipline: every attempt logged, and a standing way to check what you sent against what the other side actually shows. If you’re planning a similar build, our Medplum for healthcare systems integrations guide covers the platform in more depth.

Need a custom EHR or EMR alongside the portal?

Custom EHR/EMR Development

What Does It Take to Get Write Access Enabled?

A sequence of approvals, not a single API key. Register with the vendor’s developer program, build against the sandbox, pass the vendor’s review, then get the health system’s own approval and integration-team time.

1. Vendor developer-program registration and sandbox build. Slowed by how complete your documentation and use case are.
2. Vendor technical review. Slowed by security review on their side, especially for anything backend or bulk.
3. Health system approval. Slowed by the customer’s own change-control calendar, which usually runs on a schedule you don’t control.
4. Interface-engine work on the customer’s side. Slowed by how busy their integration team already is with other vendors.
5. A test environment that actually mirrors production. Slowed by whether the customer maintains one at all.
6. Validation with clinical stakeholders. Slowed by getting the right clinicians in a room, not by anything technical.

The health system’s integration team is a shared, scarce resource, and that, not your code, is usually the critical path. Every one of those steps is an operational cost you should put in the statement of work, not a line the client discovers in month four. No fixed timeline survives contact with someone else’s change-control calendar; plan around the variables instead.

Let’s solve your healthcare tech challenges together

Check our healthcare IT consulting services

Learn more

How Do You Design a Product When Write-Back Is Not Available Yet?

Treat write-back as a capability that varies per customer, and make the product degrade cleanly instead of assuming it will be there on day one. Healthcare teams don’t want a worse patient experience bolted onto a better backend, so the interface has to say plainly what reached the chart and what didn’t.

• Ship the document write first, and add the structured write later, once a customer’s approval clears.

• Make the write path a configurable adapter per customer, not an if-statement buried in the code.

• Keep a queue with replay, so turning a customer on doesn’t require a manual backfill scramble.

• Expose the state honestly in your own UI, so users know exactly what reached the chart and what didn’t.

• Scope write-back as a named phase in the contract, not an assumption baked into the price.

A simple capability matrix, one row per customer with which paths are enabled, which resources, and which authorization model applies, keeps this from becoming folklore that only one engineer remembers.

None of this is complicated to build. It’s a plumbing job, done well or done badly, so EHR data reaches billing tools, advanced analytics, and every other place a health system actually pipes it. Get the plumbing right, and that same data turns into actionable insights for the analytics team instead of a spreadsheet nobody trusts; get it wrong, and no dashboard downstream fixes it.

Done well, you improve operational efficiency: fewer duplicate entries and fewer late reconciliations. Clinicians often spend 2–4 minutes on manual updates per encounter, so you can save time.

That’s the practical relationship between write back and Electronic Health Record system design: plan for the gap, and the gap stops being a surprise.

Our Expertise

We work as a healthcare software development company on different solutions and tasks: HL7 and FHIR integration, EHR and EMR platform work, and Medplum builds. That includes the queue-and-reconcile discipline a write pipeline actually needs.

We’re CREST-accredited for security work, follow ISO 27001-aligned engineering practices, and have delivered 200+ projects over 11+ years, including HealthTech clients whose builds depend on exactly this kind of integration. We've helped our clients ahcieve seamless interoperability, get features for data driven decisions, and seamlessly write data.

Our cases

Our healthcare delivery work spans both sides of the data problem: building the systems that hold patient data, and proving they hold up under scrutiny. For MHC Healthcare, a personal-injury rehabilitation provider, we've spent over a decade building and maintaining a HIPAA-compliant EMR portal that handles secure medical-data exchange between the provider and its patients.

For Unumed, a cloud-native hospital management system running across Africa, Southeast Asia, and Central America, our work was security-focused. We ran a full penetration test against the platform and helped bring it into, and keep it at, ISO 27001 compliance.

That combination, build and break, is why we can speak to write-back with some authority. A write path only earns a health system's trust once it's been tested the way an attacker would test it, and these two engagements are the same discipline applied to different halves of the problem: one client needed the portal built right, the other needed proof that what was already built could withstand pressure.

Preventive Care Platform with Medplum

Learn more

Final Thoughts

90+ EHR systems can integrate data in real-time using FHIR API. Reading from an EHR is standardized. Writing to one is negotiated, path by path, vendor by vendor, customer by customer. We recommend choosing the write path that fits each customer, and designing the human acceptance step before you design the API call. You can also instrument every attempt the way a payment pipeline instruments every transaction. Modernizing this without disrupting healthcare delivery is the actual job.

Patient engagement is enhanced when patients know their data updates the EHR directly. In a [2026 Statista survey] of 100 HL7 affiliates and national standards bodies across 63 countries(https://www.statista.com/statistics/1659603/fhir-use-forecast-worldwide), most respondents expect FHIR adoption in their own country to increase sharply in the coming years, and in a companion survey of teams with a working FHIR implementation, the most common achievement they named was improved access to information, not a bigger EHR.

Regulators have already signaled where the write side of that story goes next; today’s certified API still stops at read. That’s the practical difference between write back and EHR system design done right: plan for the negotiation instead of assuming an API key ends it.

Let's discuss your EHR project needs!

Contact us

FAQ

What is EHR write-back?

EHR write-back is the process of sending data from an external application into the Electronic Health Record, such as a vital-sign reading, a note, or an order, so it becomes part of the patient’s record instead of only being read out of it.

Can you write data to an EHR using FHIR?

Yes, for the specific resources and vendors that support it. Epic, for example, documents an Observation create for patient-facing apps, but this capability is vendor-specific and usually needs the health system’s separate approval. FHIR create and update are not part of the certified read-only API every EHR must expose.

Why do certified EHR APIs only support reading data?

Certified EHR APIs only support reading data because the ONC certification criterion at 170.315(g)(10) specifically excludes write capabilities from what a certified service has to provide. A vendor can choose to support write beyond that requirement, but nothing in certification mandates it.

What is the difference between HL7 v2 and FHIR for writing data?

HL7 v2 messages, such as ORU^R01 result messages or MDM^T02 document messages, remain the highest-volume way to write into an EHR, especially for backend systems filing multiple readings at once. FHIR create and update calls are more modern and resource-specific, but vendor support for writing over FHIR is far less consistent than for HL7 v2 interfaces.

Do you need vendor approval to write to an EHR?

Yes, and usually customer approval on top of that. A vendor’s developer program controls which write capabilities exist at all, while the health system using that EHR separately decides whether your specific application gets to use them.

Where does data written by an external app appear in the chart?

Data written by an external app usually appears in a patient-entered or unverified area of the chart first, not directly in the clinical flowsheet a clinician trusts by default. A reconciliation step, whether a person accepting the value or a rules engine flagging outliers, is what moves it into the record clinicians and patients can both rely on.