3.52 Document Metadata Subscribe [ITI-52]

This section corresponds to transaction [ITI-52] of the IHE IT Infrastructure Technical Framework. Transaction [ITI-52] is used by the Document Metadata Subscriber and the Document Metadata Notification Broker Actors.

3.52.1 Scope

This transaction involves a request by the Document Metadata Subscriber to the Document Metadata Notification Broker to start a subscription using a particular set of filters, or to cancel an existing subscription.

3.52.2 Use Case Roles

Actor: Document Metadata Subscriber

Role: Sends, on the behalf of Document Metadata Notification Recipients, subscription requests, or subscription cancellation messages to the Document Metadata Notification Broker

Actor: Document Metadata Notification Broker

Role: Manages subscriptions of Document Metadata Notification Recipients

3.52.3 Referenced Standards

• OASIS Web Services Notification Family of Standards
• WS-BaseNotification 1.3 OASIS Standard
• WS-BrokeredNotification 1.3 OASIS Standard
• WS-Topics 1.3 OASIS Standard
• ITI TF-2: 3.18 - Registry Stored Query Transaction
• ITI TF-2: Appendix V

3.52.4 Messages

3.52.4.1 Subscribe Request Message

3.52.4.1.1 Trigger

A Document Metadata Notification Recipient's need to initiate a subscription will cause the Document Metadata Subscriber to trigger a Subscribe Request message.

3.52.4.1.2 Message Semantics

The Subscribe Request message shall comply with the requirements in the WS-BaseNotification standard. Note that the value of the WS-Addressing Action element is prescribed in the standard, and differs from the requirements of Appendix V. The wsnt:ConsumerReference element describes the Web Service endpoint where notifications must be sent. The wsnt:Filter element shall contain the topics and values for these topics for which a notification shall be sent. Implementers of the pattern shall specify the topic content to be put within the wsnt:Filter element. The wsnt:Filter element shall contain a TopicExpression element.

This transaction uses simple topics in accordance with the WS-Topics standard and as specified in Section 3.52.5.

This transaction uses a filter based on the Registry Stored Query [ITI-18] transaction syntax and semantics as specified in Section 3.52.5 Subscription Topics and Filter Expressions.

3.52.4.1.3 Expected Actions

The Notification Broker shall be capable of maintaining multiple concurrent Subscriptions.

The Notification Broker shall keep track of each unique subscription and will provide a unique subscription reference which shall be used by the Subscriber to send subsequent cancellations

The Subscriber may indicate the duration of the subscription using the wsnt:InitialTerminationTime element, where a time stamp (expressed as an XML Schema dateTime data type value) or a duration (expressed as an XML Schema duration data type value) can be used.

If the Document Metadata Notification Broker is not able to understand a filter expression it SHALL create faults in accordance with the following rules:

• InvalidFilterFault: the Subscribe message contained a filter that was not understood or supported by the Document Metadata Notification Broker. For example the ReferenceIdList filter parameter exists and the Document Metadata Notification Broker cannot satisfy it.
• TopicExpressionDialectUnknownFault: the Subscribe message contained a TopicExpression filter having a dialect that was not understood or supported by the Document Metadata Notification Broker.
• InvalidTopicExpressionFault: the Subscribe message contained a TopicExpression filter where the contents of the filter did not match the dialect specified.
• TopicNotSupportedFault: the Subscribe message contained a TopicExpression filter that referenced a topic that was not supported by the Document Metadata Notification Broker. This Fault SHALL be generated by a Document Metadata Notification Broker that does not support the Folder Subscription Option if it receives a request for a subscription using the topic ihe:FolderMetadata.
• SubscribeCreationFailedFault: The Document Metadata Notification Broker failed to process the Subscribe message. The Document Metadata Notification Broker SHOULD use a more specific fault message if possible. The Document Metadata Notification Broker MAY include a hint in the fault message indicating why it failed to process the Subscribe message.

