Interoperability, SNOMED, HL7 and FHIR

Principles of Interoperability: Tutorial
Tim Benson
tim.benson@r-outcomes.com
Informatics for Health Conference, Manchester
23 April 2017

Sources
• This tutorial is based
substantially on:
– Benson T, Grieve G.
“Principles of Health
Interoperability SNOMED CT
HL7 and FHIR” 3rd Edition,
Springer, 2016
5/2/20172

Tutorial Outline
1. Core concepts
2. Terminology Standards
– LOINC and SNOMED CT
3. Messaging Standards
– HL7 V2 and V3
4. Clinical Document Standards
– CDA and XDS
5. FHIR
5/2/20173

Approach
• Limited time, vast scope
• How and why these were developed
• Their complementary roles
• Why each is important
5/2/20174

PART 1 CORE CONCEPTS:
WHY INTEROPERABILITY IS HARD
5/2/20175

Interoperability Definition
• Interoperability is the ability of two or more systems or
components to exchange information and to use the
information that has been exchanged
– IEEE 1990
5/2/20176

Types of interoperability
1. Technical
2. Semantic
3. Process
4. Clinical
5/2/20177

1. Technical Interoperability
• Move data from A to B
• Domain-independent
• Based on information theory
• Now commodity
5/2/20178

2. Semantic Interoperability
• A and B understand data in the same way
• Domain specific
• What health interoperability standards focus on
• Needs codes and identifiers
5/2/20179

3. Process Interoperability
• Business systems at A and B interoperate
• Business process-specific
• Requires re-engineering and staff training
• Generates all of the benefit
5/2/201710

4. Clinical Interoperability
• The ability for 2 or more clinicians in different care teams to
transfer patients and provide seamless care to the patient.

Layers of Interoperability
1. Technology
2. Data
3. Human
4. Institutional

Standards Definition
• A standard is a document, established by consensus and
approved by a recognised body, that provides, for common and
repeated use, rules, guidelines, or characteristics for activities
or their results, aimed at the optimum degree of order in a
given context
– ISO 2004
5/2/201714

Consensus
• General agreement, characterized by the absence of sustained
opposition to substantial issues by any important part of the
concerned interests and by a process that involves seeking to
take into account the views of all parties concerned and to
reconcile any conflicting arguments. Consensus need not imply
unanimity.
– ISO 2004
5/2/201715

Recognised body
• Internationally recognised standards development organization
(SDO)
• ISO
– Regional SDOs
• CEN
– National SDOs
• BSI
• ANSI
– Affiliates (e,g, HL7)
5/2/201716

Health Informatics SDOs
• ISO TC215
• CEN TC251
• HL7
• SNOMED International (fka IHTSDO)
• CDISC
• DICOM
• ASTM
• GS1
5/2/201717

Industry Consortia
• IHE
– Integrating the Health Enterprise
• Continua Alliance
• COCIR
• Open Health Tools
• OpenEHR
5/2/201718

User Benefits
• Right information
• Right place
• Right time
• Right person
• Safe, efficient and effective care
5/2/201719

Efficiency
!
5/2/201720
Number of links = (N2-N)/2

Messaging Standards
• Types of Communication
• HL7 V2
• HL7 V3
• FHIR APIs
5/2/201721

Types of Communication
1. Within workgroup
2. Between departments
3. Between providers
4. Provider to payer
• Listed in increasing use of computers and decreasing order of
value to patients
5/2/201722

1. Within workgroup
• Scheduling
– Appointments
• EHR
– Problems
– Medication
– History and physical
– Procedures
• Medical devices
– Vital signs
5/2/201723

2. Between departments
• Orders/ Labs
– CPOE (Computer-based Physician Order Entry)
– Reports
• Medication
– Prescribe
– Dispense
– Administer
• Finance
5/2/201724

3. Between Providers
• Referral
• Discharge summary
• PMR
– GP2GP (Exchange of complete medical records between primary care
providers using different systems)
5/2/201725

4. Provider to payer
• Invoices
• Authorization
• Accountability
– Statistical returns
• Managed care
5/2/201726

Why interoperability is hard
• Translation
– A to HL7; HL7 to B
• Bit-perfect
– Computers are digital 
• User language
– Each specialty has its own context-specific dialect
• Developer language
• Each vendor has its own computer-specific dialect
5/2/201728

It takes a long time
5/2/201730

