IHE ITI TF Vol2

3.44 Patient Identity Feed HL7 V3 [ITI-44]

This section corresponds to transaction [ITI-44] of the IHE IT Infrastructure Technical Framework. Transaction [ITI-44] is used by the Patient Identity Source, Patient Identifier Cross-reference Manager and Document Registry Actors.

3.44.1 Scope

The scope is identical to ITI TF-2: 3.8.1 .

3.44.2 Use Case Roles

Actor: Patient Identity Source

Role: Provides notification to the Patient Identifier Cross-reference Manager and Document Registry for any patient identification related events including: creation, updates, merges, etc.

Corresponding HL7 v3 Application Roles:

Patient Registry Informer (PRPA_AR201301UV02)

Actor: Patient Identifier Cross-reference Manager

Role: Serves a well-defined set of Patient Identification Domains. Based on information provided in each Patient Identification Domain by a Patient Identification Source Actor, it manages the cross-referencing of patient identifiers across Patient Identification Domains.

Corresponding HL7 v3 Application Roles:

Patient Registry Tracker (PRPA_AR201302UV02)

Actor: Document Registry

Role: Uses patient identifiers provided by Patient Identity Source to ensure that XDS Documents metadata registered is associated with a known patient and updates patient identity in document metadata by tracking identity change operations (e.g., merge).

Corresponding HL7 v3 Application Roles:

Patient Registry Tracker (PRPA_AR201302UV02)

3.44.3 Referenced Standards

