1 of 67

The Interoperability Universe

Dr Wai Keong Wong, PhD MRCP MRCPath�Haematology Consultant and Chief Research Information Officer, UCLH

2 of 67

A Brief History

And some guests….

3 of 67

About me

MBBS PhD (Newcastle)

Core Medical Training (Manchester)

Haematology Training (North Central London)

Medical Management and Leadership Fellow�(FMLM - Bupa, Clinical Analytics)

CCIO Leaders Network Advisory Panel Chair

HANDI Health, NHS Hackday, Cellcountr, OpenCancer

Wachter review group

4 of 67

The document adds that “open standards, secure identity and interoperability” are crucial to the success of technology use in healthcare but adds “the gap between where we are and where we want to be is only getting bigger”.

5 of 67

NHSX: giving patients and staff the technology they need

Posted by:

Matthew Gould,

Posted on:

24 June 2019

Matthew Gould meets staff from Addenbrooke's Hospital in Cambridge

Number one is the need for interoperability. Too many NHS systems can’t talk to each other. It could be a blood test taken in one part of the NHS that can’t be viewed in another, a GP’s system that doesn’t update when a hospital switches a patient’s medication, a mental health crisis team who have no idea the patient also has a heart condition.

Our siloed systems put patient safety at risk because clinicians end up treating patients without the full information. They stifle innovation because developers can’t build on them.

6 of 67

You will know these terms by then end of this talk!

SNOMED-CT

ICD-10

dm+d

IHE

HL7

CDA

Read Codes

openAPIs

FHIR

openEHR

NHS Digital

ITK

Integration Engines

SMART

LOINC

Document

Data Models

HealthKit

Terminology

PRSB

Message

InterOPEN

XML / JSON

7 of 67

Discharge Summary

Jane, 60F, 5 day admission with Streptococcal pneumonia and has been newly diagnosed with Atrial Fibrillation

Started on Aspirin lifelong

Had a reaction to Amoxicillin -> Throat Swelling

8 of 67

At the GP System

Create a new diagnosis of Atrial Fibrillation

Create a new diagnosis of Streptococcal Pneumonia

Add Aspirin as a new medication

Add Amoxicillin as a new allergy

9 of 67

Two component parts

Transport Layer

from Hospital A -> GP B

The Content/ Payload

Document

I’m a Document. I belong to Patient C. �Type: Discharge summary

Content

Freetext
PDFs/ Images
Coded Elements (Diagnosis/ Medications/ Investigations)

Postal Service

The Discharge Letter

10 of 67

Two component parts

Transport Layer

from Hospital A -> GP B

The Content/ Payload

Header

I’m a Document. I belong to Patient C. �Type: Discharge summary

Content

Freetext
PDFs/ Images
Coded Elements (Diagnosis/ Medications/ Investigations)

11 of 67

The Standards

Transport Layer

from Hospital A -> GP B

The Content/ Payload

Header

I’m a Document. I belong to Patient C. �Type: Discharge summary

Content

Freetext
PDFs/ Images
Coded Elements (Diagnosis/ Medications/ Investigations)

DTS / MESH

HL7v3 CDA

HL7 FHIR

Document

12 of 67

At the GP System

Create a new diagnosis of Atrial Fibrillation

Create a new diagnosis of Pneumonia

Add Aspirin as a new medication

Add Amoxicillin as a new allergy

13 of 67

Terminology

Formal description of general truths of a domain, e.g. relationships of diseases, biomedical entities in the patient

Using SNOMED-CT

Amoxicillin is a drug and and is in the family of penicillins
Streptococcal Pneumonia is a bacterial pneumonia that is an infectious process that affects the lung

For this we need Terminology. It is a formal description of general truths of a domain. You can think of this like a dictionary. To ensure that both systems are referring to the same thing, you need to ensure that they are both using the same terminology. ICD-10, SNOMED-CT are examples of terminology systems. Indeed these terminology systems go beyond just being a simple dictionary. So if your GP system understands SNOMED-CT and received the Amoxicillin with it’s associated SNOMED-CT code, the GP system will ‘know’ that Amoxicillin is a drug and that it is in the family of penicillins. Similarly, it will know that Streptococcal Pneumonia is an infectious process caused by a bacterial that affects the lung.

This is why the NHS is so keen on all organisations standardising on SNOMED-CT.

14 of 67

MYTH

If the whole NHS uses SNOMED-CT we would achieve semantic interoperability

‘the ability of computer systems to exchange data with unambiguous, shared meaning’ - wikipedia

15 of 67

Data Model

Data/ Information model - Knowledge gathering activity, where the ‘knowledge’ is about individuals (patients, patient events etc in the medical domain).

