This page is part of the FHIR Specification (v0.01: Historical Archive Draft). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2
Patient
A patient is a person or animal that is receiving care.
The relative url is /patients
Content
<Patient xmlns="http://www.hl7.org/fhir">
<id> mand id Master Resource Id, always first in all resources</id>
<link> mand Zero+ (Patient) Other patients linked to this resource</link>
<active> mand boolean Whether this patient record is active (in use)</active>
<person> cond (Person) The person who is the patient</person>
<animal> cond (Animal) The animal which is the patient</animal>
<provider> mand (Organization) Organization managing the patient</provider>
<identifier> Zero+ HumanId An identifier for the person as this patient</identifier>
<diet> opt CodeableConcept Dietary restrictions for the patient</diet>
<confidentiality> opt CodeableConcept Confidentiality of the patient records</confidentiality>
<recordLocation> opt CodeableConcept Where the paper record is</recordLocation>
<extensions> opt See Extensions See Extensions </extensions>
<text> mand Narrative Text summary of person, for human interpretation</text>
</Patient>
Schema for Patient and an example (or formatted for browser)
Terminology Bindings
- Patient.diet is bound to the concept domain PatientDiet: "casual dietary restrictions associated with this patient"
- Patient.confidentiality is bound to the concept domain PatientConfidentiality: "The confidentiality of the records associated with this patient"
- Patient.recordLocation is bound to the concept domain PaperRecordLocation: "A physical location for a record. (Usually site specific)"
Notes:
- Links: linking patient records is an assertion that they both are about the same actual person. If any patient record is linked to another, then the other must be linked back to the source record.
- The patient may be a person or an animal (in order to support vetinary medicine). Either a person or an animal resource link must be provided, but not both.
- The dietary restrictions are not for specifying medical diets, but for casual dietary restrictions such as vegetarian, diary-free, nut-free, etc
Managing Patient Registration
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. For these and other
reasons, the identifiers associated with a patient may change over time.
The master identifier for the Patient Resource 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 as the master identifier. 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.
In this specification, patient records are never merged. If multiple patient records are found to be
duplicates, they are linked. In a RESTful context, this is done using the "link patients" transaction
described below. In other contexts, equivalent functionality will be needed. When patient resources
are linked, one may be chosen as the "master" - the correct record. In this case, the active status
of all the other resources is set to false, and all the content is moved to the active record by updating
it directly.
Patient records may only be in one of two statuses: active and retired. A normal record is active
- it is in use. The status retired is used when a record is created in error. Once the error is
discovered, it can either be retired or deleted. A record does not need to be linked to be retired.
RESTful Transactions
The patient resource type defines one special transaction provided by the patient manager: "Link" for
linking resources. The reason is that linking records is effectively a transaction that involves at
least two resources, and all or none must change. Since the transaction involves multiple resources,
it is implemented on the resource manager as a POST to [todo]
There is no content model for the response, except for an HTTP status code.
Searching Criteria
The following simple search/filter parameters are defined for person:
person | The identity of a person |
provider | The identity of an organization |
id | search id in any patient identifiers |
The standard search parameters also apply (see Searching).
Formal Definitions
The formal definitions for the elements above. Also available as an XML file.
Patient |
Definition | A patient is a person or animal that is receiving care |
Control | Mandatory, 1..1 |
Requirements | Tracking patient is the center of the healthcare process |
RIM Mapping | Patient |
Patient.id |
Definition | Master Resource Id, always first in all resources |
Control | Mandatory, 1..1 |
Type | id |
To Do | .id(scope=OBJ) |
Patient.link |
Definition | A linked patient record is a record that concerns the same patient. Records are linked after it is realised that at least one was created in error. |
Control | Mandatory, 0..* |
Type | Resource(Patient) |
Must Understand | true |
Requirements | Due to the clerical errors associated with the difficulties of identifying humans consistently, duplicate patient records are frequently created in error |
Comments | More then two patient records may be linked. Note that there is a special transaction for linking patient records in the RESTful context, as record linking consistency must be maintained |
Patient.active |
Definition | Whether the patient record is in use, or has been removed from active use |
Control | Mandatory, 1..1 |
Type | boolean |
Must Understand | true |
Requirements | Need to be able to mark a patient record as not to be used because it was created in error |
Comments | If a record is inactive, and linked to an active record, then future patient/person/record updates should occur on the other patient |
Patient.person |
Definition | The person that this patient record is about |
Control | Conditional, 0..1: Either an animal or a person must be provided, but not both |
Type | Resource(Person) |
Must Understand | true |
Requirements | Need to link this patient record to a known and identifiable person (or animal) |
Patient.animal |
Definition | The animal that this patient record is about |
Control | Conditional, 0..1: Either an animal or a person must be provided, but not both |
Type | Resource(Animal) |
Requirements | Need to link this patient record to a known and identifiable animal (or person) |
Patient.provider |
Definition | The provider for whom this is a patient record |
Control | Mandatory, 1..1 |
Type | Resource(Organization) |
Must Understand | true |
Requirements | Need to know who recognises this patient record |
To Do | But is thie same as institution above? |
Patient.identifier |
Definition | An identifier that applies to this person as a patient |
Control | 0..* |
Type | HumanId |
Must Understand | true |
Requirements | Patients are almos always assigned specific numerical identifiers |
Patient.diet |
Definition | Dietary restrictions for the patient |
Control | Optional, 0..1 |
Type | CodeableConcept from PatientDiet |
Requirements | Track patients reported dietary restrictions to help with catering requirements |
Comments | not for specifying medical diets, but for casual dietary restrictions such as vegetarian, diary-free, nut-free, etc |
Patient.confidentiality |
Definition | Confidentiality of the patient records |
Control | Optional, 0..1 |
Type | CodeableConcept from PatientConfidentiality |
Requirements | Need to be able to track which patient records are particularly sensitive |
Comments | Confidentiality tracking also occurs at more detailed points in the medical record |
Patient.recordLocation |
Definition | The location of the paper record for the patient, if there is one |
Control | Optional, 0..1 |
Type | CodeableConcept from PaperRecordLocation |
Requirements | Track old paper records where these are still in use |
Patient.extensions |
Definition | See Extensions |
Control | Optional, 0..1 |
Patient.text |
Definition | Text summary of person, for human interpretation |
Control | Mandatory, 1..1 |
Type | Narrative |
This is an old version of FHIR retained for archive purposes. Do not use for anything else
Implementers are welcome to experiment with the content defined here, but should note that the contents are subject to change without prior notice.
© HL7.org 2011 - 2012. FHIR v0.01 generated on Mon, May 14, 2012 09:48+1000.