MyVisitCare

A helping hand for your hospital visit — from morning alarm to discharge, you get a concierge like experience, no phone calls required.

Comment

My Visit Care

Inspiration

Most patients don't have one hospital. They have three. A primary care doctor at one system, a specialist at another, an ER visit somewhere they happened to be that day. Each of those visits writes to a different EHR. Each EHR has a different patient portal, or none at all. The records are technically interoperable now (FHIR is mandated, OAuth is standard), but the experience isn't.

If your hospital uses Epic, you have MyChart, and it's good. Roughly 250 million people in the US fall under that umbrella. The other ~30% of US hospital encounters happen at facilities running Cerner / Oracle Health, Athena, Veradigm, OpenEMR, or homegrown systems. The patient-side experience there ranges from passable to nothing. And even an Epic patient who shows up at a non-Epic facility loses their portal at the door.

The data isn't the silo. The portal is. We wanted to build the patient companion that travels with the patient instead of the hospital.

What it does

My Visit Care is an AI agent that walks a patient through six phases of an outpatient visit:

  1. Briefing: a morning summary on the day of the appointment. The agent pulls the appointment, active conditions, current medications, and allergies from the FHIR record, and the real weather at the destination. Prep instructions are specific (cold day plus cardiology means a coat and no caffeine).
  2. Travel: real distance, real drive time, real recommended departure time computed from the patient's origin and the matched hospital coordinates.
  3. Navigate: a Google Maps embed centred on the hospital's actual coordinates plus directory data for the building and entrance. We dropped fake step-by-step indoor instructions because no public API can produce honest ones for most buildings.
  4. Wait: waiting room context built from the live FHIR encounter (status, started time, location).
  5. Billing: transparency built on real chargemaster prices ingested from a public corpus of close to six thousand US hospitals, alongside the CMS Medicare benchmark for the same procedure code, with source badges on every number.
  6. Summary: a post-visit recap built from the same FHIR record (medications, conditions, follow-up).

The unifying property: the agent works the same way regardless of which EHR sits behind the FHIR endpoint. Epic, Cerner / Oracle, Athena, or any system that exposes the patient's record over FHIR R4 with a SHARP-compliant token. The same agent code lights up against any of them. No vendor SDK, no proprietary handshake.

How we built it

FHIR-first, no vendor SDK. The whole architecture is standards-aligned by design.

  • SHARP-on-MCP carries the patient's FHIR token, server URL, and patient ID across every tool call as HTTP headers (X-FHIR-Server-URL, X-FHIR-Access-Token, X-Patient-ID). PromptOpinion injects these when its General Chat Agent invokes one of our MCP tools, so the patient context flows without a per-vendor dance.
  • MCP server at /api/mcp exposing nine tools (AppointmentContext, MorningBriefing, PostVisitSummary, OutdoorDirections, IndoorDirections, RoomContext, DailySchedule, MealOptions, BillingSummary). Each tool returns structured JSON, which the platform's LLM composes into a patient-facing answer. That's the "AI Factor": the platform LLM does the natural-language stitching from our structured tool outputs.
  • A2A agent at /api/a2a with an agent card published at /.well-known/agent-card.json. Per-request base URL resolution means the agent card always declares whichever host the caller hit, which keeps the marketplace listing portable across the deployed myvisitcare.org custom domain and the Cloudflare preview URL.

Frontend stack: Next.js 15 App Router, React 19, Tailwind, on Cloudflare Pages edge runtime. Supabase / Postgres holds the hospital corpus and chargemaster prices. FHIR via fhirclient, validated against the Cerner R4 sandbox so we know the architecture works against a non-Epic system.

External data:

  • DoltHub hospital-price-transparency-v3 for chargemaster prices (close to six thousand hospitals, hundreds of millions of price rows in the source corpus).
  • CMS Procedure Price Lookup for the Medicare benchmark.
  • Open-Meteo for weather at the destination.
  • Google Maps Embed for the navigate screen.

