## Intake & Registration Decision Guide

## Companion to the Intake & Registration docs

*Companion to the Intake & Registration docs.*

## Section 1: Use Case & Participants

## 1.1 Who completes intake, and in what setting?

• Patient self-service (portal, mobile, kiosk)

• Staff-assisted (registration desk, rooming, phone, paper-to-digital)

• Mixed (patient starts online, staff verifies in person)

*Why: determines the auth model and whether an intake response may exist*  
*before the patient record is created (3.1, 3.2).*

## 1.2 When does intake happen relative to identity and scheduling?

• Before the patient record exists (greenfield / new patient signup)

• After scheduling, pre-visit (patient exists, no visit yet)

• At check-in or during the visit

• Episodic updates only (existing patient, not tied to a visit)

*Why: drives whether intake creates or updates a patient record, when*  
*responses get tied to a patient, and whether intake tasks link to a visit (3.1,*  
*3.8).*

## 1.3 How are returning patients and duplicates handled?

• Always create a new patient record on intake (rare; only if you have a  
separate dedup pipeline downstream)

• Look up by identifier (e.g. MRN, email, phone) and update if found

---

• Run a demographic candidate search and confirm with staff before  
merge

• Mixed – different rules for patient self-service vs staff-assisted

*Why: drives 3.1 and must align with your org-wide dedup policy.*

## 1.4 What consents need to be captured at intake, and are any state- or population-specific?

*Why: drives 3.6; sensitive categories may constrain what post-intake*  
*automation can auto-share or auto-route (3.7).*

## 1.5 What other systems must intake feed or read from?

• Eligibility / insurance verification (e.g. Stedi, clearinghouse 270/271)

• Practice management or legacy EHR (write-back of demographics or  
coverage)

• Prefill sources (Patient Access API, Payer-to-Payer API, partner EHR,  
HIE/TEFCA) — see 3.3

• Referrals (intake initiated by an inbound referral – see the Referrals  
guide)

*Why: surfaces integration boundaries that affect prefill (3.3), post-intake*  
*automation (3.7), and which actions live inside one intake workflow vs*  
*separate workflows.*

## Section 2: Feature Scoping

*Go through each row together. For each cell under Yes / No / Nice-to-have / *  
*Not sure, mark the customer’s answer. The* **Deep dive** *column points to the*  
*Section 3 subsection that covers each feature.*

---

| # | Feature | Deepdive | Yes | No | Nice-to-have | Notsure |
| --- | --- | --- | --- | --- | --- | --- |
| 1 | Multiple intake forms by visit type, program, or language (vs one universal form) | 3.2 |  |  |  |  |
| 2 | Separate vs shared questionnaires for patient self-service and staff-assisted intake | 3.2 |  |  |  |  |
| 3 | Non-form intake modality (conversational chatbot, voice agent) feeding the same data shape as the form | 3.2 |  |  |  |  |
| 4 | Patient identity handling at intake — identifier lookup, demographic match search, and pre-auth start linked to a patient record later | 3.1 |  |  |  |  |
| 5 | Prefill intake from prior data, payer/HIE/EHR sources, or insurance card OCR; reconciliation when patient input disagrees with the source | 3.3 |  |  |  |  |
| 6 | Insurance capture with card images, multiple plans, and non-patient subscriber (e.g. parent’s plan covering a child) | 3.5 |  |  |  |  |
| 7 | Capture clinical history (allergies, medications, conditions, SDOH, immunizations, family history) and persist as distinct structured records | 3.2, 3.4 |  |  |  |  |
| 8 | Multiple consent types captured at intake, with renewal triggers | 3.6 |  |  |  |  |
| 9 | Post-intake automation: notify staff, run eligibility, create exception tasks, route to a care team | 3.7 |  |  |  |  |
| 10 | Multi-step or multi-author intake, with steps that appear in the provider’s visit chart | 3.8 |  |  |  |  |
| 11 | Treat “intake complete” as a tracked operational status that gates downstream work (scheduling, clinical) | 3.9 |  |  |  |  |

## Section 3: Feature Deep Dives

*Cover each feature flagged Yes or Nice-to-have in Section 2. The goal is to*  
*land on a clear recommended approach by the end of each section.*

Section 3 is grouped into three lanes:

---

| Lane | Subsections | When to read |
| --- | --- | --- |
| Capture | 3.1 – 3.4 | Always |
| Coverage & Consent | 3.5-3.6 | When coverage or consent is in scope |
| After Submission | 3.7 – 3.9 | Always |

