Build Your Own EHR in the Age of AI: Who Is Responsible for What's Missing?

AI coding tools make building your own electronic health record feel more achievable. Describe a calendar, a patient chart, or a documentation screen, and a coding agent can help turn that request into working software.

For a clinician frustrated with an existing EHR, that possibility is appealing. You know your workflow. You know which clicks waste time. Why not build a system around the way you actually practice?

The question deserves a serious answer. But writing the software is only part of building an EHR. Someone must also know what the system needs, verify that it works, and accept responsibility for operating it.

A convincing demo can leave important questions unanswered

Earlier this year, a dermatology clinic I work with asked me to look at an EHR someone they knew was building with AI coding tools.

Visually, it looked good. It had an impressive calendar, and users could write a clinical note. The developer had started with another software platform, rather than building every component from scratch.

Then I asked about HIPAA compliance. The builder could not explain how those requirements were being addressed. When I asked about ONC requirements, those were not on his radar either.

That conversation did not establish every capability the application had or lacked. It did reveal a gap between what the demo could show and what the builder had considered.

A calendar and a note editor are useful accomplishments. They do not establish that a system is ready for patient care.

This is a pattern worth understanding before you commit to building. The same gap shows up in EHR evaluations generally — a demo that looks smooth in a controlled setting can hide workflow problems that only surface when real patients arrive.

AI can build the scaffolding

I use AI coding tools in my own work. They can help establish a project's structure, generate code, and accelerate development.

I describe that early output as scaffolding.

Even when I provide a framework and work through a plan, I still find gaps between the generated application and a finished product. Recognizing those gaps requires knowing what the finished product must do.

An AI tool may suggest requirements, but asking it to research everything does not verify that its list is complete or that its implementation is correct. Requirements can be misunderstood, controls can be incomplete, and a feature can work in a demonstration while failing under real conditions.

If the person directing the work does not recognize an omission, it may remain in the system.

In healthcare, those omissions can affect privacy, clinical work, payment, and the availability of patient records.

First responsibility: determine which rules apply

Healthcare requirements depend on the organization, the services it provides, the information it handles, and the programs in which it participates.

For organizations subject to HIPAA, the Security Rule addresses administrative, physical, and technical safeguards for electronic protected health information. A software feature alone cannot establish that the organization is meeting those obligations. Risk analysis, policies, workforce practices, and appropriate security measures also matter.[1]

ONC certification is a separate issue. The certification program is voluntary, but certain other programs require the use of certified health IT. The relevant question is whether the practice's participation or contractual requirements call for certified technology — not whether every EHR must carry the same certification.[2]

Before development proceeds, someone needs to identify the applicable obligations and translate them into requirements that can be tested.

Who can access a chart? How is access removed when someone leaves? How are records protected, recovered, and made available when needed? Which changes require another review?

These decisions belong in the design from the beginning. Adding a "compliance" page at the end does not resolve them.

Second responsibility: make outside communication work

An EHR operates within a larger healthcare environment. Depending on the practice, it may need to communicate with clearinghouses, laboratories, prior authorization services, and other providers through tools such as Direct secure messaging.

Each connection can become a substantial project.

Consider a laboratory interface. Sending an order is one step. The practice also needs a reliable process for receiving results, matching them to the correct patient and order, and getting them to the person responsible for review. Unmatched or failed messages need a visible path to resolution.

A clearinghouse connection raises similar operational questions. Was the claim received? Was it rejected? Can the billing team identify the problem and correct it?

Prior authorization workflows need to account for requests, supporting information, responses, and follow-up. Secure messaging needs to fit how the practice sends, receives, and handles clinical information.

These connections involve external organizations, their technical requirements, enrollment processes, testing, and ongoing changes. AI-generated code is one contribution to that work. It does not establish that the other organization has accepted the connection or that the complete workflow succeeds.

A button labeled "Send" is a beginning. The practice needs to know what happened afterward.

This is also where practices that skip implementation planning tend to lose revenue before they ever open. The revenue loss that starts before a clinic sees its first patient often traces back to exactly these integration gaps — billing connections that were never tested end-to-end.

Third responsibility: make activity auditable

Auditing deserves attention before the first patient record enters the system.

For HIPAA-regulated organizations, the Security Rule requires mechanisms to record and examine activity in systems containing or using electronic protected health information, along with procedures for regular review of information system activity.[3]

Operationally, the practice should be able to investigate questions such as who accessed a record, when an action occurred, and what changes were made. The relevant activity must be captured, protected, and retrievable by authorized people.

A log that exists but cannot be searched effectively may be of little help during an investigation. The team also needs a process for reviewing activity and responding to concerns.

A privacy investigation and a payer documentation audit are different reviews. Missing evidence does not automatically mean the same penalty or repayment in every case. It does, however, make it harder to explain and support what happened.

Start with a foundation built for healthcare

For a clinician building an EHR for their own practice, my recommendation is to begin with an established healthcare platform, such as OpenEMR, and evaluate how it fits the practice's needs.

A general application platform may provide useful calendars, forms, and databases. An EHR platform provides a foundation developed around healthcare work. That gives the project an existing body of functionality to assess and extend.

It is still necessary to review the selected version, configuration, integrations, and proposed customizations. Starting with an established platform does not automatically make a deployment compliant or every modification safe.

It does give you a more substantial starting point than recreating the entire system while also learning what belongs in it.

AI can then help develop custom forms, improve workflows, and build additional features under qualified review.

If you want to understand what a managed OpenEMR deployment looks like in practice — including how compliance, integrations, and customization are handled — the managed OpenEMR service page covers how we approach that work for independent practices.

Someone still has to own the result

Do AI tools mean you no longer need a software developer?

They may change how much coding a project requires and how the work is divided. They do not remove the need for people who can evaluate the architecture, review security, test integrations, validate clinical workflows, and maintain the result.

Those responsibilities may be shared among clinicians, developers, compliance specialists, and service providers. They need clear ownership.

When a laboratory result fails to reach the right person, patient records cannot be restored, or access history cannot be explained, the practice needs someone who can investigate and respond. "The AI built it" does not answer that need.

This is also why the EHR implementation process should start with workflow, not software. Knowing how your practice actually operates — before a single line of code is written — is what makes the difference between a system that fits and one that creates new problems.

Building your own EHR should begin with a practical question: Who will know what is missing, verify that it works, and be responsible for it after the practice starts using it?

If you want an EHR built around your workflow, start by discussing your clinical needs, required connections, and operational responsibilities. That discovery work gives AI-assisted development a direction — and gives your practice a foundation it can depend on.

Our features page shows what a purpose-built, customizable EHR looks like when those responsibilities are handled from the start. If you want to see it in action before committing, request a software demo — no sales call required.

---

Sources

1. HHS: Summary of the HIPAA Security Rule
2. ONC: About the Health IT Certification Program
3. HHS: HIPAA Audit Protocol