HL7 Version 3 Edition 2008 Patient Administration DSTU, Patient Topic (found at http://www.hl7.org/memonly/downloads/v3edition.cfm#V32008 ).

3.44.4 Messages

Figure 3.44.4-1: Patient Identity Sequence

3.44.4.1 Patient Identity Management – Add or Revise Patient Record

3.44.4.1.1 Trigger Events

The following events from a Patient Identity Source will trigger one of the Add or Revise Patient Record messages:

Patient Registry Record Added (PRPA_TE201301UV02)

This trigger event signals that a new patient was added to a Patient Identity Source.

Changes to patient demographics (e.g., change in patient name, patient address, etc.) shall trigger the following Patient Registry Record Revised message:

Patient Registry Record Revised (PRPA_TE201302UV02)

This trigger event signals that patient information was revised in a Patient Identity Source.

The Patient Identifier Cross-reference Manager shall only perform cross-referencing logic on messages received from Patient Identity Source Actors. For a given Patient Identifier Domain there shall be one and only one Patient Identity Source Actor, but a given Patient Identity Source may serve more than one Patient Identifier Domain.

3.44.4.1.2 Message Semantics

The Patient Identity Feed transaction is carried out by the HL7 v3 Patient Activate (PRPA_MT201301UV02) and Patient Revise (PRPA_MT201302UV02) messages, as defined in the subsequent sections. The Patient Identity Source shall generate the message whenever a patient is registered or when some piece of patient demographic data changes. The components of the message listed below are required, and their detailed descriptions are provided in the following subsections.

Each message shall be acknowledged by the HL7 v3 Accept Acknowledgement (MCCI_MT000200UV01), which is described in ITI TF-2: Appendix O .

The message information model in Section 3.44.4.1.2.2 describes the relevant data elements for this transaction. Specific requirements for the particular actors are found in Section 3.44.4.1.3 Expected Actions.

3.44.4.1.2.1 Major Components of the Patient Registry Record Added/Revised Messages

Patient

The Patient class is the entry point to the R-MIMs for the Patient Activate (PRPA_RM201301UV02) and Patient Revise (PRPA_RM201302UV02) models. The patient identifiers are captured using an Instance Identifier (II) data type. Please see ITI TF-2: Appendix E for a detailed description about the use of the HL7 V3 II data type for patient identifiers.

Provider Organization

The Patient class is scoped by the provider organization where this person is a patient. The HL7 definition of the CMET requires that the provider organization needs to be identified by an id attribute, and at least one of address, telecommunications address, or contact person to be present. The id attribute SHALL have only a root, expressed as an ISO OID.

Person

The Person class contains identifying and demographic data elements for the focal person similar to those in the HL7 v2.x PID segment such as name, gender, date of birth, marital status and deceased indicator and time.

Language Communication

Information about what language(s) should be used to communicate with the focal person can be sent in the LanguageCommunication class.

PersonalRelationship

This is used for sending information pertaining to the mother’s maiden name.

Citizen

Citizenship information for a person, including citizen identifier and effective time can be sent in the Citizen class. The nation that scopes the Citizen role, as identified by Nation.code , is mandatory.

Other Identifiers

The OtherIDs class is used to capture other identifiers associated with the person, such as a driver’s license number or a social security number. In this transaction, the IDs assigned by the scoping provider organization are represented in the id attribute of the Patient class. All other IDs are represented in the OtherIDs class. For the purposes of interoperability, where both HL7 V3 and HL7 v2.x - based transactions are used, the following requirement is imposed on the OtherIDs.id attribute and on the scopingOrganization.id attribute:

OtherIDs.id.root SHALL be identical to scopingOrganization.id.root
scopingOrganization.id.extension SHALL NOT have any value

Please see ITI TF-2: E.2 for details on the use of the II data type for patient identifiers.

3.44.4.1.2.2 Message Information Model of the Patient Registry Record Added/Revised Messages

Below is the Message Information Model for both the Patient Activate and Patient Revise messages, as restricted for this transaction. The purpose of the model is to describe the data elements relevant for this transaction. It is a strict common subset of the Patient Activate (PRPA_RM201301UV02) and Patient Revise (PRPA_RM201302UV02) RMIMs. While HL7 defines two models for the two messages, a single common subset is sufficient for the purposes of this IHE transaction.

The base RMIMs can be found on the HL7 V3 2008 Edition CD at Edition2008/domains/uvpa/editable/PRPA_RM201301UV.htm and Edition2008/domains/uvpa/editable/PRPA_RM201302UV.htm. The following restrictions are made on the original RMIMs to arrive at the restricted model:

The focal entity choice is restricted to be only a person

The relationship holder of the personal relationship is restricted to be a person (using CMET COCT_MT030207UV)

The provider organization which is scoping the patient role is required in both the Add and Revise messages (it is optional in the original Revise message definition).

The following roles are omitted:

asPatientOfOtherProvider
guarantor
guardian
contactParty
asMember
careGiver
asStudent

The following participations are omitted:

subjectOf (administrativeObservation)
coveredPartyOf (coverage)

Figure 3.44.4.1.2.2-1: RMIM Diagram

The attributes of this model are described in the following table. Note that CMETs are not discussed, as the HL7 definitions for them are being used.

Table 3.44.4.1.2.2-1: Model Attributes

PRPA_HD201301IHE Patient Activate/Revise	This HMD extract defines the message used to report that a new patient record was added, or a patient record was updated. Derived from Figure 3.44.4.1.2.2-1 (PRPA_RM201301IHE)
Patient	The primary record for the focal person in a Patient Identity Source
classCode [1..1] (M) Patient (CS) {CNE:PAT}	Structural attribute; this is a "patient" role
id [1..*] (M) Patient ( SET < II >)	Identifiers designated by this patient identity source for the focal person
statusCode [1..1] Patient (CS) {CNE:active, fixed value= "active"}	A value specifying the state of this record in a patient registry (based on the RIM role class state-machine). This record is active.
confidentialityCode [0..*] Patient (SET<CE>) {CWE:Confidentiality}	Value(s) that control the disclosure of information about this living subject as a patient
veryImportantPersonCode [0..1] Patient (CE) {CWE:PatientImportance}	A code specifying the patient's special status granted by the scoper organization, often resulting in preferred treatment and special considerations. Examples include board member, diplomat.
Person	A subtype of LivingSubject representing a human being Either Person.name or Patient.id must be non-null
classCode [1..1] (M) Person (CS) {CNE:PSN, fixed value= "PSN"}	Structural attribute; this is a "person" entity
determinerCode [1..1] (M) Person (CS) {CNE:INSTANCE, fixed value= "INSTANCE"}	Structural attribute; this is a specific person
name [1..*] Person (BAG<PN>)	Name(s) for this person
telecom [0..*] Person (BAG<TEL>)	Telecommunication address(es) for communicating with this person
administrativeGenderCode [0..1] Person (CE) {CWE:AdministrativeGender}	A value representing the gender (sex) of this person. Note: this attribute does not include terms related to clinical gender which is a complex physiological, genetic and sociological concept that requires multiple observations in order to be comprehensively described.
birthTime [0..1] Person (TS)	The date and time this person was born
deceasedInd [0..1] Person (BL)	An indication that this person is dead
deceasedTime [0..1] Person (TS)	The date and time this person died
multipleBirthInd [0..1] Person (BL)	An indication that this person was part of a multiple birth
multipleBirthOrderNumber [0..1] Person (INT)	The order in which this person was born if part of a multiple birth
addr [0..*] Person (BAG<AD>)	Address(es) for corresponding with this person
maritalStatusCode [0..1] Person (CE) {CWE:MaritalStatus}	A value representing the domestic partnership status of this person
religiousAffiliationCode [0..1] Person (CE) {CWE:ReligiousAffiliation}	A value representing the primary religious preference of this person
raceCode [0..*] Person (SET<CE>) {CWE:Race}	A set of values representing the races of this person
ethnicGroupCode [0..*] Person (SET<CE>) {CWE:Ethnicity}	A set of values representing the ethnic groups of this person
OtherIDs	Used to capture additional identifiers for the person such as a Drivers’ license or Social Security Number. Please see notes above in the Major Components section on the use of OtherIDs.
classCode [1..1] (M) Role (CS) {CNE:ROL}	Structural attribute. This can be any specialization of "role" except for Citizen, or Employee.
id [1..*] (M) Role (SET<II>)	One or more identifiers issued to the focal person by the associated scopingOrganization (e.g., a Driver’s License number issued by a DMV)
PersonalRelationship	A personal relationship between the focal living subject and another living subject
classCode [1..1] (M) Role (CS) {CNE:PRS, fixed value= "PRS"}	Structural attribute; this is a "personal relationship" role
id [0..*] Role ( SET < II >)	Identifier(s) for this personal relationship
code [1..1] (M) Role (CE) {CWE:PersonalRelationshipRoleType}	A required value specifying the type of personal relationship between the relationshipHolder and the scoping living subject drawn from the PersonalRelationshipRoleType domain, for example, spouse, parent, unrelated friend
statusCode [0..1] Role (CE) {CWE:RoleStatus}	A value specifying the state of this personal relationship (based on the RIM Role class state-machine), for example, following divorce a spouse relationship would be "terminated".
effectiveTime [0..1] Role (IVL<TS>)	An interval of time specifying the period during which this personal relationship is in effect, if such time is applicable and known.
Citizen	Used to capture person information relating to citizenship.
classCode [1..1] (M) Role (CS) {CNE:CIT, fixed value= "CIT"}	Structural attribute; this is a "citizen" role
id [0..*] Role (SET<II>)	Identifier(s) for the focal person as a citizen of a nation
effectiveTime [0..1] Employee (IVL<TS>)	An interval of time specifying the period during which this employment relationship is in effect, if such time limit is applicable and known.
Nation	A politically organized body of people bonded by territory and known as a nation.
classCode [1..1] (M) Organization (CS) {CNE:NAT, fixed value= "NAT"}	Structural attribute; this is a 'nation' type of entity
determinerCode [1..1] (M) Organization (CS) {CNE:INSTANCE, fixed value= "INSTANCE"}	Structural attribute; this is a specific entity
code [1..1] (M) Organization (CD) {CWE:NationEntityType}	A value that identifies a nation state
name [0..1] Organization (ON)	A non-unique textual identifier or moniker for this nation
Employee	A relationship of the focal person with an organization to receive wages or salary. The purpose of this class is to identify the type of relationship the employee has to the employer rather than the nature of the work actually performed. For example, it can be used to capture whether the person is a Military Veteran or not..
classCode [1..1] (M) Employee (CS) {CNE:EMP}	Structural attribute; this is an "employee" role
statusCode [0..1] Employee (CS) {CNE:RoleStatus}	A value specifying the state of this employment relationship (based on the RIM Role class state-machine), for example, active, suspended, terminated.
statusCode [0..1] Employee (CS) {CNE:RoleStatus}	A value specifying the state of this employment relationship (based on the RIM Role class state-machine), for example, active, suspended, terminated.
effectiveTime [0..1] Employee (IVL<TS>)	An interval of time specifying the period during which this employment relationship is in effect, if such time limit is applicable and known.
occupationCode [0..1] Employee (CE) {CWE:EmployeeOccupationCode}	A code qualifying the classification of kind-of-work based upon a recognized industry or jurisdictional standard. OccupationCode is used to convey the person's occupation as opposed to jobClassCode (not used in this transaction) which characterizes this particular job. For example, it can be used to capture whether the person is a Military Veteran or not.
BirthPlace	The birthplace of the focal living subject.
classCode [1..1] (M) Birthplace (CS) {CNE:BIRTHPL}	Structural attribute; this is a "birthplace" role.
id [0..*] Birth place ( SET < II >)	A living subject's birth place represented by a unique identifier.
addr [0..*] Patient (BAG<AD>)	A living subject's birth place represented as an address. Note: Either BirthPlace.addr or an associated Place.name must be valued.
classCode [1..1] (M) Birthplace (CS) {CNE:BIRTHPL}	Structural attribute; this is a "birthplace" role.
LanguageCommunication	A language communication capability of the focal person
languageCode [1..1] (M) LanguageCommunication (CE) {CWE:HumanLanguage}	A value representing a language for which the focal person has some level of proficiency for written or spoken communication. Examples: Spanish, Italian, German, English, American Sign
preferenceInd [0..1] LanguageCommunication (BL)	An indicator specifying whether or not this language is preferred by the focal person for the associated mode

3.44.4.1.2.3 Control Act and Transmission Wrappers

Please see ITI TF-2: Appendix O for details on the IHE guidelines for implementing the wrappers. Table 3.44.4.1.2.3-1 contains the Transmission and Control Act wrappers used for the two interactions, and the associated constraints.

Table 3.44.4.1.2.3-1: Wrappers and Constraints

Transmission Wrapper

Trigger Event Control Act Wrapper

MCCI_MT000100UV01 – Send Message Payload

MFMI_MT700701UV01 – Master File / Registry Notification Control Act, Role Subject

The value of interactionId SHALL be set to PRPA_IN201301UV02 or PRPA_IN201302UV02

The value of processingModeCode SHALL be set to T

The acceptAckCode SHALL be set to AL

There SHALL be only one receiver Device

The trigger event code in ControlActProcess.code SHALL be set to PRPA_TE201301UV02 or PRPA_TE201302UV02 respectively

RegistrationEvent.statusCode SHALL be set to “active”

There SHALL be no InReplacementOf act relationship for these interactions.

The composite message schemas which describe the full payload of these interactions, including the wrappers, can be found online: see ITI TF-2: Appendix W. The HL7 V3 2008 Normative Edition schemas are at Edition2008/processable/multicacheschemas/PRPA_IN201301UV02.xsd and Edition2008/processable/multicacheschemas/PRPA_IN201302UV02.xsd.

3.44.4.1.2.4 Web Services Types and Messages

The Patient Registry Record Added/Revised messages will be transmitted using Web Services, according to the requirements specified in ITI TF-2: Appendix V .

The following WSDL naming conventions SHALL apply:

“add” message -> "PRPA_IN201301UV02_Message"
“revise” message -> "PRPA_IN201302UV02_Message"
acknowledgement -> "MCCI_IN000002UV01_Message"

The following WSDL snippet describes the types for these messages:

<…>
<types>
    <xsd:schema elementFormDefault="qualified" 
            targetNamespace="urn:hl7-org:v3"
            xmlns:hl7="urn:hl7-org:v3">
        <!-- Include the HL7 V3 message schema from an example location -->
        <xsd:import namespace="urn:hl7-org:v3" schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/PRPA_IN201301UV02.xsd"/>
        <xsd:element name="PRPA_IN201301UV02"/>
    </xsd:schema>
    <xsd:schema elementFormDefault="qualified" 
            targetNamespace="urn:hl7-org:v3"
            xmlns:hl7="urn:hl7-org:v3">
        <!-- Include the HL7 V3 message schema from an example location -->
        <xsd:import namespace="urn:hl7-org:v3" schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/PRPA_IN201302UV02.xsd"/>
        <xsd:element name="PRPA_IN201302UV02"/>
    </xsd:schema>
    <xsd:schema elementFormDefault="qualified" 
            targetNamespace="urn:hl7-org:v3"
            xmlns:hl7="urn:hl7-org:v3">
        <!-- Include the HL7 V3 message schema from an example location -->
        <xsd:import namespace="urn:hl7-org:v3" schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/MCCI_IN000002UV01.xsd"/>
        <xsd:element name="MCCI_IN000002UV01"/>
    </xsd:schema>
</types>
<…>

The messages are described by the following snippet:

<…>
<message name="PRPA_IN201301UV02_Message">
    <part element="hl7:PRPA_IN201301UV02" name="Body"/>
</message>
<message name="PRPA_IN201302UV02_Message">
    <part element="hl7:PRPA_IN201302UV02" name="Body"/>
</message>
<message name="MCCI_IN000002UV01_Message">
    <part element="hl7:MCCI_IN000002UV01" name="Body"/>
</message>
<…>

The port types for the WSDL describing the Patient Identity Feed Service are described together with the expected actions of the actors which receive these messages in Sections 3.44.4.1.3 and 3.44.4.1.4.

3.44.4.1.3 Expected Actions – PIX Manager

The Patient Identifier Cross-reference Manager shall be capable of accepting attributes specified in Table 3.44.4.1.2.2-1 above. This is to ensure that the Patient Identifier Cross-reference Manager can handle a sufficient set of corroborating information in order to perform its cross-referencing function.

The Patient Identifier Cross-reference Manager shall only recognize a single Patient Identity Source per domain.

The cross-referencing process (algorithm, human decisions, etc.) is performed within the Patient Identifier Cross-reference Manager, but its specification is beyond the scope of IHE.

Once the Patient Identifier Cross-reference Manager has completed its cross-referencing function, it shall make the newly cross-referenced identifiers available to PIX queries and send out notification to any Patient Identifier Cross-reference Consumers that have been configured as being interested in receiving such notifications using the PIX Update Notification HL7 V3 transaction (see Section 3.46 for the details of that transaction).

3.44.4.1.3.1 Web Services Port Type and Binding Definitions

IHE-WSP201) The attribute /wsdl:definitions/@name SHALL be "PIXManager".

