Case Study - Building a Clinical Product Inside the EHR, Not Around It
A clinician workspace, member app and AI layer built on top of Healthie — with the EHR kept as the system of record, configured so the two never fight, and its quirks found before they became duplicate patients and lost labs.
- Client
- Metabolic Health Platform
- Year
- Service
- EHR Build & Integration
- My role
- Fractional CTO
We added the AI, labs and assessment layer the EHR didn’t have, while keeping Healthie as the system of record — reading from it heavily, writing back narrowly, and configuring it so clinicians and members never saw the seams.
The challenge
The care team lived in Healthie: demographics, medications, diagnoses, forms, documents, appointments and messaging. The product needed more than Healthie offers — an AI clinicians could question about a chart, lab results from an outside lab partner, and an assessment pipeline feeding a member app. The trap in that situation is building a second EHR next to the first, so clinicians end up checking two places and neither is complete.
My role
I decided what belonged in the EHR and what belonged in the product around it, configured Healthie to fit, and led the build of the clinician workspace, the member app and the integrations between them — working with the care coordinators and clinicians whose day runs on both.
Leadership decisions
Decision 1
Keep the EHR as the system of record — read heavily, write back narrowly.
Instead of: Copying the chart into the product and treating that copy as the source of truth.
Healthie stays authoritative for identity, the medical record, scheduling and messaging. The product reads from it constantly — refreshing a member's chart before every AI conversation, so the AI never answers from a stale copy — and writes back only what clinicians need to find there, such as resulted lab reports filed in the chart.
Decision 2
Store outside lab results beside the EHR, and file the report in it.
Instead of: Forcing third-party results into the EHR's native lab objects.
Healthie's lab orders and results are wired to its own lab integrations, not to an outside lab partner. Pushing results into them would have produced records that looked right and behaved wrong. Instead the structured results live in the product, where the interpretation engine needs them, and the lab's report is filed in the member's Healthie chart under a consistent name — so the chart is complete for the clinician without pretending to be something it isn't.
Decision 3
Configure the EHR so the product owns onboarding and notifications.
Instead of: Leaving the EHR's defaults on, and layering the product's own messages on top.
Left alone, members would have received two of everything — the EHR's welcome email and the product's onboarding, the EHR's message alerts and the product's. So Healthie's native welcome and notification emails were switched off, a webhook hands new messages to the product, and members are only notified if a message is still unread half an hour later. Appointment types were mapped to booking rules, and an unknown type fails loudly — telling staff to check the Healthie configuration — rather than silently disappearing from the calendar.
The solution
A clinician workspace, a member app and an AI pipeline that sit on top of Healthie rather than beside it. Members are created in the EHR once and assigned to the right clinician by visit type. Scheduling, cancellation and rescheduling run against the EHR's own appointment types and rules. Every clinician AI conversation starts from a fresh copy of the chart, and every lab report ends up where clinicians expect to find it.
Impact
- One record, not two. Clinicians keep working in the EHR they know; the product adds what it lacked without competing with it.
- Problems found before they reached a patient record — duplicate members, lab results that never reached the right chart, and onboarding state erased by a retry were each designed out.
- Members hear from the practice once. No duplicate welcome emails or message alerts.
Under the hood — the technical detail
Browser calls to Healthie go through a server-side GraphQL proxy authenticated with the user's own session, so the organization's key never reaches the browser. Member creation is find-before-create on an exact, normalized email, so a payment webhook and a registration racing each other can't create two patients. Writes that update a member are partial updates rather than full replacements, so a retried webhook can't erase onboarding progress. Chart snapshots for the AI are hashed and only rewritten when the chart changes; documents are copied and indexed for retrieval within the EHR's short-lived download window.
- Healthie (GraphQL API, webhooks, configuration)
- EHR system-of-record design
- Scheduling and provider routing
- Third-party lab integration
- Idempotent, event-driven integration