---
type: "resource"
title: "Patient"
resource: "Patient"
---
# Patient
## Introduction
## Scope and Usage
This Resource covers data about patients and animals involved in a wide range of health-related activities, including:
- Curative activities
- Psychiatric care
- Social services
- Pregnancy care
- Nursing and assisted living
- Dietary services
- Tracking of personal health and exercise data
- Tracking financial services (e.g. insurance subscriber/policy holder)
- Public health
- Population health
The data in the Resource covers the "who" information about the patient: its attributes are focused on the demographic information necessary to support the administrative, financial and logistic procedures. A Patient record is generally created and maintained by each organization providing care for a patient. A patient or animal receiving care at multiple organizations may therefore have its information present in multiple Patient Resources.
Not all concepts are included within the base resource (such as race, ethnicity, organ donor status, nationality, etc.), but may be found in [profiles](patient-profiles) defined for specific jurisdictions (e.g., US Meaningful Use Program) or [standard extensions](patient-core). Such fields vary widely between jurisdictions and often have different names and valuesets for the similar concepts, but they are not similar enough to be able to map and exchange.
## Boundaries and Relationships
The Patient resource is the primary resource used to represent the recipient of care, services or processes. Patient is the appropriate resource even when a domain may use a different term for that person, such as client, subscriber, member, guarantor, etc.
There are several resources that can be used to represent an individual:
- Person can be used to link all resources that represent the same individual, including Patient. See the [Patient vs. Person vs. Patient.Link vs. Linkage](patient#linking) section.
- Patient.contact and RelatedPerson may both be used to represent patient contacts. See the [Patient.contact vs. RelatedPerson](patient#contact) section.
- For employee health, a single individual may be represented as both a Patient and a Practitioner. The Patient representation would be used when the individual is the subject of care or services, and the Practitioner would be used when the individual is providing care or services. The Person resource may be used to indicate that the Patient and Practitioner represent the same individual, as described in the [Patient vs. Person vs. Patient.Link vs. Linkage](patient#linking) section.
The Patient resource can be used to represent non-human recipients of care, such as animals. See the [Veterinary Care](patient#veterinary) section. In the case of a collective group of animals, such as a herd, if the individual animal is tracked, then Patient resources would be used to represent each animal. If the individual animals are not tracked, Group would be used to represent the collective.
Patient resources may be used in multiple contexts. For example, in the financial context, the Patient may fill the role of [guarantors](account-definitions#Account.guarantor), [subscribers](coverage-definitions#Coverage.subscriber), [beneficiaries](coverage-definitions#Coverage.beneficiary), or other financial actors. In this case, different Patient resource instances may be used if the patient had different demographics that are relevant for each context.
## Notes
Notes:
- multipleBirth can be either expressed as a Boolean (just indicating whether the patient is part of a multiple birth) or as an integer, indicating the actual birth order.
- Patient records may only be in one of two statuses: in use (active=true) and not in use (active=false). A normal record is active, i.e. it is in use. Active is set to 'false' when a record is created as a duplicate or in error. A record does not need to be linked to be inactivated.
- The _link_ element is used to assert that two or more Patient resources are both about the same actual patient. See below for further discussion
- There should be only one preferred language (Language.preference = true) per mode of expression.
- The Contact for a Patient has an element _organization_, this is for use with guardians or business related contacts where just the organization is relevant.
## Patient ids and Patient resource ids
A Patient record's [Resource Id](resource#id) can never change. For this reason, the identifiers with which humans are concerned (often called MRN - Medical Record Number, or UR - Unit Record) should not be used for the resource's id, since MRN's may change, i.e. as a result of having duplicate records of the same patient. Instead they should be represented in the _Patient.identifier_ list where they can be managed. This is also useful for the case of institutions that have acquired multiple numbers because of mergers of patient record systems over time.
Where there is a need to implement an automated MRN Identifier created for a patient record, this could be achieved by providing an identifier in the patient with an appropriate assigner, MRN Type and/or system but with _no value_ assigned. Internal business rules can then detect this and replace/populate this identifier with 1 or more identifiers (as required).
## Merging records
There are two common approaches for resolving duplicate patient records: merging and linking. Linking duplicate patients is described in the [Linking Patients](#links) section, or merging duplicate patients as described in the [$merge](https://build.fhir.org/ig/HL7/admin-incubator/branches/main/en/OperationDefinition-Patient-merge.html) operation page.
## Linking Patients
The _link_ element is used to assert that patient resources refer to the same patient. This element is used to support the following scenarios where multiple patient records exist:
### Duplicate Patient records
Managing Patient registration is a well-known difficult problem. Around 2% of registrations are in error, mostly duplicate records. Sometimes the duplicate record is caught fairly quickly and retired before much data is accumulated. In other cases, substantial amounts of data may accumulate.
There are two common approaches for resolving duplicate patient records: merging and linking. Merging duplicate patients is described in the [$merge](https://build.fhir.org/ig/HL7/admin-incubator/branches/main/en/OperationDefinition-Patient-merge.html) operation page.
Linking duplicate records can be accomplished by using a link of type 'replaced-by' where the record containing such a link is marked as a duplicate and the link points forward to a record that should be used instead. Note that the record pointed to may in its turn have been identified as created in error and forward to yet another Patient resource. Records that replace another record _may_ use a link type of 'replaces' pointing to the old record.
### Patient record in a Patient index
A Patient record may be present in a system that acts as a Patient Index: it maintains a (summary of) patient data and a list of one or more servers that are known to hold a more comprehensive and/or authoritative record of the same patient. The link type 'refer' is used to denote such a link. Note that linked records may contain contradictory information. The record referred to does not point back to the referring record.
### Distributed Patient record
In a distributed architecture, multiple systems keep separate patient records concerning the same patient. These records are not considered duplicates, but contain a distributed, potentially overlapping view of the patient's data. Each such record may have its own focus or maintaining organization and there need not be a sense of one record being more complete or more authoritative than another. In such cases, links of type 'see also' can be used to point to other patient records. It is not a requirement that such links are bilateral.
## Patient vs. Person vs. Patient.Link vs. Linkage
The Person resource on the surface appears to be very similar to the Patient resource, and the usage for it is very similar to using the Patient.Link capability.
The intention of the Person resource is to be able to link instances of resources together that are believed to be the same individual. This includes across resource types, such as RelatedPerson, Practitioner, Patient and even other Person resources.
The primary use case for the Person resource is to be able to support person registries that do not necessarily have a healthcare context, and are able to identify and quantify confidence levels that this is the same person.
This could include consumer portals where the maintainer of the person information is the actual person themselves.
A system could use the Person entry to cross check changes to information applied to one part of a record to values in another system; e.g., when moving, a consumer updates his contact numbers and address in his person record, and then a Patient Administration system is able to see that this data is changed and prompt the organization to follow up with the patient that was linked to the person record if they want their details updated, or if they no longer need services and they should be cancelled, as they've moved from the area.
The [Linkage](https://build.fhir.org/ig/HL7/pc-incubator/StructureDefinition-Linkage.html) resource and the Patient.link property conceptually perform similar functions in FHIR, both provide an assertion of linkages between multiple resource instances that are referring to the same underlying individual.
When a Patient resource is linked/merged then it needs to have an internal indication that there is another patient resource that should be considered when referencing other records, which is achieved using the patient.link property.
Not detecting/checking for a potential linkage could mean that related clinical records are not discovered, potentially impacting patient safety. (which is why using the Linkage resource is not appropriate, as its use in this manner would force the use of either another query to potentially locate other patient resources to consider, or use \_revinclude)
Therefore, the Linkage Resource should not be used in these cases:
- Linking patients - that should use Patient.link
- Linking individuals - that should use Person as the linking resource
- Linking encounters - that should use the new Encounter.link Extension
## Patient.contact vs. RelatedPerson
The contact element on the Patient resource should be used for storing the details of people to contact. This information always travels with the Patient resource, and cannot be used as the target of a reference. Where related people need to be referenced by other resources (e.g. CarePlan.participant, Encounter.participant, DocumentReference.author, Appointment.participant), the RelatedPerson resource must be used.
It is not expected that these records will be used for recording the primary care provider; this information should be stored in the Patient.generalPractitioner field.
## Patient Gender and Sex
Many systems and organizations only provide for a single attribute that aspires to represent all aspects of a patient's gender and sex with a single value. However, there are many considerations around sex and gender documentation and interoperability. Listed below are various social and biological attributes that are relevant in the healthcare setting, as well as information on how each can be communicated. Each of these attributes may be useful to address different use cases, and it is up to the implementer to identify which attribute or combination of attributes are most appropriate.
- **Administrative Gender** - in order to interoperate with systems that use a single generic property, the basic [Patient.gender](patient-definitions#Patient.gender) property represents an administrative gender: the gender that the patient is considered to have for administration and record keeping purposes. This property is often used as an input to patient matching algorithms. Systems should not infer any specific clinical meaning from Patient.gender without pre-coordination with exchange partners.
- **Gender Identity** - a gender the patient has indicated they consider themselves to be. The gender identity can influence how the patient prefers to be addressed by care providers and other individuals. The standard [genderIdentity]([%extensions-location%]StructureDefinition-individual-genderIdentity) extension may be used to communicate this property. When determining how to address the patient, the [pronouns]([%extensions-location%]StructureDefinition-individual-pronouns) extension may also be applicable.
- **Sex Parameter for Clinical Use (SPCU)** - a parameter that provides guidance on how a recipient should apply settings or reference ranges that are derived from observable information such as an organ inventory, recent hormone lab tests, genetic testing, menstrual status, obstetric history, etc.. This property is intended for use in clinical decision making, and indicates that treatment or diagnostic tests should consider best practices associated with the relevant reference population. The standard [sexParameterForClinicalUse]([%extensions-location%]StructureDefinition-patient-sexParameterForClinicalUse) extension may be used to communicate this property.
- **Clinical Observations about sex characteristics** - a testable observation about a biological property of the patient. This could include karyotypic sex, genetic sex, chromosomal sex, gonadal sex, ductal sex, hormone levels, or various other phenotypic attributes. Clinical observations about sex characteristics should be represented using [Observation](observation), qualified with the appropriate clinical codes from LOINC, SNOMED, or other relevant clinical terminologies. These observations may serve as supporting information for the Sex Parameters for Clinical Use categorization.
- **Recorded Sex or Gender (RSG)** - recorded sex or gender information includes the various sex and gender concepts that are often used in existing systems but are known NOT to represent a gender identity, sex parameter for clinical use, or attributes related to sexuality, such as sexual orientation, sexual activity, or sexual attraction. Examples of recorded sex or gender concepts include administrative gender, administrative sex, legal sex, and sex assigned at birth. When exchanging these concepts, refer to the guidance in the [Gender Harmony Implementation Guide.](http://hl7.org/xprod/ig/uv/gender-harmony/)
- **Legal Sex** - a sex value documented on a legal document, such as a passport, driver's license, birth certificate, or other document. Regional and national entities often categorize citizens using a single legal sex value. The legal sex of a patient can vary from region to region and country to country. A single patient may have multiple legal sex values at the same time in different jurisdictions, or even on different legal documents within a single jurisdiction. In cases where the Patient.gender administrative property is not sufficient to communicate legal sex, refer to the guidance in the [Gender Harmony Implementation Guide](http://hl7.org/xprod/ig/uv/gender-harmony/).
- **Sex assigned at Birth** - the sex assigned at birth is a sex or gender value assigned to a patient at birth. This value is often documented on the birth registration. Some jurisdictions allow variations such as not yet determined, unknown, or undifferentiated, while others do not. Some jurisdictions also allow birth registration information to be updated. The sex assigned at birth may often be a poor approximation of the patient's current sex for clinical use, especially for adult patients. See [sexParameterForClinicalUse]([%extensions-location%]StructureDefinition-patient-sexParameterForClinicalUse) as a way to communicate a patient's current sex for clinical use. Refer to the guidance in the [Gender Harmony Implementation Guide](http://hl7.org/xprod/ig/uv/gender-harmony/) for options to exchange this concept.
For veterinary use, the animal extension also includes the genderStatus which indicates sterility information.
## Mother and newborn relationships
There are several ways to represent the relationship between a mother and a child. This variability is due to the timing when it is recorded and the purpose for which it is recorded:
- To express the family relationship and legal responsibility thereof for administrative purposes: use the Patient/RelatedPerson structure.
This structure is consistent over time.
- To relate the encounters of a mother and her baby in a maternity encounter, for administrative and billing purposes: use the [encounter.partof](encounter-definitions#Encounter.partOf) property
- To collect information about the patient's relatives that might be relevant to the patient's medical condition: use the [FamilyMemberHistory](familymemberhistory) resource
During a maternity encounter, the Patient and Encounter resources for the mother will be present. After the child is born, new Patient, Encounter and RelatedPerson (for the mother) records will be created. The Child's encounter should reference the Mother's encounter using the partOf property.
The Patient/RelatedPerson structure should also be created for ongoing usage, as shown in this example:
## Patient Matching using an MPI
A Master Patient Index ([MPI](http://en.wikipedia.org/wiki/Enterprise_master_patient_index)) is a service used to manage patient identification in a context where multiple patient databases exist. Healthcare applications and middleware use the MPI to match patients between the databases, and as new patient details are encountered. MPIs are highly specialized applications, often tailored extensively to the institution's particular mix of patients. MPIs can also be run on a regional and national basis.
To ask an MPI to match a patient, clients call the patient [$match](patient-operation-match) operation, which processes a parameters resource containing a complete or fragment of a patient resource, along with some other control parameters.
This provided patient resource does not need to pass full validation (mandatory fields, or invariants) as the resource will not be stored, it does however need to be a parsable instance.
The MPI can then use the properties of the resource as MPI inputs, and process them using an internal MPI algorithm of some kind to determine the most appropriate matches in the patient set. It does not have to use all the properties provided, and may ignore others provided quietly.
A specific profile (with the required fields/invariants) can be used to define what parameters the MPI algorithm requires.
POST \[base\]/Patient/$match
\[some headers including content-type xml or json\]
\[parameters body with patient resource inside\]
The response from an MPI $match operation is a set of patient records, ordered from most likely to least likely. If there are not patient matches, the MPI SHALL return an empty search set with no error, but may include an [operation outcome](operationoutcome) with further advice. All patient records should have a score from 0 to 1, where 1 is the most certain match, along with an [extension](extensibility) ["match-grade"]([%extensions-location%]StructureDefinition-match-grade) that indicates the MPI's position on the match quality:
The match-grade extension has one of the [following codes]([%extensions-location%]ValueSet-match-grade):
\[%codelist-nh http://terminology.hl7.org/CodeSystem/match-grade%\]
The purpose of using an MPI search versus a regular search is that the MPI search is really intended to target and find a specific single patient for recording information about reducing errors through incorrectly selecting the wrong patient. Often MPIs won't return data if there is insufficient search parameter data, such as a partial surname.
This compares to a regular search which can be used for finding lists of patients, such as to locate a group of patients that share a property in common, such as live in a specific location, or fit within an age range for performing population analysis.
A [formal definition](operation-patient-match) for the MPI $match operation is published.
## Veterinary Care
Veterinary care is very much within the scope of FHIR, and the Patient resource can be used to communicate information about animal patients. To support this, there is a standard [patient-animal extension]([%extensions-location%]StructureDefinition-patient-animal) which can be used for recording details about species, breed, and gender status. This extension is not intended to cover all relevant properties for veterinary care, and the use of additional domain-relevant extensions is expected for areas such as laboratory, zoological and livestock care.
The veterinary client ("owner") is represented using the RelatedPerson resource.
## StructureDefinition
### Elements (Simplified)
- **[Patient](/patient-definitions#Patient)** [0..*]: - Information about an individual or animal receiving health care services
- **[Patient.identifier](/patient-definitions#Patient.identifier)** [0..*]: [Identifier](/Identifier) An identifier for this patient
- **[Patient.active](/patient-definitions#Patient.active)** [0..1]: [boolean](/boolean) Whether this patient's record is in active use
- **[Patient.name](/patient-definitions#Patient.name)** [0..*]: [HumanName](/HumanName) A name associated with the patient
- **[Patient.telecom](/patient-definitions#Patient.telecom)** [0..*]: [ContactPoint](/ContactPoint) A contact detail for the individual
- **[Patient.gender](/patient-definitions#Patient.gender)** [0..1]: [code](/code) required:[administrative-gender](/valueset-administrative-gender) male | female | other | unknown
- **[Patient.birthDate](/patient-definitions#Patient.birthDate)** [0..1]: [date](/date) The date of birth for the individual
- **[Patient.deceased[x]](/patient-definitions#Patient.deceased%5Bx%5D)** [0..1]: [boolean](/boolean), [dateTime](/dateTime) Indicates if/when the individual is deceased
- **[Patient.address](/patient-definitions#Patient.address)** [0..*]: [Address](/Address) An address for the individual
- **[Patient.maritalStatus](/patient-definitions#Patient.maritalStatus)** [0..1]: [CodeableConcept](/CodeableConcept) extensible:[marital-status](/valueset-marital-status) Marital (civil) status of a patient
- **[Patient.multipleBirth[x]](/patient-definitions#Patient.multipleBirth%5Bx%5D)** [0..1]: [boolean](/boolean), [integer](/integer) Whether patient is part of a multiple birth
- **[Patient.photo](/patient-definitions#Patient.photo)** [0..*]: [Attachment](/Attachment) Image of the patient
- **[Patient.contact](/patient-definitions#Patient.contact)** [0..*]: [BackboneElement](/BackboneElement) A contact party (e.g. guardian, partner, friend) for the patient
- **[Patient.contact.relationship](/patient-definitions#Patient.contact.relationship)** [0..*]: [CodeableConcept](/CodeableConcept) preferred:[v3-PersonalRelationshipRoleType](/valueset-v3-PersonalRelationshipRoleType) The kind of personal relationship
- **[Patient.contact.role](/patient-definitions#Patient.contact.role)** [0..*]: [CodeableConcept](/CodeableConcept) preferred:[relatedperson-relationshiptype](/valueset-relatedperson-relationshiptype) The kind of functional role
- **[Patient.contact.name](/patient-definitions#Patient.contact.name)** [0..1]: [HumanName](/HumanName) A name associated with the contact person
- **[Patient.contact.additionalName](/patient-definitions#Patient.contact.additionalName)** [0..*]: [HumanName](/HumanName) Additional names for the contact person
- **[Patient.contact.telecom](/patient-definitions#Patient.contact.telecom)** [0..*]: [ContactPoint](/ContactPoint) A contact detail for the person
- **[Patient.contact.address](/patient-definitions#Patient.contact.address)** [0..1]: [Address](/Address) Address for the contact person
- **[Patient.contact.additionalAddress](/patient-definitions#Patient.contact.additionalAddress)** [0..*]: [Address](/Address) Additional addresses for the contact person
- **[Patient.contact.gender](/patient-definitions#Patient.contact.gender)** [0..1]: [code](/code) required:[administrative-gender](/valueset-administrative-gender) male | female | other | unknown
- **[Patient.contact.organization](/patient-definitions#Patient.contact.organization)** [0..1]: Reference([Organization](/Organization)) Organization that is associated with the contact
- **[Patient.contact.period](/patient-definitions#Patient.contact.period)** [0..1]: [Period](/Period) The period during which this contact person or organization is valid to be contacted relating to this patient
- **[Patient.communication](/patient-definitions#Patient.communication)** [0..*]: [BackboneElement](/BackboneElement) A language which may be used to communicate with the patient about his or her health
- **[Patient.communication.language](/patient-definitions#Patient.communication.language)** [1..1]: [CodeableConcept](/CodeableConcept) required:[all-languages](/valueset-all-languages) The language which can be used to communicate with the patient about his or her health
- **[Patient.communication.preferred](/patient-definitions#Patient.communication.preferred)** [0..1]: [boolean](/boolean) Language preference indicator
- **[Patient.generalPractitioner](/patient-definitions#Patient.generalPractitioner)** [0..*]: [Reference(Organization](/Reference(Organization), [Practitioner](/Practitioner), [PractitionerRole)](/PractitionerRole)) Patient's nominated primary care provider
- **[Patient.managingOrganization](/patient-definitions#Patient.managingOrganization)** [0..1]: Reference([Organization](/Organization)) Organization that is the custodian of the patient record
- **[Patient.link](/patient-definitions#Patient.link)** [0..*]: [BackboneElement](/BackboneElement) Link to a Patient or RelatedPerson resource that concerns the same actual individual
- **[Patient.link.other](/patient-definitions#Patient.link.other)** [1..1]: [Reference(Patient](/Reference(Patient), [RelatedPerson)](/RelatedPerson)) The other patient or related person resource that the link refers to
- **[Patient.link.type](/patient-definitions#Patient.link.type)** [1..1]: [code](/code) required:[link-type](/valueset-link-type) replaced-by | replaces | refer | seealso
## Mappings
- [Patient Mappings](/patient-mappings) — 105 mapping entries
## Implementation Guide
### implementationguide-Patient-core.xml
```xml
```
## Operations
- [match](/patient-operation-match) — Find patient matches using MPI based logic — A Master Patient Index ([MPI](http://en.wikipedia.org/wiki/Enterprise_master_patient_index) ) is a service used to manage patient identification in a context where multiple patient databases exist.
- [purge](/patient-operation-purge) — Purge Patient Record — This operation is used to request the removal of all current and historical versions for all resources in a patient compartment.
[Full Operations](/patient-operations)
## Resource Packs
### list-Patient-packs.xml
```xml
```
## Search Parameters
- [active](/patient-search#active) — **token** — Whether the patient record is active — `Patient.active`
- [address](/patient-search#address) — **string** — A server defined search that may match any of the string fields in the Address, including line, city, district, state, country, postalCode, and/or text — `Patient.address`
- [address-city](/patient-search#address-city) — **string** — A city specified in an address — `Patient.address.city`
- [address-country](/patient-search#address-country) — **string** — A country specified in an address — `Patient.address.country`
- [address-postalcode](/patient-search#address-postalcode) — **string** — A postalCode specified in an address — `Patient.address.postalCode`
- [address-state](/patient-search#address-state) — **string** — A state specified in an address — `Patient.address.state`
- [address-use](/patient-search#address-use) — **token** — A use code specified in an address — `Patient.address.use`
- [birthdate](/patient-search#birthdate) — **date** — The patient's date of birth — `Patient.birthDate`
- [death-date](/patient-search#death-date) — **date** — The date of death has been provided and satisfies this search value — `(Patient.deceased.ofType(dateTime))`
- [deceased](/patient-search#deceased) — **token** — This patient has been marked as deceased, or has a death date entered — `Patient.deceased.exists() and Patient.deceased != false`
- [email](/patient-search#email) — **token** — A value in an email contact — `Patient.telecom.where(system='email')`
- [family](/patient-search#family) — **string** — A portion of the family name of the patient — `Patient.name.family`
- [gender](/patient-search#gender) — **token** — Gender of the patient — `Patient.gender`
- [general-practitioner](/patient-search#general-practitioner) — **reference** — Patient's nominated general practitioner, not the organization that manages the record — `Patient.generalPractitioner`
- [given](/patient-search#given) — **string** — A portion of the given name of the patient — `Patient.name.given`
- [identifier](/patient-search#identifier) — **token** — A patient identifier — `Patient.identifier`
- [language](/patient-search#language) — **token** — Language code (irrespective of use value) — `Patient.communication.language`
- [link](/patient-search#link) — **reference** — All patients/related persons linked to the given patient — `Patient.link.other`
- [name](/patient-search#name) — **string** — A server defined search that may match any of the string fields in the HumanName, including family, given, prefix, suffix, and/or text — `Patient.name`
- [organization](/patient-search#organization) — **reference** — The organization that is the custodian of the patient record — `Patient.managingOrganization`
- [phone](/patient-search#phone) — **token** — A value in a phone contact — `Patient.telecom.where(system='phone')`
- [phonetic](/patient-search#phonetic) — **string** — A portion of either family or given name using some kind of phonetic matching algorithm — `Patient.name`
- [telecom](/patient-search#telecom) — **token** — The value in any kind of telecom details of the patient — `Patient.telecom`
[Full Search Parameters](/patient-search)
## Examples
- [animal](/patient-example-animal) — patient-example-animal — An example of an animal
- [b248b1b2-1686-4b94-9936-37d7a5f94b51](/patient-example-b248b1b2-1686-4b94-9936-37d7a5f94b51) — patient-examples-general — Stock people (defined by HL7 publishing)
- [b3f24cf14-d349-45b3-8134-3d83e9104875](/patient-example-b3f24cf14-d349-45b3-8134-3d83e9104875) — patient-examples-cypress-template — Example People from cypress project
- [ch-example](/patient-example-ch-example) — patient-example-chinese — Example Patient resource with Chinese content
- [dicom](/patient-example-dicom) — patient-example-dicom — Taken from a DICOM sample
- [example](/patient-example-example) — patient-example — General Person Example
- [f001](/patient-example-f001) — patient-example-f001-pieter — Real-world patient example (anonymized)
- [f201](/patient-example-f201) — patient-example-f201-roel — Real-world patient example (anonymized)
- [genetics-example1](/patient-example-genetics-example1) — patient-genetics-example1 — Additional Genetics Example
- [glossy](/patient-example-glossy) — patient-glossy-example — Example for glossy
- [ihe-pcd](/patient-example-ihe-pcd) — patient-example-ihe-pcd — Example from IHE-PCD example
- [infant-fetal](/patient-example-infant-fetal) — patient-example-infant-fetal — Pre-birth fetal infant Example
- [infant-mom](/patient-example-infant-mom) — patient-example-infant-mom — Mother of infant twins and fetal infant.
- [infant-twin-1](/patient-example-infant-twin-1) — patient-example-infant-twin-1 — Newborn Eldest Twin Example
- [infant-twin-2](/patient-example-infant-twin-2) — patient-example-infant-twin-2 — Newborn Youngest Twin Example
- [mom](/patient-example-mom) — patient-example-mom — Mother of Newborn Patient Example
- [newborn](/patient-example-newborn) — patient-example-newborn — Newborn Patient Example
- [pat1](/patient-example-pat1) — patient-example-a — Patient 1 for linking
- [pat2](/patient-example-pat2) — patient-example-b — Patient 2 for linking
- [pat3](/patient-example-pat3) — patient-example-c — Deceased patient (using time)
- [pat4](/patient-example-pat4) — patient-example-d — Deceased patient (using boolean)
- [patient-example](/patient-example-patient-example) — patient-example
- [patient-example-a](/patient-example-patient-example-a) — patient-example-a
- [patient-example-animal](/patient-example-patient-example-animal) — patient-example-animal
- [patient-example-b](/patient-example-patient-example-b) — patient-example-b
- [patient-example-c](/patient-example-patient-example-c) — patient-example-c
- [patient-example-chinese](/patient-example-patient-example-chinese) — patient-example-chinese
- [patient-example-d](/patient-example-patient-example-d) — patient-example-d
- [patient-example-dicom](/patient-example-patient-example-dicom) — patient-example-dicom
- [patient-example-f001-pieter](/patient-example-patient-example-f001-pieter) — patient-example-f001-pieter
- [patient-example-f201-roel](/patient-example-patient-example-f201-roel) — patient-example-f201-roel
- [patient-example-ihe-pcd](/patient-example-patient-example-ihe-pcd) — patient-example-ihe-pcd
- [patient-example-infant-fetal](/patient-example-patient-example-infant-fetal) — patient-example-infant-fetal
- [patient-example-infant-mom](/patient-example-patient-example-infant-mom) — patient-example-infant-mom
- [patient-example-infant-twin-1](/patient-example-patient-example-infant-twin-1) — patient-example-infant-twin-1
- [patient-example-infant-twin-2](/patient-example-patient-example-infant-twin-2) — patient-example-infant-twin-2
- [patient-example-mom](/patient-example-patient-example-mom) — patient-example-mom
- [patient-example-newborn](/patient-example-patient-example-newborn) — patient-example-newborn
- [patient-example-proband](/patient-example-patient-example-proband) — patient-example-proband
- [patient-example-sex-and-gender](/patient-example-patient-example-sex-and-gender) — patient-example-sex-and-gender — Transgender Person Example
- [patient-example-us-extensions](/patient-example-patient-example-us-extensions) — patient-example-us-extensions
- [patient-example-xcda](/patient-example-patient-example-xcda) — patient-example-xcda
- [patient-example-xds](/patient-example-patient-example-xds) — patient-example-xds
- [patient-examples-cypress-template](/patient-example-patient-examples-cypress-template) — patient-examples-cypress-template
- [patient-examples-general](/patient-example-patient-examples-general) — patient-examples-general
- [patient-examples-header](/patient-example-patient-examples-header) — patient-examples-header
- [proband](/patient-example-proband) — patient-example-proband — Genetic Risk Assessment Person
- [xcda](/patient-example-xcda) — patient-example-xcda — 2nd person example
- [xds](/patient-example-xds) — patient-example-xds — XDS Patient
[Full Examples](/patient-examples)
## Mapping Exceptions
### patient-fivews-mapping-exceptions.xml
### Unmapped Elements
- **FiveWs.what** — Unknown
- **FiveWs.recorded** — Unknown
- **FiveWs.author** — Unknown
- **FiveWs.actor** — Unknown
- **FiveWs.cause** — Unknown
- **FiveWs.version** — Unknown
- **FiveWs.witness** — Unknown
- **FiveWs.class** — Unknown
- **FiveWs.where** — Unknown
- **FiveWs.context** — Unknown
- **FiveWs.init** — Unknown
- **FiveWs.why** — Unknown
- **FiveWs.source** — Unknown
- **FiveWs.who** — Unknown
- **FiveWs.grade** — Unknown
- **FiveWs.planned** — Unknown
- **FiveWs.done** — Unknown
- **FiveWs.subject** — Unknown
### patient-participant-mapping-exceptions.xml
### Divergent Elements
- **Participant.identifier** → **Patient.identifier**
- shortUnmatched | reason=Unknown | pattern=Business Identifier for patient | resource=An identifier for this patient
- definitionUnmatched | reason=Unknown | pattern=Business identifiers assigned to this patient by one of the applications involved. These identifiers remain constant as the resource is updated and propagates from server to server. | resource=An identifier for this patient.
- commentsUnmatched | reason=Unknown | pattern=Note: This is a business identifier, not a resource identifier (see [discussion](resource.html#identifiers)). It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and a Person resource instance might share the same social insurance number. | resource=Systems MAY use identifier for user identities (using the type='USER'). Refer to the [Security and Privacy](administration-module.html#secpriv) section for additional guidance on representing user identities.
- requirementsUnmatched | reason=Unknown | pattern=Allows identification of the patient as it is known by various participating systems and in a way that remains consistent across servers. | resource=Patients are almost always assigned specific numerical identifiers.
- **Participant.active** → **Patient.active**
- shortUnmatched | reason=Unknown | pattern=Whether the patient is currently active | resource=Whether this patient's record is in active use
- **Participant.name** → **Patient.name**
- missingTypes | reason=Unknown | pattern=string
- extraTypes | reason=Unknown
- shortUnmatched | reason=Unknown | pattern=A name for the patient | resource=A name associated with the patient
- definitionUnmatched | reason=Unknown | pattern=Description of the patient as presented to a consumer while searching. | resource=A name associated with the individual.
### patient-participantcontactable-mapping-exceptions.xml
### Divergent Elements
- **ParticipantContactable.telecom** → **Patient.telecom**
- shortUnmatched | reason=Unknown | pattern=A contact detail for the patient | resource=A contact detail for the individual
- definitionUnmatched | reason=Unknown | pattern=A contact detail (e.g. a telephone number or an email address) by which the patient may be contacted. | resource=A contact detail (e.g. a telephone number or an email address) by which the individual may be contacted.
- requirementsUnmatched | reason=Unknown | pattern=Participants have (primary) ways to contact them in some way such as phone, email. | resource=People have (primary) ways to contact them in some way such as phone, email.
- **ParticipantContactable.address** → **Patient.address**
- shortUnmatched | reason=Unknown | pattern=An address for the patient | resource=An address for the individual
- definitionUnmatched | reason=Unknown | pattern=An address where the patient can be reached. | resource=An address for the individual.
### Unmapped Elements
- **Participant.identifier** — Unknown
- **Participant.name** — Unknown
- **Participant.active** — Unknown
### patient-participantliving-mapping-exceptions.xml
### Divergent Elements
- **ParticipantLiving.birthDate** → **Patient.birthDate**
- summary | reason=Unknown | pattern=false
- shortUnmatched | reason=Unknown | pattern=The date of birth for the patient | resource=The date of birth for the individual
- definitionUnmatched | reason=Unknown | pattern=The date when the patient was born. | resource=The date of birth for the individual.
- requirementsUnmatched | reason=Unknown | pattern=Used for identity verification and may drive other business processes. | resource=Age of the individual drives many clinical processes.
- **ParticipantLiving.gender** → **Patient.gender**
- summary | reason=Unknown | pattern=false
- **ParticipantLiving.photo** → **Patient.photo**
- shortUnmatched | reason=Unknown | pattern=Image of the {{title} | resource=Image of the patient
- definitionUnmatched | reason=Unknown | pattern=A facial image of the patient. | resource=Image of the patient.
- requirementsUnmatched | reason=Unknown | pattern=Many EHR systems have the capability to capture an image of the participant. Fits with newer social media usage too. | resource=Many EHR systems have the capability to capture an image of the patient. Fits with newer social media usage too.
- **ParticipantLiving.communication** → **Patient.communication**
- missingTypes | reason=Unknown | pattern=CodeableConcept
- extraTypes | reason=Unknown
- shortUnmatched | reason=Unknown | pattern=Language used by patient | resource=A language which may be used to communicate with the patient about his or her health
- definitionUnmatched | reason=Unknown | pattern=The language which can be used to communicate with the patient. | resource=A language which may be used to communicate with the patient about his or her health.
- commentsUnmatched | reason=Unknown | pattern=The ISO-639-1 alpha 2 code in lower case for the language, optionally followed by a hyphen and the ISO-3166-1 alpha 2 code for the region in upper case; e.g. "en" for English, or "en-US" for American English versus "en-AU" for Australian English. | resource=If no language is specified, this *implies* that the default local language is spoken. If you need to convey proficiency for multiple modes, then you need multiple Patient.Communication associations. For animals, language is not a relevant field, and should be absent from the instance. If the Patient does not speak the default local language, then the Interpreter Required Standard can be used to explicitly declare that an interpreter is required.
- requirementsUnmatched | reason=Unknown | pattern=Most systems in multilingual countries will want to convey language. Not all systems actually need the regional dialect. | resource=If a patient does not speak the local language, interpreters may be required, so languages spoken and proficiency are important things to keep track of both for patient and other persons of interest.
### Unmapped Elements
- **Participant.identifier** — Unknown
- **Participant.name** — Unknown
- **Participant.active** — Unknown
- **ParticipantContactable.address** — Unknown
- **ParticipantContactable.telecom** — Unknown