3.55 Cross Gateway Patient Discovery [ITI-55]

This section corresponds to transaction [ITI-55] of the IHE ITI Technical Framework. Transaction [ITI-55] is used by the Initiating Gateway and Responding Gateway Actors.

This transaction is modified by Trial Implementation Supplement: Defined in Cross-Community Patient Discovery (XCPD) Health Data Location and Revoke Option Supplement

3.55.1 Scope

The Cross Gateway Patient Discovery transaction supports the ability for Initiating Gateways and Responding Gateways to discover mutually known patients. This transaction assumes an environment where patient data is well described and high quality demographic data is available.

Because the transaction supports the mutual discovery of patients it can be seen as having dual purposes.

• To support a query by the Initiating Gateway requesting a demographically matching patient from within the Responding Gateway’s community.
• To support a feed to Responding Gateway announcing that the patient is known by the Initiating Gateway’s community.

This dual nature of the transaction is chosen for scalability purposes, as demographic matching algorithms are expensive on a large scale and once a match is identified it is important that both the initiating and responding sides of the transaction can use the results of that successful match.

The Cross Gateway Patient Discovery transaction has several modes, useful in different environments:

• Demographic Query only mode – in this mode only the demographics of the patient are included in the request. The initiating community does not have, or does not choose to specify, a patient identifier for use by the Responding Gateway.
• Demographic Query and Feed – in this mode both the demographic and initiating community identifier are included in the request.
• Shared/national Patient Identifier Query and Feed – in this mode only a shared/national identifier is specified. Demographics are not necessary because matching can be done on the identifier alone.

This transaction can be used synchronously and asynchronously.

The Cross Gateway Patient Discovery request asks for information about patients whose demographic data match data provided in the query message. The request is received by the Responding Gateway Actor. The Responding Gateway indicates in its response whether the community has knowledge of a patient matching the set of demographic data and, if a match is found, returns the demographics known by the responding community. If more than one match is found the Responding Gateway has the option of providing a list (Returning a list of matches may potentially expose information that is unrelated to the patient requested. Implementers are encouraged to consider ways to keep the number of elements in a list to a minimum. Deployment organizations may choose to declare a limit to the number of elements allowed to be returned.) of matching patients or returning nothing. When nothing is returned the Responding Gateway may include in the response a set of additional demographic attributes which, if supplied, would aid in disambiguating the multiple matches.

In the case of a match, the Responding Gateway may further update its own cache to indicate that the initiating community knows this patient and should be queried if data for this patient is desired.

The criteria used for demographic matching is defined by policy and not specified here, but fully enabled by the transaction.

3.55.2 Use Case Roles

Actor: Initiating Gateway

Role: Requests the Responding Gateway to indicate whether the community has knowledge of a patient matching a set of demographic criteria.

Corresponding HL7 v3 Application Roles :

Person Registry Query Placer (PRPA_AR201303UV02)

Actor: Responding Gateway

Role: If a demographics match is found, returns demographics known by the responding community. If more than one match is found the Responding Gateway has the option of providing a small list of matching patients or returning no match. In the case of no match, the Responding Gateway may provide a list of additional demographic attributes needed to disambiguate multiple matches.

Corresponding HL7 v3 Application Roles:

Person Registry Query Fulfiller (PRPA_AR201304UV02)

3.55.3 Referenced Standard