Challenges we ran into

Building portable is harder than building for one system. FHIR sandboxes are uneven across vendors. Cerner has gaps Epic doesn't (sparse CarePlan, sometimes empty Coverage). Epic has its own quirks around Appointment slot availability. We rewrote every screen to render gracefully when a resource comes back empty, rather than coding for one vendor's happy path.

Indoor wayfinding has no public API for most US hospitals. Google Indoor Maps covers a few hundred. The rest would need either floor plans the hospital publishes or BLE beacon infrastructure neither of us has. We ripped out hardcoded "turn left at the elevator" steps and replaced them with a real map plus the directory data we do have, marked as such.

Chargemaster prices for the same CPT code can vary by ten times between two hospitals on the same block. The first time we showed a single price it looked invented. We added source badges everywhere, plus the CMS benchmark alongside, so a patient or judge can see exactly where each number came from.

Keeping the demo honest was its own challenge. Every time we caught a hardcoded fallback (the weather string, a placeholder drive time, a synthetic patient name leaking into a real-data page), we ripped it out. The recent commit history is mostly that work.

Accomplishments that we're proud of

No vendor lock-in. The same agent code runs against any FHIR R4 endpoint plus a SHARP-compliant token. We tested against the Cerner public sandbox, but nothing in the agent assumes Cerner. Drop in Epic's open endpoint, Athena's, OpenEMR's, the agent works.

The data layer isn't a mock. Live Cerner FHIR pulls across nine resource types. A real hospital corpus in Postgres. Real chargemaster prices. Real CMS benchmarks. Real weather and real distances.

Both PromptOpinion paths wired. MCP tools, A2A agent, agent card. Per-request host resolution so the marketplace listing stays correct as the deployment moves between domains.

Source badges on every data point. A patient or a judge can tap any number and see whether it came from the EHR, a public dataset, an estimate, or a hospital-published price file.

Honest about limits. We chose to drop fake indoor wayfinding rather than fake it. Easier to add fake instructions than to admit a limit. We chose the limit.

What we learned

MyChart is the existence proof that a patient companion works, but only when the hospital owns the contract. It's been one of the most successful patient-facing products in healthcare for almost two decades. What MyChart can't do is travel with the patient. The contract is hospital-side. The portal is per-system.

Open standards (FHIR, MCP, A2A, SHARP) move that contract to the patient side. The same agent can serve a patient at three different facilities on three different EHRs, because the only assumption is that the records expose FHIR with a SHARP-compliant token. Both of those are federally standard now. The portable model is suddenly buildable.

Other lessons: FHIR sandboxes are rough across all vendors, you build for the gaps. "Real-feeling" beats "real-looking": a sourced number reads better than a glossy synthetic one. MCP and A2A are easy to scaffold; the work is everything around them (token propagation, sandbox quirks, agent card validation, surviving real platform invocations). A demo's credibility lives or dies on the first hardcoded thing a judge spots.

What's next for My Visit Care

Three concrete commitments.

  1. Validate against more vendors. Test against the Epic, Athena, Veradigm, and OpenEMR FHIR sandboxes. The agent should require zero code changes; the architecture says so, but we should prove it.
  2. Pilot where MyChart doesn't reach. Engage one VA, DoD, or HCA facility to host the agent for their patients. These are large patient populations that Epic doesn't serve, with poor patient-portal experiences today.
  3. Cross-system mode. The interesting case: a patient who has records at two or three different FHIR endpoints. The agent reconciles them in one session, surfaces medication conflicts across providers, gives a single morning briefing instead of three. MyChart Central exists for the Epic-only version of this; nothing exists for the cross-vendor case.

After that: real MyChart / SMART-on-FHIR patient auth in place of the demo cookie, and Phase 2 of the PRD (inpatient room companion, daily cost digest, visitor wayfinding via shareable link).

Built With

Share this project:

Updates