Skip to main content

An EHR That Teaches: Building an AI-Powered Clinical Learning Environment with Medplum

· 10 min read
Paulius Mui, MD
CEO, Distillemr
Misha Manulis
CTO, Distillemr

Building an open-source, AI-enabled clinical learning environment with Medplum and PhenoML​

Electronic health records were designed primarily to support patient care, documentation, and billing. But what would an EHR look like if we designed it specifically for teaching? We’ve been thinking and writing about this topic for years. That's the question we set out to explore with this project.

As a family physician who has spent time working on both clinical education and EHR development, I've long been interested in how technology can help clinicians become better at their craft. We spend years teaching medical students and residents how to gather information, develop differential diagnoses, and make clinical decisions. Yet the software they use every day rarely makes that reasoning visible.

Most EHRs capture what a clinician documents or orders, but very little about why they made those decisions. We wanted to experiment with something different: an EHR that makes it easy to work with clinical information, captures the thinking behind decisions, and provides feedback that helps clinicians learn. Using Medplum as our FHIR-based backend and PhenoML to translate natural language into structured clinical information, we built an early prototype of an AI-enabled EHR designed around clinical education. And we've made it open-source so others can explore, build on, and improve it.

Starting with a blank canvas

One of our first design decisions was to rethink the interface itself. Rather than replicate the dense screens, nested menus, and rigid forms of traditional EHRs, we took inspiration from Google Docs. The interface is organized around simple, navigable pages representing familiar parts of a patient chart: medications, allergies, vital signs, laboratory results, conditions, medical history, encounters, and more.

Clinicians can navigate between these pages much like they would navigate between sections of a document. A persistent patient summary, which we call the "one-liner," provides a quick reminder of who the patient is, including relevant medical history and even personal details that matter to their care.

Behind this simplified interface, Medplum manages the underlying clinical data using FHIR resources. Creating a patient in our application creates a corresponding patient record in Medplum. Adding medications, conditions, observations, orders, appointments, and tasks similarly updates the underlying structured record. This separation lets us experiment with the clinician experience without having to build the underlying healthcare data infrastructure from scratch.

Making structured data entry feel like writing

One of the biggest frustrations with traditional EHRs is the amount of effort required to enter structured information. A clinician may know exactly what they want to document, but still need to navigate multiple fields, dropdowns, and search interfaces to enter it. We wanted to see whether natural language could replace much of that interaction. Our prototype includes an AI-enabled action panel that interprets free-text clinical instructions and translates them into structured data.

  • For example, a user can type:
  • "Metoprolol — hives" to record a medication allergy and its associated reaction.
  • "Brother had a heart attack at age 55" to populate family history fields.
  • "Smokes one pack per week" to document tobacco use.
  • "Order CBC" to prepare a laboratory order.
  • "Refer to cardiology" to create a referral.

The system interprets the request, presents an appropriate structured entry for confirmation, and saves the information to the patient chart. We also experimented with more complex entries, such as capturing a patient's goals of care or identifying members of the care team and their roles. What makes this possible is our integration with PhenoML, which helps translate natural-language clinical instructions into structured FHIR resources.

Rather than requiring us to manually map every possible user input to the appropriate FHIR resource, field, and terminology, PhenoML handles much of that translation. A clinician can express what they want to document or order in plain language, review the structured result, and confirm it. Medplum then serves as the underlying FHIR data platform, allowing that information to be stored and retrieved in a standardized format. Together, Medplum and PhenoML let us combine the flexibility of natural-language interaction with the interoperability of structured clinical data.

The important design principle is that clinicians should be able to express clinical information naturally, while the software handles much of the work of structuring it. AI isn't replacing structured data here. It's making structured data easier to create.

Capturing clinical reasoning, not just clinical facts