PART 2 CLINICAL TERMINOLOGY
5/2/201731

Clinical Terminology
• The issue
• LOINC
• SNOMED CT

Humpty Dumpty
• 'I don't know what you mean by "glory",' Alice said.
• Humpty Dumpty smiled contemptuously. 'Of course you
don't—till I tell you. I meant "there's a nice knock-down
argument for you!"'
• 'But "glory" doesn't mean "a nice knock-down argument",'
Alice objected.
• 'When I use a word,' Humpty Dumpty said, in rather a
scornful tone, 'it means just what I choose it to mean—
neither more nor less.'
• 'The question is,' said Alice, 'whether you can make words
mean so many different things.'
• 'The question is,' said Humpty Dumpty, 'which is to be
master—that's all.'
33

Desiderata for clinical
terminology
7. Reject NEC
8. Multiple granularities
9. Multiple consistent views
10. Context representation
11. Evolve gracefully
12. Recognize redundancy
Source J Cimino 1997
34
1. Content completeness
2. Concept orientation
3. Concept permanence
4. Meaningless identifiers
5. Polyhierarchy
6. Formal definitions
An excellent set of requirements, which was influential in the design of SNOMED CT

Exploding Bicycle Accidents
Source: Rector and Rogers (7 x 4 x 4 x 4 =448)
35
Structured Data Entry
File Edit Help
What you hit
Your Role
Activity
Location
Cycling Accident

LOINC Scope
• Clinical Laboratory Tests
– The test not the result
• Clinical observables
– “Eye color”, not “Blue eyes”
• Form headings
• Document types
• Assessment scales

Origins of LOINC
• Designed for use in interoperability
• Clem McDonald
– ASTM 1238 (1988)
– Standard Specification for Transferring Clinical Laboratory Data Between Independent
Computer Systems
– HL7 V2.0 OBX Segment
• EU EUCLIDES and OpenLabs projects

HL7 v2 OBX segment
• Turn-round document
• Observable
– Code
• Value
– Code
– Physical quantity

LOINC Codes
• LOINC Code
– Consecutive number + Check digit
– e.g. 12345-9
• Short convenient name
• Long common name
• Pre-coordinated to common concept model
• Six dimensions
– slightly different from EUCLIDES

LOINC Dimensions
• Component
– what is being measured
• Property
– kind of property measured
• Timing
– point in time or period
• System
– sample or body part
• Scale
– nominal, ordinal, interval or ratio
• Method
– procedure used to produce the result or other observation

Problems of LOINC
• Complex
• Many similar codes with only small differences
– mass concentration v molecular concentration
– anatomical position of pulse or BP
• Dimensions are not hierarchical so limits subsumption testing

Good aspects of LOINC
• Free
• Does what it claims to do (but no more)
• Fit for purpose
• Easy and quick to add new codes

Timeline
43
SNOP
SNOMED 2
SNOMED RT
SNOMED CT
Read 4 byte
READ 2
READ 3 (CTV3)
1970
1980
1990
2000
SNOMED 3

Origins of SNOMED CT (1)
• SNOMED
– CAP committee 1955
– SNOP 1965
• topography, morphology, etiology, function (physiology)
– SNOMED 1975
– SNOMED III 1993
– SNOMED RT (Reference Terminology) 1997

Origins of SNOMED CT (2)
• Read Codes (UK)
– Coded terms in EHR e.g. “Blue Eyes”
– Developed 1983-1986
• by James Read and Tim Benson for use in GP EHR
– Purchased by DH in 1990
– Version 3 (CTV3) 1992-96
• Used by all GPs in UK (100%) and NZ
– Basis of payment
– Unsuccessful in any other specialty

Read Code (v1,2) Chapters
• Diagnoses
– ICD Chapters A-Z
• Medication
– BNF Chapters a-z
• History and physical
– Occupations (0), history and symptoms (1), physical examination findings (2)
• Procedures
– Diagnostic (3), lab (4), imaging (5), prevention (6), therapy (7), surgery (8), admin
(9)

SNOMED CT
• Merger of Read Codes and SNOMED RT
• Reference Terminology
– Defined by reference to other concepts
– All concepts are in hierarchies (19)
• Concepts
• Descriptions (terms)
• Relationships
– Defining, qualifying, sub-type, association
• Description Logic

SNOMED RT
CTV3
Both
New
Source of Concepts in SNOMED CT
48

