|Purpose Description||To notify receiving systems that the duplicate records are resolved in a patient registry, or that the patient's H- or FH-number has been replaced by his official id (D-/F-number). |
See below for storyboards that illustrate the purpose of this operation.
|Logic Description||The operation informes the recipient that two patients have been linked (e.g. it is the same patient), or that a patient has been updated with a preferred id. This enables the recipient to update its own registry with the new information. (Either as an automatic or a manual process.)|
|Input/Output||Input: Patient Registry Duplicates Resolved Notification (PRPA_IN201304NO).
Output: Accept Acknowledgement (MCCI_IN000002UV01).
|Composition Role||Business level service|
|Composition Member Capabilities||None.|
|Keywords||Demographics data, patient, patient registry, patient identifier, id|
|Finalization Status within HL7 Norway||Draft|
Purpose of the operation
The aim of the PatientRegistry.DuplicatesResolved service is to notify a patient tracking system after duplicate records are resolved in a patient registry. The receiver is expected to mark the incorrect registration as "obsolete" and link information to the surviving registration. The notification interaction has an immediate response in the form of an Accept Acknowledgement. Note that an Accept Acknowledgement serves both as an assurance that the interaction was received, and as a statement that the interaction was –at a glance- syntactically correct.
This storyboard demonstrates notifying tracking systems after a duplicate resolution has been done in a person registry.
During the patient admission process, the registrar did not find a record for Eve Everywoman in the ADT system and created a new record with identifier ID2. Eve Everywoman had actually been to the healthcare facility several times in the past under her maiden name, Eve Everymaiden, with identifier ID1. The problem persists for a while. During that time, several more encounters are assigned to Eve under her newly created identifier ID2. Finally, the problem is discovered and Medical Records sets the registration for Eve Everymaiden to "obsolete" and links it to the newer registration for Eve Everywoman [Patient Registry Duplicates Resolved interaction]. The ADT system sends the notification to other systems containing patient registry information. For the receiving system the scenario is one of four:
- The receiving system contains both ID1 and ID2 and must mark the obsolete id and link the id to survive.
- The receiving system contains only the ID to be marked as obsolete and must change this or link to the new id to survive.
- The receiving system contains only the ID to to survive and there is no need to do anything.
- The receiving system does not content any of the IDs and there is no need to do anything.
The notification operation has an immediate response in the form of an Accept Acknowledgement.
|Patient Registry Duplicates Resolved Notification||PRPA_IN201304NO|
|Note that the above interaction use the “NO” realm code. The models used are (currently) specific for this project and will be brought forward for inclusion in the international standard.|
The payload model of the revise interaction is shown here. The query interaction has an immediate response. The response interaction as set by the Patient Registry will contain all known identifiers as well as demographics details of the patient.
Input Information Model
|As the 'linking' and 'unlinking' of Patient Roles is subject to international discussion, the model depicted below is for illustration purposes only.|
Output Information Model
The output has the form of an Accept Acknowledgement.