The following WSDL naming conventions SHALL apply for wsdl:definitions/@name="PIXManager":

“add” message    -> "PRPA_IN201301UV02_Message"
“revise” message -> "PRPA_IN201302UV02_Message"
acknowledgement -> "MCCI_IN000002UV01_Message"
portType         -> "PIXManager_PortType"
add operation    -> "PIXManager_PRPA_IN201301UV02"
revise operation -> "PIXManager_PRPA_IN201302UV02"
SOAP 1.2 binding -> "PIXManager_Binding_Soap12"
SOAP 1.2 port    -> "PIXManager_Port_Soap12"

The following WSDL snippets specify the Patient Identity Feed Port Type and Binding definitions, according to the requirements specified in ITI TF-2: Appendix V .

3.44.4.1.3.1.1 Port Type

<…>
<portType name="PIXManager_PortType">
    <operation name="PIXManager_PRPA_IN201301UV02">
        <input message="tns:PRPA_IN201301UV02_Message" wsaw:Action="urn:hl7-org:v3:PRPA_IN201301UV02"/>
        <output message="tns:MCCI_IN000002UV01_Message" wsaw:Action="urn:hl7-org:v3:MCCI_IN000002UV01"/>
    </operation>
    <operation name="PIXManager_PRPA_IN201302UV02">
        <input message="tns:PRPA_IN201302UV02_Message" wsaw:Action="urn:hl7-org:v3:PRPA_IN201302UV02"/>
        <output message="tns:MCCI_IN000002UV01_Message" wsaw:Action="urn:hl7-org:v3:MCCI_IN000002UV01"/>
    </operation>