Allergy/ Adverse Reaction
Problem/ Diagnosis
Discharge Summary

16 of 67

Adverse Reaction (GP2GP)

This is the data model of an adverse reaction that was created to support the transfer of adverse reaction events between the main GP system suppliers. You might have heard of this. It is called the GP2GP service.

If you show this to a room of clinicians they might agree or disagree with elements of it. They may want to add elements to it, for example they might want to add a time of exposure and a time to the reaction so that you can calculate the interval between exposure and reaction. If then I then try to transmit this additional piece of information into a system where this concept does not exist, there is simply no place to put it! You can’t simply ram information into a system that has no place to put it.

You can already see how easily incompatible data models can lead to the inability to transfer data in an unambiguous way.

For me it helps to think of a data model as a digital representation of reality. There can be many ways to represent the ‘same’ reality, and you may choose to represent it differently depending on the use case.

17 of 67

Who should develop �Data Models?

So in the case of electronic healthcare systems it is the clinicians that should be defining that data models. For example, it should be the cardiothoracic surgeon that should be defining that data model on how to represent what happened in a coronary artery bypass graft surgery.

Most of the frustrations around IT systems tend to evolve around user interface and data modelling issues. When you buy a system these are the items that you can seldom change or that you have little chance of influencing. So I would suggest when you next evaluate a vendor for any clinical information system, you need to ask them to show you their data models, and ask how you go about requesting changes to the model that serve the needs of your area.

Remember, a data model is a digital representation of reality for the computer. You really need to make sure that your reality and your computers are aligned! Or indeed if that system’s view of the world is the same as the wider NHS!

18 of 67

Terminology Binding

Amoxicillin

(SNOMED Description Id : 1211211013)

19 of 67

SNOMED-CT vs ICD-10

SNOMED-CT describes

Focus on clinical use

ICD-10 classifies

Focus on reporting / statistics

20 of 67

Semantic Interoperability = Terminology + Model

Terminology

�SNOMED-CT

ICD-10

LOINC�DM+D

Open Information Models

�HL7 - RIM

HL7 - FHIR

openEHR International CKM

CIMI

+

I hope that this illustrates that terminology alone is not sufficient for unambiguous data exchange between computer systems. Here I list some examples of terminologies that you may be familiar with. I’ve also listed 4 open information models that are used in the healthcare domain. HL7 themselves have produced the HL7 RIM and is currently developing the data models for FHIR, their next generation standard that I will be returning to later. The openEHR foundation also publishes their data models openly.

Note that every enterprise level clinical system will have some form of data model (ie. companies like EPIC/ Cerner/ Intersystems/ Orion Health).

However, they will differ widely in their quality, complexity, versatility and their willingness to expose them to the wider community for peer review.

21 of 67

Semantic Failure

Information Model

Bespoke� Proprietary

Information Model

HL7v3 - RIM

Information Model

Bespoke� Proprietary

Hospital A

HL7 - CDA�(encoded in XML)

GP System

Terminology

ICD-10

Terminology

SNOMED-CT

Terminology

READ Code

22 of 67

Semantic Failure

Hospital A

HL7 - CDA�(encoded in XML)

GP System

Terminology

ICD-10

Information Model

Bespoke� Proprietary

Terminology

SNOMED-CT

Terminology

READ Code

Information Model

HL7v3 - RIM

Information Model

Bespoke� Proprietary

Transform�Loss of Meaning

Integration Engine

23 of 67

Semantic Failure

Hospital A

HL7 - CDA�(encoded in XML)

GP System

Terminology

SNOMED-CT

Information Model

Bespoke� Proprietary

Terminology

SNOMED-CT

Terminology

SNOMED-CT

Information Model

HL7v3 - RIM

Information Model

Bespoke� Proprietary

Transform�Loss of Meaning

Integration Engine

Still different models

24 of 67

Semantic Failure

Information Model

Bespoke� Proprietary

Information Model

HL7v3 - RIM

Information Model

Bespoke� Proprietary

Transform�Loss of Meaning

Very difficult to understand/ implement

Hospital A

HL7 - CDA�(encoded in XML)

GP System

Terminology

ICD-10

Terminology

SNOMED-CT

Terminology

READ Code

25 of 67

Bringing HL7 standards into the connect world..

26 of 67

CDA Levels

1	BLOB�This can be Freetext/ PDF document/ any XML/ or anything
2	Defines Various Sections and their order�For eg PRSB Headings. You can only put freetext in the sections.
3	The sections can only have Datatypes as defined by the HL7 Reference Information Model (RIM)