Reference Terminology Example
49
Appendix
Excision
Laparoscopic excision
Laparoscopic
procedure on
appendix Appendicectomy
Using laparoscope
Laparoscopic appendicectomy

Concepts
• A concept is a clinical idea
• Each concept has a unique identifier
– SCTID
• Each concept is in a hierarchy
– 19 hierarchies
• Concepts can have more than one parent
• Concepts are defined by reference to others
5/2/201750

SNOMED CT Hierarchies
• Object hierarchies
– clinical finding
– procedure
– observable
– event
– situation
– staging or scale
– specimen
• Value hierarchies
– body structure
– organism
– substance
– pharma product
– physical object
– physical force
– social context
– environment / location
5/2/201751

Description
• Human readable term
• Fully-specified term
• Preferred term
• Synonym
– Dialect
5/2/201752

Relationship
• Description logic
– “concept: attribute = value”
• Defining
– fully defined or primitive
• Qualifying
– SNOMED concept model
– Post-coordination
• Historical and additional
5/2/201753

Refsets (subsets)
• Language
– e.g. UK English
• Realm
– e.g. UK general practice
• Navigation
– e.g. pick list of common problems
5/2/201754

Problems of SNOMED CT
• Legacy baggage
• Lack of transparency
– Lack of free access outside member countries
– Initial lack of good web-based tools
• Complexity
– Post-coordination is not a practical proposition
– Slow rate of adoption
• Undefined boundaries
– Over-sold as answer to all terminology problems

Benefits of SNOMED CT
• Future-proof structure
• Can be improved and made fit for purpose
• Inherently multi-lingual
• Broad coverage

The Education Problem
• Few people are competent in both LOINC and SNOMED
• Clinical terminology is not taught well
– One of 186 topics in AMIA Core Curriculum for Clinical Informatics (JAMIA, 2009)
• Formal training is essential
– 93% of all those who rated themselves as competent had had more than 3 days
formal training in SNOMED CT
• (n=177, Report for DH, 2011)

Need for blended education
• Learn by doing (assignments and examples)
• Face-to-face presentations
• Web-based presentations and videos
• User guides and books
• Pick it up from colleagues

LOINC + SNOMED CT together
• Joint collaboration
• All clinical statements comprise:
– Narrative text
– Context (who, when, where, etc)
– Observable
– Finding
• (Rector A. What’s in a code, MEDINFO 2007)

Observable
• “Observables” are qualities of patients that are present in all
patients
– and whose values or states are determined by observation
• This is what LOINC is designed to code and does it well

Finding
• Information specific to a particular patient
• Finding = Observable + Value
• Value may be various data types
– Physical quantity, code, date, text etc
• SNOMED CT is good for Observation Value Codes

Conclusions
• LOINC and SNOMED are complementary
• You need to understand know both
• Both are complex!

PART 3 HL7 V2 AND V3
SYNTAX FOR INTEROPERABILITY
5/2/201763

Messaging
• HL7 V2
• HL7 V3
5/2/201764

HL7 V2 History
• HL7 Founded 1987
– HL7 V2.0 1988
• Strong Influences
– ISO OSI 7-layer model
– ANSI X.12 and ISO EDIFACT
– Simborg ADT specifications
– Clem McDonald AST E.1238 Clinical Laboratory
• Backward compatibility
– Evolution by addition
5/2/201765

HL7 V2 Message Structure
• Message
• Segment
• Field
• Data Type
• Vocabulary
5/2/201766

V2 Message
• Message type
• Trigger event
• Abstract message syntax table
– Specifies segments
5/2/201767

V2 Segments
• Segment identifier
– 3 characters
– Z-segments are locally defined
• Abstract message syntax table
5/2/201768

Segment definition table
5/2/201769

V2 Segment definition table
• Field sequence
• Maximum length
• Optionality
• Repeatable
• Table reference
• Item reference
• Name
5/2/201770

V2 Field delimiters
5/2/201771

V2 Data types
• 89 data types
• Simple
– Date DT
– String ST
– Numeric NM
• Complex
– Codes and identifiers
– Names and addresses
5/2/201772

Code data type (CWE)
5/2/201773

Example lab report
• Header
– type, origin and date time of the message
• Single patient with
– ID number, name, sex, date of birth, address and GP identifier
• Specimen details
– laboratory accession number (ID), source, body site, time of collection and
requester
• Test results
– including the test name and result and abnormality flag.
5/2/201774

