Architectural Approaches for Exchanging Information 29-Oct 2014 Informa
Jan 26, 2015
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