</portType>
<…>

3.44.4.1.3.1.2 Bindings

SOAP 1.2 binding:

<…>
<binding name="PIXManager_Binding_Soap12" type="PIXManager_PortType">
    <wsoap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="PIXManager_PRPA_IN201301UV02">
        <wsoap12:operation soapActionRequired="false"/>
        <input>
            <wsoap12:body use="literal"/>
        </input>
        <output>
            <wsoap12:body use="literal"/>
        </output>
    </operation>
    <operation name="PIXManager_PRPA_IN201302UV02">
        <wsoap12:operation soapActionRequired="false"/>
        <input>
            <wsoap12:body use="literal"/>
        </input>
        <output>
            <wsoap12:body use="literal"/>
        </output>
    </operation>
</binding>
<…>

An informative WSDL for the PIX Manager implementing the PIXV3 Profile is available online: see ITI TF-2: Appendix W .

3.44.4.1.3.2 Message Examples

Message examples can be found online: see ITI TF-2: Appendix W .

3.44.4.1.4 Expected Actions – Document Registry

The Document Registry shall be capable of accepting attributes in the Patient Registry Record Added or Patient Registry Record Revised messages as specified in Table 3.44.4.1.2.2-1. The Patient Identity Feed transaction contains more than what the XDS Document Registry needs for its operation.

The Document Registry shall store only the patient identifiers of the patient identification domain designated by the Affinity Domain for document sharing in the registry. Patient identifiers of other patient identification domains, if present in a received message, shall be ignored.

3.44.4.1.4.1 Web Services Port Type and Binding Definitions

IHE-WSP201) The attribute /wsdl:definitions/@name SHALL be "DocumentRegistry".

The following WSDL naming conventions SHALL apply for wsdl:definitions/@name="DocumentRegistry":

"add" message    -> "PRPA_IN201301UV02_Message"
"revise" message -> "PRPA_IN201302UV02_Message"
acknowledgement -> "MCCI_IN000002UV01_Message"
portType         -> "DocumentRegistry_PortType"
add operation    -> "DocumentRegistry_PRPA_IN201301UV02"
revise operation -> "DocumentRegistry_PRPA_IN201302UV02"
SOAP 1.2 binding -> "DocumentRegistry_Binding_Soap12"
SOAP 1.2 port    -> "DocumentRegistry_Port_Soap12"

The following WSDL snippets specify the Patient Identity Feed Port Type and Binding definitions, according to the requirements specified in ITI TF-2: Appendix V .

3.44.4.1.4.1.1 Port Type

<…>
<portType name="DocumentRegistry_PortType">
    <operation name="DocumentRegistry_PRPA_IN201301UV02">
        <input message="tns:PRPA_IN201301UV02_Message" wsaw:Action="urn:hl7-org:v3:PRPA_IN201301UV02"/>
        <output message="tns:MCCI_IN000002UV01_Message" wsaw:Action="urn:hl7-org:v3:MCCI_IN000002UV01"/>
    </operation>
    <operation name="DocumentRegistry_PRPA_IN201302UV02">
        <input message="tns:PRPA_IN201302UV02_Message" wsaw:Action="urn:hl7-org:v3:PRPA_IN201302UV02"/>
        <output message="tns:MCCI_IN000002UV01_Message" wsaw:Action="urn:hl7-org:v3:MCCI_IN000002UV01"/>
    </operation>
</portType>        
<…>

3.44.4.1.4.1.2 Bindings

SOAP 1.2 binding:

<…>
<binding name="DocumentRegistry_Binding_Soap12" type="DocumentRegistry_PortType">
    <wsoap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="DocumentRegistry_PRPA_IN201301UV02">
        <wsoap12:operation soapActionRequired="false"/>
        <input>
            <wsoap12:body use="literal"/>
        </input>
        <output>
            <wsoap12:body use="literal"/>
        </output>
    </operation>
    <operation name="DocumentRegistry_PRPA_IN201302UV02">
        <wsoap12:operation soapActionRequired="false"/>
        <input>
            <wsoap12:body use="literal"/>
        </input>
        <output>
            <wsoap12:body use="literal"/>
        </output>
    </operation>
</binding>
<…>

An informative WSDL for the Document Registry implementing the XDS.b Profile is available online: see ITI TF-2: Appendix W .