Example
• The abstract syntax:
– MSH Message header
– PID Patient Identification Details
– PV1 Patient Visit
– OBR Results header
– {OBX} Results detail (repeats)
• All segments are required.
5/2/201775

Example message structure
MSH|delimiters||sender|||dateTime||messageType|messageID|processingSta
tus|syntaxVersion
PID|||patientID^^^sourceÎDtype||familyName^givenName||dateOfBirth|sex
|||streetAddressâddressLine2^^^postCode
PV1|||patientLocation|||||patientsGP
OBR|||accessionNumber|testCode^testName^codeType|||specimenDate|||||||
|specimenSource^^^bodySite^siteModifier|requester
OBX||valueType|observableCodeôbservableName|observationSubID|valueCod
e^valueText^valueCodeType|||abnormalFlag
OBX ...
5/2/201776

Example message instance
MSH|^~&||^123457^Labs|||200808141530||ORU^R01|123456789|P|2.4
PID|||123456^^^SMH^PI||MOUSE^MICKEY||19620114|M|||14 Disney
Rd^Disneyland^^^MM1 9DL
PV1|||5N|||||G123456^DR SMITH
OBR|||54321|666777^CULTURE^LN|||20080802||||||||SW^^^FOOT^RT|C987654
OBX||CE|0^ORG|01|STAU||||||F
OBX||CE|500152^AMP|01||||R|||F
OBX||CE|500155^SXT|01||||S|||F
OBX||CE|500162^CIP|01||||S|||F
5/2/201777

Example message rendering
Report from: Lab123457, 15:30 14-Aug-2008, Ref 123456789
Patient: MICKEY MOUSE, DoB: 14-Jan-1962, M
Address: 14 Disney Rd, Disneyland, MM1 9DL
Specimen: Swab, FOOT, Right, Requested By: C987654,
Location: 5N
Patients GP: Dr Smith (G123456)
Organism: STAU
Susceptibility: AMP R
SXT S
CIP S
5/2/201778

Why V3?
• “When you have seen one implementation of V2, you have
seen one implementation; every one is different”
• Need for a stringent, model-based approach
• Work on V3 began in 1992.
5/2/201779

V3 RIM
• Reference Information Model
• The “grammar” for V3
– nouns, verbs etc
– structural attributes
5/2/201780

V3 RIM backbone
• Core classes
– Act
– Role
– Entity
• Associations
– ActRelationship
– Participation
– RoleLink
– Entity-Role
5/2/201781

V3 Act
• Something that has or may happen
• moodCode
• classCode
– Specializations
• Attributes
• Associations
– ActRelationship
– Participation
5/2/201783

V3 Act moodCode
• The tense of the Act
– Event (EVN)
– Proposal (PRP)
– Request (RQO)
– Promise (PRMS)
– Definition (DEF)
5/2/201784

V3 Act specializations
• Observation
– Request
– Finding
– Report
• PatientEncounter
– Book
– Encounter
• SubstanceAdministration
– Prescribe
– Dispense
– Administer
• Procedure
– Plan
– Perform
5/2/201785

V3 Act attributes
• id
• status
– State-machine
• active
• completed
• cancelled
• code
– external code scheme
• Observation.value
– Any data type
• Times
– effectiveTime
– activityTime
– availabilityTime
• priorityCode
• confidentialityCode
• languageCode
• negationInd
5/2/201786

V3 Act state-machine
5/2/201787

V3 ActRelationship
• Links acts together
• typeCode
– comprises
– documents
– fulfills
– refers to
– replaces
5/2/201788

V3 Participation
• Links Role to Act
• typeCode
– subject
– author
– performer
– location
– active ingredient
5/2/201789

V3 Entity
• Any living or non-living thing
• Living things
– person, animal, plant, organism
• Non-living
– manufactured item, chemical substance,
– physical place
– organisation
• Determiner code
– instance, quantified kind or kind
5/2/201790

V3 Entity attributes
• classCode
• determinerCode
• id, status, name, code, quantity, desc
• LivingSubject
– birthTime
– deceasedTime
– administrativeGenderCode
– multipleBirthOrderNumber
• Device
– manufacturerModelName
5/2/201791