3.52.4.1.4 Example Subscribe Request Message (subscription on a document filter)

 

3.52.4.2 Subscribe Response Message

3.52.4.2.1 Trigger

This message is an immediate response to a Subscribe Request, and it is sent from the Document Metadata Notification Broker to the Document Metadata Subscriber.

3.52.4.2.2 Message Semantics

The Subscribe Response message shall comply with the requirements in the WS-BaseNotification standard, including the use of the appropriate SOAP Fault messages. Note that the value of the WS-Addressing Action element is prescribed in the standard, and differs from the requirements of ITI TF-2: Appendix V.

The subscription identifier is assigned by the Notification Broker as a subscription reference, communicated in the response in the SOAP body in wsnt:SubscribeResponse/wsnt:SubscriptionReference (a WS-Addressing endpoint). The subscription reference shall consist of:

• an Address element, containing a webservices endpoint

In order to unsubscribe, the request shall be sent to the endpoint specified in the Address component of the SubscriptionReference.

3.52.4.2.3 Expected Actions

If the Document Metadata Subscriber had indicated a requested duration for the subscription, the Document Metadata Notification Broker shall send the assigned duration for the subscription using the wsnt:TerminationTime element.

If the Document Metadata Subscriber had not indicated a requested duration for the subscription, the Document Metadata Notification Broker may send an assigned duration for the subscription (if any), using the wsnt:TerminationTime element.

If the Document Metadata Notification Broker sends an assigned duration for the subscription, the Subscriber shall associate the assigned duration with the accepted subscription request.

The Document Metadata Subscriber shall associate the accepted subscription request with the subscription reference address assigned by the Document Metadata Notification Broker in order to be able to send cancellations for existing subscriptions.

3.52.4.2.4 Example

3.52.4.3 Unsubscribe Request Message

3.52.4.3.1 Trigger

When a subscription is no longer needed, a Document Metadata Subscriber will trigger an Unsubscribe Request message.

3.52.4.3.2 Message Semantics

The Unsubscribe Request message shall comply with the requirements in the WS-BaseNotification standard. The message conveys the request to cancel an existing subscription. Note that the value of the WS-Addressing Action element is prescribed in the standard, and differs from the requirements of ITI TF-2: Appendix V.

3.52.4.3.3 Expected Actions

The Document Metadata Subscriber shall send this message to the endpoint associated with the existing subscription.

The Document Metadata Notification Broker shall cancel the corresponding subscription, and respond with an Unsubscribe Response message. In the case when, for whatever reason, the subscription cannot be canceled, the Document Metadata Notification Broker shall respond with a ResourceUnknownFault or an UnableToDestroySubscriptionFault SOAP Fault message as appropriate.

3.52.4.3.4 Example

3.52.4.4 Unsubscribe Response Message

3.52.4.4.1 Trigger

This message is an immediate response to an Unsubscribe Request message, and it is sent from the Document Metadata Notification Broker to the Document Metadata Subscriber.

3.52.4.4.2 Message Semantics

The Unsubscribe Response message shall comply with the requirements in the WS-BaseNotification standard. This message indicates that an Unsubscribe message was successfully processed. Note that the value of the WS-Addressing Action element is prescribed in the standard, and differs from the requirements of ITI TF-2: Appendix V.

3.52.4.4.3 Expected Actions

The Document Metadata Notification Broker shall cancel the corresponding subscription.

The Document Metadata Subscriber shall mark the corresponding subscription as successfully terminated.

3.52.4.4.4 Example

3.52.5 Subscription Topics and Filter Expressions

This transaction restricts the subscription topic to be one of FullDocumentEntry or MinimalDocumentEntry (Section 3.52.5.1) and restricts the semantics of filter expressions to the semantics of a subset (Section 3.52.5.2) of the Registry Stored Query [ITI-18] transaction.

3.52.5.1 Topics

