1 / 11

Pull-style Notification (PNOT)

Pull-style Notification (PNOT). Profile Proposal for 2012/13 presented to the IT Infrastructure Technical Committee Mauro Zanardini Mc Lean, December, 4 th 2012. PNOT - Key Elements.

dani
Download Presentation

Pull-style Notification (PNOT)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Pull-style Notification(PNOT) Profile Proposal for 2012/13 presented to the IT Infrastructure Technical Committee Mauro Zanardini Mc Lean, December, 4th 2012

  2. PNOT - Key Elements This proposal focuses on the definition of a new modality to deliver notification, extending the powerful platform built upon DSUB profile Key elements: • Overcome the push-and-forget style of notification • Introduce a new actor that can manage Notification instead of the Recipient (if it can receive the notification directly) • This approach allows the sending of notification to actors that can’t grant the requirements of Synchronous Web Services. • Efficient way to overcome NAV profile and query approach using a more flexible and secure infrastructure instead of SMTP server.

  3. PNOT - Necessity Why it is necessary the Pull-style notification approach: • Spread of eHeath sytems, the increasing of the number of products integrated with a centralized sharing infrastructure (like XDS Regstry) requires the development of systems of notification for granting a more efficient access to clinical content • DSUB is not applicable where systems involved are not on-line anytime and where the Recipient cannot show a public IP. • DSUB provides a good solution for managing a publish and subscribe infrastructure. The extension proposed can empower the DSUB guidelines increasing the applicability to a wide range of systems.

  4. Alignment with IHE purpose: • The extension grants backward compatibility with DSUB’s products. • Applicability of the DSUB guidelines to all the actors involved in a sharing infrastructure • Many project at European level, National Level, Regional Level involves GP’s EHRs (that typically don’t grant DSUB requirements) • Clinical Workflows such as eReferral, ePrescription, telemonitoring, tumor-board have to be based on common stable notification infrastructure.

  5. Use Case??? It is not possible the identification of a specific use-case, It is possible to identify systems that can be affected and empowered by the solution: • Any use-case that needs a notification system based on DSUB, but that involves actors without the strict requirement of Synchronous WS. Requirement not satisfied: • Public IP, • continuity of the service H24, • actors hidden by NAT siystem or FireWall

  6. Proposed Standards & Systems • ITI Afferent IHE Profiles: • DSUB • Other standards items: • WS-BaseNotification, WS-Topics, WS-Addressing, WS-BaseFaults • Systems: • EHR, GP’s software, ect…

  7. Technical Approach Transaction for the-Point creation of the Pull New Actor that can be created by the Recipient that need a Pull-Point for the notifications Transaction for the polling of all notifications

  8. Technical Approach • Define new transactions: • [ITI-XX] Create Pull Point transaction: Started by the Notification Recipient, and sent to the Notification Pull Point actor. This transaction allows the activation of a pull point for the specific recipient that started the transaction itself. This transaction involves a request message (message CreatePullPoint) and a Response message. • [ITI-YY] Retrieve Document Metadata Notification transaction: Started by the Notification Recipient, and sent to the Notification Pull Point actor. This transaction allows the retrieve of the notifications produced by the Notification Broker and stored by the Notification Pull Point actor. (message getMessages).

  9. Open Issues • Possbility to manage two different paths for notification at the same time: Push-and-forget and Pull-style (DSUB&PNOT) Backwardcompatibilitybetween DSUB and PNOT • Value of using a mixture of other standards and profiles to address the problems encountered

  10. Discussion • NO QUERY APPROACH: • The first purpose of the Notification is to avoid useless queries to the registry (useless because content is not yet published). • It is not possible any time to understand in advance the type of content needed (notification used for communication between provider). • NO NAV, or XDM+DSUB: • Customized transaction are needed • Using of guidelines out of the standard • Limited content that can be delivered using SMTP

  11. Effort Estimates • The work effort (in term of documentation) for profiling the PNOT is MEDIUM because the OASIS WS-BaseNotification already define this new style of notification • It is necessary to define two new transactions and one new actor. • It is necessary to give a detailed description of the security constraint on the Pull-Point actors. • Proposed editors: • Mauro Zanardini, Arsenàl.IT, mzanardini@consorzioarsenal.it • Organization: Arsenàl.IT, www.consorzioarsenal.it

More Related