This page is part of the FHIR Specification (v0.06: DSTU 1 Ballot 2). 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

Resource Patient - Content 3.11

Status: Not an approved resource: examplar. Under Consideration by Patient Administration Working Group

A patient is a person or animal that is receiving care.

The resource name as it appears in a RESTful URL is /patient/

Note: while the content of the current Patient resource is not yet under ballot, the Patient Administration workgroup would like to draw your opinions about the intended rename of "Patient" to "SubjectOfCare". This input will be taken into account when preparing the May 2013 ballot, which will contain a Patient/SubjectOfCare prepared by the Work Group

The decision to change the "Patient" resource name to "SubjectOfCare" was made to be inclusive of health-related care events where the focus was not on curative activities within the Patient Administration scope of work. This would include examples in care such as within social services as well as pregnancies, wherein mothers-to-be do not consider themselves "patients" to be cured of any illness.

Resource Content 3.11.1

UML Image

<Patient xmlns="http://hl7.org/fhir">
 <link><!-- 0..* Resource(Patient) Other patients linked to this resource --></link>
 <active><!-- 1..1 boolean Whether this patient record is active (in use) --></active>
 <subject><!-- 1..1 Resource(Person|Animal) The person or animal that is the patient --></subject>
 <provider><!-- 1..1 Resource(Organization) Organization managing the patient --></provider>
 <identifier><!-- 0..* HumanId An identifier for the person as this patient --></identifier>
 <diet><!-- 0..1 CodeableConcept Dietary restrictions for the patient --></diet>
 <confidentiality><!-- 0..1 CodeableConcept Confidentiality of the patient records --></confidentiality>
 <recordLocation><!-- 0..1 CodeableConcept Where the paper record is --></recordLocation>
 <extension><!-- 0..* Extension  See Extensions  --></extension>
 <text><!-- 1..1 Narrative Text summary of resource (for human interpretation) --></text>
</Patient>

Alternate definitions: Schema/Schematron, RDF (to do), XML, XMI (to do), Resource Profile

Terminology Bindings

PathDetailsStrength
Patient.diet casual dietary restrictions associated with this patient (not bound to any particular codes)complete/unstated
Patient.confidentiality The confidentiality of the records associated with this patient (not bound to any particular codes)complete/unstated
Patient.recordLocation A physical location for a record. (Usually site specific) (not bound to any particular codes)complete/unstated

Notes:

Managing Patient Registration 3.11.2

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 3.11.3

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.

Search Parameters 3.11.4

Search Parameters for RESTful searches. The standard parameters also apply. See Searching for more information.

$page : integerStarting offset of the first record to return in the search setsingle
$count : integerNumber of return records requested. The server is not bound to conformsingle
$id : tokenThe logical resource id associated with the resource (must be supported by all servers)single
subject : qtokenThe identity of the subjectunion
provider : qtokenThe identity of an organizationunion
identifier : qtokenA patient identifierunion

(See Searching).


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.06 generated on Tue, Dec 4, 2012 00:04+1100. License