This transaction defines simple topics as described in the WS-Topics specification. If the Document Metadata Notification Broker supports the Folder Subscription Option it shall support all the following topics in a Document Metadata Subscribe Request; otherwise it shall reject subscription Request which specify folder's topic generating a fault (see Section 3.52.4.1.3 “Expected Actions”). The Document Metadata Subscriber may support a subset of these topics:

3.52.5.1.1 ihe:FullDocumentEntry

This topic indicates that the events for which the subscription is made shall be Document Entry registrations, and that the notification shall contain the full metadata describing each matching Document Entry as described in the Notification transaction in Section 3.53.4.1.2.

3.52.5.1.2 ihe:MinimalDocumentEntry

This topic indicates that the events for which the subscription is made shall be Document Entry registrations, and that the notification shall contain the minimal set of data describing each matching Document Entry as described in the Document Metadata Notify transaction in Section 3.53.4.1.2.

3.52.5.1.3 ihe:SubmissionSetMetadata

This topic indicates that the event for which the subscription is made shall be creating a SubmissionSet and that the notification shall contain the full metadata describing the match with the SubmissionSet object, as described in the Document Metadata Notify transaction in Section 3.53.4.1.2.

3.52.5.2 Building Filter Expressions

The XDS metadata, specified in ITI TF-3: 4.1, describes the objects which are used in a document registration. The Registry Stored Query [ITI-18] transaction uses a subset of the metadata to build a list of queries available to a XDS Document Consumer to search for documents with specific characteristics. The list of queries is in ITI TF-2: 3.18.4.1.2.3.7. The transaction Document Metadata Subscribe uses the syntax of the Registry Stored Query [ITI-18] transaction for the creation of the filtering expression.

Filters can be created using the parameters of the FindDocuments, FindDocumentsByReferenceId, FindSubmissionSet queries defined within the Registry Stored Query transaction and use the syntax of the FindDocuments FindDocumentsByReferenceId or FindSubmissionSets queries to express the filter.

The evaluation of filter expressions is based on the XDS metadata model. In this transaction, the stream of events for which subscriptions are possible is limited to events representing the existence of SubmissionSet and documentEntry Objects. The Document Metadata Notification Broker becomes aware of such events either via a Document Metadata Publish [ITI-54] transaction, or via other mechanisms not specified by IHE. The Document Metadata Notification Broker shall determine if there is a subscription which matches any of the Document Entry Objects or SubmissionSet Object in an event.

A match means that if a Registry Stored Query, with the same parameters as the filter expression in the subscription, were sent to a XDS Document Registry containing the Document Entry Objects or SubmissionSet Object from the event, the result of this Stored Query would contain one or more of these Objects.

In an XDS Affinity Domain context, the applicable events are likely to be Register Document Set [ITI-42] transaction containing one or more Document Entry objects. In this case, the Document Metadata Notification Broker may have to map between the model within which the events took place, and the Document Sharing metadata model.

A good understanding of the Registry Stored Query transaction and the XDS metadata is necessary to understand how the filter expressions work. For example, if the filter expression below were implemented as a stored query on the registry

it will return all document entries for patient with ID st3498702 (assigned by an authority identified by the OID 1.3.6.1.4.1.21367.2005.3.7) where the event code metadata contains at least one of the codes listed (in this case CPT codes for various appendectomies). When used as a filter expression, the same structure will yield a match against a document entry in an XDS registry submission, where the document entry is for patient with ID st3498702 and the event code is "44970". The following snippet shows an example of such a submission:

When a Document Metadata Notification Subscriber constructs a filter expression, it shall include the whole stored query expression (as shown above) directly in the Subscribe Request message as a child of the wsnt:Filter element:

How the Document Metadata Notification Broker evaluates the filter expression, and how it performs the matching against the existing subscriptions, is out of scope of this transaction. It is expected that such implementation details will allow vendors to differentiate themselves in the marketplace.