HL7 Version 3 Edition 2008, Patient Administration DSTU, Patient Topic (found at https://www.hl7.org/implement/standards/product_brief.cfm?product_id=186 )

Implementers of this transaction shall comply with all requirements described in ITI TF-2: Appendix V Web Services for IHE Transactions

3.55.4 Messages

3.55.4.1 Cross Gateway Patient Discovery Request

The Cross Gateway Patient Discovery Request is implemented using the HL7 Patient Registry Query by Demographics (PRPA_MT201306UV02) message.

3.55.4.1.1 Trigger Events

The initiating community needs to determine whether a patient is known by another community. Specific possible trigger events include, but are not limited to:

• The initiating community registers a new patient who has permitted sharing of healthcare data with external communities.
• A healthcare provider within the community requests that records regarding a particular patient be accessed from a particular external community or all external communities known.

3.55.4.1.2 Message Semantics

The components of the Patient Registry Query by Demographics message with cardinality greater than 0 (as shown below) are required, and the detailed description of the message is provided in Sections 3.55.4.1.2.1 to 3.55.4.1.2.3.

For each element which is required, the element shall be specified by the Initiating Gateway in the request and shall be used by the Responding Gateway as part of its demographic matching algorithm.

For each element which is optional the element does not need to be specified by the Initiating Gateway in the request but, if specified, shall be used by the Responding Gateway as part of its demographic matching algorithm.

The Responding Gateway shall support Asynchronous Web Services Exchange as described in ITI TF-2: V.5, Synchronous and Asynchronous Web Services Exchange. If the Initiating Gateway declares the Asynchronous Web Services Exchange Option it shall also support Asynchronous Web Services Exchange as described in ITI TF-2: V.5. Use of Asynchronous Web Services Exchange is necessary when transactions scale to large numbers of communities because it allows for more efficient handling of latency and scale.

The Initiating Gateway may specify a duration value in the SOAP Header element of the request. This value suggests to the Responding Gateway a length of time that the Initiating Gateway recommends caching any correlation resulting from the interaction. The duration value is specified in the SOAP Header using the CorrelationTimeToLive element and contains a value conformant with the xs:duration type defined in http://www.w3.org/TR/xmlschema-2/#duration. If no CorrelationTimeToLive element is specified in the SOAP Header the Responding Gateway shall interpret this as a recommendation against caching, unless a mutually agreed policy states otherwise.

An example of specifying the CorrelationTimeToLive element follows, which recommends caching of 7 days.

<xcpd:CorrelationTimeToLive>P0Y0M7D</xcpd:CorrelationTimeToLive>

3.55.4.1.2.1 Major Components of the Patient Registry Query by Demographics

LivingSubjectName Parameter

This required parameter specifies the name of the person whose information is being queried. If multiple instances of LivingSubjectName are provided, the receiver shall consider them as possible alternatives, logically connected with an "or". Within each LivingSubjectName element, a single person name (PN) data item shall be specified in the LivingSubjectName.value attribute. An Initiating Gateway may specify all, or only a subset of the name parts within the PN data type (e.g., family name). The use attribute of the value element shall not be set to "SRCH".

LivingSubjectAdministrativeGender Parameter

This optional parameter specifies the administrative gender of the person whose information is being queried. For this parameter item, a single administrative gender code shall be specified in the LivingSubjectAdministrativeGender.value attribute.

LivingSubjectBirthTime Parameter

This required parameter specifies the birth data and time of the person whose information is being queried. This parameter can convey an exact moment (e.g., January 1, 1960 @ 03:00:00 EST), an approximate date (e.g., January 1960), or even a range of dates (e.g., December 1, 1959 through March 31, 1960).

PatientAddress Parameter

This optional parameter specifies one or more addresses associated with the person whose information is being queried.

LivingSubjectId Parameter

This optional repeating parameter specifies an identifier associated with the patient whose information is being queried (e.g., a local identifier, or an account identifier). If this parameter is specified, LivingSubjectName and LivingSubjectBirthTime are optional. This feature allows this query to be used when a national/shared patient identifier is known. The identifier specified in the LivingSubjectId.value attribute is expressed using the II data type. Please see ITI TF-2: Appendix E for the use of the II data type for patient identifiers.

The Initiating Gateway has the option of designating one of the identifiers in LivingSubjectId as the patient identifier that the Responding Gateway may use in an XCA Cross Gateway Query to the community represented by the Initiating Gateway (see Section 3.55.4.1.2.4).

LivingSubjectBirthPlaceAddress Parameter

This optional parameter specifies the birth address of the patient.

LivingSubjectBirthPlaceName Parameter

This optional parameter specifies the name of the entity (like hospital name) where the patient was born.

MothersMaidenName Parameter

This optional parameter specifies the maiden name of the mother of the person whose information is being queried. For this parameter item, a single person name (PN) data item shall be specified in the Person.value attribute. Within the PN data type, the given name and family name may be specified. The use attribute of the value element shall not be set to "SRCH"

PatientTelecom

This optional parameter specifies a telecommunication address or addresses for communication with the patient.

PrincipalCareProviderId

This optional parameter specifies the care provider identifier of a person who has been assigned as the principal care provider of this patient. The requestor may specify multiple PrincipalCareProviderId elements which the responder shall consider as possible alternatives, logically connected with an "or". Within each PrincipalCareProviderId element, a single identifier shall be specified in the PrincipalCareProviderId.value attribute.

3.55.4.1.2.2 Message Information Model of the Patient Registry Query by Demographics Message

Below is the Message Information Model for the Query by Demographics 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 Registry Query by Demographics (PRPA_RM201306UV02) RMIM.

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

• The optional attributes ParameterList.id, MatchCriterionList.id, QueryByParameter responseElementGroupId, QueryByParameter.modifyCode, and QueryByParameter.executionAndDeliveryTime were omitted from the model.
• QueryByParameter.responsePriorityCode is required and is either I (Immediate) or D (Deferred). See Section 3.55.6.2 for use of Deferred.
• QueryByParameter.responseModalityCode is required and is fixed to R (Real Time).
• QueryByParameter.statusCode is defaulted to "new".
• The data type of MatchAlgorithm.value is constrained to ST.
• The data type of MinimumDegreeMatch.value is constrained to INT between 0 and 100.
• The data type of LivingSubjectName.value is constrained to PN.
• The optional SortControl was omitted from the model.
• The optional MatchWeight was omitted from the model.
• The following optional parameters were omitted from the model:

• PatientStatusCode
• LivingSubjectDeceaseTime
• OtherIDsScopingOrganization
• initialQuantity
• initialQuantityCode

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

Table 3.55.4.1.2.2-1: Model Attributes

PRPA_HD201306IHE Patient Registry Query by Demographics	This HMD extract defines the message used to query a community for patients matching a set of demographics information. Derived from Figure 3.55.4.1.2.2-1 (PRPA_RM201306IHEXCPD)
QueryByParameter	The entry point for the domain content in this query
queryId [1..1] QueryByParameter  ( II )	Unique identifier for the query
statusCode [1..1] (M) QueryByParameter  ( CS ) {CNE: QueryStatusCode , fixed value="new"}	The status of the query, shall be "new"
responseModalityCode [1..1] QueryByParameter  ( CS ) {CNE: ResponseModality , fixed value="R"}	The mode of the response – always real-time.
responsePriorityCode [1..1] QueryByParameter  ( CS ) {CNE: QueryPriority }	Either “I” or “D” shall be specified. “I” (Immediate) indicates that the Responding Gateway is required to send an immediate response. “D” (Deferred) indicates the Responding Gateway is required to send a deferred response, see Section 3.55.6.2.
initialQuantity [0..1] QueryByParameter  ( INT )	Not supported, any value will be ignored by responder.
initialQuantityCode [0..1] QueryByParameter  ( CE ) {CWE: QueryRequestLimit , default="RD"}	Not supported, any value will be ignored by responder.
MatchAlgorithm	This parameter conveys instructions to the Responding Gateway specifying the preferred matching algorithm to use and may be ignored
value [1..1] ParameterItem  (ST)	The name of the algorithm
semanticsText [1..1] ParameterItem  ( ST ){default= "MatchAlgorithm"}
MinimumDegreeMatch	This parameter conveys instructions to the Responding Gateway specifying minimum degree of match to use in filtering results and may be ignored
value [1..1] ParameterItem  (INT)	The numeric value of the degree of match. Shall be value between 0 and 100.
semanticsText [1..1] ParameterItem  ( ST ){default= "MinimumDegreeMatch"}
LivingSubjectAdministrativeGender	This query parameter is a code representing the administrative gender of a person in a patient registry.
value [1..1] ParameterItem  ( CE ) {CWE: AdministrativeGender }
semanticsText [1..1] ParameterItem  ( ST ){default= "LivingSubject.administrativeGender"}
LivingSubjectBirthTime	This query parameter is the birth date of a living subject.
value [1..1] ParameterItem  ( IVL < TS >)	A date or date range. This parameter can convey an exact moment (e.g., January 1, 1960 @ 03:00:00 EST), an approximate date (e.g., January 1960), or even a range of dates (e.g., December 1, 1959 through March 31, 1960).
semanticsText [1..1] ParameterItem  ( ST ){default= "LivingSubject.birthTime"}
LivingSubjectId
value [1..*] (M) ParameterItem  ( II )	A patient identifier, used to assist in finding a match for the query and, when so designated by the Initiating Gateway, used by the Responding Gateway in a XCA Cross Gateway Query directed to the Community designated by the homeCommunityId value specified in the Control Act Wrapper – see Section 3.55.4.1.2.4.
semanticsText [1..1] ParameterItem  ( ST ){default= "LivingSubject.id"}
LivingSubjectName	This query parameter is the name of a person. If multiple instances of LivingSubjectName are provided, the receiver must consider them as possible alternatives, logically connected with an "or".
value [1..1] ParameterItem  (PN)	Only one instance of the value element is allowed. Only some of the name parts may be populated. If, for example, only the family and given name parts of a person's name are sent, then the query would match all persons with that family name and given name regardless of their initials. The use attribute of the value element shall not be set to "SRCH".
semanticsText [1..1] ParameterItem  ( ST ){default= "LivingSubject.name"}
PatientAddress	This query parameter is a postal address for corresponding with a patient. There shall be only a single PatientAddress element.
value [1..*] ParameterItem  ( AD )	Multiple instances of the value element within a Patient Address may be specified and are combined with OR logic.
semanticsText [1..1] ParameterItem  ( ST ){default= "Patient.addr"}
LivingSubjectBirthPlaceAddress	This query parameter is a patient's birthplace represented as an address
value [1..*] ParameterItem (SET<AD>)
semanticsText [1..1] ParameterItem (ST){default= "LivingSubject.BirthPlace.Addr"}
LivingSubjectBirthPlaceName	This query parameter is a patient's birthplace represented as a place name
value [1..*] ParameterItem (SET<EN>)
semanticsText [1..1] ParameterItem (ST){default= "LivingSubject.BirthPlace.Place.Name"}
PrincipalCareProviderId	This query parameter is the care provider identifier of a person who has been assigned as the principal care provider of this patient. The requestor may specify multiple PrincipalCareProviderId elements which responder shall consider as possible alternatives, logically connected with an "or".
value [1..1] ParameterItem (II)	There shall have only one id in the “value” attribute.
semanticsText [1..1] ParameterItem (ST){default= "AssignedProvider.id"}
MothersMaidenName	This query parameter is the maiden name of a focal person's mother. It is included as a parameter because it is a common attribute for confirming the identity of persons in some registries. This parameter does not map to a single RIM attribute, instead, in RIM terms Mother's maiden name is the person name part of "family" with an EntityNamePartQualifier of "birth" for the person who is the player in a PersonalRelationship of type of "mother" to the focal person.
value [1..1] ParameterItem  ( PN )	A person name. In this case it may consist of only the given name part, the family name part, or both.
semanticsText [1..1] ParameterItem  ( ST ){default= "Person.MothersMaidenName"}
PatientTelecom	This query parameter is a telecommunications address for communicating with a living subject in the context of the target patient registry. It could be a telephone number, fax number or even an email address. There shall be only a single PatientTelecom element.
value [1..*] ParameterItem  ( TEL )	A telecommunications address. The scheme attribute specifies whether this is a telephone number, fax number, email address, etc. Multiple instances of the value element within a PatientTelecom may be specified and are combined with OR logic.
semanticsText [1..1] ParameterItem  ( ST ){default= "Patient.telecom"}

3.55.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.55.4.1.2.3-1 contains the Transmission and Control Act wrappers used for this interaction, and the associated constraints.

Table 3.55.4.1.2.3-1: Wrappers and Constraints

Transmission Wrapper	Trigger Event Control Act Wrapper
MCCI_MT000100UV01 - Send Message Payload	QUQI_MT021001UV01 - Query Control Act Request : Query By Parameter
The value of interactionId shall be set to PRPA_IN201305UV02 The value of processingModeCode shall be set to T The acceptAckCode shall be set to AL There shall be only one receiver Device	The value of ControlActProcess.moodCode shall be set to EVN The trigger event code in ControlActProcess.code shall be set to PRPA_TE201305UV02 If an authorOrPerformer participation is present, the value of authorOrPerformer.typeCode SHALL be set to AUT

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_IN201305UV02.xsd

3.55.4.1.2.4 Values used by Responding Gateway for a reverse Cross Gateway Query

The Initiating Gateway shall specify two values in the request which allow the responding community to generate a reverse Cross Gateway Query in search of data about the patient identified in the Cross Gateway Patient Discovery request. The two values are homeCommunityId and community patient id assigning authority.

homeCommunityId – this value is a globally unique identifier for a community – further defined in Section 3.38.4.1.2.1. The Initiating Gateway shall specify this value in the Cross Gateway Patient Discovery request unless the Initiating Gateway is not grouped with a Responding Gateway.

The Responding Gateway uses the homeCommunityId to obtain the Web Services endpoint of services that provide access to data in the Initiating Gateway’s community.

The homeCommunityId is specified as the id element within the Organization associated with the device of the sender. The id element designating the homeCommunityId shall have only the root element the contents of which is the homeCommunityId.

An example of specifying the homeCommunityId element follows, where homeCommunityId=1.2.3.

Community patient id assigning authority – this value designates the assigning authority for the patient identifier to be used within a reverse Cross Gateway Query. This value is not the assigning authority for all patient identifiers used by that community, but only the patient identifier used for the patient identified in the query. The Initiating Gateway shall be capable of specifying this value in the Cross Gateway Patient Discovery request.

The Responding Gateway may use the specified assigning authority to identify which of the LivingSubjectID values to use in a reverse Cross Gateway Query.

The community patient id assigning authority is specified as the id element within the assignedDevice associated with the authorOrPerformer element. The id element designating the community patient id assigning authority shall have only the root element, the contents of which designate the assigning authority of the LivingSubjectId to be used in the reverse Cross Gateway Query.

An example of specifying the community patient id assigning authority element follows, where the assigning authority specified is 1.2.840.114350.1.13.99997.2.3412 which identifies the first LivingSubjectID (root="1.2.840.114350.1.13.99997.2.3412" extension="1234") as the patient identifier to be used in a reverse Cross Gateway Query.

Comparison of homeCommunityId and assigning authority

The value of homeCommunityId is an OID which may, or may not, also be an assigning authority. An assigning authority is designated by an OID and issues identifiers, in this case patient identifiers. A community’s patient identifier assigning authority issues patient identifiers for patients managed by the community. It is possible for there to be more than one patient identifier assigning authority in a community. The Initiating Gateway must specify the right patient identifier assigning authority for the patient being described. There is only one homeCommunityId per community. This OID may also be used by the community as the patient identifier assigning authority, but this is not required and should not be expected. While both values are OIDs, they have no necessary relationship. In general it is expected that the homeCommunityId will be assigned by an organization which governs the interaction among communities. In many countries this will be facilitated by the government who will manage the community level agreements necessary for sharing and also assign homeCommunityIds. An assigning authority has no expected level of management, and there may be multiple patient identifier assigning authorities within a community.

3.55.4.1.2.5 Requesting Results From A Single Community in a Hierarchy

When the Responding Gateway serves more than one community, such as the case in ITI TF-1: 27.3.2.2, the Initiating Gateway might only want results from one of those communities. In that case, the Initiating Gateway can indicate which community it wants results from by populating the homeCommunityId of the targeted community in the id element within the Organization associated with the device of the receiver. See Figure 3.55.4.1.2.4-1.

3.55.4.1.3 Expected Actions

If responsePriorityCode is “I” the Responding Gateway shall return a Find Candidates Response message as specified in Section 3.55.4.2. The response message uses the Application Acknowledgement transmission wrapper, as specified in ITI TF-2: O.1.3, and no other acknowledgments are part of this the transaction.

If responsePriorityCode is “D” and the Responding Gateway does not support the Deferred Response Option, it shall return an application error in the HL7 V3 Accept Acknowledgement with acknowledgeDetail to indicate Unsupported Processing Mode.

If the Responding Gateway supports the Deferred Response Option, it shall respond as described in Section 3.55.6.2.

If the Responding Gateway is unable to process the request due to an internal error, such as the local Master Patient Index system is offline, the Responding Gateway shall return an application error as described in Section 3.55.4.2.3 Case 5.

The community associated with the Responding Gateway may make use of the homeCommunityId and community patient identifier assigning authority by initiating a Cross Gateway Query. See Section 3.55.4.1.2.4 for more information. This provisioning of the Responding Gateway community may be cached indefinitely, but efforts are needed to ensure that changes are properly reflected. For more detail about this issue refer to Section 3.55.4.2.3.1.

3.55.4.1.3.1 Query Parameter Processing

The Responding Gateway shall be capable of accepting, searching on, and responding with attributes in the Query Person by Demographics message.

Handling of phonetic issues, alternate spellings, upper and lower case, accented characters, etc., if deemed appropriate, is to be supported by the Responding Gateway rather than by the Initiating Gateway. The Responding Gateway shall return any matches to the query parameters that reflect a high degree of match, after consideration of all policy constraints; IHE does not further specify matching requirements, except as already discussed in the LivingSubjectName parameter description.

3.55.4.1.3.2 Targeted Community Processing

If the Responding Gateway serves results from multiple communities, and the Initiating Gateway specified a target community in which to search results as described in Section 3.55.4.1.2.5, then the Responding Gateway SHOULD search only the community identified by the homeCommunityId of the receiver device’s Organization. If the homeCommunityId is not one that is served by the Responding Gateway, then it SHOULD return an error as specified in Case 5 of Section 3.55.4.2.3.

3.55.4.2 Cross Gateway Patient Discovery Response

The Cross Gateway Patient Discovery Response is implemented using the HL7 Patient Registry Find Candidates Response message (PRPA_MT201310UV02).

3.55.4.2.1 Trigger Events

The Patient Registry Find Candidates Response message (PRPA_MT201310UV02) is sent by the Responding Gateway in response to the query (PRPA_MT201306UV02) message previously received.

3.55.4.2.2 Message Semantics

The components of the message with cardinality greater than 0 (as shown below) are required, and the detailed description of the message is provided in Sections 3.55.4.2.2.1 to 3.55.4.2.2.7. All other attributes of the message are optional.

For each element that is required this means that it shall be provided by Responding Gateway, unless not available, and shall be accepted by requestor but requestor is not required to process the value in any way, only accept it without any error.

When populating data elements that are part of the Patient, the Responding Gateway shall populate values according to the patient identity record maintained by the responding community.

The Responding Gateway shall support Asynchronous Web Services Exchange as described in ITI TF-2: V.5, Synchronous and Asynchronous Web Services Exchange. If the Initiating Gateway declares the Asynchronous Web Services Exchange Option it shall also support Asynchronous Web Services Exchange as described in ITI TF-2: V.5. Use of Asynchronous Web Services Exchange is necessary when transactions scale to large numbers of communities because it allows for more efficient handling of latency and scale.

The Responding Gateway may specify a duration value in the SOAP Header element of the response. This value suggests to the Initiating Gateway a length of time that the Responding Gateway recommends caching any correlation resulting from the interaction. The duration value is specified in the SOAP Header using the CorrelationTimeToLive element and contains a value conformant with the xs:duration type defined in http://www.w3.org/TR/xmlschema-2/#duration. If no CorrelationTimeToLive element is specified in the SOAP Header the Initiating Gateway shall interpret this as a recommendation against caching, unless a mutually agreed policy states otherwise.

An example of specifying the CorrelationTimeToLive element follows, which recommends caching of 7 days.

<xcpd:CorrelationTimeToLive>P0Y0M7D</xcpd:CorrelationTimeToLive>

3.55.4.2.2.1 Major Components of the Patient Registry Find Candidates Response Message

This message shares all the major components of the Patient Activate/Revise messages, as described in Section 3.44.4.1.2.1. The only additional component is the QueryMatchObservation class.

Query Match Observation

The QueryMatchObservation class is used to convey information about the quality of the match for each record returned by the query response.

3.55.4.2.2.2 Message Information Model of the Patient Registry Find Candidates Response Message

Below is the Message Information Model for the Patient Registry Find Candidates Response 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 common subset of the Patient Registry Find Candidates Response (PRPA_RM201310UV02) RMIM.

The base RMIM can be found on the HL7 V3 2008 Edition CD at Edition2008/domains/uvpa/editable/PRPA_RM201310UV.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
• The relationship holder of the personal relationship is restricted to be a person (using CMET COCT_MT030207UV)
• The following roles are omitted:

• asPatientOfOtherProvider
• guarantor
• guardian
• contactParty
• asMember
• careGiver
• asStudent

The following participations are omitted:

• subjectOf2 (administrativeObservation)
• coveredPartyOf (coverage)

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.55.4.2.2.2-1: Attributes

PRPA_HD201310IHE Patient Registry Find Candidates Response	This HMD extract defines the message used to return records from a patient registry in response to a Find Candidates Query. Derived from Figure 3.55.4.2.2.2-1 (PRPA_RM201310IHE)
Patient	The primary record for the focal person
classCode [1..1] (M) Patient (CS) {CNE:PAT}	Structural attribute; this is a "patient" role
id [1..1] (M) Patient ( SET < II >)	The Patient Identifier to be used in subsequent XCA Cross Gateway Query transactions related to this patient when sent to the Responding Gateway sending the response. All other patient identifiers shall be specified in the OtherIDs.id attribute.
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. May be null i.e., <name nullFlavor=”NA”/> only if the request contained only a patient identifier and no demographic data.
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
birthPlace
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.
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., identifiers from a different Patient Identity Domain).
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
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
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.
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.
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
QueryMatchObservation	Used to convey information about the quality of the match for each record.
classCode [1..1] (M) Observation  ( CS ) {CNE: ActClass , default= "OBS"}	Structural attribute – this is an observation
moodCode [1..1] (M) Observation  ( CS ) {CNE: ActMood , default= "EVN"}	Structural attribute – this is an event
code [1..1] (M) Observation  ( CD ) {CWE:QueryMatchObservationType}	A code, identifying this observation as a query match observation.
value [1..1] (M) QueryMatch Observation  (INT)	A numeric value indicating the quality of match for this record. It shall correspond to the MinimumDegreeMatch.value attribute of the original query, and it shall have the same meaning (e.g., percentage, indicating confidence in the match).

