Document Metadata Subscription - IHE

Integrating the Healthcare Enterprise5IHE ITITechnical Framework Supplement10Document Metadata Subscription(DSUB)15Trial Implementation SupplementAugust 10, 2009Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)______________________________________________________________________________4045505560657075CONTENTSIntroduction................................................................................................................................4Profile Abstract .......................................................................................................................... 4Open Issues and Questions ........................................................................................................ 4Closed Issues.............................................................................................................................. 4Glossary ..................................................................................................................................... 51.7 History of Annual Changes.................................................................................................. 52.1 Dependencies among Integration Profiles ........................................................................... 52.2.26 Document Metadata Subscription Integration Profile................................................ 626 Document Metadata Subscription Integration Profile ............................................................... 626.1 Actors/ Transactions .......................................................................................................... 626.1.1 Actors ........................................................................................................................ 726.1.2 Transactions .............................................................................................................. 826.2 Document Metadata Subscription Integration Profile Options.......................................... 826.2.1 Document Metadata Publish Recipient Option.......................................................... 926.3 Grouping ........................................................................................................................... 926.4 Document Metadata Subscription Process Flow............................................................... 926.4.1 Unexpected Notification Use Case ........................................................................... 926.4.2 Long-term Subscription Use Case........................................................................... 1026.4.3 Antepartum Record Availability Use Case ............................................................. 1126.5 Document Metadata Subscription Security Considerations............................................. 123.52 Document Metadata Subscribe ........................................................................................ 163.52.1 Scope ........................................................................................................................ 163.52.2 Use Case Roles......................................................................................................... 163.52.3 Referenced Standards............................................................................................... 163.52.4 Interaction Diagram.................................................................................................. 173.52.5 Subscription Topics and Filter Expressions ............................................................ 203.52.6 Security Considerations............................................................................................ 243.53 Document Metadata Notify.............................................................................................. 273.53.1 Scope ....................................................................................................................... 273.53.2 Use Case Roles........................................................................................................ 283.53.3 Referenced Standards.............................................................................................. 283.53.4 Interaction Diagram................................................................................................. 293.53.5 Security Considerations........................................................................................... 323.54 Document Metadata Publish ............................................................................................ 353.54.1 Scope ....................................................................................................................... 353.54.2 Use Case Roles........................................................................................................ 353.54.3 Referenced Standards.............................................................................................. 353.54.4 Interaction Diagram................................................................................................. 363.54.5 Security Considerations........................................................................................... 374.4 Publish/Subscribe Infrastructure ....................................................................................... 414.4.1 Publish/Subscribe Actors and Patterns...................................................................... 424.4.2 Publish/Subscribe Transactions and Patterns............................................................ 46__________________________________________________________________________Rev. 1.3 - 2009-08-103Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)80Introduction8590This supplement contains two related parts. The first part is the Document Metadata Subscription(DSUB) Integration Profile, which describes the use of subscriptions within an XDS AffinityDomain or across communities. A Document Metadata Subscriber may subscribe on behalf ofthe Document Metadata Notification Recipient to receive notifications about the availability ofdocuments based on specific criteria. A Document Metadata Notification Broker keeps track ofthe subscriptions and sends the appropriate notifications based on the registration of objects in anXDS Document Registry. Subscriptions exist for a certain period of time and can be cancelled.The second part is a new section for Chapter 4 of Volume 2 of the ITI Technical Framework,which describes a general framework for defining web-services based publish/subscribeinteractions. The purpose of this new section is to help other profiles and domains to specifypublish/subscribe interactions when needed. The DSUB profile in this supplement is the first useof the general pattern.Profile Abstract95This profile describes the use of subscription and notification mechanism for use within an XDSAffinity Domain and across communities. The subscription allows for the matching of metadataduring the publication of a new document for a given patient, and results in the delivery of anotification.Open Issues and Questions100NoneClosed Issues1051101. Specify the IHE Publish/subscribe pattern in Volume 2, Chapter 42. This profile uses WS-Notification. Is this choice appropriate? Yes, for both the profile,and the framework3. Should the Publish/Subscribe Framework (Chapter 4 section) describe XPath as auniversal filter language for XML transactions?4. Notification/Subscription domains and NB cascading5. Should we extend the topics to include MPQ? Not at this time6. Should notifications include document content? Exposure of document content poseschallenges. Decision: no document content.7. Should the DSUB profile support XDR? Out of scope at this time.8. The XCA environment is supported by this profile.2009-08-10 4 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)GlossaryVolume 1 – Integration Profiles115120125Add the following terms to the Glossary:Notification Broker – a system or a module in a publish/subscribe framework, the purpose ofwhich is to process subscription/un-subscription requests, to keep track of existing subscriptions,to receive publish information, and based on the set of filters for each subscription to send anotification about the published information to the appropriate notification recipients.Publisher – a system or a module in a publish/subscribe framework, the purpose of which is topublish information to the notification broker about events for which there may be existingsubscriptions.Subscriber – a system or a module in a publish/subscribe framework, the purpose of which is tosend subscribe and unsubscribe requests to the notification broker on the behalf of a notificationrecipient. The subscribe request contains a set of filters to determine the information for whichthe subscription applies.Notification Recipient – a system or a module in a publish/subscribe framework, the purpose ofwhich is to receive and process notifications from the notification broker.1.7 History of Annual Changes130Add the following bullet to the end of the bullet list in Section 1.7• Added the Document Metadata Subscription Profile which describes the use of subscriptionand notification mechanism within an XDS Affinity Domain and across communities.2.1 Dependencies among Integration Profiles135 Add the following to Table 2-1DSUBAudit Trail andNodeAuthenticationEach DSUB Actor shall begrouped with Secure Node orSecure Application ActorDSUB Consistent Time Each DSUB Actor shall begrouped with the Time ClientActor- Required to manage audittrail of exported PHI, nodeauthentication andtransport security.- Required due to ATNAgrouping.Add the following section to Section 2.22009-08-10 5 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)2.2.26 Document Metadata Subscription Integration Profile140This profile describes the use of subscription and notification mechanism for use within an XDSAffinity Domain and across communities. The subscription allows for the matching of metadataduring the publication of a new document for a given patient, and results in the delivery of anotification.145Add Section 2626 Document Metadata Subscription Integration Profile150This profile describes the use of subscription and notification mechanism for use within an XDSAffinity Domain and across communities. The subscription allows for the matching of metadataduring the publication of a new document for a given patient, and results in the delivery of anotification.26.1 Actors/ Transactions155Figure 26.1-1 shows the actors directly involved in the Document Metadata SubscriptionIntegration Profile and the relevant transactions between them. Other actors that may beindirectly involved due to their participation in the XDS integration profile, etc. are notnecessarily shown.Document MetadataPublisherDocument MetadataSubscriber↓ Document MetadataPublish [ITI-54]↓ Document Metadata Subscribe[ITI-52]Document MetadataNotification Broker↓ Document MetadataNotify [ITI-53]Document MetadataNotification RecipientFigure 26.1-1. Document Metadata Subscription Actor Diagram2009-08-10 6 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)160Table 26.1-1 lists the transactions for each actor directly involved in the Document MetadataSubscription Profile. In order to claim support of this Integration Profile, an implementationmust perform the required transactions (labeled “R”). Transactions labeled “O” are optional. Acomplete list of options defined by this Integration Profile and that implementations may chooseto support is listed in Section 26.2.165Table 26.1-1. Document Metadata Subscription Integration Profile - Actors andTransactionsActors Transactions Optionality SectionDocument MetadataDocument Metadata Subscribe R ITI TF-2b:3.52Notification BrokerDocument Metadata Notify R ITI TF-2b:3.53Document Metadata Publish O ITI TF-2b:3.54Document Metadata Subscriber Document Metadata Subscribe R ITI TF-2b:3.52Document Metadata Publisher Document Metadata Publish R ITI TF-2b:3.54Document MetadataNotification RecipientDocument Metadata Notify R ITI TF-2b:3.5326.1.1 Actors26.1.1.1 Document Metadata Notification Broker170175The Document Metadata Notification Broker is the receiver of the Document MetadataSubscribe transaction containing a subscription request, or a subscription cancellation. It keepstrack of all subscriptions in the Metadata Notification domain, including the time limits ofsubscriptions. Based on the metadata associated with document registrations, this actor sendsnotifications to interested subscribers. This actor may optionally receive Document MetadataPublish Transactions representing the stream of events against which the existing subscriptionsare matched. Within an XDS Affinity Domain the Document Metadata Notification Broker willmost likely be grouped with a Document Registry actor. In a cross-community environment, thisactor will most likely be grouped with Initiating and Responding Gateway Actors.26.1.1.2 Document Metadata Subscriber180The Document Metadata Subscriber actor initiates and terminates subscriptions on behalf of aDocument Metadata Notification Recipient. Within an XDS Affinity Domain the subscriber willmost likely be grouped with a Document Consumer actor. In a cross-community environment,the subscriber will most likely be grouped with an Initiating Gateway Actor.26.1.1.3 Document Metadata Publisher185The Document Metadata Publisher actor shall send a Document Metadata Publish transaction tothe Document Metadata Notification Broker for any event for which a subscription may exist.This profile does not specify how the Document Metadata Publisher becomes aware of events2009-08-10 7 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)about new documents becoming available. Within an XDS Affinity Domain the DocumentMetadata Publisher actor will most likely be grouped with a Document Registry actor.26.1.1.4 Document Metadata Notification Recipient190195This actor receives the notification about an event, when the subscription filters specified for thisDocument Metadata Notification Recipient are satisfied. Within an XDS Affinity Domain thisactor will very likely be grouped with a Document Consumer. In a cross-communityenvironment the Document Metadata Notification Recipient will most likely be grouped with aResponding Gateway actor.26.1.2 Transactions26.1.2.1 Document Metadata Subscribe200This transaction is sent by the Document Metadata Subscriber to the Document MetadataNotification Broker in order to start a subscription for a particular set of topics, indicatingpossible start and end time for the subscription. Subscriptions cannot be modified. Anysubscriber actor can cancel a subscription, as long as they have the subscription id. Thesubscription request shall specify whether a full notification or a minimal notification will besent when there is a match to the subscription's filter.26.1.2.2 Document Metadata Notify205This is a transaction from the Document Metadata Notification Broker to the DocumentMetadata Notification Recipients, sending a notification about the availability of a document ordocuments of interest, based on the subscribers' filters on selected topics.26.1.2.3 Document Metadata PublishThis transaction is sent from the Document Metadata Publisher to the Document MetadataNotification Broker when an event occurs for which there may be a subscription.21026.2 Document Metadata Subscription Integration Profile OptionsOptions that may be selected for this Integration Profile are listed in the table 26.2-1 along withthe Actors to which they apply. Dependencies between options when applicable are specified innotes.Table 26.2-1 Document Metadata Subscription - Actors and OptionsActor Options Vol &SectionDocument Metadata NotificationBrokerDocument MetadataPublish RecipientDocument Metadata Subscriber No options defined - -Document Metadata Publisher No options defined - -ITI TF-1:26.2.1Document Metadata NotificationRecipientNo options defined - -2009-08-10 8 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)21526.2.1 Document Metadata Publish Recipient OptionIf the Document Metadata Notification Broker supports this option, it shall accept and processDocument Metadata Publish transactions, representing applicable events for which there may bevalid subscriptions.26.3 Grouping220Each DSUB Actor shall be grouped with Secure Node or Secure Application Actor in order tomanage audit trail of exported PHI, node authentication and transport security. As a consequenceof this requirement, each DSUB Actor shall be grouped with the Time Client Actor as well.26.4 Document Metadata Subscription Process Flow26.4.1 Unexpected Notification Use Case225230A patient in the emergency department has all her relevant available documents retrieved viaXDS transactions. As initial triage of the patient is done, an additional document regardingdiagnostic results for this patient is registered in the XDS Document Registry. Currently, there isno way for the Emergency department to learn about the existence of this new information. Witha publish/subscribe infrastructure, the initial query to the XDS Document Registry would beaccompanied with a subscription request, as a result of which a notification would be sent to theemergency department. The subscription will be terminated once the patient is no longer underthe care of the emergency department's institution.2009-08-10 9 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)280285occasionally to the XDS Affinity Domain and enterprises. In these instances, IHE’sresponsibility to notify affected parties is fulfilled through the following section.A policy decision can be made during the Subscribe transaction, whether the subscription is anauthorized subscription and whether a notification/type of notification is authorized. (This couldbe based on the XUA identity, the consumer address value, etc.)This profile does not include the solution to changes of policy between the subscribe time andnotify time (which can be substantial). The recommendation is that the policy is enforcedconservatively (i.e. the length of subscription can be determined by the Document MetadataNotification Broker).Specific security considerations are presented in the security section of each transaction inVolume 2b.2009-08-10 13 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB) Actor Summary Definitions290295300Document Metadata Notification Broker – The Document Metadata Notification Broker is thereceiver of the Document Metadata Subscribe transaction containing a subscription request, or asubscription cancellation. It keeps track of all subscriptions in the Metadata Notification domain,including the time limits of subscriptions. Based on the metadata associated with documentregistrations, this actor sends notifications to interested subscribers. This actor may optionallyreceive Document Metadata Publish Transactions representing the stream of events againstwhich the existing subscriptions are matched.Document Metadata Subscriber – The Document Metadata Subscriber actor initiates andterminates subscriptions on behalf of a Document Metadata Notification Recipient.Document Metadata Publisher – The Document Metadata Publisher actor shall send aDocument Metadata Publish transaction to the Document Metadata Notification Broker for anyevent for which a subscription may exist.Document Metadata Notification Recipient – This actor receives the notification about anevent, when the subscription filters specified for this Document Metadata Notification Recipientare satisfied.2009-08-10 14 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB) Transaction Summary Definitions30531031552. Document Metadata Subscribe: This transaction is sent by the Document MetadataSubscriber to the Document Metadata Notification Broker in order to start a subscription for aparticular set of topics, indicating possible start and end time for the subscription. Subscriptionscannot be modified. Any subscriber actor can cancel a subscription, as long as they have thesubscription id. The subscription request shall specify whether a full notification or a minimalnotification will be sent when there is a match to the subscription's filter.53. Document Metadata Notify: This is a transaction from the Document Metadata NotificationBroker to the Document Metadata Notification Recipients, sending a notification about theavailability of a document or documents of interest, based on the subscribers' filters on selectedtopics.54. Document Metadata Publish: This transaction is sent from the Document MetadataPublisher to the Document Metadata Notification Broker when an event occurs for which theremay be a subscription.2009-08-10 15 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)3.52.4 Interaction Diagram345Figure 3.52.4-1: Document Metadata Subscribe Sequence3.52.4.1 Subscribe Request Message3.52.4.1.1 TriggerA Document Metadata Notification Recipient's need to initiate a subscription will cause theDocument Metadata Subscriber to trigger a Subscribe Request message.3503553.52.4.1.2 Message SemanticsThe Subscribe Request message shall comply with the requirements in the WS-BaseNotificationstandard as described in ITI TF-3: 4.4.2.1.4.1.2.This transaction uses simple topics in accordance with the WS-Topics standard and as specifiedin ITI TF-2b: 3.52.5.This transaction uses a filter based on the XDS Registry Stored Query transaction syntax andsemantics as specified in ITI TF-2b: 3.52.5 Subscription Topics and Filter Expressions.3.52.4.1.3 Expected ActionsThe expected actions are described in ITI TF-3: 4.4.2.1.4.1.3.3.52.4.1.4 Example360

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soapenvelopehttp://www.w3.org/2005/08/addressing http://www.w3.org/2005/08/addressing/ws-addr.xsdhttp://docs.oasis-open.org/wsn/b-2 http://docs.oasis-open.org/wsn/b-2.xsdurn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0 ../schema/ebRS/rim.xsd">370 http://docs.oasis-open.org/wsn/bw-2/NotificationProducer/SubscribeRequest382dcdc7-8e84-9fdc-8443-48fd83bca938375 380 https://NotificationRecipientServer/xdsBnotificationihe:MinimalDocumentEntry385 'st3498702^^^&1.3.6.1.4.1.21367.2005.3.7&ISO'390 ('Emergency Department')395 2010-05-31T00:00:00.00000Z400 3.52.4.2 Subscribe Response Message4053.Y52.4.2.1 TriggerThis message is an immediate response to a Subscribe Request, and it is sent from the DocumentMetadata Notification Broker to the Document Metadata Subscriber.3.52.4.2.2 Message SemanticsThe message semantics are described in ITI TF-3: 4.4.2.1.4.2.2.4103.52.4.2.3 Expected ActionsThe expected actions are described in ITI TF-3: 4.4.2.1.4.2.3.3.52.4.2.4 Example415

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)xmlns:ihe="urn:ihe:iti:dsub:2009"420 xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soapenvelopehttp://www.w3.org/2005/08/addressing http://www.w3.org/2005/08/addressing/ws-addr.xsdhttp://docs.oasis-open.org/wsn/b-2 http://docs.oasis-open.org/wsn/b-2.xsd">http://docs.oasis-open.org/wsn/bw-425 2/NotificationProducer/SubscribeResponse430https://NotificationBrokerServer/Subscription/382dcdc7-8e84-9fdc-8443-48fd83bca938435 2008-05-31T00:00:00Z4403.52.4.3 Unsubscribe Request Message3.52.4.3.1 TriggerWhen a subscription is no longer needed, a Document Metadata Subscriber will trigger anUnsubscribe Request message.4453.52.4.3.2 Message SemanticsThe message semantics are described in ITI TF-3: 4.4.2.1.4.3.2.3.52.4.3.3 Expected ActionsThe expected actions are described in ITI TF-3: 4.4.2.1.4.3.3.3.52.4.3.4 Example450 460 http://docs.oasis-open.org/wsn/bw-2/SubscriptionManager/UnsubscribeRequest382dcdc9-8e86-9fde-8445-48fd83bca93ahttps://NotificationBrokerServer/Subscription/465382dcdc7-8e84-9fdc-8443-48fd83bca938470 2009-08-10 19 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)3.52.4.4 Unsubscribe Response Message3.52.4.4.1 TriggerThis message is an immediate response to an Unsubscribe Request message, and it is sent fromthe Document Metadata Notification Broker to the Document Metadata Subscriber.4753.52.4.4.2 Message SemanticsThe message semantics are described in ITI TF-3: 4.4.2.1.4.4.2.3.52.4.4.3 Expected Actions480The actions are described in ITI TF-3: 4.4.2.1.4.4.3.The Document Metadata Notification Broker shall cancel the corresponding subscription.The Document Metadata Subscriber shall mark the corresponding subscription as successfullyterminated.3.52.4.4.4 Examplehttp://docs.oasis-open.org/wsn/bw-2/SubscriptionManager/UnsubscribeRequest495 3.52.5 Subscription Topics and Filter Expressions500This transaction restricts the subscription topic to be one of FullDocumentEntry orMinimalDocumentEntry (ITI TF-2b: 3.52.5.1) and restricts the semantics of filter expressions tothe semantics of a subset (ITI TF-2b: 3.52.5.2) of the Registry Stored Query.3.52.5.1 Topics505This transaction defines simple topics as described in the WS-Topics specification. TheDocument Metadata Notification Broker shall support the following topics in a DocumentMetadata Subscribe Request, and the Document Metadata Subscriber may support a subset ofthese:2009-08-10 20 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)3.52.5.1.1 ihe:FullDocumentEntry510This topic indicates that the events for which the subscription is made shall be Document Entryregistrations, and that the notification shall contain the full metadata describing each matchingDocument Entry as described in the Notification transaction in ITI TF-2b: 3.53.4.1.2.3.52.5.1.2 ihe:MinimalDocumentEntry515This topic indicates that the events for which the subscription is made shall be Document Entryregistrations, and that the notification shall contain the minimal set of data describing eachmatching Document Entry as described in the Notification transaction in ITI TF-2b: 3.53.4.1.2.3.52.5.2 Building Filter ExpressionsThe XDS metadata, specified in ITI TF-3: 4.1, describes the objects which are used in adocument registration. The Registry Stored Query transaction [ITI-18] uses a subset of themetadata to build a list of queries available to a XDS Document Consumer to search for520 documents with specific characteristics. The list of queries is in ITI TF-2a: 3.18.4.1.2.3.7. Thistransaction limits the filtering expression to only a subset of the parameters of theFindDocuments query defined within the Registry Stored Query transaction and uses the syntaxof the FindDocuments query to express the filter.The evaluation of filter expressions is based on the XDS metadata model. In this transaction, the525 stream of events, for which subscriptions are possible, is limited to events representing theexistence of Document Entry Objects. The Document Metadata Notification Broker becomesaware of such events either via a Document Metadata Publish transaction [ITI-54], or via othermechanisms, not specified by IHE. The Document Metadata Notification broker shall determineif there is a subscription which matches any of the Document Entry Objects in an event.530 A match means that if a FindDocuments Stored Query, with the same parameters as the filterexpression in the subscription, were sent to a XDS Document Registry containing the DocumentEntry Objects from the event, the result of this Stored Query contains one or more of theDocument Entry Objects.In an XDS Affinity Domain context, the applicable events are likely to be Register Document535 Set transactions containing one or more Document Entry objects. In a cross-community context,the applicable events are defined by the XCA gateway and out of scope for this profile. In thelatter case, the Document Metadata Notification Broker may have to map between the modelwithin which the events took place, and the XDS metadata model.A good understanding of the Registry Stored Query transaction and the XDS metadata is540 necessary to understand how the filter expressions work. For example, in an XDS AffinityDomain context, the stored query545 'st3498702^^^&1.3.6.1.4.1.21367.2005.3.7&ISO'550 ('44950' '44955' '44960' '44970' '44979')2009-08-10 21 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)555560will return all document entries for patient with ID st3498702 (assigned by an authorityidentified by the OID 1.3.6.1.4.1.21367.2005.3.7) where the event code metadata contains atleast one of the codes listed (in this case CPT codes for various appendectomies). When used asa filter expression, the same structure will yield a match against a document entry in an XDSregistry submission, where the document entry is for patient with ID st3498702 and the eventcode is "44970". The following snippet shows an example of such a submission:565 ...570 CPT codes575 ...When a Document Metadata Notification Subscriber constructs a filter expression, it shallinclude the whole stored query expression (as shown above) directly in the Subscribe Requestmessage as a child of the wsnt:Filter element:http://docs.oasis-open.org/wsn/bw-2/NotificationProducer/SubscribeRequest605 382dcdc7-8e84-9fdc-8443-48fd83bca938https://NotificationRecipientServer/xdsBnotification615 ihe:FullDocumentEntry2009-08-10 22 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)620 'st3498702^^^&1.3.6.1.4.1.21367.2005.3.7&ISO'625 ('44950' '44955' '44960' '44970' '44979')630 2008-07-31T00:00:00.00000Z635640The actual implementation of how the Document Metadata Notification Broker evaluates thefilter expression, and how it performs the matching against the existing subscriptions, is out ofscope of this profile. It is expected that such implementation details will allow vendors todifferentiate themselves in the marketplace.It is important to note that not all stored queries, and not all parameters defined for the storedqueries, are suitable for filter expressions. The Document Metadata Notification Broker shallsupport the following stored queries and associated parameters when used in subscriptionrequests, and the Document Metadata Subscriber may support a subset of these:3.52.5.2.1 Subscriptions based on FindDocuments query645650655660Document Metadata Notification Brokers that accept a Subscribe Request containing filterexpressions based on the FindDocuments stored query shall yield a match as described earlier inthis section. Note that the parameters to the Find Documents stored query which are not listedbelow do not have clear applicability as a filter expression.1. $XDSDocumentEntryPatientId: this required parameter contains the patient ID forwhich a document entry is being registered in the XDS Document Registry2. $XDSDocumentEntryClassCode: this parameter matches against theXDSDocumentEntry.classCode metadata elements in a given registry submission3. $XDSDocumentEntryPracticeSettingCode: this parameter matches against theXDSDocumentEntry.practiceSettingCode metadata elements in a given registrysubmission4. $XDSDocumentEntryHealthcareFacilityTypeCode: this parameter matches againstthe XDSDocumentEntry.healthcareFacilityTypeCode metadata elements in a givenregistry submission5. $XDSDocumentEntryEventCodeList: this parameter matches against theXDSDocumentEntry.eventCodeList metadata elements in a given registry submission6. $XDSDocumentEntryConfidentialityCode: this parameter matches against theXDSDocumentEntry.confidentialityCode metadata elements in a given registrysubmission7. $XDSDocumentEntryFormatCode: this parameter matches against theXDSDocumentEntry.formatCode metadata elements in a given registry submission2009-08-10 23 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)6658. $XDSDocumentEntryAuthorPerson: this parameter matches against theXDSDocumentEntry.author metadata elements in a given registry submission. Allproperties of this parameter specified in ITI TF-2a: 3.18.4.1.2.3.7.1 are applicable inthis transaction.3.52.5.3 Combining topics and filter expressions670675A topic defines static rules for creating notifications. This transaction defines two topics in ITITF-2b: 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. Filterconditions expressed as query parameters and used in the expressions must satisfy the samerequirements as a corresponding Registry Stored Query:• the values for all specified query parameters must match (AND all differentparameters)• at least one of the values of multi-valued parameters must match (OR the values in amulti-valued query parameter)3.52.6 Security Considerations680685690695700The risk assessment for the Document Metadata Subscribe transaction is described in the riskassessment spreadsheet for the Document Metadata Subscription profile, which is available fromIHE at http://wiki.ihe.net/images/4/46/DSUB_risk_assesment.xls. The derived mitigations are asfollows:• Document Metadata Subscriber and Document Metadata Notification Broker shall begrouped with an ATNA Secure Node or Secure Application actor for NodeAuthentication and Audit Trails• The use of encrypted TLS is recommended when the transmission is not otherwisesecured (e.g. transmission over a secure network)As it is possible through the document metadata subscribe transaction to maliciously overloadthe Document Metadata Notification Recipient actors, it is recommended that a strongauthentication be used in combination with access rights enforcement and that authenticationdata should be conveyed through XUA. This recommendation also addresses the possibility ofmalicious cancellations of subscriptions.Additionally, it is recommended that organizational measures be taken to avoid:• overload of a Document Metadata Notification Recipient through subscription whichcannot be cancelled because the subscription id has been lost e.g. through anadministrative service allowing cancellation of subscription under well definedcircumstances• cancellation of a subscription unnoticed by the intended document metadatanotification recipient e.g. through an informative message (out of the scope of thisprofile) sent to the intended recipient2009-08-10 24 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)3.52.6.1 Audit Record ConsiderationsThe Subscribe Transaction is a Query Information event as defined in table ITI TF-2a: 3.20.6-1.The Actors involved shall record audit events according to the following:7053.52.6.1.1 Document Metadata Subscriber audit message:Field Name Opt Value ConstraintsEventAuditMessage/EventIdentificationEventID M EV(110112, DCM, “Query”)EventActionCodeM“C” (Create) for Subscription message exchange“D” (Delete) for Unsubscribe message exchangeEventDateTime M not specializedEventOutcomeIndicator M not specializedEventTypeCode 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)Patient (0..1)Query Parameters(1)Where:SourceAuditMessage/ActiveParticipantUserID C When WS-Addressing is used: AlternativeUserIDMthe process ID as used within the local operating system in the localsystem logs.UserName U not specializedUserIsRequestor M “true”RoleIDCode M EV(110153, DCM, “Source”)NetworkAccessPointTypeCode M “1” for machine (DNS) name, “2” for IP addressNetworkAccessPointID M The machine name or IP address, as specified in RFC 3881.HumanRequestor(if known)AuditMessage/ActiveParticipantUserID M Identity of the human that initiated the transaction.AlternativeUserID U not specializedUserName U not specializedUserIsRequestor M “true”RoleIDCode U Access Control role(s) the user holds that allows this transaction.NetworkAccessPointTypeCodeNetworkAccessPointIDNANADestinationAuditMessage/ActiveParticipantUserID M SOAP endpoint URI.AlternativeUserID U not specializedUserName U not specializedUserIsRequestor M “false”RoleIDCode M EV(110152, DCM, “Destination”)NetworkAccessPointTypeCode M “1” for machine (DNS) name, “2” for IP addressNetworkAccessPointID M The machine name or IP address, as specified in RFC 3881.2009-08-10 25 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)Audit SourceAuditMessage/AuditSourceIdentificationAuditSourceID U Not specialized.AuditEnterpriseSiteID U not specializedAuditSourceTypeCode U not specializedPatient(if known)(AudittMessage/ParticipantObjectIdentification)ParticipantObjectTypeCode M “1” (Person)ParticipantObjectTypeCodeRole M “1” (Patient)ParticipantObjectDataLifeCycle U not specializedParticipantObjectIDTypeCode M EV(2, RFC-3881, “Patient Number”)ParticipantObjectSensitivity U not specializedParticipantObjectID M The patient ID in HL7 CX format.ParticipantObjectName U not specializedParticipantObjectQuery U not specializedParticipantObjectDetail U not specializedQueryParameters(AudittMessage/ParticipantObjectIdentification)ParticipantObjectTypeCode M “2” (system object)ParticipantObjectTypeCodeRole M “24” (query)ParticipantObjectDataLifeCycle U not specializedParticipantObjectIDTypeCode M EV(“ITI-52”, “IHE Transactions”, “Document Metadata Subscribe”)ParticipantObjectSensitivity U not specializedParticipantObjectID U not specializedParticipantObjectName C If known the value of ParticipantObjectQuery M the value of element, base64 encoded.ParticipantObjectDetail U not specialized7103.52.6.1.2 Document Metadata Notification Broker audit message:EventAuditMessage/EventIdentificationField Name Opt Value ConstraintsEventID M EV(110112, DCM, “Query”)EventActionCodeM“C” (Create) for Subscription message exchange“D” (Delete) for Unsubscribe message exchangeEventDateTime M not specializedEventOutcomeIndicator M not specializedEventTypeCode 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)Patient (0..1)Query Parameters(1)Where:SourceAuditMessage/ActiveParticipantUserID C When WS-Addressing is used: AlternativeUserID U not specializedUserName U not specializedUserIsRequestor M “true”RoleIDCode M EV(110153, DCM, “Source”)NetworkAccessPointTypeCode M “1” for machine (DNS) name, “2” for IP addressNetworkAccessPointID M The machine name or IP address, as specified in RFC 3881.2009-08-10 26 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)DestinationAuditMessage/ActiveParticipantUserID M SOAP endpoint URI.AlternativeUserIDMthe process ID as used within the local operating system in the localsystem logs.UserName U not specializedUserIsRequestor M “false”RoleIDCode M EV(110152, DCM, “Destination”)NetworkAccessPointTypeCode M “1” for machine (DNS) name, “2” for IP addressNetworkAccessPointID M The machine name or IP address, as specified in RFC 3881.Audit SourceAuditMessage/AuditSourceIdentificationAuditSourceID U Not specialized.AuditEnterpriseSiteID U not specializedAuditSourceTypeCode U not specializedPatient(If known)(AudittMessage/ParticipantObjectIdentification)QueryParameters(AudittMessage/ParticipantObjectIdentification)ParticipantObjectTypeCode M “1” (Person)ParticipantObjectTypeCodeRole M “1” (Patient)ParticipantObjectDataLifeCycle U not specializedParticipantObjectIDTypeCode M EV(2, RFC-3881, “Patient Number”)ParticipantObjectSensitivity U not specializedParticipantObjectID M The patient ID in HL7 CX format.ParticipantObjectName U not specializedParticipantObjectQuery U not specializedParticipantObjectDetail U not specializedParticipantObjectTypeCode M “2” (system object)ParticipantObjectTypeCodeRole M “24” (query)ParticipantObjectDataLifeCycle U not specializedParticipantObjectIDTypeCode M EV(“ITI-52”, “IHE Transactions”, “Document Metadata Subscribe”)ParticipantObjectSensitivity U not specializedParticipantObjectID U not specializedParticipantObjectQuery M the value of element, base64 encoded.ParticipantObjectDetail U not specialized7153.53 Document Metadata Notify720This section corresponds to Transaction ITI-53 of the IHE IT Infrastructure TechnicalFramework. Transaction ITI-53 is used by the Document Metadata Subscriber and the DocumentMetadata Notification Broker actors.3.53.1 ScopeThis transaction delivers a notification from the Document Metadata Notification Broker to theDocument Metadata Notification Recipient about an event which matches an existingsubscription.2009-08-10 27 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)725 3.53.2 Use Case Roles730Actor: Document Metadata Notification BrokerRole: Sends notifications to subscribed Document Metadata Notification Recipients based onreceived Publish transactionsActor: Document Metadata Notification RecipientRole: Receives and processes notifications about events matching a set of filter expressions.3.53.3 Referenced StandardsOASIS Web Services Notification Family of StandardsWS-BaseNotification 1.3 OASIS Standard735 WS-BrokeredNotification 1.3 OASIS StandardWS-Topics 1.3 OASIS StandardIHE ITI TF-2b: 3.43.4.2.2IHE ITI TF-2x: Appendix V2009-08-10 28 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)3.53.4 Interaction Diagram740Figure 3.53.4-1 Document Metadata Notify Sequence3.53.4.1 Notify Message3.53.4.1.1 Trigger745When an event occurs where the topics of the event match the filter requirements of one or moreexisting subscriptions, the Document Metadata Notification Broker will trigger a Notificationmessage to the corresponding Document Metadata Notification Recipient. The description ofmatching subscriptions to events can be found in ITI TF-2b: 3.52.5.2.3.53.4.1.2 Message Semantics750755760765Depending on the event which triggered the notification, there may be one or more DocumentEntry Objects whose metadata matches the filter conditions of any particular subscription. Thistransaction defines the following structures for conveying a Notify message:• A Full Notification, which shall be sent if the subscription request included the topicihe:FullDocumentEntry (see ITI TF-2b: 3.52.5.1). In this case, the notification shallconsist of parts of the payload of a Register Document Set-b Transaction as defined inITI TF-2b: 3.42.4.1. The element is the only child of thewsnt:Notify/wsnt:NotificationMessage/wsnt:Message element in this message. The element shall be the only child of the element. Only elementsrepresenting Document Entries shall be sent within the element.• A Minimal Notification, which shall be sent if the subscription request included the topicihe:MinimalDocumentEntry. In this case the response consists of the element, as defined in the XDS Retrieve DocumentSet transaction (ITI TF-2b: 3.43.4.1). The element is sent as the only child of thewsnt:Notify/wsnt:NotificationMessage/wsnt:Message element.2009-08-10 29 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)There shall be a single wsnt:Notify/wsnt:NotificationMessage/wsnt:Message element in thistransaction. If multiple DocumentEntries need to be represented in a single notification, theunderlying structure allows this to be done.3.53.4.1.3 Expected Actions770775The Document Metadata Notification Recipient shall accept the Notify message. The Notifymessage shall be processed according to the configuration and business logic of the actor.Possibilities include conveying the notification information to other systems and/or users.The Document Metadata Notification Broker may send the filter conditions of the subscription,and/or the address of the producer reference from where the Document Metadata Publishtransaction originated. Both of these options increase certain security risks, their use should bedetermined by local policy for security and confidentiality.3.53.4.1.4 Examples3.53.4.1.4.1 Full Notification Example780

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)825 CPT codes...830 835 ...840 845 3.53.4.1.4.2 Minimal Notification Example860 http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify382dcdca-8e87-9fdf-8446-48fd83bca93bhttps://NotificationRecipientServer/xdsBnotification865 https://NotificationBrokerServer/Subscription/870 382dcdc7-8e84-9fdc-8443-48fd83bca938ihe:MinimalDocumentEntry875 https://ProducerReference880 urn:oid:1.3.2458.2423.458.3.21.3.6.4…10001.3.2458.2423.456.5.3.5885 2009-08-10 31 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)890 3.53.5 Security ConsiderationsThe risk assessment for the Document Metadata Notify transaction is described in the riskassessment spreadsheet for the Document Metadata Subscription profile, which is available fromIHE at http://wiki.ihe.net/images/4/46/DSUB_risk_assesment.xls. The derived mitigations are asfollows:895900905• Document Metadata Notification Broker and Document Metadata Notification Recipientactors shall be grouped with an ATNA Secure Node or Secure Application for NodeAuthentication and Audit Trails• The use of encrypted TLS is recommended when the transmission is not otherwisesecured (e.g. transmission over a secure network)Additionally, it is recommended that the Document Metadata Notify transaction be associatedwith a SAML assertion outlining authorizations to the notification content so that the DocumentMetadata Notification Recipient will be able to enforce these authorizations (for example, see theXUA profile ITI TF-1: 13). This recommendation is highly dependent on an XDS AffinityDomain or a cross-community environment managing roles for its users correctly as most of theauthorizations will be based on roles.3.53.5.1 Audit Record ConsiderationsThe Document Metadata Notify Transaction is an Export event, as defined in ITI TF-2b Table3.20.6-1. The Actors involved in the transaction shall create audit data in conformance withDICOM (Supp 95) “Data Export”/”Data Import”, with the following exceptions.9103.53.5.1.1 Document Metadata Notification Recipient audit message:Field Name Opt Value ConstraintsEvent EventID M EV(110107, DCM, “Import”)AuditMessage/ EventActionCode M “C” (Create)EventIdentificationEventDateTime M not specializedEventOutcomeIndicator M not specializedEventTypeCode M EV(“ITI-53”, “IHE Transactions”, “Document Metadata Notify”)Source (Document Metadata Notification Broker) (1)Destination (Document Metadata Notification Recipient) (1)Human Requestor (0..n)Audit Source (Document Metadata Notification Recipient) (1)Patient (0..1)Document (1..n)Where:Source UserID M When WS-Addressing is used: 2009-08-10 32 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)AlternativeUserID U not specializedUserName U not specializedUserIsRequestor M “false”RoleIDCode M EV(110153, DCM, “Source”)NetworkAccessPointTypeCode M “1” for machine (DNS) name, “2” for IP addressNetworkAccessPointID M The machine name or IP address, as specified in RFC 3881.DestinationAuditMessage/ActiveParticipantHumanRequestor(if known)AuditMessage/ActiveParticipantUserID C When WS-Addressing is used: AlternativeUserIDMthe process ID as used within the local operating system in the localsystem logs.UserName U not specializedUserIsRequestor M “true”RoleIDCode M EV(110152, DCM, “Destination”)NetworkAccessPointTypeCode M “1” for machine (DNS) name, “2” for IP addressNetworkAccessPointID M The machine name or IP address, as specified in RFC 3881.UserID M Identity of the human that initiated the transaction.AlternativeUserID U not specializedUserName U not specializedUserIsRequestor M “true”RoleIDCode U Access Control role(s) the user holds that allows this transaction.NetworkAccessPointTypeCode NANetworkAccessPointIDNA915Audit SourceAuditMessage/AuditSourceIdentificationPatient(if-known)(AudittMessage/ParticipantObjectIdentification)AuditSourceID U Not specialized.AuditEnterpriseSiteID U not specializedAuditSourceTypeCode U not specializedParticipantObjectTypeCode M “1” (Person)ParticipantObjectTypeCodeRole M “1” (Patient)ParticipantObjectDataLifeCycle U not specializedParticipantObjectIDTypeCode M EV(2, RFC-3881, “Patient Number”)ParticipantObjectSensitivity U not specializedParticipantObjectID M The patient ID in HL7 CX format.ParticipantObjectName U not specializedParticipantObjectQuery U not specializedParticipantObjectDetail U not specializedParticipantObjectTypeCode M “2” (System)ParticipantObjectTypeCodeRole M “3” (report)ParticipantObjectDataLifeCycle U not specializedParticipantObjectIDTypeCode M EV(9, RFC-3881, “Report Number”)ParticipantObjectSensitivity U not specializedParticipantObjectID M The value of ParticipantObjectName C If known the value of ParticipantObjectQuery U not specialized2009-08-10 33 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)ParticipantObjectDetail U not specialized3.53.5.1.2 Document Metadata Notification Broker audit message:EventAuditMessage/EventIdentificationField Name Opt Value ConstraintsEventID M EV(110106, DCM, “Export”)EventActionCode M “R” (Read)EventDateTime M not specializedEventOutcomeIndicator M not specializedEventTypeCode M EV(“ITI-53”, “IHE Transactions”, “Document Metadata Notify”)Source (Document Metadata Notification Broker) (1)Destination (Document Metadata Notification Recipient) (1)Audit Source (Document Metadata Notification Broker) (1)Document (1..n)Where:SourceAuditMessage/ActiveParticipantUserID M When WS-Addressing is used: AlternativeUserIDMthe process ID as used within the local operating system in the localsystem logs.UserName U not specializedUserIsRequestor M “false”RoleIDCode M EV(110153, DCM, “Source”)NetworkAccessPointTypeCode M “1” for machine (DNS) name, “2” for IP addressNetworkAccessPointID M The machine name or IP address, as specified in RFC 3881.DestinationAuditMessage/ActiveParticipantUserID C When WS-Addressing is used: AlternativeUserID U not specializedUserName U not specializedUserIsRequestor M “true”RoleIDCode M EV(110152, DCM, “Destination”)NetworkAccessPointTypeCode M “1” for machine (DNS) name, “2” for IP addressNetworkAccessPointID M The machine name or IP address, as specified in RFC 3881.Audit SourceAuditMessage/AuditSourceIdentificationAuditSourceID U Not specialized.AuditEnterpriseSiteID U not specializedAuditSourceTypeCode U not specialized920ParticipantObjectTypeCode M “2” (System)ParticipantObjectTypeCodeRole M “3” (report)ParticipantObjectDataLifeCycle U not specializedParticipantObjectIDTypeCode M EV(9, RFC-3881, “Report Number”)ParticipantObjectSensitivity U not specializedParticipantObjectID M The value of ParticipantObjectName C If known the value of ParticipantObjectQuery U not specialized2009-08-10 34 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)ParticipantObjectDetail U not specialized3.54 Document Metadata Publish925This section corresponds to Transaction ITI-54 of the IHE IT Infrastructure TechnicalFramework. Transaction ITI-54 is used by the Document Metadata Notification Broker andDocument Metadata Publisher actors.3.54.1 ScopeThis transaction delivers information from the Document Metadata Publisher to the DocumentMetadata Notification Broker about an event which may have a subscription.3.54.2 Use Case Roles930935Actor: Document Metadata Notification BrokerRole: Receives and processes information about events for which there may be a subscription.Actor: Document Metadata PublisherRole: Publishes information to the Document Metadata Notification Broker when newapplicable events occur.3.54.3 Referenced StandardsOASIS Web Services Notification Family of StandardsWS-BaseNotification 1.3 OASIS StandardWS-BrokeredNotification 1.3 OASIS Standard940 WS-Topics 1.3 OASIS StandardIHE ITI TF-2b: 3.43.4.2.2IHE ITI TF-2x: Appendix V2009-08-10 35 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)3.54.4 Interaction Diagram945Figure 3.54.4-1: Document Metadata Publish Sequence3.54.4.1 Notify Message3.54.4.1.1 Trigger950When an event occurs of interest to the Document Metadata Notification Broker, the DocumentMetadata Publisher will trigger a Notification message to the configured Document MetadataNotification Broker.3.54.4.1.2 Message SemanticsThe format of the Notify message used in the Document Metadata Publish transaction is identicalto the format of the Full Notification structure of the Notify message used in the DocumentMetadata Notify transaction. The format is defined in ITI TF-2b: 3.53.4.1.2.9553.54.4.1.3 Expected ActionsThe Document Metadata Notification Broker shall evaluate the Publish transaction, and if thereare matching subscriptions, it shall send the corresponding Notification transaction to theappropriate Document Metadata Notification Recipients.3.54.4.1.4 Example960 http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify2009-08-10 36 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)382dcdca-8e87-9fdf-8446-48fd83bca93b975 https://NotificationBroker/xdsBpublish980 https://DocumentSource985 …990 995 3.54.5 Security Considerations10001005The risk assessment for the Document Metadata Publish transaction is described in the riskassessment spreadsheet for the Document Metadata Subscription profile, which is available fromIHE at http://wiki.ihe.net/images/4/46/DSUB_risk_assesment.xls. The derived mitigations are asfollows:• The Document Metadata Publisher and the Document Metadata Notification Broker shallbe grouped with an ATNA Secure Node or Secure Application for Node Authenticationand Audit Trails• The use of encrypted TLS is recommended when the transmission is not otherwisesecured (e.g. transmission over a secure network)3.54.5.1 Audit Record Considerations1010The Document Metadata Publish Transaction is an Export event, as defined in ITI TF-2a: Table3.20.6-1. The Actors involved in the transaction shall create audit data in conformance withDICOM (Supp 95) “Data Export”/”Data Import”, with the following exceptions.3.54.5.1.1 Document Metadata Publisher Audit Message:Field Name Opt Value ConstraintsEventAuditMessage/EventIdentificationEventID M EV(110107, DCM, “Import”)2009-08-10 37 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)EventActionCode M “C” (Create)EventDateTime M not specializedEventOutcomeIndicator M not specializedEventTypeCode M EV(“ITI-54”, “IHE Transactions”, “Document Metadata Publish”)Source (Document Metadata Publisher) (1)Destination (Document Metadata Notification Broker) (1)Human Requestor (0..n)Audit Source (Document Metadata Publisher) (1)Patient (0..1)Document (1..n)Where:1015SourceAuditMessage/ActiveParticipantDestinationAuditMessage/ActiveParticipantHumanRequestor(if known)AuditMessage/ActiveParticipantUserID M When WS-Addressing is used: AlternativeUserID U not specializedUserName U not specializedUserIsRequestor M “false”RoleIDCode M EV(110153, DCM, “Source”)NetworkAccessPointTypeCode M “1” for machine (DNS) name, “2” for IP addressNetworkAccessPointID M The machine name or IP address, as specified in RFC 3881.UserID C When WS-Addressing is used: AlternativeUserIDMthe process ID as used within the local operating system in the localsystem logs.UserName U not specializedUserIsRequestor M “true”RoleIDCode M EV(110152, DCM, “Destination”)NetworkAccessPointTypeCode M “1” for machine (DNS) name, “2” for IP addressNetworkAccessPointID M The machine name or IP address, as specified in RFC 3881.UserID M Identity of the human that initiated the transaction.AlternativeUserID U not specializedUserName U not specializedUserIsRequestor M “true”RoleIDCode U Access Control role(s) the user holds that allows this transaction.NetworkAccessPointTypeCode NANetworkAccessPointIDNAAudit SourceAuditMessage/AuditSourceIdentificationAuditSourceID U Not specialized.AuditEnterpriseSiteID U not specializedAuditSourceTypeCode U not specializedParticipantObjectTypeCode M “1” (Person)2009-08-10 38 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)ParticipantObjectTypeCodeRole M “1” (Patient)ParticipantObjectDataLifeCycle U not specializedParticipantObjectIDTypeCode M EV(2, RFC-3881, “Patient Number”)ParticipantObjectSensitivity U not specializedParticipantObjectID M The patient ID in HL7 CX format.ParticipantObjectName U not specializedParticipantObjectQuery U not specializedParticipantObjectDetail U not specializedDocument(AudittMessage/ParticipantObjectIdentification)ParticipantObjectTypeCode M “2” (System)ParticipantObjectTypeCodeRole M “3” (report)ParticipantObjectDataLifeCycle U not specializedParticipantObjectIDTypeCode M EV(9, RFC-3881, “Report Number”)ParticipantObjectSensitivity U not specializedParticipantObjectID M The value of ParticipantObjectName C If known the value of ParticipantObjectQuery U not specializedParticipantObjectDetail U not specialized3.54.5.1.2 Document Metadata Notification Broker audit message:EventAuditMessage/EventIdentificationField Name Opt Value ConstraintsEventID M EV(110106, DCM, “Export”)EventActionCode M “R” (Read)EventDateTime M not specializedEventOutcomeIndicator M not specializedEventTypeCode M EV(“ITI-54”, “IHE Transactions”, “Document Metadata Publish”)Source (Document Metadata Publisher) (1)Destination (Document Metadata Notification Broker) (1)Audit Source (Document Metadata Notification Broker) (1)Document (1..n)Where:SourceAuditMessage/ActiveParticipantUserID M When WS-Addressing is used: AlternativeUserIDUserName U not specializedMthe process ID as used within the local operating system in the localsystem logs.UserIsRequestor M “false”RoleIDCode M EV(110153, DCM, “Source”)NetworkAccessPointTypeCode M “1” for machine (DNS) name, “2” for IP addressNetworkAccessPointID M The machine name or IP address, as specified in RFC 3881.1020UserID C When WS-Addressing is used: 2009-08-10 39 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)AlternativeUserID U not specializedUserName U not specializedUserIsRequestor M “true”RoleIDCode M EV(110152, DCM, “Destination”)NetworkAccessPointTypeCode M “1” for machine (DNS) name, “2” for IP addressNetworkAccessPointID M The machine name or IP address, as specified in RFC 3881.Audit SourceAuditMessage/AuditSourceIdentificationAuditSourceID U Not specialized.AuditEnterpriseSiteID U not specializedAuditSourceTypeCode U not specializedDocumentURI(AudittMessage/ParticipantObjectIdentification)ParticipantObjectTypeCode M “2” (System)ParticipantObjectTypeCodeRole M “3” (report)ParticipantObjectDataLifeCycle U not specializedParticipantObjectIDTypeCode M EV(9, RFC-3881, “Report Number”)ParticipantObjectSensitivity U not specializedParticipantObjectID M The value of ParticipantObjectName C If known the value of ParticipantObjectQuery U not specializedParticipantObjectDetail U not specialized2009-08-10 40 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)1025Add the following Section to Chapter 4 in Volume 3 of the ITI Technical Framework4.4 Publish/Subscribe Infrastructure10301035104010451050Event driven information exchange patterns dominate the data interchange in most healthcaresettings. For example, most HL7 version 2.x interfaces send messages based on events within thesender's system. Most current IHE profiles assume either static, out-of-band determination of thesenders and receivers of event driven information exchange, or describe query-response patterns.There is a need for a profiled dynamic infrastructure for event-driven information exchangepatterns within IHE. This section describes such a framework based on the publish/subscribedata exchange model.Publish/subscribe patterns of data exchange are conceptually simple, and involve a limitednumber of actors and transactions. The transactions allow for automating the determination ofinformation consumers based on events or content "topics". For example, if an IHE profiledescribes information content where a diagnosis is present and coded using a particular codingsystem, a subscriber can request to receive notifications when a diagnosis code from a particularset of codes is present. If the subscription is accepted, the system which keeps track ofinformation recipients will start sending notifications when new data matches the describedcriteria.The above example demonstrates an important issue which needs to be addressed by profilersand implementers of publish/subscribe interactions. Based on the information exchangeenvironment, topics can be described in various ways. This section presents a specific approachfor delivering abstract publish/subscribe content within a SOAP-based web servicesenvironment.The implementation of publish/subscribe in healthcare environments also needs to take intoaccount the need for security and privacy of the exchanged information. It is expected thatspecific bindings of IHE profiles to this framework will include details about security, accesscontrols and auditing controls within the bound profile.2009-08-10 41 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)4.4.1 Publish/Subscribe Actors and PatternsPublisher↓ Publish 4.4.2.3Notification Broker← Subscribe 4.4.2.1Subscriber↓Notify 4.4.2.2Notification RecipientFigure 4.4.1-1 Publish/Subscribe Actor Diagram10551060Figure 4.4.1-1 shows a general publish/subscribe pattern, expressed in the usual IHEActor/Transaction diagram. The actors and transactions described in this section are “abstract”,in the sense that the purpose of these descriptions is to provide the common underlying transportinfrastructure for publish/subscribe. A profile using the publish/subscribe pattern will provide thecontent and actual implementable details for the above actors and transactions within the contextof that profile. Such a profile may chose to omit certain actors or transactions, or to requirespecific grouping with other IHE actors.The following subsections discuss the various patterns applicable to a publish/subscribeimplementation, which are intended to help systems designers and profile authors toappropriately apply publish/subscribe to different types of data interchanges.4.4.1.1 General Publish/Subscribe Pattern1065The general publish/subscribe pattern contains four separate actors, which communicate via threetransactions. The actors are Notification Broker, Publisher, Subscriber, and NotificationRecipient. While in many practical cases some of these actors may be grouped, the most generaldiscussion of publish/subscribe can occur when these actors are considered individually.4.4.1.1.1 Notification Broker1070The Notification Broker keeps track of all subscriptions, and based on the information receivedin a Publish transaction it sends notifications to the appropriate Notification Recipients. Thisactor is the receiver of the Subscribe transaction, which represents subscription requests,2009-08-10 42 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)subscription modifications, and subscription cancellations. It also keeps track of the time limitsof subscriptions.107510804.4.1.1.2 PublisherWithin the publish/subscribe pattern, the Publisher actor is the source of the information towhich there may be a subscription. The Publisher is the sender of the Publish transaction andwhen the publish/subscribe pattern is applied to an existing IHE profile, in most cases it will begrouped with an existing IHE actor.4.4.1.1.3 SubscriberThe Subscriber actor initiates, modifies, and terminates subscriptions on behalf of a NotificationRecipient. It is the sender of the Subscribe transaction, and it may be servicing any number ofNotification Recipients.4.4.1.1.4 Notification Recipient1085The Notification Recipient actor receives the notification about a published event, when thesubscription filters specified for this Notification Recipient are satisfied.4.4.1.2 Combined Publisher/Notification BrokerPublisherNotification Broker← Subscribe 4.4.2.1Subscriber↓Notify 4.4.2.2Notification RecipientFigure 4.4.1-2 Combined Publisher/Notification Broker Actor Diagram1090 The Publisher and Notification Broker may be grouped together in cases where the source ofinformation to which there may be subscriptions can be enhanced with Notification Brokercapabilities, or when the Notification Broker is able to access the information for which theremay be subscriptions via some alternate mechanism. In such cases the Publish transaction willnot be present in the publish/subscribe implementation.2009-08-10 43 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)1095 4.4.1.3 Combined Subscriber/Notification RecipientPublisher↓ Publish 4.4.2.3Notification BrokerNotify 4.4.2.2 ↓↑ Subscribe 4.4.2.1NotificationRecipientSubscriberFigure 4.4.1-3 Combined Subscriber/Notification Recipient Actor Diagram1100In many cases, the Notification Recipient will have the capability to manage its ownsubscriptions, thus making the grouping of Subscriber and Notification Recipient a commonoccurrence.4.4.1.4 Combined Publisher/Notification Broker and CombinedSubscriber/Notification RecipientPublisherNotification BrokerNotify 4.4.2.2 ↓↑ Subscribe 4.4.2.1NotificationRecipientSubscriberFigure 4.4.1-4 Minimal Pub/Sub Actor Diagram2009-08-10 44 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)1105 In many data exchange cases there is only a need for two end points to establish apublish/subscribe relationship. Combining the Notification Recipient and Subscriber on one end,and the Publisher, and Notification Broker on the other is sufficient to provide publish/subscribefunctionality. It is expected that the simplicity of this pattern will make implementations easier.4.4.1.5 Cascading NotificationsPublisherNotification BrokerNotify ↓↑ SubscribeNotificationBrokerPublisherNotificationRecipientSubscriberNotify ↓↑ SubscribeNotificationRecipientSubscriber1110Figure 4.4.1-5 Cascading NotificationsIn some cases, the Notification Recipient may be grouped with another publisher, which allowsthe results of matching one subscription filter to become the input to another set of subscriptionfilter matches. This figure shows a possible configuration for such a case.2009-08-10 45 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)1115 4.4.1.6 Cascading Subscriptions↑ Subscribe↑ SubscribeNotify ↓NotificationBrokerSubscriberNotify ↓NotificationBrokerSubscriberNotify ↓NotificationBrokerSubscriberSubscribe↑Subscribe↑Subscribe↑NotificationRecipientSubscriberNotificationRecipientSubscriberNotificationRecipientSubscriber Notify ↓Figure 4.4.1-6 Cascading Subscriptions1120In some cases, the Notification Broker may be grouped with a Subscriber, which allows asubscribe request sent to the Notification Broker to be forwarded to other Notification Brokers.This figure shows a possible configuration for such a case.4.4.2 Publish/Subscribe Transactions and PatternsFigure 4.4.1-1 shows the set of transactions available for implementing publish/subscribefunctionality. The following subsections will describe the transactions and some possible uses.1125 The publish/subscribe transactions described in this section use the OASIS Web ServicesNotification family of standards as the basis for the format of the transactions.4.4.2.1 Subscribe4.4.2.1.1 Scope1130This transaction involves a request by the Subscriber actor to the Notification Broker to start asubscription using a particular set of filters, or to cancel an existing subscription.2009-08-10 46 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)4.4.2.1.2 Use Case Roles1135Actor: SubscriberRole: Sends, on the behalf of Notification Recipients, subscription requests, subscriptionmodifications, or subscription cancellation messages to the Notification BrokerActor: Notification BrokerRole: Manages subscriptions of Notification Recipients4.4.2.1.3 Referenced StandardsOASIS Web Services Notification Family of Standards1140 WS-BaseNotification 1.3 OASIS StandardWS-BrokeredNotification 1.3 OASIS StandardWS-Topics 1.3 OASIS StandardIHE ITI TF-2x: Appendix V11452009-08-10 47 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)4.4.2.1.4 Interaction Diagram4.4.2.1.4.1 Subscribe Request MessageFigure 4.4.2.1.4-1: Subscribe Sequence11504.4.2.1.4.1.1 TriggerA Notification Recipient's need to initiate a subscription will cause the Subscriber to trigger aSubscribe Request message.4.4.2.1.4.1.2 Message Semantics11551160The Subscribe Request message shall comply with the requirements in the WS-BaseNotificationstandard. 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 elementdescribes the Web Services end point where notifications must be sent. The wsnt:Filter elementshall 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:Filterelement. The wsnt:Filter element shall contain a TopicExpression element.4.4.2.1.4.1.2 Expected Actions1165The Notification Broker shall be capable of maintaining multiple concurrent Subscriptions.The Notification Broker shall keep track of each unique subscription and will provide a uniquesubscription reference which shall be used by the Subscriber to send subsequent cancellationsThe Subscriber may indicate the duration of the subscription using thewsnt:InitialTerminationTime element, where a time stamp (expressed as an XML Schema2009-08-10 48 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)dateTime data type value) or a duration (expressed as an XML Schema duration data type value)can be used.4.4.2.1.4.1.4 Example1170 1180 http://docs.oasis-open.org/wsn/bw-2/NotificationProducer/SubscribeRequest382dcdc7-8e84-9fdc-8443-48fd83bca9381185 1190 https://NotificationRecipientServer/xdsBnotification1195 2008-05-31T00:00:00.00000Z1200 4.4.2.1.4.2 Subscribe Response Message4.4.2.1.4.2.1 Trigger1205This message is an immediate response to a Subscribe Request, and it is sent from theNotification Broker to the Subscriber.4.4.2.1.4.2.1 Message Semantics12101215The Subscribe Response message shall comply with the requirements in the WS-BaseNotification standard, including the use of the appropriate SOAP Fault messages. Note thatthe value of the WS-Addressing Action element is prescribed in the standard, and differs fromthe requirements of Appendix V.The subscription identifier is assigned by the Notification Broker as a subscription reference,communicated in the response in the SOAP body inwsnt:SubscribeResponse/wsnt:SubscriptionReference (a WS-Addressing end point). Thesubscription reference shall consist of:• an Address element, containing a web services end point2009-08-10 49 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)1220122512301235• an optional Reference Parameter, containing an ihe:SubscriptionId element, which, whenpresent, shall contain a UUID uniquely identifying the subscription. The referenceparameter is optional, since the URI in the Address element can be constructed touniquely represent each subscription.In order to unsubscribe, the request shall be sent to the end point specified in the Addresscomponent of the SubscriptionReference, and, if the ihe:SubscriptionId element was sent as aReference Parameter of the subscription reference, it shall be sent as part of the SOAP headeraccording to the rules described in WS-Addressing.4.4.2.1.4.2.3 Expected ActionsIf the Subscriber had indicated a requested duration for the subscription, the Notification Brokershall send the assigned duration for the subscription using the wsnt:TerminationTime element.If the Subscriber had not indicated a requested duration for the subscription, the NotificationBroker may send an assigned duration for the subscription (if any), using thewsnt:TerminationTime element.If the Notification Broker sends an assigned duration for the subscription, the Subscriber shallassociate the assigned duration with the accepted subscription request.The Subscriber shall associate the accepted subscription request with the subscription referenceaddress assigned by the Notification broker in order to be able to send cancellations for existingsubscriptions.4.4.2.1.4.2.4 Example1245 http://docs.oasis-open.org/wsn/bw-2/NotificationProducer/SubscribeResponse1250 https://NotificationBrokerServer/UniqueSubscription/382dcdc7-8e84-9fdc-8443-48fd83bca9382008-05-31T00:00:00Z1260 2009-08-10 50 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)4.4.2.1.4.3 Unsubscribe Request Message4.4.2.1.4.3.1 Trigger1265When a subscription is no longer needed, a Subscriber will trigger an Unsubscribe message.4.4.2.1.4.3.2 Message Semantics1270The 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, anddiffers from the requirements of Appendix V.4.4.2.1.4.3.3 Expected Actions1275The subscriber shall send this message to the end point associated with the existing subscription.The Notification Broker shall cancel the corresponding subscription, and respond with anUnsubscribe Response message. In the case when, for whatever reason, the subscription cannotbe canceled, the Notification Broker shall respond with a ResourceUnknownFault or anUnableToDestroySubscriptionFault SOAP Fault message as appropriate.4.4.2.1.4.3.4 Examplehttp://docs.oasis-open.org/wsn/bw-2/SubscriptionManager/UnsubscribeRequest382dcdc9-8e86-9fde-8445-48fd83bca93a1290 https://NotificationBrokerServer/Unique Subscription/382dcdc7-8e84-9fdc-8443-48fd83bca9381295 4.4.2.1.4.4 Unsubscribe Response Message4.4.2.1.4.4.1 Trigger1300This message is an immediate response to an Unsubscribe message, and it is sent from theNotification Broker to the Subscriber.4.4.2.1.4.4.2 Message SemanticsThe Subscription Response message shall comply with the requirements in the WS-BaseNotification standard. This message indicates that an Unsubscribe message was successfully2009-08-10 51 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)1305processed. Note that the value of the WS-Addressing Action element is prescribed in thestandard, and differs from the requirements of Appendix V.4.4.2.1.4.4.3 Expected ActionsThe Notification Broker shall cancel the corresponding subscription.The Subscriber shall mark the corresponding subscription as successfully terminated.4.4.2.1.4.4.4 Example1310 13201325http://docs.oasis-open.org/wsn/bw-2/SubscriptionManager/UnsubscribeRequest4.4.2.1.5 Security ConsiderationsIHE Profiles shall provide a complete risk assessment when using this pattern.4.4.2.2 Notify13304.4.2.2.1 ScopeThis transaction delivers a notification from the Notification Broker to the Notification Recipientabout an event which matches an existing subscription.4.4.2.2.2 Use Case Roles1335Actor: Notification Broker2009-08-10 52 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)Role: Sends notifications to subscribed Notification Recipients based on events for which thereis a subscription.Actor: Notification RecipientRole: Receives and processes notifications about events matching a set of filter expressions.134013454.4.2.2.3 Referenced StandardsOASIS Web Services Notification Family of StandardsWS-BaseNotification 1.3 OASIS StandardWS-BrokeredNotification 1.3 OASIS StandardWS-Topics 1.3 OASIS Standard4.4.2.2.4 Interaction Diagram4.4.2.2.4.1 Notify Message4.4.2.2.4.1.1 TriggerFigure 4.4.2.2.4-1: Notify Sequence1350When an event occurs, where the topics of the event match the filter requirements of one or moreexisting subscriptions, the Notification Broker will trigger a Notify message to the correspondingNotification Recipient.4.4.2.2.4.1.2 Message Semantics13551360The Notify 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, anddiffers from the requirements of Appendix V. The content of thewsnt:Notify/wsnt:NotificationMessage/wsnt:Message element depends on the environment inwhich the Publish/Subscribe infrastructure is implemented. Within an IHE profile, thetransaction definition of the particular profile will define the content that is carried in thewsnt:Notify/wsnt:NotificationMessage/wsnt:Message element of the Notify message.2009-08-10 53 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)4.4.2.2.4.1.3 Expected Actions1365The Notification Recipient may take some action, based on the notification information, e.g.convey the notification information to other systems and/or users.The Notification Broker may send the topic expression of the subscription, and/or the address ofthe information source where the event originated. Both of these options increase certain securityrisks; their use should be determined by local policy to security and confidentiality.4.4.2.2.4.1.4 Example1380 http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify382dcdca-8e87-9fdf-8446-48fd83bca93bhttps://NotificationRecipientServer/xdsBnotification1385 https://NotificationBrokerServer/Unique Subscription/382dcdc7-1390 8e84-9fdc-8443-48fd83bca9381395 https://Publisher1400 14054.4.2.2.5 Security ConsiderationsProfiles shall provide a complete risk assessment when using this pattern.4.4.2.3 Publish4.4.2.3.1 Scope1410This transaction publishes information from the Publisher to the Notification Broker about anevent for which there may be a subscription.2009-08-10 54 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)4.4.2.3.2 Use Case Roles1415Actor: PublisherRole: Publishes a well-defined stream of events to the Notification Broker.Actor: Notification BrokerRole: Receives and processes information about events for which there may be a subscription.4.4.2.3.3 Referenced StandardsOASIS Web Services Notification Family of StandardsWS-BaseNotification 1.3 OASIS Standard1420 WS-BrokeredNotification 1.3 OASIS StandardWS-Topics 1.3 OASIS StandardIHE ITI TF-2x: Appendix V4.4.2.3.4 Interaction Diagram1425 Figure 4.4.2.3.4-1: Publish Sequence2009-08-10 55 Copyright © 2009: IHE International

