EHR software development: add AI without breaking workflows

01What EHR software development involves today

An EHR, EMR or practice management product is now judged as much on how cleanly it exchanges data as on its screens. Four standards and rules shape most roadmaps.

FHIR as the data contract. HL7 describes FHIR as a standard for exchanging healthcare information electronically, where all exchangeable content is defined as a resource, and a CapabilityStatement describes the interfaces an implementation exposes. Your internal schema can look like anything, but Patient, Encounter and Observation data should map cleanly to FHIR resources.

SMART on FHIR for app access. The SMART App Launch guide defines OAuth 2.0 based patterns that authorize a user-facing app to connect to a FHIR server, with scopes such as user/Encounter.rs that limit an app to the records its user can already see, and a launch context that tells the app which patient is open. The project behind it describes the goal as substitutable healthcare applications, which is a useful test: could a clinic swap your app for another without rewiring its EHR?

ONC certification and USCDI. The ONC Health IT Certification Program is voluntary, but CMS Promoting Interoperability programs still require certified health IT, so most EHR vendors selling to U.S. providers treat it as table stakes. The standardized API criterion, 170.315(g)(10), expects FHIR R4 with US Core, SMART App Launch for authorization, Bulk Data for multi-patient export, and data that covers the USCDI, a standardized set of health data classes and elements that ONC revises in published versions.

Information blocking. ONC describes information blocking as a practice by an actor that is likely to interfere with the access, exchange or use of electronic health information, and health IT developers of certified health IT are among those actors. Exceptions are set out in 45 CFR Part 171. If your AI feature stores generated notes or summaries in a place that patients and other systems cannot reach, ask your counsel whether that content is electronic health information before you decide where it lives.

02Three ways to add AI to an EHR

The architecture decision comes before any prompt, because it fixes who owns identity, data access and the screen. We see three patterns.

If you own the EHR, building inside it gives you the most context and the least friction, but every customer receives the feature at once, so feature flags and per-tenant settings matter from day one. A SMART app is the right answer when your buyers run EHRs from other vendors and you are not the record system. The service-beside pattern is underrated: intake summaries, prior history pulls and coding suggestions often do better as a background service that posts a draft into the chart than as a new screen a busy physician has to find.

Many products pair a background service with a small review panel. Our piece on AI data integration covers the feed side.

03Identity, roles and audit logs come first

Every AI call that touches a chart should carry the identity of the person it is helping. A single service account that reads every patient is quick to build and very hard to defend. The HIPAA Security Rule asks for access control, audit controls and person or entity authentication: access only for persons or software programs that have been granted access rights, and mechanisms that record and examine activity in systems that contain electronic protected health information.

In practice, that means:

• Delegated access. SMART scopes or a token derived from the user's session, so the model sees only the patients and record types the clinician can see.
• Role rules in the backend. A front desk user and a physician should get different AI features, enforced by your API rather than by a line in a prompt.
• An audit event for every AI step. Who asked, which patient, which source records were read, which model and prompt version ran, what was drafted, and who accepted, edited or rejected it. Our article on building an AI audit trail goes through the fields we log.
• Tenant separation. In a multi-clinic product, one clinic's data must never appear in another clinic's context window, cache or evaluation set.

04PHI handling and BAAs for AI features

Every vendor in the AI path that creates, receives, maintains or transmits PHI on your behalf is a candidate business associate. HIPAA lets a covered entity disclose PHI to a business associate once it has satisfactory assurance, documented in a written contract or agreement, that the information will be appropriately safeguarded. For an AI feature, that list usually includes the model provider, the speech-to-text provider, the cloud host, and any logging or tracing service that might capture prompts.

Two design habits reduce the surface:

1. 01

   Send the minimum.

   Strip names, birth dates and other direct identifiers before a model call when the task does not need them, and replace them with an internal ID you can map back after the response.

2. 02

   Keep prompts and outputs out of general logs.

   A trace that holds a transcript is PHI and needs the same controls as the chart.

Our guide to HIPAA and AI covers vendor choice and retention. Where a rule decides whether you can ship, confirm it with your own counsel.

05Clinician-in-the-loop documentation, coding, intake and scheduling

The AI features that hold up in clinics share one shape: the model prepares, a person with the right role approves, and only the approved version enters the record.

• Documentation. Transcribe the visit, pull relevant history through FHIR or your own API, draft the note in the template the clinic already uses, and show it beside the source so the clinician can edit quickly. Keep version history. Our article on how much time AI clinical documentation saves looks at where the time actually comes back.
• Coding suggestions. Suggest codes with the sentence in the note that supports each one, and let the coder or clinician accept them one at a time. Never auto-submit a claim from a model output.
• Intake. Ask adaptive follow-up questions, accept voice and tap answers, and turn them into a structured summary the physician reads before walking in. The summary describes; it does not diagnose.
• Scheduling. Use AI to read referral documents and intake answers and propose the right visit type, provider and duration, then let staff confirm. The booking itself goes through your existing scheduling rules.

Each review screen should make rejection as easy as acceptance. Our piece on human-in-the-loop AI covers where to place the approval step and how to measure whether reviewers are actually reading.

06Testing with real but de-identified cases

Real charts have copied-forward notes, conflicting medication lists and specialty abbreviations that demo patients never show. A test set should be built from real cases, de-identified first. HIPAA recognizes two methods of de-identification: expert determination, where a qualified person finds that the risk of identification is very small, and safe harbor, where 18 listed identifier types are removed and the entity has no actual knowledge that the rest could identify someone.

We build an evaluation set for each feature, covering the common visit types and the awkward ones, have clinicians score drafts against what they would have written, and rerun the set on every prompt or model change. A version that scores worse on a case clinicians flagged as important does not ship, even if the average improves.

07What we see in production

MIRA, an AI patient intake product founded by a practicing pain clinician, wanted each patient's full pain history collected before the visit. We built an adaptive intake where follow-up questions change with earlier answers, offered common medication doses and intervals as choices, and let patients answer by tap or by voice, with Whisper transcribing spoken answers into the same flow. GPT writes a structured summary for the physician that does not diagnose. No patient names or birth dates are stored, only a generic ID per intake, and the first version ran as three separate Azure deployments, one per practice.

When MIRA moved to a product clinics could sign up for, the first version had physician logins set in code and no multi-tenant database. We kept the intake flow that already worked and rebuilt the backend beneath it: self-service clinic sign-up, billing per provider, three roles with each clinic isolated from the others, and removal of patient names and birth dates before any call to OpenAI. It was built to HIPAA practice, with the client holding the BAA and the third-party audit. Sending notes into EMR systems is listed as a next step, which is where the architecture choices above come in.

For a dental clinical documentation AI company, appointment audio is transcribed during the visit, the patient's history is pulled from the practice's records system as context, and a structured draft is ready for the dentist to edit, override and approve on a review screen with version history. No note is released before the dentist approves it.

If you know which outcome you want first, a three-week Build Sprint for $10,000 puts that one outcome working in your product's staging environment, and the fee counts toward production. If you are not sure what to build first, the two-week Planning Sprint ranks the options for $5,000. More of our healthcare work is on the industry page.

Frequently asked questions