110 likes | 246 Views
Full metadata Subscription (FSUB). Profile Proposal for 2012/13 presented to the IT Infrastructure Technical Committee Mauro Zanardini Mc Lean, December, 4 th 2012. FSUB - Key Elements. This proposal focuses on the extension of DSUB profile Key elements:
E N D
Full metadata Subscription(FSUB) Profile Proposal for 2012/13 presented to the IT Infrastructure Technical Committee Mauro Zanardini Mc Lean, December, 4th 2012
FSUB - Key Elements This proposal focuses on the extension of DSUB profile Key elements: • Notification of events occurred during a clinical workflow • Notification of content published whose type can’t be known in advance by Notification Recipient (hospitalization etc…) • Notification of content specifically targeted to one Recipient. • Address inconsistencies or lacks of DSUB profiles (e.g. constraint in using fullNotification)
FSUB - Necessity Why it is necessary to extend DSUB: • DSUB is not implemented in a wide way, probably because it is focused on a restricted set of use-cases. • DSUB has built a powerful notification infrastructure, that can be used to increase the process of digitalization reaching a more efficient access to the clinical content. • Many vendors has already implemented products based on DSUB out of the standard. • A workflow Management system without a notification system is not applicable in real use case.
Alignment with IHE purpose: • The extension grants backward compatibility with DSUB’s products. • The addition of new use-cases can only increase the of vendors interested in the profile • The extension doesn’t involve additional complexity to the profile. • Many other domains (PCC, RAD, PHARACY) have developed Workflow Definition profiles with the idea that DSUB’s notification system could be applied. ITI has to provide an instrument to fix this lack.
Use Case 1: clinical workflow • Many use-case (each workflow that can be managed using XDW), same functionalities needed: • During a clinical workflow, actors involved would like to be acknowledged for the specific workflow they belong to (notify in accordance to Workflow fixed reference). • A clinician would like to understand instantly which is the workflow that has been updated (self-consistent notification). • Notification system can be used to update the set of actors involved in the workflow (coupling between WS-HumanTask notification system and DSUB).
Use Case 2: laboratory Report production, hospitalization, etc… • Other use-cases requires that a notification has to be sent to a specific Recipient identified by the Source of clinical document: • Laboratory Report: the requester ask for a result, but in many case what he can request is different from the test performed by the laboratory (the source identifies the intendedRecipient of the content). • Report produced without the request of the GP: many processes requires the uknowledgment of the GP, but he is not involved in the process as requester (hospitalization)
Use Case 3: prolonged patient hospitalization • Many times all clinical information produced during an hospitalization are collected using a folder: • Clinician involved can’t define in advance the type of content produced: the subscribtion of documentEntry metadata are not useful. • Some clinician can only put inside a folder the reference to other documents already published: this action has to be notified as like as a new pubblication
Proposed Standards & Systems • ITI Afferent IHE Profiles: • DSUB, XDW, • Afferent IHE Profiles: • Pharmacy: CMPD, • Patient Care Coordination: XBeR-WD, XTB-WD, XTHM-WD, etc. • Radiology: XSM-WD • Other standards items: • WS-BaseNotification, WS-Topics • Stability and robustness: • No new transaction are introduced • No new actors are defined • Backwards compatibility
Simple Technical Approach • Exension of the filter expression: now DSUB profile allows to create subscriptions only based on findDocuments query • Changes affect: • Actors: Document Metadata Subscriber, Document Metadata Notification Broker • Transactions: Document Metadata Notify, Document Metadata Subscribe • Purpose: implementing subscriptions not based on query (content defined in ITI-18 transaction) but based on metadata. The subscription has to use the query sintax but the filter expression can be created using any combination of metadata.
Simple Technical Approach • Allows different notification payloads: the payload is defined by the topicExpression tag. DSUB now define only two values for this tag: ihe:MinimalDocumentEntry, ihe:FullDocumentEntry. • Changes affect: • Actors: Document Metadata Notification Broker, Document Metadata Notification Recipient • Transactions: Document Metadata Notify • Purpose: Allows the delivery of other objects then documents. Folders or submissions can contain information more useful in some cases (folderId, sourceId, intendedRecipient…).
Effort Estimates • The work effort (in term of documentation) for profiling the FSUB is SMALL because there aren’t new transactions and the new actor, and the template of DSUB can be used for the extension. • Only two transactions are affected by the extension, • The main part of the work can be the definition of new use-cases and addressing inconsistencies of DSUB. • Proposed editors: • Mauro Zanardini, Arsenàl.IT, mzanardini@consorzioarsenal.it • Organization: Arsenàl.IT, www.consorzioarsenal.it