PersonRegistry.LinkPersonRecords

From Wiki for HL7 Norge
Revision as of 13:19, 22 June 2011 by Wikiadmin (Talk | contribs) (Created page with "CATEGORY:Operation ==Operation-level Profile== {|border="1" |- |Operation Name |PersonRegistry.LinkPersonRecords |- |Purpose Description |To link to different id of a person...")

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


Operation-level Profile

Operation Name PersonRegistry.LinkPersonRecords
Purpose Description To link to different id of a person together.
See below for storyboards that illustrate the purpose of this operation.
Logic Description A will be linked to B (A shall be superseded by B; where A is the value of OtherIdentifiedPerson.id and B the value of IdentifiedPerson.id) if (and only if)
  • both A and B are existing/valid identifiers,
  • A is not an F or D number (those unlinkages may only be done by the Folkeregister), and
  • neither A nor B may currently be superseded by another number. However, B may currently supersede other numbers, and A may currently supersede other numbers (in which case those numbers, along with A, will become direct children of B alongside the children B originally had).

This operation does allow for linking of identifiers that were previously unlinked.

Input/Output Input: Person Registry LinkPersonRecords.


See below for details of the information models as well as examples.

Composition Role Business level service
Composition Member Capabilities None.
Keywords Merge, Resolve, duplicates, person, person identifier, Folkeregister, link
Version 5.0
Finalization Status within HL7 Norway For review
Custodian HL7 Norway

Purpose of the Operation

The aim of the PatientRegistry.LinkPersonRecords operation is to request that a person registry maintains a link from a less-preferential to a more-preferential person record after detecting that two person records (effectively: two person identifiers) are related to one and the same person.

The request has an immediate response in the form of an Application Acknowledgement - which provides an indiction of the success or failure of the request.

Interaction Diagram

The interaction diagram below depicts the exchange of data between the user and the provider of the operation.

File:PRPA ST101901NO.png

Textual Storyboard

  1. Eve Everywoman gives birth to a newborn baby. The baby does not exist in the Norwegian National Population Registry so a temporary identifier is requested and assigned by the FH-registry. When the PAS receives the official birth number from the Norweigan National Population Registry two weeks later the PAS informs the FH-registry of the linking from the temporary number to the new official birth number.
  2. An unconcious man is brought to the Emergency Department and a FH-number (ID1) is assigned to the person because the ID of the person is unknown. A few hours later the person has regained conciousness and identifies himself as Adam Everyman with official birth number (ID2). The official birth number is linked with the temporary FH-number in the PAS which then informs the FH-registry of the official birth number of the patient.

Input/Output

The request (input) model contains one or more person records (which each have one identifier) that the requesting application wishes to link to another person record (which has a more preferred/reliable identifier). The output model will contain an indication of whether the request was processed succesfully or not.

Input/Output List
Person Registry Link Record Request PRPA_IN101901NO
Application Acknowledgement (Generic) MCAI_IN000004NO

Information Models

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, the ControlAct Wrapper, the Registration Act (a RegistrationRequest) and a so-called payload model.

The payload information model is shown below.

PRPA RM101901NO.png

The information model is documented in two parts:

  1. the Identifiedperson class and its assigningOrganization (the E_Organization CMET)
  2. the identifiedBy relationship and the OtherIdentifiedPerson class.
Class Component Documentation
IdentifiedPerson id Contains a maximum of one unique person identifier.

@root contains an identification of the ‘unique person identification mechanism’ (for example: the OID for F-Number: 2.16.578.1.12.4.1.4.1, the OID for D-Number: 2.16.578.1.12.4.1.4.2 or the OID for FH-number: 2.16.578.1.12.4.1.4.3), and @extension contains the identifier created according to that identification mechanism.

  statusCode Indicates the status of the role. @code may only contain the value ‘active’ to indicate that the role is active (and therefore that the identifier is 'in active use' as well. the default value is 'active'; if omitted the statusCode shall be assumed to be 'active'.).

The IdentifiedPerson has exactly one identifiedBy relationships and the OtherIdentifiedPerson classes associated with it (the model shown above allows for multiple such relationships, this is however not allowed in this Norwegian implementation guide):

Class Component Documentation
identifiedBy statusCode Contains the fixed value 'active'. The creation of a link causes an 'active' link to occur between the person records (and also of the identifiers of these records).
  effectiveTime The time interval during which the link is/was active. Upon activation the value of the lower bound of the interval is set to the time of the creation of the link.
OtherIdentifiedPerson id Contains a maximum of one unique person identifier.

@root contains an identification of the ‘unique person identification mechanism’ (for example: the OID for FH-number: 2.16.578.1.12.4.1.4.3), and @extension contains the identifier created according to that identification mechanism.

  statusCode Indicates the status of the role. If valued @code may only contain the value ‘active’.