It is important to note that not all stored queries, and not all parameters defined for the stored queries, are suitable for filter expressions. The Document Metadata Notification Broker shall support the following filters and associated parameters when used in subscription requests, and the Document Metadata Subscriber may support a subset of these:

3.52.5.2.1 Subscriptions for DocumentEntry metadata

A Document Metadata Notification Broker that accepts a Subscribe Request containing filter expressions created using DocumentEntry metadata shall yield a match as described in Section 3.52.5.2. Parameters that can be used for creating the filter expression are described below:

• $XDSDocumentEntryPatientId : this required parameter contains the patient ID for which a document entry is being registered in the XDS Document Registry

• $XDSDocumentEntryClassCode : this parameter matches against the XDSDocumentEntry.classCode metadata elements in a given registry submission
• $XDSDocumentEntryTypeCode : this parameter matches against the XDSDocumentEntry.typeCode metadata elements in a given registry submission
• $XDSDocumentEntryReferenceIdList : this parameter matches against the XDSDocumentEntry.referenceIdList metadata elements in a given registry submission

Note: The ReferenceIdList attribute is optional. If the parameter is specified, the filter matches only documents where the ID contains the value conveyed in the parameter. If the document does not contain a value in the ReferenceIdList, there is no match.

• $XDSDocumentEntryPracticeSettingCode : this parameter matches against the XDSDocumentEntry.practiceSettingCode metadata elements in a given registry submission
• $XDSDocumentEntryHealthcareFacilityTypeCode : this parameter matches against the XDSDocumentEntry.healthcareFacilityTypeCode metadata elements in a given registry submission
• $XDSDocumentEntryEventCodeList : this parameter matches against the XDSDocumentEntry.eventCodeList metadata elements in a given registry submission
• $XDSDocumentEntryConfidentialityCode : this parameter matches against the XDSDocumentEntry.confidentialityCode metadata elements in a given registry submission
• $XDSDocumentEntryFormatCode : this parameter matches against the XDSDocumentEntry.formatCode metadata elements in a given registry submission
• $XDSDocumentEntryAuthorPerson : this parameter matches against the XDSDocumentEntry.author metadata elements in a given registry submission. All properties of this parameter specified in ITI TF-2: 3.18.4.1.2.3.7.1 are applicable in this transaction.

With the exception of $XDSDocumentEntryPatientId , all parameters may be multi-valued.

The AdHocQuery/@id attribute SHALL store an identifier specific for the type of filter used in creating the subscription. The UUID that identifies subscriptions for DocumentEntry’s metadata is:

“urn:uuid:aa2332d0-f8fe-11e0-be50-0800200c9a66”.

An example of subscription on a document filter is presented below:

 

3.52.5.2.2 Subscriptions for SubmissionSets metadata

Document Metadata Notification Broker that accepts a Subscribe Request containing a filter expression based on the FindSubmissionSets stored query shall yield a match as described in Section 3.52.5.2. The subscription filter expression represents a subset of the FindSubmissionSets query parameters, with a specific extension. A Document Metadata Subscriber MAY be able to create a filter expression that includes XDSSubmissionSet.patientId, XDSSubmissionSet.sourceId, XDSSubmissionSet.authorPerson and XDSSubmissionSet.intendedRecipient. Parameters that can be used for this type of filter are described below:

• $XDSSubmissionSetPatientId : this is a required parameter that contains the identifier of the patient target of the clinical content published by a submission and represent the value of the XDSSubmissionSet.PatientId metadata.

• $XDSSubmissionSetSourceId : this optional parameter identifies the source of the content published by the submission and represent the value of the XDSSubmissionSet.sourceId metadata. This parameter may be multi-valued.
• $XDSSubmissionSetAuthorPerson : this optional parameter identifies the authorPerson of the content published by the submission and represents the value of the XDSSubmissionSet.authorPerson metadata. This parameter may be multi-valued.

