Patient
Patient
The Patient resource represents an individual receiving healthcare services. It contains demographics and other administrative information essential for care coordination, billing, and identity management across healthcare systems.
Overview
Maturity (R4+): Normative
The Patient resource achieved normative status in FHIR R4, meaning its structure is stable and backward-compatible changes only.
Common uses
- Patient Demographics: Name, birthdate, gender, address, contact information
- Patient Identification: Medical record numbers, national IDs, insurance member IDs
- Care Team Coordination: Communication preferences, contact persons, primary care provider
- Administrative: Deceased status, multiple birth indicator, photo
Key elements
Identifier
Patient identifiers are crucial for matching and linking records across systems.
{
"resourceType": "Patient",
"identifier": [
{
"use": "official",
"type": {
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/v2-0203",
"code": "MR",
"display": "Medical Record Number"
}]
},
"system": "http://hospital.example.org/patients",
"value": "12345"
}
]
}
Name
Supports multiple names with use qualifiers (official, nickname, maiden, etc.).
{
"name": [
{
"use": "official",
"family": "Smith",
"given": ["John", "Robert"],
"prefix": ["Mr."]
}
]
}
Telecom and address
Addresses, phone numbers, and email with use qualifiers and periods.
{
"telecom": [
{
"system": "phone",
"value": "+1-555-123-4567",
"use": "mobile"
},
{
"system": "email",
"value": "john.smith@example.com",
"use": "home"
}
],
"address": [
{
"use": "home",
"type": "physical",
"line": ["123 Main Street", "Apt 4B"],
"city": "Springfield",
"state": "IL",
"postalCode": "62701",
"country": "US"
}
]
}
Version notes
FHIR R5 Enhancements
New in R5:
deceased[x]now supportsdeceasedStringfor approximate death information (e.g., “early 2020”)contact.periodadded for time-bounded contact relationships- Enhanced search parameters for better patient matching
FHIR R4 (Current Normative)
R4 Features:
- Stable, normative resource structure
- Full support for US Core profiles
- Production-ready for all healthcare systems
STU3 (Legacy)
Differences from R4:
- Simpler
animalelement (deprecated in R5, use extension instead) - Different cardinality on some elements
- Consider migrating to R4 for better interoperability
Search
Common search parameters for Patient:
| Parameter | Type | Description | Example |
|---|---|---|---|
identifier | token | Patient identifier | GET /Patient?identifier=12345 |
name | string | Patient name | GET /Patient?name=Smith |
family | string | Family name | GET /Patient?family=Smith |
given | string | Given name | GET /Patient?given=John |
birthdate | date | Birth date | GET /Patient?birthdate=1980-01-15 |
gender | token | Gender | GET /Patient?gender=male |
phone | token | Phone number | GET /Patient?phone=555-123-4567 |
email | token | Email address | GET /Patient?email=john@example.com |
Implementation considerations
Patient Matching
Patient matching is critical for avoiding duplicate records:
- Use multiple identifiers when available
- Implement fuzzy matching on names (account for typos)
- Consider probabilistic matching algorithms
- Use standardized address formats
Privacy and Security
- Patient resources contain PHI/PII - secure appropriately
- Implement proper consent management
- Use SMART on FHIR scopes:
patient/Patient.read - Consider patient-mediated exchange (patient can control access)
Profiles
US Core Patient Profile
For US implementations, use the US Core Patient Profile:
- Requires: identifier, name, gender, birthDate
- Must support: race, ethnicity, address, telecom
- Recommended: communication (preferred language)
Related resources
- Person: Administrative person (may link multiple Patient resources)
- RelatedPerson: Family members, caregivers, emergency contacts
- Practitioner: Healthcare providers
- PractitionerRole: Provider in specific role at organization