V3 Entity-Role association
• Entity plays role
– person plays patient
– person plays practitioner
– chemical plays therapeutic agent
• Entity scopes role
– organisation scopes patient
– organisation scopes (makes) therapeutic agent
5/2/201792

V3 Role
• A competency of an Entity
• Associations
– Participation
– Entity scope and play
– RoleLink
5/2/201793

V3 Role
• Person
– Patient
– Practitioner
– Employee
• Place
– Hospital
– Home
– Clinic
• Item
– Therapeutic agent
– Instrument
– Computer system
• Organization
– Provider
– Payer
– Employer
– Supplier
• Responsibility
– Parent
– Employer
– Manufacturer
5/2/201794

V3 data types
• Basic data types
• Codes and identifiers
• Date/time
• Name and address
• Generic collections
5/2/201795

V3 Basic data types
• BL Boolean
• BIN Binary
• ST String
• ED Encapsulated data
• INT Integer
• REAL Real number
• PQ Physical quantity
• MO Money
5/2/201796

V3 Identifiers
• Registry identifier
– OID
– 2.16.840.1.113883
– iso.country.us.organization.hl7
– extensible structure
• Instance identifier
– UUID
– 128 bit
– 550e8400-e29b-41d4-a716-446655440000
5/2/201797

V3 Code data types
• CS simple code value (defined by HL7)
• CV code value, includes coding scheme identifier
• CE code with equivalents
– used with local and national codes
• CD concept descriptor allows qualifiers
5/2/201798

V3 CD example
• Compression fracture of neck of femur
<code code="71620000" codeSystem="2.16.840.1.113883.6.96"
displayName="fracture of femur">
<qualifier>
<name code="363698007" displayName="finding site"/>
<value code="29627003" displayName="structure of neck of femur"/>
</qualifier>
<qualifier>
<name code="116676008" displayName="associated morphology"/>
<value code="21947006" displayName="compression fracture"/>
</qualifier>
</code>
5/2/201799

V3 Date/Time
• TS Point in Time
• IVL <TS> Interval of Time
• PIVL Periodic interval of time
• EIVL Event-related periodic interval of time
• GTS General Timing Specification
• The time format based on ISO 8601
– (e.g. YYYYMMDDhhmmss).
5/2/2017100

V3 Name and address
• TN Trivial name (unstructured)
• ON Organisation name
• EN Entity name (any thing)
• PN Person name
– a sequence of name parts such as family name, given name(s), prefix and suffix, together with name use
(legal, maiden name, former name, alias)
• AD Postal Address
– a sequence of address parts, such as house, street, city, postal code, country and the address use (home,
temporary etc)
• TEL Telecommunication Address
– Universal Resource Locator (URL), which covers telephone numbers (voice, fax or mobile) e-mail addresses
and web pages.
5/2/2017101

V3 Generic Collections
• SET is an unordered collection of values without any repeats
• LIST is a sequence, containing values in a defined sequence (repeats not
allowed)
• BAG is an unordered collection of values, which are allowed to repeat
• IVL is a set of consecutive values of an ordered base type such as time
or physical quantity.
5/2/2017102

V3 Root attributes
• Optional attributes in all classes
– nullFlavour
– realmCode
– typeId
– templateId
5/2/2017103

Constrained Information Models (CIM)
• All uses of V3 are constraints on the V3 RIM
• Types of constrained model
– DMIM
– RMIM
– CMET
– HMD
– MT
– ITS
5/2/2017104

Constraint Types
• Omission
• Cloning
• Multiplicity
• Data type constraint
• Code binding
– CNE or CWE
5/2/2017105

Vocabulary and value sets
• Vocabulary is list of all possible codes
• Value set is set of codes permitted in a constrained model
• HL7 Vocabulary
– Hierarchical structure
• External Vocabularies
5/2/2017106

V3 Artifact naming
• Subsection
• Domain
• Type
• Numeric Id
• Realm
• Version
• Type
– Application Role
– DMIM
– HMD
– Interaction
– Message Type
– RMIM
– Storyboard
– Trigger event
5/2/2017107

V3 Dynamic Model
• Interaction
• Trigger event
• Application role
• Message Type
• Interaction sequence
• Message wrapper
• Acknowledgement
5/2/2017109

V3 Interaction
• One-way transfer
• Association of
• trigger event
• application roles
• message type
5/2/2017110

V3 Trigger event
• Interaction-based
• State-transition-based
• User request-based
5/2/2017111