3.44.4.1.4.2 Message Examples

Message examples can be found online: see ITI TF-2: Appendix W .

3.44.4.2 Patient Identity Management – Patient Identity Merge

3.44.4.2.1 Trigger Events

When two patients’ records are found to identify the same patient by a Patient Identity Source in a Patient Identifier Domain, the Patient Identity Source shall indicate this information using the following trigger:

Patient Registry Duplicates Resolved (PRPA_TE201304UV02)

This trigger event signals that duplicate records were resolved in a patient registry.

A Patient Registry Duplicates Resolved message indicates that the Patient Identity Source has done a merge within a specific Patient Identification Domain. That is, the surviving identifier (patient ID) has subsumed a duplicate patient identifier.

3.44.4.2.2 Message Semantics

The Patient Registry Duplicates Resolved interaction is carried out by the HL7 v3 Patient Demographics message (PRPA_MT201303UV02). The message shall be generated by the system (Patient Identity Source) that performs the update whenever two patient records are found to reference the same person.

The components of the HL7 Merge Patient message listed below are required, and the detailed description of the message is provided in Sections 3.44.4.2.2.1 to 3.44.4.2.2.4.

Each message shall be acknowledged by the HL7 v3 Accept Acknowledgement (MCCI_MT000200UV01), which is described in ITI TF-2: Appendix O .

When two Patient identifiers are to be merged, the subsumed identifier is referenced in the Registry Trigger Event Control Act Wrapper and the payload is sent for the surviving identifier. For example, if Patients A, B, and C are all to be merged into Patient B, then two messages are sent. In the first message Patient A’s identifier is referenced in the Registry Trigger Event Control Act Wrapper via the replacementOf act relationship and Patients B’s identifier is referenced in the Patient class of the payload. In the second message Patient C’s identifier is referenced in the wrapper, and Patient B’s identifier is, again, in the payload.

The message information model in Section 3.44.4.2.2.2 describes the relevant data elements for this transaction. Specific requirements for the particular actors are found in Section 3.44.4.2.3 Expected Actions.

3.44.4.2.2.1 Major Components of the Patient Registry Duplicates Resolved

Patient

The Patient class is the entry point to the R-MIM for the Patient Demographics (PRPA_RM201303UV02) in the Patient Identity Source. The patient identifier is represented using an Instance Identifier (II) data type. Please see ITI TF-2: Appendix E for a detailed description about the use of the HL7 V3 II data type for patient identifiers.

Provider Organization

The Patient class is scoped by the provider organization which is the assigning authority for the patient’s identifier. For this message the provider organization class is optional. The HL7 definition of the CMET requires that the provider organization needs to be identified by an id attribute, and at least one of address, telecommunications address, or contact person to be present. The id attribute SHALL have only a root expressed as an ISO OID, and it shall match the root of the Patient.id attribute

Person

The Person class contains the name for the focal person (similarly to the requirement for the HL7 v2.x PID segment).

3.44.4.2.2.2 Message Information Model of the Patient Registry Duplicates Resolved Message

Below is the Message Information Model for the Duplicates Resolved message, as restricted for this transaction. The purpose of the model is to describe the data elements relevant for this transaction. It is a strict subset of the Patient Demographics (PRPA_RM201303UV02) RMIM.

The base RMIM can be found on the HL7 V3 2008 Edition CD at Edition2008/domains/uvpa/editable/PRPA_RM201303UV.htm . The following restrictions were made on the original RMIMs to arrive at the restricted model:

The focal entity choice is restricted to be only a person
All optional classes are removed
All optional attributes in the Patient and Person class are removed

This restricted model makes clear the purpose of this message – it is to inform about the merge of identities in the Patient Identity Source. If there are any updates to the demographics of the patient in question, this information shall be relayed via a Patient Registry Record Revised message. This follows the semantics of the Patient Identity Feed transaction as defined in ITI TF-2: 3.8 , and is a restriction on the semantics of this message as defined by HL7 (where any demographics information can be updated with the Duplicates Resolved message).

The provider organization is also optionally available.

Figure 3.44.4.2.2.2-1: Message Information Model for Duplicates Resolved Message

The attributes of this model are described in the following table.

Table 3.44.4.2.2.2-1: Model Attributes

PRPA_HD201303IHE Duplicates Resolved	This HMD extract defines the message used to report that two patient identifiers were merged (i.e., a duplicate was resolved). Derived from Figure 3.44.4.2.2.2-1 (PRPA_RM201303IHE)
Patient	The primary record for the focal person in a Patient Identity Source
classCode [1..1] (M) Patient (CS) {CNE:PAT}	Structural attribute; this is a "patient" role
id [1..*] (M) Patient ( SET < II >)	Identifiers designated by various patient identity sources for the focal person
statusCode [1..1] Patient (CS) {CNE:active, fixed value= "active"}	A value specifying the state of this record in a patient registry (based on the RIM role class state-machine). This record is active.
Person	A subtype of LivingSubject representing a human being Both Person.name and Patient.id must be non-null
classCode [1..1] (M) Person (CS) {CNE:PSN, fixed value= "PSN"}	Structural attribute; this is a "person" entity
determinerCode [1..1] (M) Person (CS) {CNE:INSTANCE, fixed value= "INSTANCE"}	Structural attribute; this is a specific person
name [1..*] Person (BAG<PN>)	Name(s) for this person

3.44.4.2.2.3 Control Act and Transmission Wrappers

Please see ITI TF-2: Appendix O for details on the IHE guidelines for implementing the wrappers. Table 3.44.4.2.2.2-1 contains the Transmission and Control Act wrappers used for this interaction, and the associated constraints.

Table 3.44.4.2.2.2-1: Wrappers and Constraints

Transmission Wrapper	Trigger Event Control Act Wrapper
MCCI_MT000100UV01 – Send Message Payload	MFMI_MT700701UV01 – Master File / Registry Notification Control Act, Role Subject
The value of interactionId SHALL be set to PRPA_IN201304UV02 The value of processingModeCode SHALL be set to T The acceptAckCode SHALL be set to AL There SHALL be only one receiver Device	The trigger event code in ControlActProcess.code SHALL be set to PRPA_TE201304UV02 RegistrationEvent.statusCode SHALL be set to “active” There SHALL be an InReplacementOf act relationship The value of PriorRegistration.statusCode SHALL be “obsolete” There SHALL be a PriorRegisteredRole role There SHALL be a single PriorRegisteredRole.id attribute, representing the subsumed patient identifier.

