IHE ITI Technical Framework
The Final Text ITI Technical Framework is published here in HTML format and is no longer published as PDF. Trial Implementation supplements are available from the Volume 1 Table of Contents.

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

Figure 3.55.4-1: Interaction Diagram

Figure 3.55.4-1: Interaction Diagram

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:

PatientRegistryQueryByDemographicsMessage

Figure 3.55.4.1.2.2-1: Patient Registry Query by Demographics Message

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.

MCCI_RM000100UV

Figure 3.55.4.1.2.4-1: Send Message Payload

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

    <sender typeCode="SND">

        <device classCode="DEV" determinerCode="INSTANCE">

            <id root="1.2.840.114350.1.13.999.567"/>

            <asAgent classCode="AGNT">

              <representedOrganization classCode="ORG" determinerCode="INSTANCE">

          <!-- homeCommunityId=urn:oid:1.2.3 -->

                <id root="1.2.3"/>

              </representedOrganization>

            </asAgent>

        </device>

    </sender>

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 (see highlighted text) 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. In essence, the highlighted text must match to designate the patient identifier.

    <controlActProcess  classCode="CACT" moodCode="EVN">

        <code code="PRPA_TE201305UV02" codeSystem="2.16.840.1.113883.1.6"/>

        <!-- Identifies the first LivingSubjectID in the parameterList as the patient

             Identifier to be used by responder in a reverse Cross Gateway Query -->

        <authorOrPerformer typeCode="AUT">

          <assignedDevice>

            <id root="1.2.840.114350.1.13.99997.2.3412"/> 

          </assignedDevice>

        </authorOrPerformer>

        <queryByParameter>

            <queryId root="1.2.840.114350.1.13.28.1.18.5.999" extension="18204"/>

            <statusCode code="new"/>

            <parameterList>

                <livingSubjectBirthTime>

                   <value value="19630804"/>

                   <semanticsText>LivingSubject..birthTime</semanticsText>

               </livingSubjectBirthTime>

                <livingSubjectName>

                    <value>

                        <given>Jimmy</given>

                        <family>Jones</family>

                    </value>

                    <semanticsText>LivingSubject.name</semanticsText>

                </livingSubjectName>

                <LivingSubjectId>

                  <value root="1.2.840.114350.1.13.99997.2.3412" extension="1234"/>

                  <semanticsText>LivingSubject.id</semanticsText>

                </LivingSubjectId>

                <LivingSubjectId>

                    <value root="2.16.840.1.113883.4.1" extension="58910"/>

                    <semanticsText>LivingSubject.id</semanticsText>

                </LivingSubjectId>

            </parameterList>

        </queryByParameter>

    </controlActProcess>

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

<MCCI_IN000002UV01 …

  ( . . . )

    <acknowledgement>

        <typeCode code="AE"/>

        <targetMessage>

            <id root="22a0f9e0-4454-11dc-a6be-3603d6866807"/>

        </targetMessage>

        <acknowledgementDetail typeCode="E">

            <code code="NS250" displayName="Unsupported processing mode"/>

            <text>Deferred Response not supported.</text>

        </acknowledgementDetail>

    </acknowledgement>

</MCCI_IN000002UV01>

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

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)
PRPA_RM201310UV-IHE-XCPI

Figure 3.55.4.2.2.2-1: Patient Registry Find Candidates Response Message

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

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

   <subject typeCode="SUBJ">

       <registrationEvent classCode="REG" moodCode="EVN">

           <id nullFlavor="NA"/>

           <statusCode code="active"/>

           <subject1 typeCode="SBJ">

               …  (details of the matching patient)

           </subject1>

           <custodian typeCode="CST">

               <assignedEntity classCode="ASSIGNED">

                   <id root="1.2.840.114350.1.13.99998.8734"/>

                  <code code="SupportsHealthDataLocator"

                        codeSystem="1.3.6.1.4.1.19376.1.2.27.2"/>

               </assignedEntity>

           </custodian>

       </registrationEvent>

   </subject>

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:

   <subject typeCode="SUBJ">

       <registrationEvent classCode="REG" moodCode="EVN">

           <id nullFlavor="NA"/>

           <statusCode code="active"/>

           <subject1 typeCode="SBJ">

               …  (details of the matching patient)

           </subject1>

           <custodian typeCode="CST">

               <assignedEntity classCode="ASSIGNED">

                   <id root="1.2.840.114350.1.13.99998.8734"/>

                  <code code="NotHealthDataLocator"

                        codeSystem="1.3.6.1.4.1.19376.1.2.27.2"/>

               </assignedEntity>

           </custodian>

       </registrationEvent>

   </subject>

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.