IHE Technical Framework Supplement - Document Metadata Subscription (DSUB)4.4.2.3.4.1 Notify Message4.4.2.3.4.1.1 TriggerWhen a relevant event as defined by an IHE profile occurs the Publisher will trigger a Notifymessage to the corresponding Notification Broker.1430143514401445145014551460146514704.4.2.3.4.1.2 Message SemanticsThe transport format of the Notify message is identical to the format of the Notify message in theNotify transaction (see ITI TF-3: 4.4.2.2.4.1). When profiles implement this pattern, the contentof the message may be the same or different from the Notify transaction.Note that there is no subscription information in the Notify message in the Publish transaction.4.4.2.3.4.1.3 Expected ActionsThe Notify message shall comply with the requirements in the WS-BaseNotification standard.The Notification Broker shall evaluate the Publish transaction, and if there are matchingsubscriptions, it shall send the corresponding Notification transaction to the appropriateNotification Recipients.4.4.2.3.4.1.4 Examplehttp://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify382dcdca-8e87-9fdf-8446-48fd83bca93bhttps://NotificationRecipientServer/xdsBnotificationhttps://Publisher4.4.2.3.5 Security ConsiderationsIHE Profiles shall provide a complete risk assessment when using this pattern.2009-08-10 56 Copyright © 2009: IHE International