Full metadata Subscription and Pull-style Notification (FSPN)

1. DSUB.b or Full metadata Subscription and Pull-style Notification (FSPN) Brief Profile Proposal for 2012/13 presented to the ITI Planning Committee Mauro Zanardini (consorzio Arsenàl.IT) October, 30th October 2012

2. Proposal goals: The goals of the Proposal are two: • To extend functionalities of DSUB (Document metadata Subscription) profile with these purposes: • full metadata subscription, • extend notification payload • Pull-style notification • Define modalities to create subscription and/or deliver notification in accordance to access policies defined This allows: • The Creation of systems of notification adaptable for Workflow Management Systems based on XDW. • The definition a new modality to convey notifications applicable to Recipients that can’t show public IP or that can’t grant continuity of service.

3. TheProblem Build a Notification System to empower the XDW Workflow Management: • The only fixed reference to a specific workflow is the folderId: if an actor want to be acknowledged for a specific workflow it SHALL subscribe the related folderId • The payload of a notification (created for a workflow update) SHOULD contain the folder object that has been updated. • Actors involved in a distributed workflow doesn’t grant continuity of service, many times are masked by a firewall and/or can’t show a public IP. In these cases a Push-and-forget style of notification is not applicable. Pull-style is more flexible and already defined by WS-BaseNotification standard.

4. Use-case (1/3) Mr. Brown goes to his GP’s (Dr. Smith) to have a consultation because he has a dizziness. Dr. Smith prescribes two specialistic consultations (creating two eReferral workflow documents): • both the Workflow Documents are characterized by the same document metadata. • he creates subscriptions for both the folders that contain the two Workflow Documents. Same Metadata WD. 1 WD. 2 eReferral 1 eReferral 2 folderId.1 Specific references to Workflows folderId.2

5. Use-case (2/3) Mr. Brown goes to the healthcare provider of his choice to perform one of the visits: • The HCP takes in charge the eReferral and it schedules an appointment for the patient. The Workflow Document related is updated. • The Broker finds a subscription (created by the GP) for the specific folder updated and consequently it generates a notification with the folder object as payload. • Delivering of folder objects is the only way to give the GP’s the possibility to access the most recent version of the Workflow Document Notification: -WorkflowDocument The WD can be an already deprecated version Notification Recipient Notification Broker Notification: -Folder Using the folderId it can find every time the last WD

6. Use-case (3/3) The notification can’t be sent to the Recipient because the GP’s software is a not skilled application. • The Recipient can use a Pull-style notification to be acknowledged for updates. • Notifications are not lost and they are managed by a Pull-point directly created by the GP’s application. This software can access the pull-point and can poll all notifications pending in a simple and secure way. Notification delivered directly to the recipient are lost NAT or Firewall Pull Point Notification Broker Notification Recipient Polling of all notification pending Notification delivered to the Pull-point are managed and stored

7. Some Numbers for Veneto Region: Data coming from the Veneto region (4.900.000 habitants): Actors not allowed use a DSUB system of notification: • 3500 GPs; • 14.500 Hospital Clinicians; Clinical processes in which they are involved: • 60.000.000 prescriptions per year: for specialist consultation, laboratory investigation or pharmaceutical services. Each prescription involves at least 2 notifications to the Requester; • 500.000 patients can be potentially involved in telemonitoring processes; • 750.000 hospitalizations per year; Each GP receives almost 600 notifications/week related to ePrescriptions, and has to follow the telemonitoring processes for almost 140 patients, who collect data every day and generate alarms which have to be readily managed.

8. Existing profiles and standards (1/3): • Query Approach: • Large number of useless queries to the registry. • High complexity of requests made by the Recipient for multiple patientIdand multiple content (this two points can involve overloading for a registry or long time for responses) • There is not a system to track events occurred and notified, but not acknowledged by the Recipient. It can be done only with a notification queue manager and outpacing the push-and-forget style. • In a query scenario the Recipient has to know what it would like to find (or the patient related), using DSUB the subscription can be created by an actor distinct from the Recipient.

9. Existing profiles and standards (2/3): • NAV profile: • Requires that the Source knows the email address of the recipient for each content published. • It is not definied how a recipient can ask to be acknowledged for a specific content • Notification delivered using SMTP can convey only: • UUID of documents published, location of the registry, free text, email address of the sender. • SMTP server can create system of notification not suitable for a environment with large number of actors.

10. Existing profiles and standards (3/3): • Hybrid approaches (DSUB+NAV or DSUB+XDM): allow to wrap DSUB functionalities with SMTP infrastructure to deliver notifications • Customized approach that requires to use NAV out of the standards. • Customized transactions are required to translate DSUB sintax into NAV sintax and vice versa. • Communication is not secure (with NAV). • This approach can’t avoid the need of the extension of DSUB (allowing full metadata subscription and full object delivery). DocumentMetadata Notification Broker Notification Sender ITI-25 Send Notification SMTP ITI-26 Receive Notification Notification Receiver DocumentMetadata Notification Recipient