3.55.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.55.4.2.2.3-1 contains the Transmission and Control Act wrappers used for this interaction, and the associated constraints.

Table 3.55.4.2.2.3-1: Wrappers and Constraints

Transmission Wrapper	Trigger Event Control Act Wrapper
MCCI_MT000300UV01 – Send Application Acknowledgement	MFMI_MT700711UV01 – Master File/Registry Query Response Control Act (Role Subject)
The value of interactionId shall be set to PRPA_IN201306UV02 The value of processingModeCode shall be set to T The acceptAckCode shall be set to NE There shall be only one receiver Device	The value of ControlActProcess.moodCode shall be set to EVN The trigger event code in ControlActProcess.code shall be set to PRPA_TE201306UV02 There shall be zero or more RegistrationEvents present in this message. For each matching record returned, there shall be exactly one RegistrationEvent present in this message. If a RegistrationEvent is part of the message, there shall be exactly one Patient role present in the payload. There shall be no replacementOf act-relationship present in this message The QueryAck.resultTotalQuantity, QueryAck.resultCurrentQuantity, and QueryAck.resultRemainingQuantity attributes shall not be populated. There shall be a QueryByParameter copy of the original query which shall be in the control act wrapper following the queryAck element.

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_IN201306UV02.xsd.

3.55.4.2.2.4 Specifying homeCommunityId in Response