Transmission Wrapper

Trigger Event Control Act Wrapper

MCCI_MT000100UV01 – Send Message Payload

MFMI_MT700701UV01 – Master File / Registry Notification Control Act, Role Subject

The value of interactionId SHALL be set to PRPA_IN201304UV02

The value of processingModeCode SHALL be set to T

The acceptAckCode SHALL be set to AL

There SHALL be only one receiver Device

The trigger event code in ControlActProcess.code SHALL be set to PRPA_TE201304UV02

RegistrationEvent.statusCode SHALL be set to “active”

There SHALL be an InReplacementOf act relationship

The value of PriorRegistration.statusCode SHALL be “obsolete”

There SHALL be a PriorRegisteredRole role

There SHALL be a single PriorRegisteredRole.id attribute, representing the subsumed patient identifier.

The composite message schemas which describe the full payload of this interaction, including the wrappers, can be found online: see ITI TF-2: Appendix W. The schemas from the HL7 V3 2008 Normative Edition can be found at Edition2008/processable/multicacheschemas/PRPA_IN201304UV02.xsd.

3.44.4.2.2.4 Web Services Types and Messages

The Patient Registry Duplicates Resolved message will be transmitted using Web Services, according to the requirements specified in ITI TF-2: Appendix V.

The following WSDL naming conventions SHALL apply:

"resolve duplicates" message -> "PRPA_IN201304UV02_Message"
Acknowledgement -> "MCCI_IN000002UV01_Message"

The following WSDL snippet describes the types for these messages:

<…>
<types>
    <xsd:schema elementFormDefault="qualified" 
            targetNamespace="urn:hl7-org:v3"
            xmlns:hl7="urn:hl7-org:v3">
        <!-- Include the HL7 V3 message schema from an example location -->
        <xsd:import namespace="urn:hl7-org:v3" schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/PRPA_IN201304UV02.xsd"/>
        <xsd:element name="PRPA_IN201304UV02"/>
    </xsd:schema>
    <xsd:schema elementFormDefault="qualified" 
            targetNamespace="urn:hl7-org:v3"
            xmlns:hl7="urn:hl7-org:v3">
        <!-- Include the HL7 V3 message schema from an example location -->
        <xsd:import namespace="urn:hl7-org:v3" schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/MCCI_IN000002UV01.xsd"/>
        <xsd:element name="MCCI_IN000002UV01"/>
    </xsd:schema>
</types>
<…>

The messages are described by the following snippet:

<…>
<message name="PRPA_IN201304UV02_Message">
    <part element="hl7:PRPA_IN201304UV02" name="Body"/>
</message>
<message name="MCCI_IN000002UV01_Message">
    <part element="hl7:MCCI_IN000002UV01" name="Body"/>
</message>
<…>

The port types for the WSDL describing the Duplicates Resolved Service are described together with the expected actions of the actors which receive these messages in Section 3.44.4.2.3 and Section 3.44.4.2.4.

3.44.4.2.3 Expected Actions – PIX Manager

The Patient Identifier Cross-reference Manager shall be capable of accepting attributes in the Duplicates Resolved message as specified in Table 3.44.4.2.2.2-1.

The Patient Identifier Cross-reference Manager shall perform the Expected Actions similar to the ones specified in ITI TF-2: 3.8.4.2.3. The particular behavior is described below.

When the Patient Identifier Cross-reference Manager receives the Duplicates Resolved message type of the Patient Identity Feed transaction, it shall cross-reference the patient identifiers provided in the wrapper and the payload of the message by replacing any references it is maintaining internally to the patient ID provided in the wrapper by the patient ID included in the payload. After the identifier references are replaced, the Patient Identifier Cross-reference Manager shall reapply its internal cross-referencing logic/ policies before providing the updated information via either the PIX V3 Query [ITI-45] or PIX V3 Update Notification [ITI-46] transactions.

3.44.4.2.3.1 Web Services Port Type and Binding Definitions

IHE-WSP201) The attribute /wsdl:definitions/@name SHALL be "PIXManager".

The following WSDL naming conventions SHALL apply for wsdl:definitions/@name="PIXManager":

"merge" message -> "PRPA_IN201304UV02_Message"
acknowledgement -> "MCCI_IN000002UV01_Message"
portType -> "PIXManager_PortType"
merge operation -> "PIXManager_PRPA_IN201304UV02"
SOAP 1.2 binding -> "PIXManager_Binding_Soap12"
SOAP 1.2 port -> "PIXManager_Port_Soap12"

The following WSDL snippets specify the Patient Identity Feed Port Type and Binding definitions, according to the requirements specified in ITI TF-2: Appendix V .

3.44.4.2.3.1.1 Port Type

<…>
<portType name="PIXManager_PortType">
    <operation name="PIXManager_PRPA_IN201304UV02">
        <input message="tns:PRPA_IN201304UV02_Message" wsaw:Action="urn:hl7-org:v3:PRPA_IN201304UV02"/>
        <output message="tns:MCCI_IN000002UV01_Message" wsaw:Action="urn:hl7-org:v3:MCCI_IN000002UV01"/>
    </operation>
</portType>
<…>

3.44.4.2.3.1.2 Bindings

SOAP 1.2 binding:

<…>
<binding name="PIXManager_Binding_Soap12" type="PIXManager_PortType">
    <wsoap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="PIXManager_PRPA_IN201304UV02">
      <wsoap12:operation soapActionRequired="false"/>
      <input>
          <wsoap12:body use="literal"/>
      </input>
      <output>
          <wsoap12:body use="literal"/>
      </output>
    </operation>
</binding>
<…>

An informative WSDL for the PIX Manager implementing the PIXV3 Profile is available online: see ITI TF-2: Appendix W .

3.44.4.2.3.2 Message Examples

Message examples can be found online: see ITI TF-2: Appendix W .

3.44.4.2.4 Expected Actions – Document Registry

