grahame grieve - health intersections - architectural approaches for exchanging information

Architectural Approaches for Exchanging Information

29-Oct 2014

Informa

Architecture

• Design: Making choices to create structures that solve problems

• Exchanging Information

– Getting it from one place to another

– Doing something useful with it

Three Laws of Interoperability

1. Interoperability: It’s all about the people

All about the people

• Technical communication is easy

• To make it useful, people have to agree on what they are communicating

• You need the right kind of people

Political Technical

Three Laws of Interoperability

1. Interoperability: It’s all about the people

2. You can hide the complexity, or make it worse, but you can’t make it go away

Sources of Complexity

• Inherent in problem & description

• business variability between instances

• incompetence / inappropriate solutions

Three Laws of Interoperability

1. Interoperability: It’s all about the people

2. You can hide the complexity, or make it worse, but you can’t make it go away

3. Trilemma: Cheap, flexible, and interoperable: you can have two of these

Interoperability

• Drive-by Interoperability

– Vendors with antagonistic relationships

– Highly variable business arrangements

– ‘Worst case interoperability’

• National Program Interoperability

– Large contracts with efficiency of scale

– Standardised business practices imposed on variable architecture

6 Requirements

Transmission of Data A transmission channel between the two, so they can exchange symbols of meaning (usually this is bidirectional, but not always)

Common Terminology A common set of terms (words) with meanings that both parties understand

Identification Policies Some way to identify instances of things that are being talked about

Information Structures A common method to assemble the terms / words into a coherent larger structure

Behavioral Models A conversation protocol (who says what when, and then what happens next – this also needs to be aligned with consequences beyond the conversation)

Common Understanding A common understanding of the context in which the discussion is taking place

Element Person Computer

Transmission

Of Data

Voice; phone; email Files, TCP/IP, HTTP, XML

Common

Terminology

Oxford Dictionary Controlled Vocabularies

(ISO/IETF standards)

Identification

Policies

Names, Telephone

Book

DNS system, OIDs

Information

Structures

English Language HTML, WSDL, vCard

Behavioral

Model

Hello / Goodbye HTTP, SMTP, WS-*

Common

Understanding

Education,

professional

societies

Provided by the

programmers

#1: Transmission of Data

• Used to be hard

• TCP/IP rules the world

• Moving bytes from here to there is easy

• Interpreting them is hard

#2: Common Terminology

• Have to agree about the basic words

• Dictionaries, Terminologies, Vocabularies, Code Systems, Classifications, Ontologies, Semantic Webs– Blind leading the blind

– SNOMED, LOINC, ICD-X, ICPC, AMT…

• Recommended Reading:– ISO 704 http://www.iso.org/iso/catalogue_detail.htm?csnumber=38109

– Cimino’s Desiderata http://courses.mbl.edu/mi/2009/pubs/cimino_desiderata.pdf

#3: Identification Policies

• Need to able to identify instances of things, as well as types of things

• Humans and Human derived processes are not intrinsically identified

– Clerical error rate ~2%

– Biometrics are close, but problematic

– Need to identify your bits too…

#3: Identification Policies

• Need to able to identify instances of things, as well as types of things

• Humans and Human derived processes are not intrinsically identified

– Biometrics are close, but problematic

– Need to identify your bits too…

– Clerical error rate ~2%

#4 Information Structures

• Data Elements and Grammar

• ISO 11179- a good framework for thinking about data elements

• Data elements never exist in a vacuum – they influence each other

• Structures = a grammar for data elements

• Many forms – UML, schema, tables etc

#5: Behavioural Agreement

• What exchanges happen, what data moves, what obligations to they have?

• Behavioural Framework:– a set of known systems and exchanges– how these relate to transaction scopes– information structures for each exchange– how these relate to the business processes and what

business requirements there are– what kind of consequences/responses follow the

exchange– how exchanges and how errors are handled

#6: Common Understanding

• Shared culture, education

• Things taken for granted

• The more we innately agree about, the easier it is to exchange meaning

• Corrollary: the less people agree about things, the more exchanging meaning costs

Split Level Modelling

• “Reference Model” – basic structures that everyone shares in common– Engineering (cross-industry)

• “Profiles” – constraint/mapping models that describes how the base structures are actually used– Mostly arises in healthcare (or in ISO 11179)

• OpenEHR / HL7 v2 / CDA / FHIR / Snomed CT

• A major source of complexity

Handling Extensibility

• Local extensions are a huge problem

