QIPP Digital Technology and ITK Care Co-Ordination: Interoperability WebEx4. 14 th November 2012

WebEx  Overview of the end-to-end basic “store, notify and retrieve” interaction pattern  Get Document – considered and chosen options  Get Document serialisation options  Potential future directions  There will then be time for questions and comments at the end.  During the WebEx all participants will be muted to avoid background noise  Discussion on this WebEx – either:  Use the “raise hand” and I will un-mute you so you can speak, or  Use the “chat” box to ask a question or make a comment  Please ensure you send it to “all” and not just the host!  The WebEx is being recorded, and a recording will be made available on the ITK NHS networks site after the session.

Store, notify and retrieve pattern GP Clinician John EPaCCS System Notification GP SystemCommunity SystemAmbulance SystemAcute SystemOOH System Care Preferences The GP creates John’s EPaCCS record. Note: This is only an example! Recipient Systems Care Preferences Get Document

Store, notify and retrieve pattern Document Source Document Repository Document Consumer Subscription Service Send Document Notification Get Document Subscriptions Endpoint Resolution From previous example – e.g. GP system EPaCCS e.g. OOH system Been discussed but out of scope for now These aspects have been discussed in workshops but out of scope of specification for now Resolve repository

Potential use cases for Get Document Message  View Document  View Referral Letter  View specific PHMR  View (single instance) Document  View SCR  View latest PHMR  View EPaCCS (End of Life) record  View Care Plan  View (on-demand) Document  View GP system summary

Option 1: Get document by specific document/document set id Option 2: Get document by other unique identifier (e.g. UBRN) Option 3: Get document by document type Option 4: Optimised “Get Document List” 6 Retrieval options

Get Document Content ItemDescriptionNotes Document Set IDUnique identifier of the document setThe message should contain either document set Id or document Id Document IDUnique identifier of an instance (version) of the document within the document set. The message should contain either document set Id or document Id  A note on ITK Document Sets  MUST only contain different versions of the same document  When using Get Document with Document Set ID  The Document repository (e.g. EPaCCS system) MUST return the latest document within the identified document set  When using Get Document with Document ID  The Document repository (e.g. EPaCCS system) MUST return the specific document instance/version even where it is not the latest in the set  No errors or warnings will be issued by the document repository  In this iteration there will be no specification for retrieval of document history (i.e. all document instance ids within the document set)

 Messaging based options Option 1: ITK creates its own message Option 2: IHE “Retrieve Document Set” transaction Option 3: EIS defined “Get Document” interface  Non-messaging (HTTP based) Option 4: IHE Mobile access to Health Documents “Get Document” Option 5: HL7 FHIR Restful document API Option 6: HTML form POST Option 7: Extend the notification click-through mechanism  Other Option 8: Existing supplier API Serialisation options

 General Assumptions There is a “user waiting” for the document The Document Consumer needs to resolve the address resolution (locally) or be provided it in the notification message  Pre-requisites for non-messaging (HTTP) based options Document consumer can “reach” the Document source via HTTP Synchronous request/response  Are there any requirements for a messaging – e.g. Indirect retrieval, batch synchronisation?  Should we only support one of the simpler non-messaging options?  Should we support both messaging and non-messaging?  What are the implications for future patterns (e.g. registry / repository)? Technical landscape and choice of serialisation

 Messaging Request ITK message in standard wrappers (e.g. SOAP for WS, DistributionEnvelope for all transports) HL7v3 payload message Response BusinessAck – for errors HL7 response wrappers + CDA payload  Non-messaging HTTP POST HTTP GET Potential Serialisation

Potential future directions (e.g. registry / repository pattern) Document Source Document Repository Document Registry Document Consumer Patient Identity Source Register document Patient Identity feed Send Document Get Document Get Document List Endpoint Resolution Resolve repository

SPARE SLIDES 12

Use-caseDocument id Other identifier Document type Optimised Document List View Referral Letter  View specific PHMR  View SCR  View latest PHMR  View EPaCCS record  View Care Plan  View on-demand record?  Retrieval options analysis

 Option 1: Get document by specific document/document set id Justification Chosen because it is simplest and future compatible with the full registry / repository pattern Requires the least amount of up-front analysis whilst still satisfying the core QIPP EPaCCS use-case Implications Creates a dependency on the Notification capability Probably requires around 50% of the analysis for the Get Document List/meta- data needs to be complete to ensure the transaction is future proof. Chosen option and justification