Patient Intake Gateway

A medical practice took accident-callback requests through a rented form on a vendor's servers. Now it runs an owned intake that collects the callback and nothing clinical, keeps protected health information out by design, and routes each request to the team on its own.

Role

Design, build, automate

Client

A personal-injury medical practice

Year

2026

Stack

Web app · Database · Automation

Status

Complete build

01 The problem

An injured patient fills out a form to ask for a callback. Simple, until you look at where the form lived. It was rented, hosted on a vendor’s servers, and every field it collected sat in a database the practice did not own and could not fully see. A patient intake form is one careless field away from holding protected health information on a platform someone else controls, and this one was already close. The practice paid a yearly rent for it, wore the vendor’s branding on its own intake, and lived inside the vendor’s caps on how much it could take and how many of the team could even read it.

02 The system

So I built the practice its own intake, on its own domain, around a single rule: the public form collects a callback and nothing a doctor would chart. A name, a number, the state and rough date of the accident, consent to be called. That is all it can hold, because that is all it asks. A challenge turns bots away before anything saves. The request lands in an encrypted database the practice owns, an automation carries it to a private dashboard and onto the case board, and the only people who can open it sign in by magic link from a short allowlist. The medical detail comes later, in the system built to hold it under HIPAA, never at the front door.

03 How it holds up

The privacy here is structural, not a promise on a settings page. The intake never collects protected health information, so the public surface has nothing sensitive to spill. The alert that announces a new request carries the fact of it, not the patient inside it. Bots are screened before a save, the store is encrypted, and access is an allowlist with magic-link sign-in, not a shared password making the rounds. The data lives in the practice’s own database, not a vendor’s. You cannot leak what you never collected, and you cannot lose control of what you already own.

04 The result

What used to be a rented form is now the practice’s own system, on its own domain and in its own database. No yearly rent for a tool someone else controls, no cap on how many requests come in or how many of the team can see them, no patient data parked on a platform the practice cannot audit. The front door stays clean of anything clinical, every request routes itself to the people allowed to handle it, and the sensitive work happens where it belongs. The practice stopped renting its own intake and started owning it.

1. The public form collects a callback request and nothing clinical: a name, a phone number, the state and rough date of the accident, and consent to be contacted. Protected health information never enters the intake layer, so the public surface has nothing sensitive to leak.

2. A bot challenge screens every submission before it is saved, requests are held in an encrypted database, the alerts carry no patient detail, and admins reach the dashboard only through a magic link tied to an allowlist.

3. It is software the practice owns, on its own domain and in its own database, instead of a form rented from a third party that holds the data and caps how much it can take and how many of the team can read it.