This page is part of the FHIR Specification (v1.4.0: STU 3 Ballot 3). 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

• Content
• Examples
• Detailed Descriptions
• Mappings
• Profiles
• Operations

5.1 Resource Patient - Content

Patient Administration Work Group

Maturity Level: 3

Compartments: Patient, Practitioner

Demographics and other administrative information about an individual or animal receiving care or other health-related services.

This resource is referenced by Account, AllergyIntolerance, Appointment, AppointmentResponse, AuditEvent, Basic, BodySite, CarePlan, CareTeam, Claim, ClinicalImpression, Communication, CommunicationRequest, Composition, Condition, Contract, Coverage, DetectedIssue, Device, DeviceUseRequest, DeviceUseStatement, DiagnosticOrder, DiagnosticReport, DocumentManifest, DocumentReference, EligibilityRequest, Encounter, EnrollmentRequest, EpisodeOfCare, ExplanationOfBenefit, FamilyMemberHistory, Flag, Goal, Group, GuidanceResponse, ImagingExcerpt, ImagingObjectSelection, ImagingStudy, Immunization, ImmunizationRecommendation, List, MeasureReport, Media, MedicationAdministration, MedicationDispense, MedicationOrder, MedicationStatement, NutritionOrder, Observation, Order, Person, Procedure, ProcedureRequest, Protocol, Provenance, QuestionnaireResponse, ReferralRequest, RelatedPerson, RiskAssessment, Schedule, Sequence, Specimen, SupplyDelivery, SupplyRequest, Task and VisionPrescription

5.1.2 Resource Content

 

Alternate definitions: Schema/Schematron, Resource Profile (XML, JSON), Questionnaire

5.1.2.1 Terminology Bindings

Path	Definition	Type	Reference
Patient.gender Patient.contact.gender	The gender of a person used for administrative purposes.	Required	AdministrativeGender
Patient.maritalStatus	The domestic partnership status of a person.	Required	Marital Status Codes
Patient.contact.relationship	The nature of the relationship between a patient and a contact person for that patient.	Extensible	PatientContactRelationship
Patient.animal.species	The species of an animal.	Example	AnimalSpecies
Patient.animal.breed	The breed of an animal.	Example	AnimalBreeds
Patient.animal.genderStatus	The state of the animal's reproductive organs.	Example	GenderStatus
Patient.communication.language	A human language.	Required	IETF language tag
Patient.link.type	The type of link between this patient resource and another patient resource.	Required	LinkType

5.1.2.2 Constraints

• pat-1: On Patient.contact: SHALL at least contain a contact's details or a reference to an organization (expression on Patient.contact: name or telecom or address or 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 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.

5.1.3 Patient id's and Patient resource id's

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

5.1.4 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:

5.1.4.1 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. By using a link of type 'replace', 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, do not point back to the replaced record.

5.1.4.2 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 it are known to hold a more comprehensive and/or authorative record of the same patient. The link type 'refer' is used denote such a link. Note that linked records may contain contradictory information. The record referred to does not point back to the referring record.

5.1.4.3 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 authorative 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.

5.1.5 Patient vs. Person vs. Patient.Link

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 Patient Link however is only intended to be used for Patient 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.

5.1.6 Patient.contact vs. RelatedPerson

The contact element on the Patient Resource should be used for storing people to contact information. Where a system has a separate record for other people for purposes other than just the contact details, the RelatedPerson resource should be used.
This includes cases where these related people are actually contributing to the record, and need to be referenced individually (e.g. CarePlan.Participant, Encounter, DocumentReference, Appointment) where the Patient.Contact component cannot 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.careProvider field.

5.1.7 Merging records

This specification does not specify merge functionality: if multiple patient records are found to be duplicates, they can be linked together, as described above. These links merely express the relationship between records, and in the case of a replacement link, indicate a "master" record. This specification does not mandate that FHIR servers migrate information between such records on finding such a link. Note:

• Health information administrators may call the process "merging", but it is often implemented as "linking" at the record level
• Servers are allowed to implement merging/record migration even though it is not mandated.