Note: Any other classes not listed above, but shown in the diagram, are reserved for future use in Norway. Sending applications SHOULD not use these model elements; receiving applications SHALL nor produce an error if these model elements are present, and MAY ignore these model elements if present.

Output Information Model

Generic Application Acknowledgement

Error Handling

See Error Handling for a general discussion of how errors can be identified in the response.

The response may contain an indication of errors during the processing of the request. The error codes are taken from the PersonRegistryErrors coding system (managed/maintained by NHN), with OID 2.16.578.1.12.4.5.2.1.1.

In case of processing errors the value of Acknowledgement.typeCode will be set to "AE", and the value of the DetectedIssueEvent.code attribute will be set to one of the codes shown below.

Lvl Code Description Documentation
1 INVALPID Invalid person identifier (One of) the person identifier(s) is invalid (null, empty, or not a valid F-, D-, or FH-number [a checksum failure])
1 NONEXIST Non existing person identifier The person identifier doesn't exist (in the database of the recieving application).
1 NOAUTH Caller does not have sufficient rights e.g. a request to update the demographics associated with an F-number, or link/unlinking where the source of the link is a D-number.
1 NOCHILD Person identifier is not a preferential identifier The first and/or second person identifier is already linked to a more preferential ID. Examples: a parameter is already a child of another number; The service user should determine the most prferential ID for a person (using the PersonRegistry.GetDemographics operation) prior to using this operation.
1 SERVERROR Generic error Uncaught exception, either from code or database - will only occur if there is a bug in the link/unlink code.
1 S:linkErrors Grouping of link errors This symbolic node groups Person Registry errors that are exclusively used when dealing with a link request.
2 LINKED The specified link is already present An existing link can't be linked again.
2 EQUALPID The two parameters are equal  
2 REVLINK Reverse link already present The two parameters are already linked in the opposite direction

Examples

Input Example

In the example below (only the payload is shown) two identifiers are linked to a D-number.

<subject typeCode="SUBJ">
   <registrationRequest classCode="REG" moodCode="RQO">
       <!-- re-use message ID -->
       <id extension="93836363" root="2.16.578.1.34.1.922.3"/>
       <statusCode code="active"/>
       <subject1 typeCode="SBJ">
           <identifiedPerson classCode="IDENT">
               <!-- D-Number; most preferential known ID -->
               <id extension="64109642356" root="2.16.578.1.12.4.1.4.2"/>
               <!-- Below: one or more secondary identifiers which all link to the above (preferntial) identifier -->
               <identifiedBy typeCode="IDENT">
                   <statusCode code="active"/>
                   <otherIdentifiedPerson classCode="IDENT">
                       <!-- First FH number being linked to the above D-Number -->
                       <id root="2.16.578.1.12.4.1.4.3" extension="991234567890"/>
                   </otherIdentifiedPerson>
               </identifiedBy>
               <identifiedBy typeCode="IDENT">
                   <statusCode code="active"/>
                   <otherIdentifiedPerson classCode="IDENT">
                       <!-- Second (different) FH number being linked to the above D-Number -->
                       <id root="2.16.578.1.12.4.1.4.3" extension="992222288888"/>
                   </otherIdentifiedPerson>
               </identifiedBy>
           </identifiedPerson>
       </subject1>
       <author typeCode="AUT">
           <!-- person responsible for the request -->
           <assignedEntity classCode="ASSIGNED">
               <id root="2.16.578.1.34.3.1" extension="3838383"/>
           </assignedEntity>
       </author>
   </registrationRequest>
</subject>

Output Example

The response (XML fragments shown below) will contain a code to indicate (as in this example) that the request was processed successfully..

<acknowledgement typeCode="AA">
   <!-- AA = Affirmative acknowledgement -->
   <targetMessage>
       <!-- .. related to this original message ID -->
       <id extension="93836363" root="2.16.578.1.34.1.922.3"/>
   </targetMessage>
</acknowledgement>

..or a failure, in which case an error code will be returned as well.

<acknowledgement typeCode="AE">
   <!-- AE = Application Error -->
   <targetMessage>
       <!-- .. related to this original message ID -->
       <id extension="93836363" root="2.16.578.1.34.1.922.3"/>
   </targetMessage>
</acknowledgement>
<controlActProcess classCode="CACT" moodCode="EVN">
   <authorOrPerformer typeCode="AUT">
       <!-- details not shown -->
   </authorOrPerformer>
   <reasonOf typeCode="RSON">
       <detectedIssueEvent classCode="ALRT" moodCode="EVN">
           <code code="NOCHILD" codeSystem="2.16.578.1.12.4.5.2.1.1" 
            displayName="One of the supplied IDs is already linked to a more preferential ID."/>
       </detectedIssueEvent>
   </reasonOf>
</controlActProcess>