Perhaps the most important educational feature is also one of the simplest. Every section of the chart has an optional notes panel. While the structured part of the chart records clinical information, this separate space allows learners to document what they're thinking about that information. For example, while reviewing a patient's laboratory results, a learner might write:

  • "I'm concerned that these findings could represent an evolving kidney injury, but I need to review the medication list and prior creatinine values."
  • Or, while placing an imaging order: "I'm considering intracranial pathology because of the new headache pattern and associated neurological symptoms."

Clinical Reasoning Notes

These notes don't need to fit into a particular diagnostic or billing field. They're a scratchpad for clinical reasoning.

We also added browser-based speech transcription so learners can talk through their thinking instead of typing everything. This creates an interesting educational opportunity. In traditional clinical training, preceptors often have to reconstruct a learner's reasoning by asking questions after the encounter. If learners can capture their thought process while reviewing a chart, educators can better understand how they interpreted the available information and arrived at a decision. The goal isn't to create more documentation. It's to make the reasoning process easier to observe and discuss.

Closing the loop with AI-generated feedback

Capturing clinical reasoning is only half of the equation. The other half is providing meaningful feedback. To explore this, we integrated our clinical chart review technology from Distillemr directly into the encounter workflow. After documenting a simulated clinical encounter, a learner can request a chart review.

The system evaluates the encounter and generates educational feedback across several dimensions of clinical care, including diagnosis and clinical reasoning, diagnostic workup, treatment decisions, and follow-up planning. In our demonstration, we deliberately included an inappropriate treatment choice in a simulated encounter. The review identified the concern and provided feedback about what the clinician should consider instead.

Chart Feedback

This begins to approximate an experience that has traditionally required substantial faculty time: having an experienced clinician review an encounter and explain where the learner's reasoning or management could be improved. Of course, AI-generated feedback isn't infallible and should not be treated as a substitute for clinical supervision. But it introduces the possibility of giving learners more frequent, individualized feedback than is feasible through manual chart review alone.

Rather than waiting until a scheduled chart review or preceptor discussion, learners can receive formative feedback shortly after completing an encounter. And because the feedback is connected to the underlying clinical record, we can begin exploring how learning needs change across multiple encounters.

Making the chart interactive

We also wanted the EHR to serve as an interactive learning environment rather than simply a repository of information. The prototype includes a conversational interface that allows users to ask questions about the patient's chart. For example:

  • "Summarize this patient's medical history."
  • Or: "What was this patient's highest recorded blood pressure?"

Instead of manually searching through different sections, users can query the available chart information. We also built support for reusable note templates, including SOAP notes and follow-up visits, and the ability to insert chart variables directly into an encounter.

This makes it possible to bring existing clinical information into a note without repeatedly copying and pasting it. Alongside these AI-enabled features, we implemented more conventional workflows, including appointment scheduling, task creation, and patient messaging, all connected to Medplum. These features matter because our goal isn't to build a disconnected educational simulator. We're interested in whether an EHR can support familiar clinical workflows while also being optimized for teaching.

Why we built on Medplum

One of the biggest advantages of building on Medplum was the ability to focus our development effort on the user experience and educational functionality rather than the foundational infrastructure. Medplum gives us a FHIR-native backend for storing and managing clinical information. PhenoML provides a natural-language interface for translating user instructions into interoperable FHIR resources. Together, they create a powerful foundation for experimentation. For example, when a clinician types "brother had a heart attack at age 55," we can use PhenoML to interpret the statement and organize it into appropriate structured data, which can then be saved to Medplum. Similarly, natural-language medication requests, diagnoses, laboratory orders, and other clinical information can be translated into structured resources without forcing clinicians to navigate traditional forms.

The architecture is conceptually simple: a clinician enters information in natural language, PhenoML interprets it and helps generate structured FHIR data, and Medplum stores and manages the resulting resources. For us, this meant we could spend more time exploring the questions we actually cared about:

  • Can an EHR feel as intuitive as a modern document editor?
  • Can AI reduce the friction of structured data entry?
  • Can we make clinical reasoning visible without adding documentation burden?
  • Can routine clinical encounters become opportunities for individualized learning?
  • Can we do all of this while maintaining standardized, interoperable clinical data?

