Patterns of Interoperability 1 16 th December 2014 Adam Hatherly (HSCIC) Inderjit Singh (NHS England)

Topics to Cover Information Sharing Patterns Supporting Capabilities Sharing across Boundaries Group Discussion

Introducing Patterns A “pattern” is a formal way of documenting a solution to a design problem in a particular field of expertise – this case sharing clinical information between systems. Patterns are not mutually exclusive: many real solutions will use more than one pattern. Solutions may evolve from simpler to more complex patterns over time. Some patterns will be better for specific sharing needs than others – there is no “one size fits all”. Some patterns will scale better to larger populations. Some patterns require additional capabilities or services to be in place. Which patterns can best support your local needs?

Single Shared Application In some local health communities, an existing centrally hosted clinical system is already in place and is used across a number of care settings. In this case, it is logical to make use of this shared system to share patient information across services in that community. Typically modular – modules tailored for each care-setting’s workflows Data is (typically) shared via a common shared data store. Clinical System Module A care setting A Module B care setting b Shared data store

Click-Through The Click-Through pattern can provide a simple mechanism for allowing a user to view the contents of another clinical system launched as a new “tab” or window from their own system. This is typically achieved using a simple web address (URL) to allow the remote application to be opened with a specific patient context. Clinical System A Clinical System B Click-through

Point-to-Point / Broadcast Document Source Document Consumer Send Document The Document Source sends a copy of the full document to each of the Document Consumers. The document source typically has prior knowledge of the Document Consumers who would like to receive a copy of the document. Document Source and Document Consumers now hold copies of the same information An extension of the point-to-point pattern is to broadcast documents to multiple recipients. Document Consumer N

Message Broker In order to simplify the process of connecting multiple systems to one-another a message broker (a.k.a. middleware / integration engine / TIE) may be used. This may provide message routing, transformations, etc. It may also allow more advanced orchestration, flow control, security or other features. Document Source Message Broker Send Document Document Consumer Send Document

Portal Clinician views a summary of information extracted from multiple clinical systems via the portal Integration between the portal and clinical systems managed on a case-by-case basis Typically provides a read-only view of data, but may allow some limited write-back capabilities Typically, no data is persisted in the portal Portal Clinical System A Get Patient Information Clinical System B Clinical System N

Store and Notify When a new or updated piece of information (or document) is created, the Document Source sends the document into a Document Repository. The Document Repository then sends out notifications to inform other parties that new or updated information is available. Document Consumers would then be able to store a “pointer” to the information, and add a flag to the appropriate patient record to indicate that the information is available. The Document Consumer may then retrieve the document electronically, either immediately or when it is required for display. Document Source Document Repository Document Consumer Put Document Notification Get Document Document Consumer Notification

Shared Repository In large organisations with multiple systems, a single shared repository is sometimes used to provide a central point for sharing information (typically documents). This generally performs two key roles: –Provides a “registry” or index of the documents that are held about each patient. –Provides a “repository” of the information / documents, and a means to add, update and delete Document Source Document Repository Document Consumer Put Document Get Document List Get Document

Registry Repository This is an evolution of the shared repository pattern in which the “registry” and “repository” components are separated. This allows a single registry to provide indexing and querying of information and documents held across multiple repositories. This can be implemented in a variety of ways – the repository can initiate the creation of the registry entry, or vice-versa, or it can be done directly by the Document Source. Document Source Document Repository Document Registry Document Consumer Register document Put DocumentGet Document Get Document List

Summary of Patterns Sys AB Data AB SrcCon SrcBrk Con Single Shared Application Click-Through Send point-to point / Broadcast Message Broker Src Rep Con Portal Store and Notify Shared Repository Registry Repository Ptl A B N Do cu m en t So ur ce Src RepCon D oc u m e nt S o ur ce SrcRep RegCon

Introducing Supporting Capabilities A “capability” in the context of these slides, is a piece of functionality which can support implementation of specific interoperability patterns. Capabilities listed here are “logical” – they may be separate services, but may also be built into other systems. Not all capabilities are necessarily required to successfully implement individual patterns, but they will generally aid wider scalability of the patterns. Some capabilities exist nationally, although their use may be limited to specific services (e.g. Spine messaging). Which capabilities should be provided nationally?

Connectivity System A System B N3 Broker / Middleware Using N3 to provide connectivity Internet Broker / Middleware

Identity System A System B Patient Identity (NHS Numbers) Organisation Directory User Directory Lookup Organisation Identity Lookup User Identity and Roles Patient Index Lookup Citizen Identity Citizen Identity (For Online Access) N3 Internet Broker / Middleware

Discovery System A System B System and Service Discovery Patient Information Discovery Organisation Directory User Directory Lookup Registry Query Patient Index Lookup Citizen Identity N3 Internet Endpoint Directory Broker / Middleware

TLS MA System A System B Security Public Key Infrastructure (Trust and Encryption) Organisation Directory User Directory Lookup SSORBAC Single Sign-On Role-Based Access Control Endpoint Directory Lookup Registry Query Patient Index Lookup Citizen Identity N3 Internet PKI Broker / Middleware

