|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)
This operation does allow for linking of identifiers that were previously unlinked.
|Input/Output||Input: Person Registry LinkPersonRecords.
|Composition Role||Business level service|
|Composition Member Capabilities||None.|
|Keywords||Merge, Resolve, duplicates, person, person identifier, Folkeregister, link|
|Finalization Status within HL7 Norway||For review|
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.
The interaction diagram below depicts the exchange of data between the user and the provider of the operation.
- 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.
- 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.
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.
|Person Registry Link Record Request||PRPA_IN101901NO|
|Application Acknowledgement (Generic)||MCAI_IN000004NO|
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.
The information model is documented in two parts:
- the Identifiedperson class and its assigningOrganization (the E_Organization CMET)
- the identifiedBy relationship and the OtherIdentifiedPerson class.
|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.522.214.171.124.1.4.1, the OID for D-Number: 2.16.5126.96.36.199.1.4.2 or the OID for FH-number: 2.16.5188.8.131.52.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):
|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.5184.108.40.206.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
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.5220.127.116.11.18.104.22.168.
|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|
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.522.214.171.124.922.3"/> <statusCode code="active"/> <subject1 typeCode="SBJ"> <identifiedPerson classCode="IDENT"> <!-- D-Number; most preferential known ID --> <id extension="64109642356" root="2.16.5126.96.36.199.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.5188.8.131.52.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.5184.108.40.206.1.4.3" extension="992222288888"/> </otherIdentifiedPerson> </identifiedBy> </identifiedPerson> </subject1> <author typeCode="AUT"> <!-- person responsible for the request --> <assignedEntity classCode="ASSIGNED"> <id root="2.16.5220.127.116.11.1" extension="3838383"/> </assignedEntity> </author> </registrationRequest> </subject>
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.518.104.22.168.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.522.214.171.124.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.5126.96.36.199.188.8.131.52" displayName="One of the supplied IDs is already linked to a more preferential ID."/> </detectedIssueEvent> </reasonOf> </controlActProcess>