Medplum and PhenoML gave us a practical way to start answering these questions without building every part of the technology stack ourselves.

Built in the open

We also decided to make the project open-source. The application is available on GitHub at https://github.com/xprimarycare/xpc-emr.

The project is built with Next.js, React, and TypeScript, using Medplum for FHIR-based clinical data management and PhenoML for natural-language interactions with structured clinical information. Our intention isn't to present this as a finished EHR. It's an evolving prototype and an invitation to experiment.

We hope other clinicians, educators, and developers can use it as a starting point for their own ideas, whether that's creating simulated patient encounters, experimenting with AI-assisted documentation, developing clinical reasoning exercises, or exploring entirely new approaches to medical education. One of the advantages of open-source healthcare infrastructure is that we don't all have to solve the same foundational problems independently. By sharing what we've built, we hope to encourage others to explore what becomes possible when modern interfaces, AI, and interoperable clinical data come together.

If you're interested in building on the project, exploring the code, or contributing ideas, we'd love to hear from you.

Click here to view a video walkthrough of the prototype.

Where we want to take this next

This is still an early prototype, and there's plenty left to build and validate. But we're excited about what it suggests. Imagine a medical student practicing on a simulated patient, documenting an encounter, explaining their reasoning, and receiving immediate feedback. Imagine a resident completing a series of encounters and being able to see recurring gaps in diagnostic reasoning, treatment selection, or follow-up planning. Or imagine an educator being able to identify patterns across a group of learners and use those insights to guide teaching. Beyond traditional clinical training, similar capabilities could support onboarding, continuing medical education, and longitudinal professional development.

The broader idea is to make the EHR more than a tool for recording care. It could also become a place where clinicians learn from the decisions they make. What if every patient encounter could also be a learning opportunity? We're still early in answering that question, but building on Medplum and PhenoML has made it possible to move from an idea to a working prototype. And by making the project open-source, we're inviting others to help explore what a teaching-first EHR could become.

Medplum Monthly Update - September 2026

· 27 min read
Reshma Khilnani
Medplum Core Team

PlumCon 2026 happened on September 3 in San Francisco. Thank you to everyone who spoke, demoed, and came. It was the largest gathering of people building on Medplum yet, and the community demos are posted on the lineup page.

September brought 153 commits from 21 contributors, with six patch releases, v5.1.37 through v5.1.42.

Scheduling gained rescheduling, overbooking, either/or participant search, and a workspace for configuring visit types. A new Cron resource decouples a Bot's schedule from the Bot itself. The Provider App grew a full billing setup flow, and a long list of identity and session hardening landed on the server. Two new long-form posts went up: the Awell Panels case study and How Medplum thinks about FHIR.

All of this continues to drive forward our 2026 roadmap priorities.

Awell Panels: Worklists That Update Themselves

· 10 min read
Thomas Vande Casteele
Co-Founder and CEO, Awell

Awell builds care orchestration infrastructure, and on top of it Panels, a work surface where care teams define a patient population, configure how they work it, and trigger what happens next. Panels is population and workflow agnostic by design: intake, surgery prep, prescription refill, chronic care management and post-discharge follow-up each need to see different data and follow different steps.

At a national post-acute provider running 180+ inpatient facilities, post-discharge follow-up runs on Panels at roughly 250,000 discharges a year, with about 500 weekly users. A voice AI agent handles routine outreach; case manager assistants handle everyone the eligibility rules exclude. Both work the same panel. Panels did not exist before this project. It went from its first two hospitals to all 180 in nine months, on self-hosted Medplum. Guideway Care assembled the solution, implemented it, and ran the rollout.

How Medplum thinks about FHIR

· 5 min read
Maddy Li
Medplum Core Team