The homeCommunityId is a globally unique identifier for a community – further defined in Section 3.38.4.1.2.1. The Responding Gateway shall specify this value within every RegistrationEvent element in the Cross Gateway Patient Discovery response.

The Responding Gateway may specify the same homeCommunityId in every RegistrationEvent, or may specify different homeCommunityId’s. The Initiating Gateway shall interpret multiple RegistrationEvents as follows:

• Multiple RegistrationEvents with the same homeCommunityId represent multiple matches within the homeCommunityId identified community. The Initiating Gateway may choose one of the matches to use for subsequent processing.
• Each set of RegistrationEvents with the same homeComunityId represents a different possible source for documents, so in order to get the complete list of relevant documents for the patient, the Initiating Gateway shall select at least one RegistrationEvent from each set with the same homeCommunityId and use the resulting collection of patient identifiers for subsequent processing. See ITI TF-1: 27.3.2.2 for an introduction to this environment.

The homeCommunityId is specified as the id element within the assignedEntity of the custodian of the RegistrationEvent. The id element designating the homeCommunityId shall have only the root element, the contents of which is the homeCommunityId.

If the Initiating Gateway specified a target community as specified in Section 3.55.4.1.2.5, then the Responding Gateway SHOULD include only RegistrationEvents with homeCommunityIds that match the specified target community. However, the Initiating Gateway SHALL NOT rely on this behavior, and SHALL ensure that it is inspecting the homeCommunityId of each RegistrationEvent returned for relevance to its query.