## Capture

## 3.1 Patient Identity at Intake

Decide whether intake creates a new patient record, updates an existing one,  
or runs unlinked until a human confirms a match – and how the intake  
response gets tied to the right patient. For matching rules, master records,  
and merge mechanics, defer to Patient Deduplication Architectures and  
[Patient $match](/docs/api/fhir/operations/patient-match).

## Questions:

• Does the patient record exist before intake is filled out, after, or sometimes either?

• Do you run an identifier lookup, a demographic match search, both, or neither before creating a new patient record?

• When a match is ambiguous, does the intake response stay unlinked until a human confirms, or does the system pick the best candidate automatically?

• For self-service flows, can a patient submit intake before authenticating, and how is that response later associated with an account?

| Situation | Approach |
| --- | --- |
| Patient exists before intake (scheduled visit, returning patient) | Set QuestionnaireResponse.subject at create; intake Bot updates the existing Patient. |
| New patient, no candidate match | Intake Bot creates Patient, then back-fills QuestionnaireResponse.subject. |
| New patient, demographic search returns candidates | Use Patient $match for built-in scoring; require human confirmation in a Task before linking. |
| Anonymous / pre-auth start | Allow QuestionnaireResponse without subject; link at the next authenticated step or staff review. Track unlinked responses for cleanup. |

## 3.2 Form Library & Capture Flow

Decide whether intake uses one universal form or several, whether the same  
form serves both patient self-service and staff-assisted flows, and how non-form  
modalities (chat, voice) feed into the same data.

## Questions:

• One intake form for everyone, or different forms by visit type, program, or language?

• Same form for patient self-service and staff-assisted, or separate forms tuned to each audience?

• If you offer conversational or voice intake, does the transcript land in the same data shape as the form, or in a separate pipeline?

| Situation | Approach |
| --- | --- |
| One form for everyone | Single Questionnaire; one Bot maps to one consistent set of FHIR resources. |
| Forms by visit type, program, or language | Multiple Questionnaires with shared linkId conventions; Subscription criteria can target specific questionnaire URLs (see 3.7). |
| Patient vs staff variants | Either reuse one Questionnaire with a “completed-by” gate, or maintain parallel Questionnaires that map to the same target resources. |
| Conversational or voice intake | Keep a Questionnaire as the authoritative schema for what’s collected; the chatbot or voice agent maps transcript fields to linkIds before submitting a QuestionnaireResponse. Downstream extraction (3.4) stays the same. |

## 3.3 Prefill & Reconciliation

Decide whether intake starts blank or arrives pre-populated, where prefill  
data comes from, and how patient corrections are reconciled with the  
upstream source. Prefill is a superset of HIE — HIE is one source among many.

⚠ **One-way door:** Once intake silently overwrites existing records from a  
prefill source, distinguishing “patient said X” from “source said X” after the fact  
requires per-field origin tracking. Set the origin-tracking pattern before  
launch; retrofitting historical responses is painful.

## Questions:

• Does the form start blank, prefilled from data you already hold  
(returning patient, prior visit), or prefilled from an external source?

• Which external sources are in scope (insurance card OCR, Patient  
Access API, Payer-to-Payer API, partner EHR, TEFCA/QHIN, state or  
regional HIE)?

• When prefilled data and patient input disagree, who wins — the source,  
the patient, or staff?

• Does the patient see prefilled values and explicitly confirm, or is prefill  
silent?

| Situation | Approach |
| --- | --- |
| Source selection | Choose any combination of: internal (returning patient / prior intake), insurance card OCR, patient-mediated FHIR pull (Patient Access API / SMART-on-FHIR / partner EHR), Payer-to-Payer (CMS-0057, Jan 2027), HIE / TEFCA / QHIN. Each lands as draft resources for reconciliation. |
| Conflict resolution policy | Pick one per field domain: source-wins (administrative), patient-wins (clinical history), last-write-wins, or prompt staff. Document it; don’t leave it per-field. |
| Provenance | Create a Provenance resource per prefilled field (or batched per source pull) so downstream consumers know origin and pull date. |
| Patient visibility and refresh cadence | Default to “show and confirm” for clinical and demographic fields; silent prefill is acceptable for low-risk administrative fields when audit is in place. One-shot pull at form open is the safest default; re-pull on submit only for high-volatility sources (e.g. active coverage status). |

## 3.4 Extraction Model – SDC vs Bot