Thankfully, the HL7-CDA document standard does allow you to still use it to pass documents around without using HL7-RIM. They have defined 3 levels of compliance. Level 3 is what have described in the previous slides; structured data using HL7-RIM. In Level 1, you can put whatever you like in the CDA with few restrictions. This can be freetext, PDF or even a data-rich document with structured clinical data not based on the HL7-RIM model. In Level 2 you can define simple section templates/ heading such as the AoMRC headings.

However this does not contain structured data.

So with the AoMRC headings at CDA Level 2, your the computer can help the user find and see ‘Family History’ or ‘Active Medications’ section, but the text is not coded thus not machine processable. Hence the AoMRC Headings will help with human readability and document organisation. However it does not bring with it semantic interoperability. So no medicines reconciliation or automatic updates of problem lists.

But it is definitely a positive step forward from where we are today.

27 of 67

Document vs Message

Document

Archival (always stored)

Self-contained

(Discharge Letter, Referral Letter)

Message

To support a process

(new lab result, patient transferred from A+E -> Ward 6)

Triggers/ Responses

Messages can contain a document!

(new cancer referral with referral letter)

http://www.ringholm.de/docs/04200_en.htm

28 of 67

XML

Extensible Markup Language

JSON

JavaScript Object Notation

Courtesy of Matt Stibbs. InteropSummit 2017

29 of 67

30 of 67

JSON

XML

Courtesy of Matt Stibbs. InteropSummit 2017

31 of 67

Creation of Standards

E-Discharge Summary

32 of 67

https://theprsb.org/standards/edischargesummary/

33 of 67

Collision of two worlds

PRSB

Royal �Colleges

HL7

openEHR

NHS Digital

Vendors

Clinical

Technical

34 of 67

Collision of two worlds

As it stands the PRSB Headings have no technical artefacts that can be adhere to

Nightmare for Vendors

Difficult to measure compliance

SNOMED-CT mandation

But no Data Models?

35 of 67

INTEROPen

AoMRC

Royal �Colleges

HL7

openEHR

NHS Digital

Vendors

Clinical

Technical

36 of 67

37 of 67

How does the process work?

Review the International FHIR data model - for e.g. Allergy / Patient

Identify Gaps and things that are not needed

Called Extending

Then define UK specific values

Called Constraining

38 of 67

Profiling Patient Data Model

FHIR International	Extend / Remove	Constrain
First Name	First Name
Surname	Surname
Date of Birth	Date of Birth
Social security number	Social security number
	NHS Number	10 digits only

39 of 67

https://developer.nhs.uk/apis/itk3tocedischarge-2-6-0/index.html

40 of 67

Not easy for the vendors

41 of 67

So far?

42 of 67

APIs

Application-Programming Interface

43 of 67

APIs

Provides a way for one piece of software to request the service of another piece of software

Internally or halfway across the world!

APIs run the internet

GoogleMAPs API - Show the location of my shop on the internet within my webpage
Sign-in to this website using Google/ Twitter
Twitter API - Create a new tweet from any webpage

44 of 67

Healthcare Examples

Here is my NHS number. Please give me a list of my medication.
Am I eligible for any trials?�Here is my age, list of diagnosis, blood results and medication list
Here is a list of drugs, are they any interactions?
Give me a list of this my height and weight so that I can plot on my growth chart app
Hospital system puts a reminder into a GP system so say that the patient needs a review in 4 weeks?

Here are a few healthcare examples of what APIs can do. A program can say ‘Give me a list of this patient’s medication’, It can ask another piece of software the question, ‘is the patient eligible for any clinical trials?’, ‘submit a list of drug to a drug interaction service and have that service return a list of interactions’ or even pass a list of a patient’s height and weight to another program so that it can be plotted on a growth chart.

You can begin to see how powerful APIs can be. It allows an organisation or indeed an individual to choose the best pieces of software to perform an individual task particularly well. APIs can free and add value to the data from the underlying system that holds it. It can also expose the functionality of a particular piece of software to another. For eg. it can allow a hospital system to put a reminder in a GP system to make a follow up appointment if the GP system has an API to allow this function.

45 of 67

Fast Healthcare Interoperability Resources

Brings HL7 into the web world
Focus on modern web standards/ frameworks
Usable and easily implementable

Unlike HL7v3 RIM

It has got a lot of people very excited!

Like ALOT!!!

46 of 67

A

B

C

D

E

Growth �Chart App

A

B

C

D

E

Systems

5 APIs

5 Interfaces

47 of 67

A

B

C

D

E

Growth �Chart App

C

Systems

1 API

1 �Interface

48 of 67

Reusable and substitutable, open web applications
Originally a project funded by the Office of the National Coordinator for Health Information Technology (ONC) - US
The SMART API

49 of 67

50 of 67

51 of 67

Reusable and substitutable, open web applications
The SMART API FHIR API

52 of 67

