5.1 Patient リソース

logo fhir

Home ＞ Administrative ＞ Patient [patient]

Resource Patient - Content5.1

Demographics and other administrative information about a person or animal receiving care or other health-related services.

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

This Resource covers data about persons 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

The data in the Resource covers the "who" information about the patient: it's 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 person or animal receiving care at multiple organizations may therefore have its information present in multiple Patient Resources.

Resource Content5.1.1

<Patient xmlns="http://hl7.org/fhir"> <!-- from Resource: extension, narrative, and contained --> <identifier><!-- 0..* Identifier An identifier for the person as this patient § --></identifier> <name><!-- 0..* HumanName A name associated with the patient § --></name> <telecom><!-- 0..* Contact A contact detail for the individual § --></telecom> <gender><!-- 0..1 CodeableConcept Gender for administrative purposes § --></gender> <birthDate value="[dateTime]"/><!-- 0..1 The date and time of birth for the individual § --> <deceased[x]><!-- 0..1 boolean|dateTime Indicates if the individual is deceased or not § --></deceased[x]> <address><!-- 0..* Address Addresses for the individual § --></address> <maritalStatus><!-- 0..1 CodeableConcept Marital (civil) status of a person § --></maritalStatus> <multipleBirth[x]><!-- 0..1 boolean|integer Whether patient is part of a multiple birth § --></multipleBirth[x]> <photo><!-- 0..* Attachment Image of the person --></photo> <contact> <!-- 0..* A contact party (e.g. guardian, partner, friend) for the patient --> <relationship><!-- 0..* CodeableConcept The kind of relationship --></relationship> <name><!-- 0..1 HumanName A name associated with the person --></name> <telecom><!-- 0..* Contact A contact detail for the person --></telecom> <address><!-- 0..1 Address Address for the contact person --></address> <gender><!-- 0..1 CodeableConcept Gender for administrative purposes --></gender> <organization><!-- 0..1 Resource(Organization) Organization that is associated with the contact --></organization> </contact> <animal> <!-- 0..1 If this patient is an animal (non-human) § --> <species><!-- 1..1 CodeableConcept E.g. Dog, Cow § --></species> <breed><!-- 0..1 CodeableConcept E.g. Poodle, Angus § --></breed> <genderStatus><!-- 0..1 CodeableConcept E.g. Neutered, Intact § --></genderStatus> </animal> <communication><!-- 0..* CodeableConcept Languages which may be used to communicate with the patient --></communication> <provider><!-- 0..1 Resource(Organization) Organization managing the patient § --></provider> <link><!-- 0..* Resource(Patient) Other patient resources linked to this resource § --></link> <active value="[boolean]"/><!-- 0..1 Whether this patient's record is in active use § --> </Patient>

Alternate definitions: Schema/Schematron, Resource Profile

Terminology Bindings 5.1.1.1

Constraints5.1.1.2

  • Inv-1: On Patient.contact: Must at least contain a contact's details or a reference to an organization (xpath on f:Patient/f:contact:f:name or f:telecom or f:address or f:organization)

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 person. 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.

Managing Patient Registration (Linking Patients) 5.1.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.

A Patient record's 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' id. Instead they should be represented in thePatient.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.

This specification does not specify merge functionality: if multiple patient records are found to be duplicates, they can be linked together - an assertion that two (or more) Patient resources are both about the same actual person. 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.

The link element is used to assert that patient resources refer to the same person. If any patient resources is linked to another, then that other resource must also link back to the source resource in order to maintain record consistency. Systems should not update patient links across two or more patient resources using separate transactions (i.e. update operations), where later operations may fail and leave the patient resources in disagreement with each other. Instead, systems should either:

Search Parameters 5.1.3

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