The Document Registry shall be capable of accepting attributes in the Duplicates Resolved message as specified in Table 3.44.4.2.2.2-1. Other attributes may exist, but the Document Registry shall ignore them.

The Document Registry shall perform the Expected Actions similar to the ones specified in ITI TF-2: 3.8.4.2.4 . The particular behavior is described below.

When the Document Registry receives the Duplicates Resolved message of the Patient Identity Feed transaction, it shall merge the patient identity specified in the priorRegisteredRole.id attribute of the Control-Act wrapper (subsumed patient identifier) into the patient identity specified in Patient.id attribute of the message payload (surviving patient identifier) in its registry. After the merge, all Document Submission Sets (including all Documents and Folders beneath them) under the secondary patient identity before the merge shall point to the primary patient identity. The secondary patient identity shall no longer be referenced in the future services provided by the Document Registry.

Changes resulting from a Duplicates Resolved message are not reversible. No un-resolve message is supported by this transaction.

A Duplicates Resolved message contains two attributes of interest:

priorRegisteredRole.id – subsumed patient identifier: the patient identifier which is to become obsolete
Patient.id – surviving patient identifier: the patient identifier which is to remain active.

After a duplicate resolution, the Patient.id attribute represents all records formerly represented by either the Patient.id attribute or the priorRegisteredRole.id attribute. All other attributes may be ignored.

The following conditions shall be detected by the Document Registry. Messages containing these conditions shall not update the state of the Document Registry.

The subsumed patient identifier is not issued by the correct Assigning Authority according to the Affinity Domain configuration.
The surviving patient identifier is not issued by the correct Assigning Authority according to the Affinity Domain configuration.
The subsumed and surviving patient identifiers are the same.
The subsumed patient identifier has already been subsumed by an earlier message.
The surviving patient identifier has already been subsumed by and earlier message.
The subsumed patient identifier does not convey a currently active patient identifier known to the Document Registry.

If none of the above conditions occur then the Document Registry shall perform the following duties:

Records the merge. Only the subsumed and surviving patient identifiers need be remembered. A patient identifier merge affects the processing of future Registry Stored Query [ITI-18] and Register Document Set-b [ITI-42] transactions. See ITI TF-2: 3.18.4.1.2.3.9 for details of how this message type affects results of a query transaction and Section 3.42.4.1.3.3.2 to see how it affects the Register Document Set-b [ITI-42] transaction.
Multiple merge transactions can form a recorded merge chain, where the Subsumed identifier of the current merge is the Surviving identifier of a previous merge.
Register Document Set-b transactions referencing a subsumed identifier are rejected with an XDSUnknownPatientId error.
Registry Stored Query transactions referencing a subsumed identifier return no content.
Registry Stored Query transactions referencing a surviving identifier successfully match the entire recorded merge chain and return appropriate metadata.
No change in the Registry StoredQuery transaction.

Note: This transaction does not specify how the merge is to be implemented. It may or may not change the stored form of the metadata. It only specifies the observable results from the perspective of the Registry Stored Query [ITI-18] transaction and the Register Document Set-b [ITI-42].transaction.

3.44.4.2.4.1 Web Services Port Type and Binding Definitions

IHE-WSP201) The attribute /wsdl:definitions/@name SHALL be "DocumentRegistry”.

The following WSDL naming conventions SHALL apply for wsdl:definitions/@name="DocumentRegistry":

"resolve duplicates" message -> "PRPA_IN201304UV02_Message"
acknowledgement               -> "MCCI_IN000002UV01_Message"
portType                      -> "DocumentRegistry_PortType"
resolve duplicates operation -> "DocumentRegistry_PRPA_IN201304UV02"
SOAP 1.2 binding              -> "DocumentRegistry_Binding_Soap12"
SOAP 1.2 port                 -> "DocumentRegistry_Port_Soap12"

The following WSDL snippets specify the Patient Identity Feed Port Type and Binding definitions, according to the requirements specified in ITI TF-2: Appendix V .

3.44.4.2.4.1.1 Port Type

<…>
<portType name="DocumentRegistry_PortType">
    <operation name="DocumentRegistry_PRPA_IN201304UV02">
        <input message="tns:PRPA_IN201304UV02_Message" wsaw:Action="urn:hl7-org:v3:PRPA_IN201304UV02"/>
        <output message="tns:MCCI_IN000002UV01_Message" wsaw:Action="urn:hl7-org:v3:MCCI_IN000002UV01"/>
    </operation>
</portType>
<…>

3.44.4.2.4.1.2 Bindings

SOAP 1.2 binding:

<…>
<binding name="DocumentRegistry_Binding_Soap12" type="DocumentRegistry_PortType">
    <wsoap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="DocumentRegistry_PRPA_IN201304UV02">
        <wsoap12:operation soapActionRequired="false"/>
        <input>
            <wsoap12:body use="literal"/>
        </input>
        <output>
            <wsoap12:body use="literal"/>
        </output>
    </operation>
</binding>
<…>

An informative WSDL for the Document Registry implementing the XDS.b Profile is available online: see ITI TF-2: Appendix W .

3.44.4.2.4.2 Message Examples

Message examples can be found online: see ITI TF-2: Appendix W .

3.44.5 Security Requirements

This transaction is generally used in profiles that require actors to be grouped with a Secure Node as defined in the Audit Trail and Node Authentication (ATNA) Profile. This use of the ATNA Profile in an XDS Affinity Domain does not require a centralized XDS Affinity Domain Audit Record Repository.

The use of ATNA along with XDS does require that each member of the XDS Affinity Domain have audit and security mechanisms in place. See ITI TF-1: Appendix G and ITI TF-2: Appendix K .

The individual actors involved are often members of different secure domains. The data transfers between different secure domains need different protection than transfers within a secure domain and shall be encrypted with TLS authentication of both hosts.

Transfers within a single secure domain may choose to omit encryption if it is unnecessary, so it is recommended that the online transfer security mechanisms be configurable. Certificate management and exchange is defined as part of the XDS Affinity Domain business relationships and no IHE Integration Profile is specified at this time, see ITI TF-1: Appendix L .

