-Notes: -
-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. -
--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). -
- - --There are two common approaches for resolving duplicate patient records: merging and linking. Linking duplicate patients is described in the Linking Patients section, or merging duplicate patients as described in the $merge operation page. -
- - - -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:
- - -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 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.
-
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.
- - -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. -
- - -
-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 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)
-
-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.
- - --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. -
--For veterinary use, the animal extension also includes the genderStatus which indicates sterility information. -
- - --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: -
-
-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> - <id value="child"/> - <!-- The details of the child --> -</Patient> -<RelatedPerson> - <id value="rp-mom"/> - <patient> - <reference value="Patient/child"/> - </patient> -</RelatedPerson> -<Patient> - <id value="pat-mom"/> - <!-- The details of the mom --> - <link> - <other value="rp-mom"/> - <type value="see-also"/> - </link> -</Patient> -<Encounter> - <id value="mom-enc"/> - <status value="in-progress"/> - <class value="inpatient"/> - <patient> - <reference value="Patient/mom"/> - </patient> -</Encounter> -<Encounter> - <id value="child-enc"/> - <status value="in-progress"/> - <class value="inpatient"/> - <patient> - <reference value="Patient/child"/> - </patient> - <partOf> - <reference value="Encounter/mom-enc"/> - </partOf> -</Encounter> -- - - -
-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 call the patient $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 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 -"match-grade" 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/match-grade"> - <valueCode value="probable"/> - </extension> - <score value="0.80"/> - </search> - </entry> --
-The match-grade extension has one of the following codes: -
-[%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 for the MPI $match operation is published. -
- - --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 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. -
- -+Notes: +
+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. +
++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). +
+ + ++There are two common approaches for resolving duplicate patient records: merging and linking. Linking duplicate patients is described in the Linking Patients section, or merging duplicate patients as described in the $merge operation page. +
+ + + +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:
+ + +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 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.
+
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.
+ + +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. +
+ + +
+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 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: +
+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.
+ + ++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. +
++For veterinary use, the animal extension also includes the genderStatus which indicates sterility information. +
+ + ++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: +
+
+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> + <id value="child"/> + <!-- The details of the child --> +</Patient> +<RelatedPerson> + <id value="rp-mom"/> + <patient> + <reference value="Patient/child"/> + </patient> +</RelatedPerson> +<Patient> + <id value="pat-mom"/> + <!-- The details of the mom --> + <link> + <other value="rp-mom"/> + <type value="see-also"/> + </link> +</Patient> +<Encounter> + <id value="mom-enc"/> + <status value="in-progress"/> + <class value="inpatient"/> + <patient> + <reference value="Patient/mom"/> + </patient> +</Encounter> +<Encounter> + <id value="child-enc"/> + <status value="in-progress"/> + <class value="inpatient"/> + <patient> + <reference value="Patient/child"/> + </patient> + <partOf> + <reference value="Encounter/mom-enc"/> + </partOf> +</Encounter> ++ + + +
+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 call the patient $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 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 +"match-grade" 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/match-grade"> + <valueCode value="probable"/> + </extension> + <score value="0.80"/> + </search> + </entry> ++
+The match-grade extension has one of the following codes: +
+[%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 for the MPI $match operation is published. +
+ + ++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 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. +
+ +