MedRelay

Giving rural clinics the same patient handoff technology that large hospital systems have — for free. The patient arrives. The record already did.

Comment

Inspiration

Rural America has a healthcare infrastructure problem that rarely makes headlines. There are over 1,800 rural hospitals in the United States, and thousands more rural urgent care clinics and critical access facilities. Every single day, these clinics transfer patients to larger hospitals — stroke victims, cardiac patients, trauma cases, complicated deliveries. And in the vast majority of them, that handoff still happens over the phone or by fax.

The receiving hospital grabs a pen. A nurse reads vitals out loud while another writes them down. Medications get abbreviated. Allergies get missed. By the time the patient arrives, the ED team is still piecing together a clinical picture that the sending clinic already had fully documented.

We chose this problem because it is unsexy, unglamorous, and completely unsolved for the facilities that need it most. Enterprise EMR systems like Epic cost millions to implement. Rural clinics cannot afford them. They are left with fax machines and phone calls for one of the most critical moments in a patient's care journey.

MedRelay exists because that is unacceptable.

What It Does

MedRelay is a real-time patient transfer platform designed specifically for rural clinics and critical access hospitals.

When a clinic needs to transfer a patient, a nurse fills out a structured digital transfer record covering:

  • Patient identity — name, DOB, weight, sex
  • Vitals — BP, heart rate, O2 saturation, temperature, GCS score, respiratory rate, pain level
  • Clinical history — chief complaint, onset, mechanism, medical history, current medications, allergies with severity, last oral intake
  • Transfer logistics — receiving facility, ETA, transport method, transferring provider, level of care needed
  • Code status — Full Code, DNR, DNI — permanently displayed on every view of the record

The moment the record is created, MedRelay generates a secure shareable link and QR code. That link is sent to the receiving hospital. No login required on their end. No app to download. Just a URL.

The receiving hospital opens the link and immediately sees:

  • Allergies in a prominent red block — always first, always visible
  • Code status pinned at the top of the page
  • Out-of-range vitals flagged in red
  • A full audit trail of every action on the record with timestamps and AWS region
  • A live countdown to the patient's ETA
  • Auto-refresh every 15 seconds so the record stays current

The receiving team clicks Accept Transfer and the sending clinic sees the status update to Acknowledged in real time. The communication loop is fully closed before the patient walks through the door.

Key features:

  • Critical auto-detection — out-of-range vitals automatically flag a transfer as critical without any manual input
  • Code status banner — DNR/DNI status is permanently visible on every page of the record
  • Isolation precautions — Contact, Droplet, or Airborne flags displayed prominently so receiving teams can prepare rooms in advance
  • Transfer templates — pre-filled protocols for Chest Pain, Stroke, OB Transfer, and Trauma so nurses aren't starting from scratch
  • Callback request flow — receiving hospitals can request a callback with a message that appears instantly on the sending clinic's dashboard
  • Record expiry — receive links automatically expire 24 hours after the transfer ETA for HIPAA compliance
  • Full audit trail — every status change, every link open, every acknowledgment logged with timestamp and AWS region
  • Multi-region region badge — every page shows which AWS region served the request, with DB query latency in milliseconds

How We Built It

MedRelay is a full-stack Next.js 14 application deployed on Vercel, backed by Amazon Aurora DSQL.

Frontend

  • Next.js 14 with App Router and TypeScript throughout
  • shadcn/ui component library for the clinical interface
  • Zod for form validation on both client and server
  • qrcode.react for QR code generation
  • Auto-refresh via setInterval polling on the receive and confirmation pages
  • Fully responsive — designed for tablets and phones used by clinical staff

Backend

  • Next.js API routes handling all data operations
  • Aurora DSQL connection via @aws-sdk/client-dsql for token generation
  • pg driver for PostgreSQL-compatible queries
  • Session management via httpOnly cookies
  • Pre-notification emails via Resend on transfer creation

Database — Amazon Aurora DSQL

Aurora DSQL was the centerpiece of our architecture. We chose it specifically because of its active-active multi-region replication capability. A transfer record created in us-east-1 by a clinic in Kentucky is immediately available in us-west-2 for a hospital in Oregon — with no manual replication logic, no eventual consistency workarounds, and no operational overhead.