Each transaction will result in audit records describing the transaction. Each secure domain has its own audit server to capture the records for the actors that are within that domain. Access to audit records by other enterprises within the XDS Affinity Domain is managed and controlled by the business relationship terms of the XDS Affinity Domain. There is no automatic IHE transaction for such access.

3.44.5.1 Security Audit Record

When grouped with ATNA Secure Node or Secure Application Actors, this transaction is to be audited as “Patient Record” event, as defined in ITI TF-2: Table 3.20.4.1.1.1-1. The following tables show items that are required to be part of the audit record for this transaction.

Logically, a merge operation consists of a delete on one patient record, and an update of another patient record. Separate audit records shall be written for the delete operation and the update operation.

3.44.5.1.1 Patient Identity Source audit message

	Field Name	Opt	Value Constraints
Event AuditMessage/ EventIdentification	EventID	M	EV(110110, DCM, “Patient Record”)
	EventActionCode	M	“C” (create) , “U” (update), or “D” (delete) as appropriate
	EventDateTime	M	not specialized
	EventOutcomeIndicator	M	not specialized
	EventTypeCode	M	EV(“ITI-44”, “IHE Transactions”, “Patient Identity Feed”)
Source (Patient Identity Source Actor) (1)
Human Requestor (0..n)
Destination (Patient Identifier Cross-reference Manager or Document Registry) (1)
Audit Source (Patient Identity Source Actor) (1)
Patient (1)

Where:

Source AuditMessage/ ActiveParticipant	UserID	U	not specialized
	AlternativeUserID	M	the process ID as used within the local operating system in the local system logs.
	UserName	U	not specialized
	UserIsRequestor	U	not specialized
	RoleIDCode	M	EV(110153, DCM, "Source Role ID")
	NetworkAccessPointTypeCode	M	“1” for machine (DNS) name, “2” for IP address
	NetworkAccessPointID	M	the machine name or IP address.

Human Requestor (if known) AuditMessage/ ActiveParticipant	UserID	M	identity of the human that initiated the transaction.
	AlternativeUserID	U	not specialized
	UserName	U	not specialized
	UserIsRequestor	U	not specialized
	RoleIDCode	U	Access Control role(s) the user holds that allows this transaction.
	NetworkAccessPointTypeCode	U	not specialized
	NetworkAccessPointID	U	not specialized

Destination AuditMessage/ ActiveParticipant	UserID	M	SOAP endpoint URI.
	AlternativeUserID	U	not specialized
	UserName	U	not specialized
	UserIsRequestor	U	not specialized
	RoleIDCode	M	EV(110152, DCM, "Destination Role ID")
	NetworkAccessPointTypeCode	M	“1” for machine (DNS) name, “2” for IP address
	NetworkAccessPointID	M	the machine name or IP address.

Audit Source AuditMessage/ AuditSourceIdentification	AuditSourceID	U	not specialized
	AuditEnterpriseSiteID	U	not specialized
	AuditSourceTypeCode	U	not specialized

Patient (AuditMessage/ ParticipantObjectIdentification)	ParticipantObjectTypeCode	M	“1” (person)
	ParticipantObjectTypeCodeRole	M	“1” (patient)
	ParticipantObjectDataLifeCycle	U	not specialized
	ParticipantObjectIDTypeCode	M	not specialized
	ParticipantObjectSensitivity	U	not specialized
	ParticipantObjectID	M	the patient ID in HL7 CX format (see ITI TF-2: Appendix E )
	ParticipantObjectName	U	not specialized
	ParticipantObjectQuery	U	not specialized
	ParticipantObjectDetail	M	Type=II (the literal string), Value=the value of message.id

3.44.5.1.2 Patient Identifier Cross-reference Manager audit message

	Field Name	Opt	Value Constraints
Event AuditMessage/ EventIdentification	EventID	M	EV(110110, DCM, “Patient Record”)
	EventActionCode	M	“C” (create) , “U” (update), or “D” (delete) as appropriate
	EventDateTime	M	not specialized
	EventOutcomeIndicator	M	not specialized
	EventTypeCode	M	EV(“ITI-44”, “IHE Transactions”, “Patient Identity Feed”)
Source (Patient Identity Source Actor) (1)
Destination (Patient Identifier Cross-reference Manager or Document Registry) (1)
Audit Source (Patient Identifier Cross-reference Manager or Document Registry) (1)
Patient (1)

Where:

Source AuditMessage/ ActiveParticipant	UserID	U	not specialized
	AlternativeUserID	U	not specialized
	UserName	U	not specialized
	UserIsRequestor	U	not specialized
	RoleIDCode	M	EV(110153, DCM, "Source Role ID")
	NetworkAccessPointTypeCode	M	“1” for machine (DNS) name, “2” for IP address
	NetworkAccessPointID	M	the machine name or IP address.

Destination AuditMessage/ ActiveParticipant	UserID	M	SOAP endpoint URI
	AlternativeUserID	M	the process ID as used within the local operating system in the local system logs.
	UserName	U	not specialized
	UserIsRequestor	M	“false”
	RoleIDCode	M	EV(110152, DCM, "Destination Role ID")
	NetworkAccessPointTypeCode	M	“1” for machine (DNS) name, “2” for IP address
	NetworkAccessPointID	M	the machine name or IP address.

Audit Source AuditMessage/ AuditSourceIdentification	AuditSourceID	U	not specialized
	AuditEnterpriseSiteID	U	not specialized
	AuditSourceTypeCode	U	not specialized

Patient (AuditMessage/ ParticipantObjectIdentification)	ParticipantObjectTypeCode	M	“1” (person)
	ParticipantObjectTypeCodeRole	M	“1” (patient)
	ParticipantObjectDataLifeCycle	U	not specialized
	ParticipantObjectIDTypeCode	M	not specialized
	ParticipantObjectSensitivity	U	not specialized
	ParticipantObjectID	M	the patient ID in HL7 CX format (see ITI TF-2: Appendix E ).
	ParticipantObjectName	U	not specialized
	ParticipantObjectQuery	U	not specialized
	ParticipantObjectDetail	M	Type=II (the literal string), Value=the value of message.id

3.44.5.1.3 Document Registry audit message

Document Registry audit message are the same as Patient Identifier Cross-reference Manager audit message as presented in Section 3.44.5.1.2.