The following example shows part of a response specifying a homeCommunityId value of urn:oid:1.2.840.114350.1.13.99998.8734.

3.55.4.2.2.5 Specifying support as a Health Data Locator

The Responding Gateway shall specify its support for this patient as a Health Data Locator. This specification is a coded value within the assignedEntity of the custodian of the RegistrationEvent. The valid codes for this designation are described in Table 3.55.4.2.2.5-1. The codeSystem for these code elements is 1.3.6.1.4.1.19376.1.2.27.2.

Table 3.55.4.2.2.5-1: Coded values for codeSystem=1.3.6.1.4.1.19376.1.2.27.2

Value for code	Meaning of code
NotHealthDataLocator	This community does not maintain externally available location information about this patient and will respond with no data to a Patient Location Query transaction related to this patient.

The following example shows part of a response specifying no support for Health Data Locator:

3.55.4.2.2.6 Special handling for more attributes requested

The Responding Gateway has the option of informing the Initiating Gateway when additional demographic attributes may result in a match. This would most often be used in cases where the security and privacy policies do not allow release of patient data unless and until there is a level of assurance that the same patient is referenced. In this case the Responding Gateway cannot return a matching patient or patients because the level of assurance is not great enough. If the Initiating Gateway were able to specify further demographic attributes the Responding Gateway might have greater assurance of the match and thus be able to return the match information.