TLS MA System A System B Messaging Messaging Standards Messaging Reference Data Terminology, etc. SSORBAC Organisation Directory User Directory Lookup Endpoint Directory Lookup Registry Query Patient Index Lookup Citizen Identity N3 Internet PKI Broker / Middleware

TLS MA System A System B Notifications SSORBAC Organisation Directory User Directory Lookup Endpoint Directory Lookup Registry Query Patient Index Lookup Citizen Identity Reference Data Messaging Standards Subscription Service Manage Subscriptions and Topics Publish PKI Messaging N3 Internet Broker / Middleware Subscribe

TLS MA System A System B Information Governance Reference Data SSORBAC Organisation Directory User Directory Lookup Endpoint Directory Lookup Messaging Standards PKI DSA Repository Data Sharing Agreements Relationship Service Legitimate Relationships Consent Service Consent Preferences Registry Query Other IG Capabilities Sealed Envelopes Privacy Makings Subject Access Request Handling Patient Index Lookup Citizen Identity Subscription Service Query Messaging N3 Internet Broker / Middleware Publish Subscribe

Messaging TLS MA System A System B Summary Endpoint Directory Lookup Organisation Directory User Directory Lookup Reference Data SSORBAC Messaging Standards Registry Query Citizen Identity Patient Index Lookup DSA Repository Relationship Service Query Consent Service Query PKI Subscription Service N3 Internet Broker / Middleware Publish Subscribe

Sharing across Boundaries The boundaries of different health and social care organisations vary greatly, meaning there is rarely an obvious boundary that information stays within. Local Authority GP Ambulance Trust CCG Community Trust Acute Trust Hospice GP CCG GP Local Authority CCG GP

Scaling Patterns Any of the patterns described can support local sharing within an organisation, or between a small number of organisations There are likely to be many cases where wider sharing is required: –When a patient receives treatment in a neighbouring organisation. –When a patient accesses services from an ambulance trust or other organisation whose boundaries differ from the local sharing boundary. –When a patient fall ill away from home Some patterns are able to scale better to these wider sharing scenarios than others Local sharing is likely to include larger more detailed data about patients, with wider sharing focused on simpler “core” data-sets agreed across a wider community (or nationally).

The n*(n-1)/2 Problem (Spaghetti) The “single shared application” approach was the original approach of the National Programme for IT – which had limited success. Some of the patterns discussed rely on point-to-point integrations between pairs of systems. This includes: –Click-Through –Send point-to-point / Broadcast –Portal These patterns often suffer from the n*(n-1)/2 problem: –Every node has to be able to connect to every other node –As the number of nodes (n) grows, the number of links grows rapidly –This can rapidly become difficult to manage

Moving from “push” to “pull” Some patterns allow information to be stored and retrieved when required – e.g. : –Store and Notify –Shared Repository –Registry Repository This means the sender only needs to know about the repository it is sending information to. A system wanting to retrieve information may use a registry to locate the relevant repository – this may also be federated. Src Rep Con

National Capabilities National capabilities can allow point-to-point patterns to scape but providing the information to allow senders, so they can discover endpoints as required, and establish secure connections: Organisation Directory Endpoint Directory PKI Patient Index Document Source Document Consumer Send Document A consistent identity for patients is required to ensure the document consumer can link received document to the correct patient. In order to establish a connection to a document consumer, an endpoint directory may be used – which may be linked to an organisation directory allowing the document source to look up end-points for organisations they wish to send to. To establish secure connectivity between trusted systems, a PKI would generally be used to issue endpoint certificates

Region 1 Federated Capabilities If a national approach is defined, capabilities can be delivered nationally, but could also be delivered in a federated way. For example, we could consider a federated “registry” – with a simple national registry which can point to regional registries: This can only work if common standards are agreed up-front – otherwise regional capabilities can’t be linked together. D oc u m e nt S o ur ce SrcRep RegCon Region 2 D oc u m e nt S o ur ce SrcRep RegCon Region 3 Reg Con Query Retrieve Query

Building a Roadmap It is not realistic to wait for national standards and capabilities before beginning to address local sharing challenges. Equally, once national capabilities and standards are in place, it will take some time for these to be adopted by system suppliers. We therefore need to prioritise national capabilities and standards. Local organisations also need to build roadmaps that allow them to progressively migrate to using more mature patterns, and national capabilities when they are in place, and it makes sense to do so. For example, a locality may build a roadmap for sharing a specific type of information (e.g. care plans): Simple notification and click-through patterns to provide access to plans held in clinical systems Implement a shared repository and submit plans to it Link the repository with a region-wide registry to link up with other repositories across a wider region Link the region-wide registry into a national registry to allow records to be located nationally.

Discussion We would like to work with a small number of organisations who want to actively help in defining the roadmap and standards and capabilities required at a local and national level. We have resource to work with early adopters of key capabilities to support making it work through national standards / capabilities, and supporting implementation where we can. Which standards and capabilities should be prioritised? What patterns are you using / planning to use / interested in looking into? Of these, what has to be national, and what could be local and/or federated? Who would like to work with us on this?