What this automation does
Patient intake is the stack of forms, card scans and retyping that happens between booking and rooming. This workflow moves most of it before the visit and hands staff a reviewed, structured record instead of a clipboard.
- Trigger. When an appointment is booked in your practice management system, the workflow sends the patient a secure intake link by text or email a few days before the visit.
- Collect. The patient completes demographics, insurance, current medications, allergies, history and reason for visit, and signs consent, privacy notice acknowledgment and financial policy forms. Questions branch by visit type, so a returning patient only confirms what changed.
- Capture cards. The patient photographs the front and back of the insurance card and a photo ID. A vision-capable model extracts payer name, member ID, group number, subscriber name, relationship to patient and payer phone into fixed fields.
- Verify coverage. The payer and member ID go to an eligibility check through your clearinghouse (the X12 270/271 transaction). Staff see active or inactive coverage and copay details before the patient arrives.
- Summarize. The model turns free-text answers into a short pre-visit summary marked “patient-reported”: reason for visit in the patient’s own words, medications as listed, allergies and changes since the last visit. It does not interpret symptoms, rank urgency or suggest diagnoses.
- Review and file. Front-desk staff open a review screen with extracted fields beside the original images, fix anything flagged, and file the record to the chart. Clinical staff reconcile medications and history during rooming, as they do today.
When it is worth building
Start with what you already pay for. If your EHR’s own e-check-in (Epic’s MyChart check-in, athenahealth’s patient check-in tools) or a dedicated intake product covers your forms and your staff use it, configure that first. It will be cheaper and already lives inside the chart.
A custom build earns its keep when:
- Front-desk staff still retype paper or PDF forms into the practice management system.
- Registration errors, such as a mistyped member ID or an expired plan, keep turning into denied claims.
- You run specialty questionnaires, several locations or several systems that the native tool cannot handle.
- Many patients need forms in a language other than English.
- Clinicians want a one-paragraph summary instead of six pages of checkboxes.
If you check in fewer than about 20 patients a day and denials are rare, a HIPAA-eligible form builder with a BAA and a staff checklist is usually enough.
Architecture
| Layer | What we use | Why |
|---|---|---|
| Patient form | A form builder on a plan that includes a BAA (Jotform or Formstack), or a small custom web form | Patients need a mobile-friendly form, and the vendor holding responses is a business associate |
| Orchestration | Self-hosted n8n on AWS, Azure or Google Cloud under that provider’s BAA | Keeps PHI in your own environment. Many SaaS automation tools will not sign a BAA |
| Extraction and summary | Claude or OpenAI’s GPT models through an API arrangement covered by a BAA | Reads card photos directly and follows a strict schema |
| Eligibility | Your clearinghouse’s API | Coverage checks should come from the payer, not from the model |
| Staff review | A simple review screen with role-based logins | Front desk sees demographics and insurance, clinical staff see history |
| System of record | The EHR through FHIR or vendor APIs (athenahealth, DrChrono, Epic) | The chart stays the source of truth |
| Audit | An access and change log in Postgres | You need to show who viewed or edited each record |
How to build it
- Map the current packet. List every form and field, who reads it and where it ends up. Drop fields nobody uses. A shorter form gets completed more often and sends less PHI through each system.
- Sign BAAs before real data flows. Form vendor, cloud host, model provider, SMS vendor and clearinghouse each need one. Build and test with synthetic patients until every agreement is signed.
- Apply minimum necessary to every hop. The card extractor gets the card image only. The summarizer gets the history answers only, not the insurance details. Staff roles see only the sections they work.
- Build the form with branching. New versus returning patient, adult versus pediatric, and specialty add-ons. Verify identity with date of birth before showing any prefilled data.
- Extract cards with a strict schema. Return each field with a confidence flag. Anything missing or low-confidence is highlighted on the review screen rather than guessed.
- Write the summary prompt with hard limits. Quote the patient’s words, never infer, write “not provided” for blanks, and label the output as patient-reported. Clinician-written red-flag phrases trigger a fixed message and a staff alert through a plain rule outside the model.
- Start with a PDF to the chart. File the reviewed intake as a document in the EHR first. Move to structured write-back through the EHR API once partner access or your health system’s approval comes through, which often sets the real timeline.
- Pilot one location. Run two to three weeks with staff double-checking every record, then widen.
The extraction pattern is the same one in our document data extraction guide. Lumeor’s healthcare AI triage project covered patient onboarding for a symptom assessment app, which is where many of these guardrails come from.
What breaks in production
- Cards with several IDs. Medicaid managed care and Medicare Advantage cards can show more than one number. Ask the model to return every ID with its label, and let staff pick.
- Subscriber confusion. A parent fills out a child’s form and enters their own name as the patient. Ask “who is the patient” and “who holds the insurance” as separate questions.
- Duplicate charts. “Jon” and “Jonathan” with the same birth date create a second record. Match on name, date of birth and phone, and send possible matches to staff. Never auto-merge.
- Medication free text. “The blood pressure one” is not a medication. The summary keeps the patient’s words and leaves reconciliation to clinical staff.
- Expired links. Patients open the link the morning of the visit after it expired. Set expiry to the appointment time and offer a resend.
- Glare and cropped photos. Prompt the patient to retake when the image is blurry before they submit, not after.
- Model updates. Pin the model version and re-run a set of de-identified test cards before any upgrade.
Timeline and cost
Most practices go live in four to eight weeks. Lumeor builds patient intake automation in the range of $15,000 to $40,000. The low end is one location, one EHR and a reviewed PDF filed to the chart. The high end adds several locations, multilingual forms, structured write-back through an EHR partner API and an eligibility integration. Running costs include model usage (usually small per patient), hosting, and the form vendor and clearinghouse fees, which those vendors bill directly, so check their current pricing. See what adding AI to existing software costs for how these projects are scoped.
How to measure success
- Share of patients who finish intake before arriving
- Front-desk minutes per check-in, before and after
- Denials caused by registration or eligibility errors
- Correction rate on extracted card fields, by payer
- Time from arrival to rooming
- Staff and clinician feedback on the pre-visit summary