DSTU Note: We are seeking input from the implementer community on what effect linking/merging/unlinking should have on other functionality such as the GET operation (where the result is the old version of the Patient), searching, reverse includes, etc.; e.g., should observation resources from all linked/merged patients be returned when querying for one of them?
How should an unlink behavior be done? (Assuming that no data was "re-allocated" as part of merge) These suggested updated behaviors could be the subject of a future connectathon.

Feedback here .

5.1.8 Patient Matching using an MPI

A Master Patient Index (MPI ) 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 use the "mpi" query, which uses the normal search parameters defined for patient. However, rather than their normal use, they are interpreted as MPI inputs - e.g. instead of requiring that the resources literally contain the search parameters, they are passed to an MPI algorithm of some kind that uses them to determine the most appropriate matches in the patient set.

  GET [base]/Patient?_query=mpi&parameters...

The response from an "mpi" query 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 with further advice. All patient records SHALL have a score from 0 to 1, where 1 is the most certain match, along with an extension "patient-mpi-match" that indicates the MPI's position on the match quality:

  <entry> 
    <resource>
      <Patient>
        <!-- patient details -->
      </Patient>
    </resource>
    <search>
      <extension url="http://hl7.org/fhir/StructureDefinition/patient-mpi-match">
        <valueCode value="probable"/>
      </extension>
      <score value="0.80"/>
    </search>
  </entry> 

The patient-mpi-match extension has one of the following codes:

certain	This record meets the MPI criteria to be automatically considered as a full match.
probable	This record is a close match, but not a certain match. Additional review (e.g. by a human) may be required before using this as a match.
possible	This record may be a matching one. Additional review (e.g. by a human) SHOULD be performed before using this as a match.
certainly-not	This record is known not to be a match. Note that usually non-matching records are not returned, but in some cases records previously or likely considered as a match may specifically be negated by the MPI.

One optional parameter to the MPI match operation is "userid", which is used to pass the user details from a trusted client to the MPI. This may be used by the MPI to restrict the possible matches that are returned, based on the user's rights. For example, a staff member covered by policies, etc., may well get a different result than a patient trying to find their own record. Note that this parameter is used where the user would not be expected to log in to the MPI directly; whether this is appropriate or not is a deployment choice.

A formal definition for the MPI query is published.

DSTU Note: This is the first draft of this approach, as a result of connectathon testing.

Feedback is sought here .

5.1.9 Search Parameters

Search parameters for this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

Name	Type	Description	Paths
active	token	Whether the patient record is active	Patient.active
address	string	An address in any kind of address/part of the patient	Patient.address
address-city	string	A city specified in an address	Patient.address.city
address-country	string	A country specified in an address	Patient.address.country
address-postalcode	string	A postalCode specified in an address	Patient.address.postalCode
address-state	string	A state specified in an address	Patient.address.state
address-use	token	A use code specified in an address	Patient.address.use
animal-breed	token	The breed for animal patients	Patient.animal.breed
animal-species	token	The species for animal patients	Patient.animal.species
birthdate	date	The patient's date of birth	Patient.birthDate
careprovider	reference	Patient's nominated care provider, could be a care manager, not the organization that manages the record	Patient.careProvider (Organization, Practitioner)
death-date	date	The date of death has been provided and satisfies this search value	Patient.deceasedDateTime
deceased	token	This patient has been marked as deceased, or as a death date entered	Patient.deceased[x]
email	token	A value in an email contact	Patient.telecom(system=email)
family	string	A portion of the family name of the patient	Patient.name.family
gender	token	Gender of the patient	Patient.gender
given	string	A portion of the given name of the patient	Patient.name.given
identifier	token	A patient identifier	Patient.identifier
language	token	Language code (irrespective of use value)	Patient.communication.language
link	reference	All patients linked to the given patient	Patient.link.other (Patient)
name	string	A portion of either family or given name of the patient	Patient.name
organization	reference	The organization at which this person is a patient	Patient.managingOrganization (Organization)
phone	token	A value in a phone contact	Patient.telecom(system=phone)
phonetic	string	A portion of either family or given name using some kind of phonetic matching algorithm	Patient.name
telecom	token	The value in any kind of telecom details of the patient	Patient.telecom