Introduction to FHIR - New Zealand Seminar, June 2014

HL7 FHIR What is it, and why should we care

David HayAlastair Kenworthy

Koray AtalagPeter Jordan

Page 2 • HL7 New Zealand

Welcome

• Purpose of Seminar• Agenda

– Around the room– Introduction to FHIR – Specialized Vignettes

• Models and FHIR• Terminology (SNOMED)• FHIR in New Zealand

– Lunch– Deep dive

• FHIR for Architects and Developers– Wrap up and next steps

• Looking forward to the HINZ conference


Around the room

• Quick intro– Who are you– What company do you represent (if any)– What’s your experience with FHIR so far– What do you want to get out of this seminar

• Half a minute (max) only!

Introduction to FHIR

Acknowledgements• Lloyd McKenzie• Ewout Kramer• Grahame Grieve

Agenda

• Background• Business Case• Resources, Profiles & Bundles• Paradigms

• REST• Documents• Messages

• The Specification

David HayChair HL7 New Zealand

Co-Chair FHIR Management GroupMember HISO

Product Strategist Orion healthwww.fhirblog.com


The acronym

• F – Fast (to design & to implement)– Relative – No technology can make integration as fast as we’d like

• H – Health– That’s why we’re here

• I – Interoperable– Ditto

• R – Resources– Building blocks – more on these to follow

5


Why Standards

• The Great Baltimore fire February 7th & 8th 1904

• Standards enable Interoperability– Power voltages– Internet– Cell phone

• In Health Interoperability, standards save money and time– Maximizing reuse


Paradigms of Interoperability

REST

DocumentsMessages

Services


Timeline: Where does FHIR fit?

1980 20001990 2010 2020

V21987

FreshLook2011

V3CDA2005

FHIRDSTU2014

Start V31995

10 years 3years


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


Business Case for FHIR

• Simple to understand• Developer friendly

– Familiar tooling– Familiar technologies – XML/JSON/Atom, HTTP, SSL, OAuth

• All paradigms• Many Architectures• Many Clients

– Thick client, browser, mobile, devices

• Already in use– HAPI Library– 70 Organizations, 20 Countries

• US (ONC, SMART), UK (referrals), NZ (Orion Health)

Results in faster, cheaper deployments that are more re-usable


Supporting an ecosystem

NHI RLS Éclair GP LWHC

Authentication & Auditing (eg RealMe) + Privacy

TrustedApp

Store


SMART

https://apps.fhir.me/

Resources


FHIR Overview

• Has concept of ‘resources’– E.g. Patient, Problem, Prescription, Allergy

• Each resource has a base structure of commonly used data– Build-in extensibility mechanism– Profiles for local specific requirements

• Specification built like a software product– Automatic generation of artifacts apart from static files– Massive improvement in quality

• Uses simple XML, and supports JSON• Each resource has specific validation schema

– Automatically generated from resource definition files

• Defines terminologies/code sets for specific elements– But can be altered in different domains

• All resources can be versioned• Developed in conjunction with community

– All work on the web and freely available - www.hl7.org/fhir– Lots of samples– “Connectathons” to test that interoperability really works – Test servers available on-line now

• Currently DSTU (Draft Standard for Trial Use), normative 2016

http://www.hl7.org/fhir


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

16


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

17100-150 total - ever


DSTU Resource List


ResourceNarrative

Elements

Extensions Extensions

Structure of a Resource

Metadata

Page 20 • HL7 New Zealand20

Human Readable Summary

Standard Data Content: MRN Name Gender Date of Birth Provider

Extension with reference to its definition


Resource elements (structures)

• Resources are defined as an XML structure based on desired wire syntax– Hierarchy of elements– Each element has

• Name• Either a datatype or nested elements• Cardinality• Definition• RIM mapping

• But instances in XML or JSON


It’s all about combining resources . . .

Patient

Practitioner

Observation

Organization

http://moh.govt.nz/nhi/Patient/223

http://moh.govt.nz/hpi/Practitioner/87

http://lab.hospitalA.org/DiagRep/4445

http://lab.hospitalA.org/Observation/3ff27

http://moh.govt.nz/hpi/Organization/1


References between resources

23


FHIRRepository

Regardless of paradigmthe content is the same

Lab System

Receive a lab result in a message…

FHIR Message FHIR

Document

…Package it in a discharge summary document

NationalExchangeREST


Data types: Primitive

