Intake Data Model | Medplum

On this page

A patient intake form captures a wide range of information in a single interaction — demographics, insurance, medical history, medications, allergies, family history, and consent. In FHIR, this information fans out into many discrete resource types. This page maps out that resource graph, explains how the resources relate to each other, and identifies the US Core profiles that apply.

This page covers:

Resource Graph [​](/content/docs/intake/intake-data-model#resource-graph "Direct link to Resource Graph"/index.html)

Intake processing transforms a single QuestionnaireResponse into multiple FHIR resources. The graph splits naturally into two groups: core identity resources that establish who the patient is and how they're covered, and clinical history resources that capture the patient's medical background.

Core Identity Resources [​](/content/docs/intake/intake-data-model#core-identity-resources "Direct link to Core Identity Resources"/index.html)

Clinical History Resources [​](/content/docs/intake/intake-data-model#clinical-history-resources "Direct link to Clinical History Resources"/index.html)

Resource Role Reference [​](/content/docs/intake/intake-data-model#resource-role-reference "Direct link to Resource Role Reference"/index.html)

Resource Role in Intake Created or Updated Key References
Patient Demographics, contact info, emergency contacts, language preferences, extensions for race/ethnicity/veteran status Usually created (new patient) or updated (returning patient) —
Coverage Insurance information — payor, subscriber ID, relationship to subscriber Created; upserted by beneficiary + payor beneficiary → Patient, payor → Organization
RelatedPerson Insurance subscriber when subscriber is not the patient (e.g., a child on a parent's plan) Created when Coverage.relationship is not self patient → Patient
Consent Treatment consent, privacy practices, payment agreements, advance directives, communication preferences Created (one per consent type) patient → Patient
Observation Social determinants of health (housing, education), smoking status, sexual orientation, pregnancy status Created or upserted by patient + code subject → Patient
AllergyIntolerance Patient-reported allergies with reaction and onset Upserted by patient + code patient → Patient
MedicationRequest Current medications Upserted by subject + code subject → Patient
Condition Medical history / problem list Upserted by subject + code subject → Patient
FamilyMemberHistory Family medical history — condition, relationship, deceased status Upserted by patient + code + relationship patient → Patient
Immunization Vaccination history Upserted by patient + vaccine-code + date patient → Patient
CareTeam Preferred pharmacy Upserted by name + subject subject → Patient, participant.member → Organization

Created vs. Updated

In many real-world flows, the Patient resource already exists by the time the intake form is submitted — because the patient was registered or scheduled first. The intake bot in the Patient Intake Demo creates a new Patient, but your implementation may instead search for and update an existing one. Most clinical history resources (allergies, medications, conditions) use upsertResource to avoid duplicates on resubmission.

US Core Profiles [​](/content/docs/intake/intake-data-model#us-core-profiles "Direct link to US Core Profiles"/index.html)

The intake demo applies US Core profiles to resources where applicable. Adding a profile to meta.profile signals that the resource conforms to the profile's constraints and enables profile-aware validation.

Resource US Core Profile
Patient us-core-patient
Coverage us-core-coverage
AllergyIntolerance us-core-allergyintolerance
MedicationRequest us-core-medicationrequest
Immunization us-core-immunization
CareTeam us-core-careteam
Observation (smoking) us-core-smokingstatus
Observation (sexual orientation) us-core-observation-sexual-orientation

The Patient resource also uses US Core extensions for race (us-core-race), ethnicity (us-core-ethnicity), and veteran status (military-service-veteran-status).

Encounter Linkage [​](/content/docs/intake/intake-data-model#encounter-linkage "Direct link to Encounter Linkage"/index.html)

In many implementations, intake is tied to an Encounter — either a scheduled visit or a walk-in registration. When an Encounter exists:

For visit-based intake orchestrated via PlanDefinition, the $apply operation accepts an encounter parameter that automatically links generated Tasks to that Encounter.

RelatedPerson and Insurance Coverage [​](/content/docs/intake/intake-data-model#relatedperson-and-insurance-coverage "Direct link to RelatedPerson and Insurance Coverage"/index.html)

When the insurance subscriber is someone other than the patient — such as a child covered by a parent's plan — the intake process creates a RelatedPerson resource alongside the Coverage.

For full details on Coverage modeling, insurance card image capture, and payor setup, see Patient Insurance.

Relationship Code Inversion

The relationship code inverts between Coverage and RelatedPerson, and this is one of the most common sources of bugs in intake implementations:

So if Coverage.relationship is child, the corresponding RelatedPerson.relationship should be PRN (parent) — because the RelatedPerson is the parent.

Coverage.relationship RelatedPerson.relationship Why
child PRN (parent) Patient is the child; subscriber is the parent
parent CHILD (child) Patient is the parent; subscriber is the child
spouse / common SPS (spouse) Symmetric relationship

See Also [​](/content/docs/intake/intake-data-model#see-also "Direct link to See Also"/index.html)