Application Role
• Placer
• Fulfiller
• Confirmer
• Confirmation receiver
• Informer
• Tracker
5/2/2017112

Message wrapper
• Transmission wrapper
– unique ID
– creation date/time
– sender and receiver system IDs
• Trigger event control act wrapper
– previous interaction (trigger)
– asynchronous message
– query
5/2/2017113

Acknowledgement
• Accept acknowledgement
• Application acknowledgement
5/2/2017114

V3 ITS
• Implementation Technology Specification
• XML schemas
5/2/2017115

PART 4 CLINICAL DOCUMENTS
5/2/2017116

Clinical Documents
• Clinical Document Architecture (CDA)
• Continuity of Care
• IHE XDS
5/2/2017117

Document metaphor
• Wholeness
• Persistence
• Authentication
• Stewardship
• Human readability
5/2/2017118

Document properties
• What
• When
• Who (from, to, about)
• Where
• Why
5/2/2017119

CDA Releases and Levels
• Most widely used application of V3
– Single RMIM
• Release 1
– 2000
– Level 1 Document plus metadata
• Release 2
– 2005
– Level 2 Multiple documents plus metadata
– Level 3 Structured data
5/2/2017120

CDA Structure
• Header
– who, what, where, when and why
• Body
– Human readable
– XML Body
– Non-XML Body
• Entry
– Clinical statements
5/2/2017121

Constraining CDA
• CDA Templates
– Narrative
– Schematron assertion
– static model (RMIM)
• Multiple templates can apply to same part of a CDA document
• CDA Profile is set of templates that apply to a document type
5/2/2017122

Continuity of Care
• CCD
– CDA implementation of CCR
• CCR
– Developed by ASTM for patient summaries
• GP2GP
– Used in NHS to transfer life-long electronic medical records between
GPs using different systems
5/2/2017123

IHE XDS
• Integrating the Healthcare Enterprise (IHE)
• Cross Enterprise Document Sharing (XDS)
• XDS actors
– Document source
– Repository
– Registry
– Consumer
– Patient identity source
5/2/2017124

XDS Registry
• Contains metadata needed to find documents
– Patient ID
– Time of service
– Document class
– Type of event
– Facility type
• Based on OASIS ebXML Registry
– ISO 15000 parts 3 and 4
5/2/2017

XDS Repository
• Can be any number
• Stores document permanently
• Allows retrieval
• Registers documents
5/2/2017127

XDS Consumer
• Queries Registry
• Gets list of URLs
• Retrieves documents from repository
• Mainly for human readable documents
– CDA
– PDF
– Images
5/2/2017128

PART 5 FHIR
(WITH THANKS TO GRAHAME GRIEVE)
5/2/2017

FHIR
• Fast Healthcare Interoperability Resources
Pronounced “Fire”
• New kid on the block

The “FHIR” Acronym
• F – Fast (to design & to implement)
“Fast” is relative – no technology can make integration as fast as we’d like
• H – Health
• I – Interoperable
• R – Resources (Building blocks)

What is FHIR?
• A set of modular components called “Resources”
• Resources refer to each other using URLs
– Build a web to support healthcare process
• Exchange resources between systems
– Using a RESTful API (e.g. web approach)
– As a bundle of resources (messages, documents)

Genesis of FHIR
• There has been a need to share healthcare information
electronically for a long time
– HL7 v2 is over 25 years old
• Increasing pressure to broaden scope of sharing
– Across organizations, disciplines, even borders
– Mobile & cloud-based applications
– Faster – integration in days or weeks, not months or years

Genesis of FHIR
• HL7 undertook a “Fresh look”
– What would healthcare exchange look like if we started from scratch
using modern approaches?
• Web search for success markers led to RESTful based APIs
• Drafted a healthcare exchange API based on this approach

FHIR Development Progress
• July 2011 – Conception
• Aug/Sept 2012 – First Draft Ballot
• Sept 2012 – First Connectathon
• Aug/Sept 2013 – First DSTU ballot
DSTU = Draft Standard For Trial Use
• 2014 – DSTU 1
• 2016 – DSTU 2
• 2017 – DSTU 3

FHIR Manifesto
• Focus on Implementers
• Target support for common scenarios
• Leverage cross-industry web technologies
• Require human readability as base level of interoperability
• Make content freely available
• Support multiple paradigms & architectures
• Demonstrate best practice governance