Decide where extraction logic lives: on the form itself (declarative SDC rules)  
or in custom code – and how you handle resubmissions without creating  
duplicate records.

⚠ **One-way door:** Once a form is in production and its field identifiers are  
referenced by extraction code or templates, renaming them requires  
migrating historical responses or maintaining a translation layer. Decide  
naming conventions before launch.

## Questions:

• Does extraction need conditional logic (only create a subscriber/guardian record when the subscriber is not the patient, only create a consent record when the patient agreed)?

• Does extraction need to call external APIs (eligibility, address validation, geocoding) during processing?

• When intake is resubmitted (annual update, correction), what should  
happen to existing allergies, medications, conditions, and coverage  
records?

• Will non-engineers update the form, and how often?

| Situation | Approach |
| --- | --- |
| Simple field-to-resource mapping, no conditionals, no external calls | SDC $extract with template resources in Questionnaire.contained; rules ship with the form. |
| Conditional resource creation, external API calls, custom validation | Bot triggered by Subscription on QuestionnaireResponse; use getQuestionnaireAnswers and getGroupRepeatedAnswers from @medplum/core. |
| Mixed | SDC for the deterministic mapping, Bot for the conditional / external pieces. |
| Resubmission without duplicates | Upsert clinical history by stable natural keys: patient + code for AllergyIntolerance; subject + code for MedicationRequest/Condition; beneficiary + payor for Coverage. See Intake Data Model→Resource Role Reference. |

## Coverage & Consent

## 3.5 Coverage & Subscriber Relationships

Decide how insurance is modeled, especially when the subscriber is not the  
patient, and how payers are sourced (curated directory or created on  
demand).

⚠ **One-way door:** On the coverage record, the relationship field describes the  
**patient’s** relationship to the subscriber; on the linked subscriber/guardian  
record, the relationship field describes that person’s relationship to the  
patient – they invert (if coverage says “child”, the subscriber is “parent”).  
Encoding this incorrectly is one of the most common intake bugs and is hard  
to retroactively fix on historical data.

## Questions:

• Are multiple coverages (primary / secondary) captured at intake, or  
only primary?

• Is the subscriber sometimes someone other than the patient (e.g. a  
parent’s plan covering a child)?

• Do you capture insurance card images, and where do they live?

• Are payers pre-loaded as a curated directory, or created on demand?

| Situation | Approach |
| --- | --- |
| Subscriber is the patient | Single Coverage with subscriber = Patient; relationship = self. |
| Subscriber is not the patient | Coverage + RelatedPerson; remember the inversion: if Coverage.relationship is child, RelatedPerson.relationship is parent. See Intake Data Model→RelatedPerson and Insurance Coverage. |
| Multiple coverages | One Coverage per plan; use order to indicate primary vs secondary. |
| Card image capture | Store the image as a DocumentReference and link it to the Coverage via DocumentReference.context.related; for full modeling see Patient Insurance. |
| Payer directory | Curated Organization resources searched by the form; fall back to “create if missing” only when scope is too broad to curate. |

## 3.6 Consents

Decide which consent types are captured, how they’re modeled, and what  
triggers re-consent.

## Questions:

• Which consent types are required at first intake vs deferred (HIPAA,  
treatment, financial, telehealth, research)?

• Are some consents conditional on patient attributes (minor, state of  
residence, payer)?

• What triggers re-consent (annual update, policy change, new clinic  
site)?

• Does intake need to capture electronic signature artifacts (image,  
attestation timestamp)?

| Situation | Approach |
| --- | --- |
| One consent per type | One Consent resource per type captured (HIPAA, treatment, financial, etc.); don’t bundle multiple agreements into one Consent. |
| Conditional consents | Use enableWhen on the Questionnaire; SDC or Bot creates Consent only when the patient agreed. |
| Re-consent | Existing Consent moves to status: inactive; new Consent created with current effective period. |
| Signature artifact | Store as Binary referenced from Consent.sourceAttachment. |

## After Submission

## 3.7 Post-Intake Automation – Triggers & Actions

Decide what happens after intake is submitted: which automations fire, when  
eligibility runs, and which downstream actions are part of intake vs separate  
workflows.

*Note: This section is decision-focused. For the full pattern catalog, see Post*  
*Intake Automation.*

## Questions:

• Does one workflow do everything (extract + notify + verify eligibility +  
create exception tasks), or do you split concerns into multiple workflows  
wired to different triggers?

• Should intake processing re-run when the response is updated, or only  
on first submit?