Our schema includes:

  • clinics — sending facility accounts
  • facilities — receiving hospital directory
  • transfers — the full patient transfer record
  • transfer_events — append-only audit log with region tracking
  • waitlist — email capture for the marketing landing page
  • demo_requests — inbound demo interest from the landing page

Every API response includes the serving AWS region, which we surface visually on the dashboard and receive page as a region badge with DB query latency — making the multi-region architecture tangible and visible rather than invisible infrastructure.

Deployment

  • Frontend and API routes deployed on Vercel
  • Aurora DSQL cluster provisioned through the Vercel marketplace integration
  • Environment variables managed through Vercel's secure credential storage

Challenges We Ran Into

Aurora DSQL connection management Aurora DSQL uses short-lived IAM tokens for authentication rather than static passwords. Managing token refresh within Next.js API routes — which are stateless and may run across many edge instances — required careful implementation to avoid connection errors without over-generating tokens.

Multi-step form state The patient intake form spans 5 steps with complex interdependencies — for example, out-of-range vitals in Step 2 need to automatically activate the Critical flag that appears in Step 4. Managing this state across steps without losing data on navigation required a carefully structured form context.

HIPAA-aware design without a backend team Building a product that feels trustworthy enough for clinical use — with proper audit trails, record expiry, code status visibility, and access logging — as a solo full-stack build required making a lot of product decisions that enterprise healthcare teams have entire compliance departments for.

Making the receive page truly zero-friction The receiving hospital side had to work with absolutely no setup. No login, no cookie, no state. Just a URL that opens and immediately shows exactly what a nurse needs to see in the right order. Getting the information hierarchy right — allergies first, code status pinned, critical vitals in red — took more iteration than any other part of the UI.

Accomplishments That We're Proud Of

  • The automatic critical detection — vitals that fall outside safe ranges silently activate the critical flag without any manual input. In a stressful clinical moment, one less thing for a nurse to remember matters.

  • The code status implementation — something as consequential as a DNR order being permanently visible on every single view of a record, in a way that cannot be scrolled past or missed, feels like the right call. We are proud that we treated it with the seriousness it deserves.

  • Zero-friction receiving — the fact that a hospital with no MedRelay account, no IT setup, and no prior knowledge of the system can open a link and have a complete clinical picture in under 5 seconds is the product achievement we are most proud of.

  • Making Aurora DSQL's multi-region nature visible — rather than letting the infrastructure be invisible, we surfaced the serving region and query latency directly in the UI. The architecture isn't just under the hood — it's part of the product story.

What We Learned

  • Domain research changes everything. The SAMPLE mnemonic, GCS scoring, isolation precaution flags, code status requirements — none of this was in our original spec. Spending time understanding how actual patient transfers work produced a dramatically better product than building a generic form tool.

  • Aurora DSQL is genuinely different. Most distributed databases force you to choose between consistency and availability. Aurora DSQL's active-active model gives you both without requiring you to reason about replication topology in your application code. For a healthcare application where stale data is dangerous, that matters.

  • Information hierarchy is a clinical decision. The order in which information appears on the receive page — allergies, code status, vitals, history, logistics — is not a UI preference. It reflects the order in which a clinician actually needs that information when a patient is incoming. Design and clinical workflow are the same thing here.

What's Next for MedRelay

  • SMS integration — automatically text the receive link to the receiving facility's on-call number the moment a transfer is created, so no one has to manually forward it

  • In-app messaging thread — a simple text thread between sending and receiving facilities tied to each transfer record, replacing phone tag for quick clinical clarifications

  • Vital trend tracking — if vitals are re-entered during a transfer (e.g. updated by EMS en route), show sparkline trend charts so the receiving team can see whether the patient is improving or deteriorating

  • EHR integration — a webhook or HL7 FHIR export so that when a receiving hospital accepts a transfer, the record can flow directly into their existing EMR system

  • Clinic network accounts — allow health systems to manage multiple rural clinic locations under one account with centralized transfer visibility

  • Offline mode — rural clinics have unreliable internet. A PWA with local draft saving that syncs when connectivity is restored would make MedRelay usable in the most remote facilities

MedRelay started as a hackathon project. It does not have to stay one.

Built With

Share this project:

Updates