To indicate this situation in its response, the Responding Gateway codes a DetectedIssueEvent within the controlActProcess element, where the code in the actOrderRequired element references one of the coded elements described in Table 3.55.4.2.2.6-1. There may be as many triggerFor elements, each of them containing an ActOrderRequired element, as needed to code the attributes which would increase the assurance of the match. The codeSystem for these code elements is 1.3.6.1.4.1.19376.1.2.27.1.

Table 3.55.4.2.2.6-1: Coded values for codeSystem=1.3.6.1.4.1.19376.1.2.27.1

Value for code	Meaning of code
LivingSubjectAdministrativeGenderRequested	Requests the LivingSubjectAdministrativeGender attribute be specified
PatientAddressRequested	Requests the PatientAddress attribute be specified
PatientTelecomRequested	Requests the PatientTelecom attribute be specified
LivingSubjectBirthPlaceNameRequested	Requests the LivingSubjectBirthPlaceName attribute be specified
LivingSubjectBirthPlaceAddressRequested	Requests the LivingSubjectBirthPlaceAddress attribute be specified
MothersMaidenNameRequested	Requests the MothersMaidenName attribute be specified

The following example shows part of a response requesting the PatientAddress and PatientTelecom attributes.

<code … /> <reasonOf typeCode="RSON"> <detectedIssueEvent classCode="ALRT" moodCode="EVN"> <code code="_ActAdministrativeDetectedIssueManagementCode" codeSystem="2.16.840.1.113883.5.4"/> <triggerFor typeCode="TRIG"> <actOrderRequired classCode="ACT" moodCode="RQO"> <code code="PatientAddressRequested" codeSystem="1.3.6.1.4.1.19376.1.2.27.1"/> </actOrderRequired> </triggerFor> <triggerFor typeCode="TRIG"> <actOrderRequired classCode="ACT" moodCode="RQO"> <code code="PatientTelecomRequested" codeSystem="1.3.6.1.4.1.19376.1.2.27.1"/> </actOrderRequired> </triggerFor> </detectedIssueEvent> </reasonOf> <queryAck>

3.55.4.2.2.7 Specify details about problems handling request

The Responding Gateway has the option of informing the Initiating Gateway with some detail regarding a problem handling the request.

The Responding Gateway may code a DetectedIssueEvent within the controlActProcess element, where the code in the detectedIssueManagement element references one of the coded elements described in Table 3.55.4.2.2.7-1. The codeSystem for these code elements is 1.3.6.1.4.1.19376.1.2.27.3.

Table 3.55.4.2.2.7-1: Coded values for codeSystem=1.3.6.1.4.1.19376.1.2.27.3

Value for code	Meaning of code
ResponderBusy	The responder was not able to process the request because it is currently overloaded.
AnswerNotAvailable	The answer is not available. Human intervention may be needed.
InternalError	The responder was not able to respond due to an internal error or inconsistency.

The following example shows part of a response specifying that the responder is busy.

<code …" /> <reasonOf typeCode="RSON"> <detectedIssueEvent classCode="ALRT" moodCode="EVN"> <code code="_ActAdministrativeDetectedIssueManagementCode" codeSystem="2.16.840.1.113883.5.4"/> <mitigatedBy typeCode="MITGT"> <detectedIssueManagement classCode="ACT" moodCode="EVN"> <code code="ResponderBusy" codeSystem="1.3.6.1.4.1.19376.1.2.27.3"/> </detectedIssueManagement> </mitigatedBy> </detectedIssueEvent> </reasonOf> <queryAck>

3.55.4.2.3 Expected Actions

The Initiating Gateway shall accept a SOAP fault representing a transmission error. An internal error in the Responding Gateway is covered under Case 5. The Initiating Gateway shall act on a valid query response as described by the following 5 cases:

Case 1: The Responding Gateway finds exactly one patient record matching the criteria sent in the query parameters.

AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper).

OK (data found, no errors) is returned in QueryAck.queryResponseCode (control act wrapper)

One RegistrationEvent (and the associated Patient role, subject of that event) is returned from the patient information source for the patient record found. The community associated with the Initiating Gateway may use the patient demographics and identifiers to run an independent matching algorithm to ensure the quality of the match. If the Initiating Gateway is grouped with an XCA Initiating Gateway, it may use the designated patient identifier in a Cross Gateway Query to get information about records related to the patient. This grouped Initiating Gateway shall be able to handle situations where the homeCommunityId in the response is different than the original homeCommunityId used to identify the XCPD Responding Gateway. In particular, the Initiating Gateway should use the new homeCommunityId to look up a potentially different endpoint. The Initiating Gateway may also choose to cache the correlation for future use (see Section 3.55.4.2.3.1 for more information about caching).

Case 2: The Responding Gateway finds more than one patient close to matching the criteria sent in the query parameters and the policy allows returning multiple.

AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper).

OK (data found, no errors) is returned in QueryAck.queryResponseCode (control act wrapper)

One RegistrationEvent (and the associated Patient role, subject of that event) is returned for each patient record found. The community associated with the Initiating Gateway may run its own matching algorithm to select from the list of returned patients. If a correlation is found, the Responding Gateway may continue as if only one entry had been returned, see Case 1. If a correlation is still not clear it is expected that human intervention is required, depending on the policies of the Initiating Gateway’s community.

Case 3: The Responding Gateway finds more than one patient close to matching the criteria sent in the query parameters but no matches close enough for the necessary assurance level and more attributes might allow the Responding Gateway to return a match.

AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper).

OK (data found, no errors) is returned in QueryAck.queryResponseCode (control act wrapper)

