qipp digital technology and itk care co ordination interoperability webex4 14 th november 2012
Download
Skip this Video
Download Presentation
QIPP Digital Technology and ITK Care Co-Ordination: Interoperability WebEx4. 14 th November 2012

Loading in 2 Seconds...

play fullscreen
1 / 14

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


  • 214 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' QIPP Digital Technology and ITK Care Co-Ordination: Interoperability WebEx4. 14 th November 2012' - hoshi


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
qipp digital technology and itk care co ordination interoperability webex4 14 th november 2012

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

slide2

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

slide3

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!

slide4

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

slide5

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
slide6

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”

slide7

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)
slide8

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
slide9

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)?
slide10

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
slide11

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

slide14

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.

ad