Hi all,
I scribed for a few years before getting into software, first in family medicine, then at an orthopedic clinic. As a scribe, my value wasn’t that I typed quickly. I helped the doctor by easing the cognitive burden of recalling a visit, and then translating it into the right parts of the chart. Everything I wrote went to the doctor to review first and sign before it was finalized. I kept this in mind when thinking about speech and AI-based solutions.
I’ve noticed most of the discussions here have been around dictation. There was Dragon and DeepSpeech years ago, and more recently the speech-to-text in the SOAP and LBF forms. With dictation, the doctor is still the author. In contrast, an ambient scribe listens to the full encounter. It takes the first pass at actually documenting and updating the patient chart. This is both a bigger help and a bigger trust problem. Temi B described this in What would make documentation easier. The scribe listens to the conversation and automatically fills the appropriate forms. Anything uncertain gets dropped into a textbox for the provider to place. This is similar to what I have been building.
My project is called EMRgent AI. You connect with your OpenEMR account, record a visit, and the agent proposes the chart work. It scans the recording and automatically documents visit notes, vitals, problem list and medication reconciliation, referrals, follow-up appointment, and sends a visit summary to the patient portal. Every write is gated behind an approval card showing the exact fields. The model reads whatever it needs. It can’t write until reviewed and approved by the doctor.
Demo you can click, no install:
Source:
The demo runs against a mock OpenEMR with synthetic patients, so you can continue as a guest and run a full session start to finish. There’s a “use demo recording” button if you don’t want to bother with a microphone.
To see EMRgent AI in action against your own data, go to the settings page. Here, you can configure your OpenEMR server URL, client id, client secret, and connect. Note: please use a test instance rather than a live one. It’s not yet ready for real PHI (audio and transcripts currently go to a third-party model provider, rather than local).
I’m not selling anything. It’s AGPL. I’m posting purely for feedback and critique. This picks up from the voice-to-text thread, where others have been working on the dictation side, and governance questions Harley raised in AI use in OpenEMR.
How it talks to OpenEMR
It’s a standalone web app rather than a module. It uses the standard REST API over OAuth2, registering as an OIDC client. Calls carry the signed-in user’s own token and inherit that user’s permissions. Connection details (OpenEMR server URL, client ID, encrypted secret) live per user. This means that EMRgent AI can serve people running entirely different OpenEMR servers. This is most of my answer to the identity and access questions raised in Generic OIDC Login and AI Integration. It doesn’t solve auditability, since the writes trace to the user rather than the agent. I’m interested in hearing people’s thoughts on this. Would also like to hear thoughts about shipping as a module vs. standalone.
What I’d most like from this community
Does the chart output look right to people who use OpenEMR daily? I scribed in a different system, so I’ve probably made assumptions about the encounter and problem-list model that don’t match real practice. Billing codes and orders are the two gaps I already know about.
Thanks for reading, and thanks for OpenEMR. Having a real EMR with a real API I could stand up locally is the only reason one person could build this at all.