No RegistrationEvent is returned in the response, but the Responding Gateway provides a suggestion in terms of demographics that may help identify a match. The mechanism for specifying the suggestion is detailed in Section 3.55.4.2.2.6 for description of coding of the response. The Initiating Gateway may use this feedback to initiate a new Cross Gateway Patient Discovery request including the requested additional attributes.

Case 4: The Responding Gateway finds no patients anywhere close to matching the criteria sent in the query parameters.

AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper).

NF (data found, no errors) is returned in QueryAck.queryResponseCode (control act wrapper)

There is no RegistrationEvent returned in the response. The Initiating Gateway can assume this patient has no healthcare information held by the community represented by the Responding Gateway. This lack of correlation may be cached, see Section 3.55.4.2.3.1 for more information about caching.

Case 5: The Responding Gateway is unable to satisfy the request. This may be because the request came synchronously and an asynchronous request may be feasible, or because the Responding Gateway is overloaded with other requests and does not expect to answer for a significant period of time. It may also be that the Responding Gateway may need some manual configuration update to authorize responder or another error occurred while the Responding Gateway was processing the message payload.

AE (application error) is returned in Acknowledgement.typeCode (transmission wrapper).

AE (application error) is returned in QueryAck.queryResponseCode (control act wrapper)

There is no RegistrationEvent returned in the response. See Section 3.55.4.2.2.7 for more information about coding errors for this case.

3.55.4.2.3.1 Caching (Informative)

This section presents some considerations regarding caching of information learned through the Cross Gateway Patient Discovery transaction. There are no requirements regarding caching of the information, as this is a complex issue and must be addressed as part of deployment. The caching resulting from receiving and responding to the query is not updating any local information but only saving a record in a cache if so desired.

Both the requesting and responding side of the Cross Gateway Patient Discovery transaction gain knowledge through this transaction. That knowledge may be used immediately, by sending a Cross Gateway Query transaction, or may be cached for use at some other time (or both). This section addresses caching considerations when the Cross Gateway Patient Discovery transaction is used in the Demographic Query and Feed mode. Other modes are a simplification of this mode with corresponding simplifications of the considerations presented.

The knowledge gained on both sides can be represented as a tuple:

• LocalPid – Local patient identifier and demographics associated with that identifier
• ExternalCommunityId – The homeCommunityId of another community.
• ExternalPid – The patient identifier for the same patient as LocalPid within the community identified by ExternalCommunityId. This identifier also has associated demographics

For the Initiating Gateway the ExternalPid may be null indicating that the community represented by ExternalCommunityId has no correlating patient identifier available.

The tuple represents a correlation, or lack thereof, of patients in a pair of communities. The validity of this correlation may degrade over time, as changes in demographics, merge/link events and new patient registrations affect the correlation.

Local changes in demographics, merge/link

When a local change in demographics or a merge/link event affects the LocalPid, the community may initiate a Cross Gateway Patient Discovery request to validate the correlation.

External changes in demographics, merge/link

When an external change in demographics or merge/link event occurs, the external community may initiate a Cross Gateway Patient Discovery request which, when received, can be used to re-assess the correlation and adjust accordingly. Mutually agreed policies for use of the CorrelationTimeToLive SOAP header may enable greater assurance that changes are reflected when needed.

New patient registrations

When the Initiating Gateway’s community discovers the lack of correlation to its local patient (ExternalPid null) it may monitor incoming Cross Gateway Patient Discovery transactions in order to discover later if that patient has arrived in the Responding Gateway’s community.

3.55.5 Security Considerations

No transaction specific security considerations.

3.55.5.1 Security Audit Considerations

The Cross Gateway Patient Discovery transaction is a Query Information event as defined in ITI TF-2: 3.20.4.1.1.1 -1.

The actors involved shall record audit events according to the following:

3.55.5.1.1 Initiating Gateway audit message:

	Field Name	Opt	Value Constraints
Event AuditMessage/ EventIdentification	EventID	M	EV(110112, DCM, “Query”)
	EventActionCode	M	“E” (Execute)
	EventDateTime	M	not specialized
	EventOutcomeIndicator	M	not specialized
	EventTypeCode	M	EV(“ITI-55”, “IHE Transactions”, “Cross Gateway Patient Discovery”)
Source (Initiating Gateway) (1)
Human Requestor (0..n)
Destination (Responding Gateway) (1)
Audit Source (Initiating Gateway) (1)
Patient (0) No patient identifiers are included in this audit message.
Query Parameters (1)

Where:

Source AuditMessage/ ActiveParticipant	UserID	M	If Asynchronous Web Services Exchange is being used, the content of the <wsa:ReplyTo/> element. Otherwise, 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	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

Query Parameters (AuditMessage/ ParticipantObjectIdentification)	ParticipantObjectTypeCode	M	“2” (system object)
	ParticipantObjectTypeCodeRole	M	“24” (query)
	ParticipantObjectDataLifeCycle	U	not specialized
	ParticipantObjectIDTypeCode	M	EV(“ITI-55, “IHE Transactions”, “Cross Gateway Patient Discovery”)
	ParticipantObjectSensitivity	U	not specialized
	ParticipantObjectID	U	not specialized
	ParticipantObjectName	U	not specialized
	ParticipantObjectQuery	M	the QueryByParameter segment of the query , base64 encoded.
	ParticipantObjectDetail	M	type: “ihe:homeCommunityID” (literal string) value: value of the homeCommunityID Note: The specification of the ‘type’ element is inconsistent with the ITI-18 audit message, and others. This inconsistency remains because fixing it would be a ‘breaking change’ to this Final Text specification.

3.55.5.1.2 Responding Gateway audit message:

	Field Name	Opt	Value Constraints
Event AuditMessage/ EventIdentification	EventID	M	EV(110112, DCM, “Query”)
	EventActionCode	M	“E” (Execute)
	EventDateTime	M	not specialized
	EventOutcomeIndicator	M	not specialized
	EventTypeCode	M	EV(“ITI-55”, “IHE Transactions”, “Cross Gateway Patient Discovery”)
