From Wiki for HL7 Norge
Revision as of 14:09, 22 June 2011 by Wikiadmin (Talk | contribs) (Created page with "[[CATEGORY:Service[[CATEGORY:ForReview]] {{:Linking Proposal}} ==Operation-level Profile== {|border="1" |- |Operation Name |PatientRegistry.DuplicatesResolved |- |Purpose Descr...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

[[CATEGORY:ServiceLinking Proposal

Operation-level Profile

Operation Name PatientRegistry.DuplicatesResolved
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).
See below for details of the information models as well as examples.

Composition Role Business level service
Composition Member Capabilities None.
Keywords Demographics data, patient, patient registry, patient identifier, id
Version 4.0
Finalization Status within HL7 Norway Draft
Custodian HL7 Norway

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.

Storyboard Diagram

This storyboard demonstrates notifying tracking systems after a duplicate resolution has been done in a person registry.

File:PRPA ST201304NO.GIF

Textual Storyboard

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:

  1. The receiving system contains both ID1 and ID2 and must mark the obsolete id and link the id to survive.
  2. The receiving system contains only the ID to be marked as obsolete and must change this or link to the new id to survive.
  3. The receiving system contains only the ID to to survive and there is no need to do anything.
  4. 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.

Interaction List
Patient Registry Duplicates Resolved Notification PRPA_IN201304NO
Accept Acknowledgement MCCI_IN000002UV01

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

The model is defined in the form of two wrappers (which contain meta-data related to the information exchange); the Transmission Wrapper and the ControlAct Wrapper and a so-called payload 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.

XML Examples

Input Example

Output Example

See Accept Acknowledgement.