• Based on w3c schema and ISO data types• Stick to the “80% rule” – only expose what most will

use• Data types can have extensions too

25


Data types: Complex

26


The Case for Extensions

• Extensions are often problematic in 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• And you still need to find the documentation

• Simple choice – design for absolutely everything or allow extensions

27


Extensions without the pain…

• Extensions are built into the wire format– All fully conformant systems can “handle” any possible

extension - Just a bucket of “other stuff”– <extension> is element– Can occur at any level

• Use <modifierExtension> in the instance to flag extensions that “change things” – ‘isModifier’ in the definition

• Require formal definitions of extensions to be available in interoperability space (profile)

• Extensions rendered in human readable portion

28


Profiles

• Where extension definitions stored– (and other stuff)

• It’s a resource like any other– Can be queried/located like any other resource– Profile registries easy

Resource Profile

Extension

The extension points to its profileCan be (and probably are) on different servers

HTTP://server/Profile/nzpatient#iwi


Bundles

• Collections of resources– And metadata

• Needed for– Search– History– Document– Message

• Uses Atom feed– XML is standard– FHIR has defined JSON

representation

• Resources in entry elements

Bundle info

First Resource

Other Resource

Other Resource

REST


Representational State Transfer (REST)

Client Server

Request

Response

HTTP/S

• HTTP– Verbs– Headers– Status Codes

• The way the web works…


FHIR RESTful Operations

• Instance– Read GET [base]/Patient/100– Vread GET [base]/Patient/100/{vid}– Update PUT [base]/Patient/100– Delete DELETE [base]/Patient/100– History GET [base]/Patient/100/_history

• Type– Create POST [base]/Patient– Search GET [base]/Patient?name=eve– History GET [base]/Patient/_history– Validate POST [base]/Patient/100/_validate/{id}

• System– Conformance GET [base]/metadata– Transaction POST bundle to root– History GET [base]/_history– Search GET [base]/Patient?name=eve


Versioning

33, v12 – 2012-12-04

33, v13 – 2012-12-05

33, v14 – 2012-12-08

/server.org/fhir/Patient/33/_history/12




/server.org/fhir/Patient/33 or/server.org/fhir/Patient/33/_history/15

33, v15 – 2012-12-09

All FHIR resources can be versioned


Conformance Resource

• Server doesn’t have to do everything• Conformance resource indicates:

– Supported Resources– Search parameters– Supported profiles

• By paradigm

Documents


FHIR Documents

• Characteristics– A point-in-time snapshot of information– Intended for persistence– Organize information for human consumption

• Defined rules for how to render– Attested by a particular author– Do not (directly) drive behavior

• May be clinical (e.g. CDA) or non-clinical (e.g. Structured Product Labeling)

37


Documents – are bundles

38

Observation Resource

Composition Resource

SectionSection

Device Resource

Patient Resource

Prescription Resource

<feed> <entry> <Composition /> </entry> <entry> <Observation /> </entry> <entry> <Device /> </entry> <entry> <Prescription /> </entry> <entry> <Patient /> </entry></feed>

AttesterMetadata

Messages


FHIR Messages

• Messages are collections of resources sent with the intention of driving some sort of action– often replied to with another message

• Not intended for persistence as a whole• Always tied to some sort of “event”• Specific originator and intended recipient• Same as v2 and v3 message model

41


Messages – are bundles

42

Observation Resource

MessageHeadersource destination

Device Resource

Patient Resource

<feed> <entry> <MessageHeader /> </entry> <entry> <Observation /> </entry> <entry> <Patient /> </entry> <entry> <Device /> </entry></feed>

event

The Specification


The Spec: Hl7.org/fhir

44

Wrapping up (for now)


Is FHIR going to replace . . .

• HL7 v2?, v3?, CDA?

• FHIR has the potential to supplant all of the above, but that’s not going to happen soon– Sunk costs don’t get thrown out easily

• All HL7 standards will be maintained as long as implementers require

46


Key takeaways

• FHIR is a disruptive technology • Designed to be quick and (relatively) easy to implement

– And cheaper than alternatives

• Useful across all paradigms• Especially support mobile• Wide interest internationally

• This afternoon we’ll go deeper– For architects and developers

Date post:	25-May-2015
Category:	Healthcare
Upload:	david-hay
View:	1,457 times
Download:	3 times

Introduction to FHIR - New Zealand Seminar, June 2014

Healthcare