• $XDSSubmissionSetIntendedRecipient : this is an optional parameter for the subscription. A Document Metadata Subscriber shall be able to subscribe this parameter in addition to other parameters which have direct correspondence with query parameters. This parameter represents the value of the XDSSubmissionSet.intendedRecipient metadata. This parameter identifies initial targets intended for a submission. This parameter may be multi-valued.

Note: intendedRecipient attribute is optional. If the parameter is specified, the filter matches only submissionSets where the intendedRecipient contains the value conveyed in the parameter. If the document does not contain a value in the intendedRecipient, there is no match.

The AdHocQuery/@id attribute SHALL contain an identifier specific for the type of filter used in creating the subscription. The UUID that identifies subscriptions for SubmissionSet’s metadata is:

“urn:uuid:fbede94e-dbdc-4f6b-bc1f-d730e677cece”

An example of subscription on a SubmissionSet filter is presented below:

3.52.5.3 Combining topics and filter expressions

A topic defines static rules for creating notifications. This transaction defines four topics in Section 3.52.5.1. Each subscription request shall contain exactly one topic expression.

A filter expression is equivalent to a specific stored query with certain parameters. Filter conditions expressed as query parameters and used in the expressions must satisfy the same requirements as a corresponding Registry Stored Query:

• the values for all specified query parameters must match (AND all different parameters)
• at least one of the values of multi-valued parameters must match (OR the values in a multi-valued query parameter)

Topics, defined in Section 3.52.5.1 and filter expressions, defined in Section 3.52.5.2, can only be used in specific combinations. These combinations are described in Table 3.52.5.3-1:

Table 3.52.5.3-1: Topics and Filter Expression Combinations

Filter Expression	Topic Expression
subscription for DocumentEntry	ihe:FullDocumentEntry
	ihe:MinimalDocumentEntry
subscription for SubmissionSets	ihe:SubmissionSetMetadata

3.52.6 Security Considerations

The risk assessment for the Document Metadata Subscribe transaction is described in Table 1:26.5-1:DSUB risk assessment (see Section 1:26.5 DSUB Security Considerations). The derived mitigations are as follows:

• Document Metadata Subscriber and Document Metadata Notification Broker shall be grouped with a Secure Node or Secure Application in the Audit Trail and Node Authentication (ATNA) Profile.
• The use of encrypted TLS is recommended when the transmission is not otherwise secured (e.g., transmission over a secure network)

As it is possible through the document metadata subscribe transaction to maliciously overload the Document Metadata Notification Recipient Actors, it is recommended that a strong authentication be used in combination with access rights enforcement and that authentication data should be conveyed through the Cross-Enterprise User Assertion (XUA) Profile. This recommendation also addresses the possibility of malicious cancellations of subscriptions.

Additionally, it is recommended that organizational measures be taken to avoid:

• overload of a Document Metadata Notification Recipient through subscription which cannot be cancelled because the subscription id has been lost e.g., through an administrative service allowing cancellation of subscription under well-defined circumstances
• cancellation of a subscription unnoticed by the intended document metadata notification recipient e.g., through an informative message (out of the scope of this transaction) sent to the intended recipient

This profile provides the ihe:MinimalDocumentEntry topic expression to avoid disclosing sensitive information. Using this type of topic expression allows delegation of the access control decisions to the Document Sharing infrastructure.

3.52.6.1 Audit Record Considerations

The Document Metadata Subscribe transaction is a Query Information event as defined in Table ITI TF-2: 3.20.4.1.1.1 -1. The actors involved shall record audit events according to the following:

3.52.6.1.1 Document Metadata Subscriber audit message:

	Field Name	Opt	Value Constraints
Event AuditMessage/ EventIdentification	EventID	M	EV(110112, DCM, “Query”)
	EventActionCode	M	“C” (Create) for Subscribe message exchange “D” (Delete) for Unsubscribe message exchange
	EventDateTime	M	not specialized
	EventOutcomeIndicator	M	not specialized
	EventTypeCode	M	EV(“ITI-52”, “IHE Transactions”, “Document Metadata Subscribe”)
