Reading from an EHR is easy. Writing back is the project
Connecting to an EHR is two projects: reading patient data is usually open through FHIR, while writing back needs each vendor's approval.
Key takeaways
5 things that decide this
- 01Connecting to Epic, athenahealth or eClinicalWorks is two projects: reading patient data is usually available through standard FHIR APIs, while writing appointments or notes back depends on each vendor's approval and scope.
- 02Certified EHRs have to offer a standardized FHIR API for reading patient data. That is the floor you can plan on.
- 03Writing back is different. Which records you can create, and how you get approved to do it, is set by each EHR vendor and each clinic.
- 04Put a human check before any write. An AI result that a person reviews is safer than one that lands in the chart on its own.
- 05A read-only first release can ship value while write approval is still pending. Plan the project in that order.
What does "connects to Epic" actually mean?
When you ask a vendor whether their AI tool connects to Epic, athenahealth or eClinicalWorks, you will almost always hear yes. That answer hides two very different questions. Can the tool read from your EHR? And can it write back into it?
Reading means pulling a patient's demographics, appointments, problems, medications or past notes into another tool. Writing means creating or changing something in the EHR: booking an appointment, filing a note, adding a charge, updating a contact.
Most of the cost and the risk in an EHR project sits on the write side. If you scope the work as one thing, the read half gets done quickly, and the write half turns into months of waiting on approvals nobody planned for.
Why is reading from a certified EHR usually available?
In the United States, EHRs certified under the ONC Health IT Certification Program have to meet criterion 170.315(g)(10), which covers a standardized API for patient and population services. In practice that API uses FHIR, a common format for health records. It's why a read-only connection to a certified EHR is usually something you can plan on, not something you have to negotiate from scratch.
That doesn't make reading trivial. You still register an app, handle patient or clinic authorization, map the FHIR resources to what your tool needs, and deal with the gaps between what the standard defines and what a given clinic has actually filled in. But the path exists, it's documented, and it looks broadly similar across Epic, athenahealth and eClinicalWorks.
For a lot of clinic tools, read is enough to start. An assistant that can see tomorrow's schedule, a patient's last visit and their open referrals can prepare a front-desk call or a pre-visit summary without writing anything back.
Why is writing back scoped vendor by vendor?
Writing is where every EHR vendor sets its own rules. Which resources can an outside app create? And which need a clinician's sign-off? Which are open to any registered developer, and which need a commercial agreement, a review, or a listing in the vendor's own program? The answers differ between Epic, athenahealth and eClinicalWorks, and they can differ between two clinics on the same EHR.
That is why we treat write access as its own workstream. Before we quote a build, we confirm which writes the tool needs, which of those the vendor allows, and what approval each one needs. Our page on what a real Epic integration involves goes through that process for Epic. We don't claim a listing in any EHR vendor's marketplace, and you should ask any vendor who does to show you the listing.
If a vendor tells you their AI tool "writes to the chart" without naming the API, the approval and the records it touches, ask again. That one answer tells you most of what you need to know about the project.
- 01Name each write the tool needs: appointment, note, charge, task, patient contact.
- 02For each one, find the vendor's API for it and the approval it needs.
- 03Decide who reviews the write before it lands, and how that review is logged.
Where should the human check go?
Put the human check before the write, not after it. Once an AI-drafted note or a booked appointment is in the EHR, other systems and other people start acting on it. Catching a mistake after that point means unwinding it in several places.
We built TrialTriage around this rule. It ranks clinical trials for oncology patients, and a nurse reviews and finalizes every result. In the published case study's words, the nurse signs off and the record moves forward with an audit entry, not a raw AI output. The platform tracks 23 audit action types, so every step from ranking to sign-off can be traced later.
An EHR write fits the same pattern. The AI drafts the appointment, the note or the charge. A person on your team reviews it in a queue. Only the approved version is written to the EHR, and the log records who approved it and when. For charting in particular, our page on what an AI medical scribe needs to chart into your EHR covers the review step in detail.
Where should integration calls run?
EHR credentials and tokens should never sit in a browser. Every call to the EHR, and to any other service that touches patient data, should run on the server, where secrets can be stored and access can be logged.
In Algoricum, the clinic lead platform we built, calls to NexHealth and other outside services like Stripe, Twilio, Mailgun and OpenAI all run in serverless functions. Roles and per-route permissions live in the database, and every record is keyed to the clinic's workspace. That isn't an EHR write, but it's the same shape an EHR integration needs: secrets off the browser, and every call tied to a clinic and a role.
Should the first release read only?
Often, yes. A read-only first release can ship real value while write approval is still in progress. Your front desk can see a prepared summary before every call. Your clinicians can see an AI draft beside the chart and copy what they approve. Nobody waits on a vendor review to start using the tool.
The cost is a manual step. Until write access is approved, someone still moves the approved result into the EHR by hand. That's slower, but it's honest, and it gives you weeks of real use to tune the AI before it writes anything on its own. When write access arrives, the review queue you already built becomes the step before the write.
Our EHR integration and medical clinics pages show how this fits into a wider clinic build.
How do you scope an EHR project honestly?
List every place your tool needs to read from the EHR and every place it needs to write. Mark which writes you can live without for the first release. That list is the real scope.
If you want help with it, book a 45-minute call. If it makes sense to go further, we write a fixed-fee Blueprint from your real EHR setup and workflows, credited in full against the build. If the plan isn't one you'd act on, you don't pay for it. See how we work.
FAQ
01Which development firms integrate custom tools with Epic, athenahealth or eClinicalWorks?+
Hashlogics builds custom clinic tools that read from Epic, athenahealth or eClinicalWorks through their FHIR APIs and write back where the vendor approves it. We scope read and write as separate workstreams, put a human review before any write, and run every integration call on the server. The first step is a 45-minute call, then a fixed-fee Blueprint credited in full against the build.
02Is custom software better than athenahealth or eClinicalWorks for a medical clinic?+
No, and it shouldn't replace them. Your EHR stays the system of record for charts, billing and compliance. Custom software makes sense around the EHR: front-desk assistants, intake, follow-up or summaries that read from it and write back only what your team approves.
03Can an AI assistant write notes into the EHR?+
It can, if your EHR vendor lets outside apps create notes. That also depends on what approval the vendor needs and how your clinic is set up. Even where it's allowed, we put a clinician review before the write, so an AI draft never lands in the chart on its own.
Related
- EHR integration →How we connect custom tools to the EHR you already run.
- Software for medical clinics →Front-desk, intake and follow-up builds for clinics.
- Epic integration: what a real build involves →The read and write steps for Epic, in order.
- AI medical scribe: charting into your EHR →What it takes to write a note back safely.
- The EHR does 80% and people copy the rest →Where clinic staff fill the gaps by hand.