Source (Initiating Gateway) (1)
Destination (Responding Gateway) (1)
Audit Source (Responding Gateway) (1)
Patient (0..n) one for each patient whose demographic information was returned in the response.
Query Parameters (1)

Where:

Source AuditMessage/ ActiveParticipant	UserID	M	If Asynchronous Web Services Exchange is being used, the content of the <wsa:ReplyTo/> element. Otherwise, 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.
	ParticipantObjectName	U	not specialized
	ParticipantObjectQuery	U	not specialized
	ParticipantObjectDetail	U	not specialized

Query Parameters (AuditMessage/ ParticipantObjectIdentification)	ParticipantObjectTypeCode	M	“2” (system object)
	ParticipantObjectTypeCodeRole	M	“24” (query)
	ParticipantObjectDataLifeCycle	U	not specialized
	ParticipantObjectIDTypeCode	M	EV(“ITI-55”, “IHE Transactions”, “Cross Gateway Patient Discovery”)
	ParticipantObjectSensitivity	U	not specialized
	ParticipantObjectID	U	not specialized
	ParticipantObjectName	U	not specialized
	ParticipantObjectQuery	M	the QueryByParameter segment of the query, base64 encoded.
	ParticipantObjectDetail	M	type: “ihe:homeCommunityID” (literal string) value: value of the homeCommunityID Note: The specification of the ‘type’ element is inconsistent with the ITI-18 audit message, and others. This inconsistency remains because fixing it would be a ‘breaking change’ to this Final Text specification.

3.55.6 Protocol Requirements

The Cross Gateway Patient Discovery request and response will be transmitted using Synchronous or Asynchronous Web Services Exchange, according to the requirements specified in ITI TF-2: Appendix V. If the Deferred Response Option is being used the request and response will be transmitted as described in Section 3.55.6.2.

The following WSDL naming conventions shall apply:

  query message    -> "PRPA_IN201305UV02_Message"

The following WSDL snippet describes the type for this message:

3.55.6.1 Web Services Port Type and Binding Definitions

Responding Gateway:

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

The following WSDL naming conventions shall apply:

  wsdl:definitions/@name="RespondingGateway":

  ITI-55 query                 -> "PRPA_IN201305UV02_Message"

  ITI-55 response              -> "PRPA_IN201306UV02_Message"

  accept acknowledgement       -> "MCCI_IN000002UV01_Message"

  portType                     -> "RespondingGateway_PortType"

  ITI-55 operation             -> "RespondingGateway_PRPA_IN201305UV02"

  ITI-55 Deferred Response operation ->

“RespondingGateway_Deferred_PRPA_IN201305UV02”

  SOAP 1.2 binding             -> "RespondingGateway_Binding_Soap12"

  SOAP 1.2 port                -> "RespondingGateway_Port_Soap12"

Initiating Gateway:

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

The following WSDL naming conventions shall apply:

  wsdl:definitions/@name="InitiatingGateway":

  ITI-55 response              -> "PRPA_IN201306UV02_Message"

  accept acknowledgement       -> "MCCI_IN000002UV01_Message"

  portType                     -> "InitiatingGateway_PortType"

ITI-55 Deferred Response operation ->

“InitiatingGateway_Deferred_PRPA_IN201306UV02”

  SOAP 1.2 binding             -> "InitiatingGateway_Binding_Soap12"

  SOAP 1.2 port                -> "InitiatingGateway_Port_Soap12"

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

3.55.6.1.1 Port Type

Responding Gateway:

Initiating Gateway:

3.55.6.1.2 Bindings

SOAP 1.2 binding:

Responding Gateway:

Initiating Gateway:

Informative WSDL for the Responding Gateway is available online: see ITI TF-2: Appendix W.

3.55.6.2 Deferred Response Option

The Deferred Response Message pattern is a message exchange pattern where the request/response web service message exchange has been converted into two request/response message exchange patterns, where the original request and response messages are used as the request portion of each message and an application acknowledgement is the response. Figure 3.55.6.2-1 illustrates this pattern as it is used for the Cross Gateway Patient Discovery [ITI-55] transaction.

Cross Gateway Patient Discovery Request Message

The Initiating Gateway that supports the Deferred Response Option may request the use of Deferred Response message exchange by specifying the following in the Cross Gateway Patient Discovery Request Message:

• The WS-Addressing Action value shall be urn:hl7-org:v3:PRPA_IN201305UV02:Deferred: CrossGatewayPatientDiscovery
• The responsePriorityCode element shall be set to a value of ‘D’ to represent the deferred processing mode.
• The respondTo element of the transmission wrapper, see the figure in Section 3.55.4.1.2.4, shall contain a telecom element with the Web Services Endpoint where the response shall be sent.

Example of specifying the respondTo element:

Cross Gateway Patient Discovery Request Application Acknowledgement Message

If the Responding Gateway supports the Deferred Response Option it shall respond with an HL7 V3 Accept Acknowledgement message (MCCI_IN000002UV01). The WS-Addressing Action value shall be urn:hl7-org:v3:MCCI_IN000002UV01.

Cross Gateway Patient Discovery Response Message

The Responding Gateway will process the Cross Gateway Patient Discovery Request Message and generate a Cross Gateway Patient Discovery Response Message following all the applicable requirements for the transaction. If the Responding Gateway supports the Deferred Response Option, the Cross Gateway Patient Discovery Response Message will be sent as a new request as follows:

• The Responding Gateway shall direct the response message to the address specified in the respondTo element in the transmission wrapper.
• The WS-Addressing RelatesTo element of the response message shall be populated with the message identifier from the WS-Addressing MessageID element of the request message
• The WS-Addressing Action value shall be urn:hl7-org:v3:PRPA_IN201306UV02:Deferred:CrossGatewayPatientDiscovery
• Correlation with the request message is also supplied through the queryID element from the request message which shall be the same as the queryID element of the Response message.

Cross Gateway Patient Discovery Response Application Acknowledgement Message

The Initiating Gateway that supports the Deferred Response Option shall respond with an HL7 V3 application acknowledgement message (MCCI_IN000002UV01). The WS-Addressing Action value shall be urn:hl7-org:v3:MCCI_IN000002UV01.