• When does eligibility verification run – during form completion, on  
submit, or async after intake is committed?

• Which post-intake actions are required to mark intake “done” vs nice-  
to-have side effects?

---

• When eligibility, address validation, or another external call fails, does  
that block intake or surface an exception task?

| Situation | Approach |
| --- | --- |
| Monolithic intake Bot | One Bot on QuestionnaireResponse create handles extraction and all downstream actions. Simplest to operate; trade-off is larger blast radius on failure. |
| Split by concern | Separate Subscriptions: one on QuestionnaireResponse for extraction, one on Coverage for eligibility, one on Patient for welcome notifications. Each Bot has a single responsibility and audit trail. |
| Prevent re-run on updates | Use the create-only Subscription extension so Bot updates to the QuestionnaireResponse (e.g. setting subject) don’t re-trigger extraction. See Avoid Infinite Loops. |
| Exception handling | When required data is missing or an external call fails, create a Task for staff (status: requested, owner = registration pool); do not silently drop the response. |
| Eligibility — sync gate (during form or on submit) | CoverageEligibilityRequest results gate “intake complete” (3.9). Highest UX cost, lowest downstream rework. Use when day-one billing readiness matters. |
| Eligibility — async post-intake | Same Subscription pattern, but failures surface as exception Tasks rather than blocking intake. Use when intake throughput trumps day-one billing readiness. |
| Care-team / program routing | Bot creates Tasks or CareTeam memberships based on intake answers (e.g. screening result triggers a behavioral health referral). |

## 3.8 PlanDefinition Orchestration & Encounter Linkage

Decide whether intake is a single form or a multi-step workflow with several  
tasks owned by different roles – and whether those tasks must show up in the  
provider’s visit chart.

*Note: The template-driven orchestration pattern is documented in detail*  
*under Post Intake Automation PlanDefinition Orchestration →. This section*  
*stays at the level needed to decide whether to adopt that pattern.*

## Questions:

• Is intake completed by one person in one session, or split across roles  
(patient fills demographics, MA captures vitals, provider reviews)?

• Does intake need to appear as tasks in the provider’s visit chart?

• Are some intake steps non-form work (e.g. lab orders, imaging) that  
should be modeled as orders rather than questionnaires?

• Will the same intake template be reused across visit types or  
programs?

| Situation | Approach |
| --- | --- |
| Single-form intake | Skip PlanDefinition; one Questionnaire + one Bot is enough. |
| Multi-step / multi-author intake | PlanDefinition with one action per Questionnaire or ServiceRequest, applied via $apply; the operation creates a CarePlan, RequestGroup, and one Task per action. |
| Encounter-chart visibility | Pass encounter to $apply; each generated Task must set both Task.focus (Questionnaire/X or ServiceRequest/X – the provider UI uses this for rendering) and Task.input[0].valueReference (used to load the form). Missing either breaks the chart view. |
| Reusable intake template | One PlanDefinition with url, name, and title set (the provider UI’s resource search uses name, not title); referenced Questionnaires and ActivityDefinitions must also have url so $apply can resolve canonicals. |

*Scheduling integration (appointments generated from intake answers, or*  
*intake gated on a scheduled visit) is covered in depth in the Medplum*  
*Scheduling discovery guide. From the intake side, link the resulting*  
*appointment or visit back to the intake artifacts that originated it.*

## 3.9 Lifecycle & “Intake Complete”

Decide what “intake is done” means for your operations, how that signal is  
represented, and what happens to incomplete intake.

## Questions:

---

• Is “intake complete” a single moment (form submitted) or a composite  
state (extraction succeeded + eligibility verified + required consents on  
file)?

• Which downstream workflows are gated on intake completion  
(scheduling, clinical, billing)?

• For incomplete intake (patient bailed mid-form, required field missing),  
how is that surfaced and worked?

• Are partial / draft intakes a supported state, or only completed  
submissions?

| Situation | Approach |
| --- | --- |
| Simple completion | QuestionnaireResponse.status = completed is the signal; nothing further to track. |
| Composite completion | Single Task per Encounter with businessStatus advancing through extraction, eligibility, consent, and ready-for-clinical; or use CarePlan.status when intake is orchestrated via PlanDefinition (3.8). |
| Incomplete intake | QuestionnaireResponse.status = in-progress; surface via a Task assigned to registration so it doesn’t disappear. |
| Downstream gating | Scheduling, clinical chart, and billing surfaces filter on the chosen completion signal; keep the definition single-sourced.