• Existing HL7 specs:– Z-segments in v2

• What does this mean?– ZSB|20080117|Q^57|4.30^uL

– Foreign namespaces in CDA/V3• Break schemas

• In most areas of healthcare standards, there is wide variability– Between systems, countries, institutions, clinicians

23

Handling Extensibility

• Specification only supports “core” no one can use it

• Specification adds everything no one understands it

• Specification picks winners only they can use it

• Allow any extensions Implementers can’t manage this

• Allow controlled, self–describing extensions that people can use Share the burden equally

24

Paradigms

• HL7 recognises 4 interoperability paradigms

25

REST Documents

Messages Services

Documents

• E.g. CDA

• Collection of information bound together

– Fixed content

– Human selected

– Known clinical context

– Can be signed, authenticated, etc.

• Many options for transport

26

Documents

Messages

• E.g. HL7 v2

• Fixed content with known event code

• Exchanged via network or file

• Request/response behavior with mappings to real world events

– E.g. Send lab order, get back result

• Applications have ‘obligations’

27

Messages

Service Oriented Architecture (SOA)

• Describe and provide “services”

– Network end points that provide functionality

– Simple complex workflows

– Use SOAP / ESB

• E.g. Shared OMG/HSSP specifications

28

Services

REST

• A special kind of service

• Fixed operationsCreate, Read, Update, Delete

• Bound to HTTP

• Industry Standard PracticeFacebook, Twitter, Google, etc

29

REST

Paradigms

• Regardless of paradigm the problem is the same

– get some agreed content

– to the right place

– at the right time

• Messages / Services / Documents differ:

– In the content model

– What is decided in advance, and what is delegated to implementation (or user)

– Which problems they solve best

30

HL7 v2

Common Messaging standard in Australia

• Simple syntax

• East to Understand

• Widely adopted

• Much experience

• Backwards comp.preserves investment

• Old technology

• Poor format

• Very Limited Scope

• Backwards comp. limits new ideas

• Local agreement

• If you’ve seen one v2 interface…

Strengths of v2

• Widely understood / High market penetration

• Flexible adaption to local requirements

• Cheap to roll out once implemented

• Not too hard to implement (standard is not too deep)

• Underlying notions of v2 definitions have very high penetration

Weaknesses of V2

• Only good for integration at the perimeter

– Shallow, short-sighted

• While you can vary for local institution, you generally have to, even when it's not useful

– Inconsistent, incoherent, incomplete definitions

– Different cultures and integration communities

– No good way to build complex structures

• Cannot scale for Enterprises or Government

Experience with HL7 v2

• Everyone can implement it

• It’s very hard to implement well

• Highly Variable between instances– If you’ve seen one v2 implementation,

you’ve seen one v2 implementation

– If you’ve seen one set of interface requirements, you’ve seen one set of interface requirements

Clinical Document Architecture (CDA)

A clinical document ….

• Contains clinical content

• Used for communication & record-keeping

• A document that a human can read

• Includes data that a computer can understand

• Authored by a human, with machine assistance

• Fits into a clinical workflow

Clinical workflow: Trust

• Attestation

• Known Authorship

• Persistence (but not storage)

• Stewardship

• Own context

• Can be authenticated

• Not to be divided (wholeness) or changed

Messages / REST API

• Exchanges between systems are mini-transactions that occur in the context of a greater patient record

• The record has a consistent architecture – at least partially distributed

• Systems must deliver comparative, transactional and longitudinal coherency

• Who is responsible?

Documents

• Exchanges between systems are self contained missives that stand on their own

• The collection of documents may have an architecture – or not.

• Systems can’t really ensure comparative, transactional and longitudinal coherency

• The author is responsible

Question: What are the medications?

• The pcEHR is a collection of snapshot documents

• All from different systems that code the medications differently

– Australian Medications Terminology slow to catch on

• All from different clinicians who have a different perspective on the medications

Record based approach

• There is a consolidated list

• Transactions maintain it

• Each human becomes responsible for it

• Clinical Practice has to change

Documents vs Records

• Choosing a document strategy commits you to having a low coherence patient record.

• Choosing a record strategy commits you to achieving a high-coherence patient record.

• Which is safe?

Towards a new healthcare

• Atul Guwande: a new kind of medicine

– http://www.newyorker.com/magazine/2012/08/13/big-med

– http://hbr.org/web/2010/04/gawande

• These changes need meaningful IT support so they can happen and be beneficial