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

1. QIPP Digital Technology and ITKCare Co-Ordination: Interoperability WebEx4. 14th November 2012

2. 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. http://www.networks.nhs.uk/nhs-networks/interoperability-toolkit-itk

3. Store, notify and retrieve pattern Recipient Systems OOH System Acute System Community System GP System Ambulance System EPaCCS System GP Get Document Care Preferences Care Preferences Notification Clinician John • The GP creates John’s EPaCCS record. Note: This is only an example!

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

5. 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

6. Retrieval options Option 1: Get document by specific document/documentset 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”

7. Get Document Content • 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)

8. Serialisation options • 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

9. Technical landscape and choice of serialisation • 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)?

10. Potential 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

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

12. SPARE SLIDES

13. Retrieval options analysis

14. Chosen option and justification • 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.