53 of 67

54 of 67

What are openAPIs

Allows external developers to gain access to the data and functionality (services) within the program.
Specification is freely available
Documentation is freely available
There is no licensing cost
Process to gain access must be transparent

So APIs are great but we are not going to have this brand new world of reusable, modular apps unless people can actually gain access to APIs. This is what openAPIs, also called Public APIs are. The key here is that an openAPI allows external developers to gain access to the underlying data and function of a system. To be open, the specification and documentation of how to use the APIs must be freely available and they should also not be any licensing cost to use the APIs. Furthermore, the process of gaining access to the API must be transparent.

For example, if your organisation wanted to build a mobile app for HCAs to collect blood pressure readings that need to go straight into your current EPR, your organisation could get anyone to build that app if your underlying EPR have openAPIs. If they were closed, only the vendor of your EPR is allowed to build it. They can then take as long as they like and charge you whatever they like. Some of you will recognise this as vendor lock-in. Many people have great hope that openAPIs will reduce this phenomena.

55 of 67

Interoperability of Clinical Data is not enough

WHO

People - Patient / Carer / Organisation

NHS Number

Consent

Authentication

PROCESS

Pathways/ Functions/ Prescription

56 of 67

What is Interoperability anyway??

What is Interoperability anyway?

57 of 67

The tech giants are all at it...

58 of 67

The Single Source of Truth

Integrated Digital Care Records�The Single Source of Truth?

Summary Care Record, Detailed Care Record

Solving semantic interoperability will allow unambiguous transfer of meaning BUT it will never solve disagreements and differing points of view

59 of 67

http://gmahsn.github.io/gm-referral-chord/

60 of 67

Diagnosis

Type II Diabetes

Primary Hypertension

Osteoarthritis

Medications

Bendroflumetazide

Atenolol

Proglitazone

Simvastatin

Allergies

Nuts

Penicillin

Diagnosis

Type II Diabetes

Whitecoat Hypertension

Seronegative Athritis

Medications

Bendroflumetazide

Bisoprolol

Metformin

Pravastatin

Allergies

Penicillin

Diagnosis

Type II Diabetes

Osteoarthritis

Medications

Paracetamol

Allergies

Not recorded

GP

Rheumatology

Orthopaedics

61 of 67

Curation and Summarising

Clinical summarization can be defined as the act of collecting, distilling, and synthesizing patient information for the purpose of facilitating any of a wide range of clinical tasks.

Feblowitz, Joshua C., Adam Wright, Hardeep Singh, Lipika Samal, and Dean F. Sittig. 2011. “Summarization of Clinical Information: A Conceptual Model.” Journal of Biomedical Informatics 44 (4): 688–99. doi:10.1016/j.jbi.2011.03.008.

62 of 67

InteropSummit 2017

http://www.interopen.org/interopsummit2017

63 of 67

Conclusion 1/3

Unambiguous clinical meaning requires terminology and data models

Clinicians are the knowledge domain experts and must be involved in creating data models.

Translation between different data models and terminology can lead to loss of meaning and or just be plain impossible!

Standardising just on terminology is not enough

64 of 67

Conclusion 2/3

FHIR is an exciting new standard from HL7

NHS has selected this standard to support interoperability in the NHS
Still need ‘profiling’ in for use in the UK. Called ‘Curation’

Making a system compliant can be challening (esp more established systems)

65 of 67

Conclusion 3/3

openAPIs (perhaps based on FHIR) have to potential to lead to a very different Health IT marketplace

Decreased vendor lock-in
Increased opportunity for SMEs to develop apps and services

There is no such thing as the single source of truth - failure to recognise this leads of failed systems and poor benefits realisation

66 of 67

A note from father

1 of 67

2 of 67

3 of 67

4 of 67

5 of 67

6 of 67

7 of 67

8 of 67

9 of 67

10 of 67

11 of 67

12 of 67

13 of 67

14 of 67

15 of 67

16 of 67

17 of 67

18 of 67

19 of 67

20 of 67

21 of 67

22 of 67

23 of 67

24 of 67

25 of 67

26 of 67

27 of 67

28 of 67

29 of 67

30 of 67

31 of 67

32 of 67

33 of 67

34 of 67

35 of 67

36 of 67

37 of 67

38 of 67

39 of 67

40 of 67

41 of 67

42 of 67

43 of 67

44 of 67

45 of 67

46 of 67

47 of 67

48 of 67

49 of 67

50 of 67

51 of 67

52 of 67

53 of 67

54 of 67

55 of 67

56 of 67

57 of 67

58 of 67

59 of 67

60 of 67

61 of 67

62 of 67

63 of 67

64 of 67

65 of 67

66 of 67

67 of 67