QIPP Digital Technology and ITKCare Co-Ordination: Interoperability WebEx4. 14th 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.

http://www.networks.nhs.uk/nhs-networks/interoperability-toolkit-itk

Store, notify and retrieve pattern

GP

Clinician

John

EPaCCS System

Notification

GP System

Community System

Ambulance System

Acute System

OOH 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 SourceDocument

SourceDocument 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 ContentItem Description Notes

Document Set ID Unique identifier of the document set The message should contain either document set Id or document Id

Document ID Unique 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 SourceDocument

SourceDocument 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-case Document 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

• ImplicationsCreates 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