Most folks, before encountering Medplum, think of FHIR in one of two ways:

  • As a read-mostly interface bolted onto a proprietary EHR. Epic, Oracle Health, and exchange profiles like Da Vinci Payer Exchange all use FHIR only at the boundary between systems. The real data lives in someone's proprietary tables; FHIR is the negotiated contract at the edge.

  • As a FHIR repository you publish into. HAPI, Aidbox, HealthLake, and the Azure or Google FHIR stores are often stood up alongside the operational datastore that actually serves the application — a landing zone for exchange, analytics, or compliance, rather than the system of record your app reads and writes on the hot path.

In both models, FHIR sits off to the side, and a separate database is doing the real work of running the application.

So when developers come to Medplum, they usually ask something along these lines:

  • "How is the data handled and stored in the DB itself? How does that relate to FHIR?"
  • "If I point a SQL explorer at the Postgres database when running Medplum locally, will I be able to see what's happening?"
  • "Can I get direct access to the rows in the database when using your hosted service?"

These are all very reasonable questions for developers doing due diligence on Medplum, and part of the beauty of open source is that you can inspect our implementation directly. We also think these questions come from a particular understanding of the relationship between FHIR and an EHR — and this post is about how that relationship is different in Medplum.

Medplum Monthly Update - August 2026

· 21 min read
Reshma Khilnani
Medplum Core Team

PlumCon 2026 is this Thursday, September 3, in San Francisco. The agenda is posted. General registration has closed, but waitlist spots are available.

On August 1 we hosted the YC x Medplum Hackathon at the Y Combinator office in San Francisco, where 160+ hackers built on Medplum in a day. Read the recap.

It was a heavy month of shipping: 198 commits from 22 contributors, with nine patch releases, v5.1.28 through v5.1.36.

DICOM moved to Beta, scheduling got its own React package and a mountable booking workspace — the fastest path yet from empty project to a working calendar. Terminology got its 2026 refresh with multi-language display support, and externally issued JWTs can now authenticate against a specific project rather than the whole server.

All of this continues to drive forward our 2026 roadmap priorities.

Medplum Terminology Services Update - 2026

· 5 min read
Matt Willer
Founding Engineer, Medplum

We've been hard at work making updates to our Terminology Services to update them for 2026, and are excited to share all the new features and data sets available! The latest UMLS 2026AA data set has been imported into Medplum's hosted environment, and is available for customers to use in their self-hosted clusters as well. In addition, we've made a number of improvements across the core terminology API endpoints to make everything faster and serve multilingual users.

Medical Imaging in Medplum - DICOM & DICOMweb Beta

· 7 min read
Cody Ebberson
Medplum Core Team

Medical imaging has been the part of the patient record that lives somewhere else. A digital health company builds its charting, ordering, and results workflows on FHIR, and then imaging arrives and the answer is a separate PACS, a separate login, a separate access control model, and a link out to a viewer that knows nothing about the rest of the chart.

Today we are releasing DICOM and DICOMweb support in Beta. A modality on a hospital network can send a study to Medplum over the DICOM network protocol, the study is stored as ordinary Medplum resources under the project's existing access policies, and a DICOMweb viewer can read it back out — with no image server in the middle.

Profile Health: Genetic Intelligence for Longevity Medicine

· 8 min read
Mandi Bateman
CEO, Profile Health

Profile Health is building genetic intelligence for longevity and functional medicine — the concierge, naturopathic, and longevity practices that treat chronic, whole-person conditions rather than single episodes of care. Their thesis is simple: the most valuable signal in medicine — a patient's whole genome, enriched with a lifetime of their clinical records — sits scattered, unread, and never makes it into the exam room. Profile fuses the two and hands the result to the physician, so care can get ahead of disease instead of reacting to it.

That’s a Wrap: The YC x Medplum Hackathon

· 4 min read
Reshma Khilnani
Medplum Core Team
Maddy Li
Medplum Core Team

On Saturday, August 1, 2026, the Y Combinator office in San Francisco filled up with 160+ hackers for the Agentic Healthcare Hackathon, co-hosted by Medplum and Y Combinator.

This post is a celebration of that day, and to express our heartfelt appreciation to every single hacker who showed up and shipped. You are the reason events like this exist, thank you all!