Source (Document Metadata Subscriber) (1)
Human Requestor (0..n)
Destination (Document Metadata Notification Broker) (1)
Audit Source (Document Metadata Subscriber) (1)
Subscription (0..1)
Patient (0..1)
Query Parameters (0..1) (required for Subscribe message, not used for Unsubscribe message)

Where:

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

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

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

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

Subscription (if known) (AuditMessage/ ParticipantObjectIdentification)	ParticipantObjectTypeCode	M	“2” (system object)
	ParticipantObjectTypeCodeRole	M	“20” (job)
	ParticipantObjectDataLifeCycle	U	not specialized
	ParticipantObjectIDTypeCode	M	EV(“ITI-52”, “IHE Transactions”, “Document Metadata Subscribe”)
	ParticipantObjectSensitivity	U	not specialized
	ParticipantObjectID	M	For the Subscribe Message, the URI contained in the <wsnt:SubscriptionReference/wsa:Address/> of the response message For the Unsubscribe message, the URI contained in the <soap12:Header/wsa:To/> of the request message
	ParticipantObjectName	U	not specialized
	ParticipantObjectQuery	U	not specialized
	ParticipantObjectDetail	U	not specialized

Patient (if known) (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-52”, “IHE Transactions”, “Document Metadata Subscribe”)
	ParticipantObjectSensitivity	U	not specialized
	ParticipantObjectID	M	The value of <wsnt:Subscribe/wsnt:Filter/rim:AdhocQuery/@id/>
	ParticipantObjectName	U	not specialized
	ParticipantObjectQuery	M	The value of <wsnt:Subscribe/> element, base64 encoded.
	ParticipantObjectDetail	U	not specialized

3.52.6.1.2 Document Metadata Notification Broker audit message:

	Field Name	Opt	Value Constraints
Event AuditMessage/ EventIdentification	EventID	M	EV(110112, DCM, “Query”)
	EventActionCode	M	“C” (Create) for Subscribe message exchange “D” (Delete) for Unsubscribe message exchange
	EventDateTime	M	not specialized
	EventOutcomeIndicator	M	not specialized
	EventTypeCode	M	EV(“ITI-52”, “IHE Transactions”, “Document Metadata Subscribe”)
Source (Document Metadata Subscriber) (1)
Destination (Document Metadata Notification Broker) (1)
Audit Source (Document Metadata Notification Broker) (1)
Subscription (0..1)
Patient (0..1)
Query Parameters (0..1) (required for Subscribe message, not used for Unsubscribe message)

Where:

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

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

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

Subscription (if known) (AuditMessage/ ParticipantObjectIdentification)	ParticipantObjectTypeCode	M	“2” (system object)
	ParticipantObjectTypeCodeRole	M	“20” (job)
	ParticipantObjectDataLifeCycle	U	not specialized
	ParticipantObjectIDTypeCode	M	EV(“ITI-52”, “IHE Transactions”, “Document Metadata Subscribe ”)
	ParticipantObjectSensitivity	U	not specialized
	ParticipantObjectID	M	For the Subscribe Message, the URI contained in the <wsnt:SubscriptionReference/wsa:Address/> of the response message For the Unsubscribe message, the URI contained in the <soap12:Header/wsa:Address/>
	ParticipantObjectName	U	not specialized
	ParticipantObjectQuery	U	not specialized
	ParticipantObjectDetail	U	not specialized

Patient (If known) (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-52”, “IHE Transactions”, “Document Metadata Subscribe”)
	ParticipantObjectSensitivity	U	not specialized
	ParticipantObjectID	M	The value of <wsnt:Subscribe/wsnt:Filter/rim:AdhocQuery/@id/>
	ParticipantObjectQuery	M	The value of <wsnt:Subscribe/> element, base64 encoded.
	ParticipantObjectDetail	U	not specialized