patterns of interoperability 1 16 th december 2014 adam hatherly (hscic) inderjit singh (nhs...

1

Patterns of Interoperability

16th December 2014Adam 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 Acare setting A

Module Bcare 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 SourceDocument

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

Document Repository

Document Registry

Document Consumer

Register document

Put Document Get Document

Get Document List

Summary of Patterns

Sys

A B

Data

A B

Src Con

Con

Src Brk Con

Single Shared Application

Click-Through

Send point-to point / Broadcast

Message Broker

Src

Rep Con

Con

Portal

Store and Notify

Shared Repository

Registry Repository

Ptl

A

B

N

Document

Source

Src Rep Con

Document Source

Src Rep

Reg Con

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


User Directory

Lookup

LookupLookup

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)


User Directory

Lookup

Lookup

SSO RBAC

Single Sign-On Role-Based Access Control

Endpoint DirectoryLookup

Registry

Query

Patient Index


N3

Internet

PKI

Broker / Middleware

TLS

MA

System A

System B

Messaging

Messaging Standards

Messa

ging

Reference Data

Terminology, etc.

SSO RBAC


User Directory

Lookup

Lookup


Registry

Query

Patient Index


N3

Internet

PKI

Broker / Middleware

TLS

MA

System A

System B

Notifications

SSO RBAC


User Directory

Lookup

Lookup


Registry

Query

Patient Index


Reference Data

Messaging Standards

Subscription Service

Manage Subscriptions and Topics

Publish

PKI

Messa

ging

N3

Internet

Broker / Middleware

Subscribe

TLS

MA

System A

System B

Information Governance

Reference Data

SSO RBAC


User Directory

Lookup

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



Query

Query

Query

Messa

ging

N3

Internet

Broker / Middleware

Publish

Subscribe

Messa

gingT

LS M

A

System A

System B

Summary



User Directory

Lookup

Lookup

Reference Data

SSO RBAC

Messaging Standards

Registry

Query

Citizen Identity

Patient Index

Lookup

DSA Repository

Relationship Service

Query

Consent Service

Query

Query

PKI


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

GP

Ambulance Trust

CCG

Community Trust

Acute Trust

Hospice

GP

GP

GP

CCG

CCG

GP

GP

GP

GP

Local Authority

CCG

GP

GP

GP

GP

GP

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

Src

Src

Src

Rep

Con

Con

Con

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:


Endpoint Directory

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

Document Source

Src Rep

Reg Con

Region 2

Document Source

Src Rep

Reg Con

Region 3

Reg

Con

Query

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?

patterns of interoperability 1 16 th december 2014 adam hatherly (hscic) inderjit singh (nhs...

Documents