Figure 3.55.4.2.2.6-1: RMIM for DetectedIssueEvent

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”)
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”)
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 The value of “ihe:homeCommunityID” as the value of the attribute type and the value of the homeCommunityID as the value of the attribute value.
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”)
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”)
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
  1. M
The value of “ihe:homeCommunityID” as the value of the attribute type and the value of the homeCommunityID as the value of the attribute value.

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:

 

 <types>

<xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3"

xmlns:hl7="urn:hl7-org:v3">

<!-- Include the message schema -->

<xsd:import namespace="urn:hl7-org:v3" schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/PRPA_IN201305UV02.xsd"/>

<xsd:element name="PRPA_IN201305UV02"/>

</xsd:schema>

  </types>

The message is described by the following snippet:

 

  <message name="PRPA_IN201305UV02_Message">

<part element="hl7:PRPA_IN201305UV02" name="Body"/>

  </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:

  <portType name="RespondingGateway_PortType">

    <operation name="RespondingGateway_PRPA_IN201305UV02">

<input message="tns:PRPA_IN201305UV02_Message" wsaw:Action="urn:hl7-org:v3:PRPA_IN201305UV02:CrossGatewayPatientDiscovery"/>

<output message="tns:PRPA_IN201306UV02_Message" wsaw:Action="urn:hl7-org:v3:PRPA_IN201306UV02:CrossGatewayPatientDiscovery"/>

</operation>

<operation name="RespondingGateway_Deferred_PRPA_IN201305UV02">

<input message="tns:PRPA_IN201305UV02_Message" wsaw:Action="urn:hl7-org:v3:PRPA_IN201305UV02:Deferred:CrossGatewayPatientDiscovery"/>

<output message="tns:MCCI_IN000002UV01_Message" wsaw:Action="urn:hl7-org:v3:MCCI_IN000002UV01"/>

</operation>

</portType>

Initiating Gateway:

<portType name="InitiatingGatewayDeferredResponse_PortType">

  <operation name="InitiatingGateway_Deferred_PRPA_IN201306UV02">

   <input message="tns:PRPA_IN201306UV02_Message" wsaw:Action="urn:hl7-org:v3:PRPA_IN201306UV02:Deferred:CrossGatewayPatientDiscovery"/>

   <output message="tns:MCCI_IN000002UV01_Message" wsaw:Action="urn:hl7-org:v3:MCCI_IN000002UV01"/>

  </operation>

</portType>

3.55.6.1.2 Bindings

SOAP 1.2 binding:

Responding Gateway:

  <binding name="RespondingGateway_Binding_Soap12" type="RespondingGateway_PortType">

    <wsoap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

    <operation name="RespondingGateway_PRPA_IN201305UV02">

      <wsoap12:operation soapActionRequired="false"/>

  <input>

        <wsoap12:body use="literal"/>

      </input>

      <output>

        <wsoap12:body use="literal"/>

      </output>

    </operation>

    <operation name="RespondingGateway_Deferred_PRPA_IN201305UV02">

  <wsoap12:operation soapActionRequired="false"/>

  <input>

  <wsoap12:body use="literal"/>

  </input>

  <output>

  <wsoap12:body use="literal"/>

  </output>

   </operation>

  </binding>

Initiating Gateway:

  <binding name="InitiatingGatewayDeferredResponse_Binding" type="tns:InitiatingGatewayDeferredResponse_PortType">

  <soap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

  <operation name="InitiatingGateway_Deferred_PRPA_IN201306UV02">

   <soap12:operation soapActionRequired="false"/>

   <input>

    <soap12:body use="literal"/>

   </input>

   <output>

    <soap12:body use="literal"/>

   </output>

  <operation>

</binding>

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.

Figure 3.55.6.2-1: Deferred Response Message Pattern

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:

<respondTo typeCode="RSP">

   <telecom value="service entry point url"

   <entityRsp classCode="ENT" determinerCode="INSTANCE" xsi:nil="true"/>

</respondTo>

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.