Implementer Focus
• Specification is written for one target audience: implementers
– Rationale, modeling approaches, etc. kept elsewhere
• Multiple reference implementations from day 1
• Publicly available test servers
• Starter APIs published with spec
– C#, Java, Pascal, ObjectiveC – more to come
• Connectathons to verify specification approaches
• Instances you can read and understand
• Lots of validated examples
using HL7.Fhir.Instance.Model;
using HL7.Fhir.Instance.Parsers;
using HL7.Fhir.Instance.Support;
XmlReader xr = XmlReader.Create(
new StreamRead
IFhirReader r = new XmlFhirReader
// JsonTextReader jr = new JsonTe
// new StreamRead
// IFhirReader r = new JsonFhirRe
ErrorList errors = new ErrorList(
LabReport rep = (LabReport)Resour
Assert.IsTrue(errors.Count() == 0

Support “Common” Scenarios
• Focus on scenarios implementers ask for
• Inclusion of content in core specification is based on core
content rule
– “We only include data elements if we are confident that most normal
implementations using that resource will make use of the element”
– Other content in extensions (more on this later)
– Easy to say, governance challenge to achieve
• Resources are simple and easy to understand and use

Web technologies
• Instances shared using XML & JSON
• Collections represented using ATOM
– Same technology that gives you your daily news summary
– Out-of-the-box publish/subscribe
• Web calls work the same way they do for Facebook & Twitter
• Rely on HTTPS, OAuth, etc. for security functions

REST
• “Representational state transfer” – an
architecture for how to connect systems
• Outcomes
– Simple stable interfaces
– High Performance / Scalability
– Visible Process (e.g. can debug)
– Portability
– Reliability (resistance to failure)

Human Readable
• Clinical Documents have both narrative and data
• The data / narrative dynamic exists throughout the process
• In FHIR, every resource has a
human-readable expression
– Can be direct rendering or human entered

Freely available
• Unencumbered – free for use, no membership required
• http://hl7.org/fhir

FHIR & Cost of Integration
• These factors will drive down the cost of integration and interoperability
– Easier to Develop
– Easier to Troubleshoot
– Easier to Leverage in production
– More people to do the work (less expensive consultants)
• Competing approaches will have to match the cost, or disappear – effect
is already being felt

Future impact of FHIR
• Impact of FHIR on the market:
– Drive interoperability prices down
– Higher Expectations
– Increased spend on integration (N x 2!)
• Overall Market focus
– PHR on the web
– Healthcare repositories (MHD+)
– Device Data management
– Retooling existing connections (will happen slowly)

REST Operations
REST is based on CRUD(E):
• Create – create a new instance of data
• Read – get the content (state) of an instance
of data
• Update – change the content of an instance
of data
• Delete – remove the instance of data
• Execute – get the instance of data (?) to do
something for you

Resources
• “Resources” are:
– Small logically discrete units of exchange
– Defined behaviour and meaning
– Known identity / location
– Smallest unit of transaction
– “of interest” to healthcare
– V2: Sort of like Segments
– V3: Sort of like CMETs

What’s a Resource?
Examples
• Administrative
– Patient, Practitioner, Organization,
Location, Coverage, Invoice
• Clinical Concepts
– Allergy, Condition, Family History, Care
Plan
• Infrastructure
– Document, Message, Profile, Conformance
Non-examples
• Gender
– Too small
• Electronic Health Record
– Too big
• Blood Pressure
– Too specific
• Intervention
– Too broad
Goal: 100-150 total

Resource anatomy
• Resources have 3 parts
Defined
Structured
Data
Extensions
Narrative

It’s all about the resources . . .
Lab
Report
Related
Person
Patient
Practitioner
Location

FHIR Information
• FHIR:
http://hl7.org/fhir
• Development team wiki home:
http://wiki.hl7.org/index.php?title=FHIR
• Twitter:
https://twitter.com/search?q=%23FHIR
• Stack Overflow:
http://stackoverflow.com/questions/tagged/hl7-fhir

Thank you
tim.benson@r-outcomes.com

Interoperability, SNOMED, HL7 and FHIR

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Interoperability, SNOMED, HL7 and FHIR

Similar to Interoperability, SNOMED, HL7 and FHIR (20)

More from Tim Benson

More from Tim Benson (6)

Recently uploaded

Recently uploaded (20)

Interoperability, SNOMED, HL7 and FHIR