IHE France on FHIR

© 2012 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

IHE Franceon FHIR

Ewout Kramer

Paris, October 2013

Updated for

FHIR DSTU!


2

Introductions

Name: Ewout Kramer Company: Furore, Amsterdam Background:

FHIR core team, AID (RIMBAA) Software developer & healthcare

architect Contact:

[email protected] www.thefhirplace.com

mailto:[email protected]


3

Today’s program

Introduction to FHIR (probably the whole morning)

Go deeper on requested subjects? Hands-on with FHIR?


Fast Relative – No technology can make integration as fast as we’d like

HealthcareInteroperabilityThat’s why we’re here

ResourcesBuilding blocks – more on these to follow


Why?

5


“How can I get data from my server to my iOS app?”

“How do I connect my applications using cloud storage?”

“How can I give record-based standardized access to my PHR?”

The Need


January 2011The HL7 Board initiated

“Fresh Look”

“What would we do if we were to revisit the healthcare interoperability space from scratch?”

Grahame Grieve

Lloyd McKenzie Ewout Kramer

Genesis…

© 2012 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.8

Highrise


HL7 v3 (CDA)

Complex…. Slow… Hard to use and understand Require specialist skills, tools No direct support for how web, mobile &

cloud systems are built Requires localization to be useful

9

What if it didn’t have to be like that?


FHIR Manifesto

Focus on implementers Keep common scenarios simple Leverage existing web technologies Provide human readability

One syntax – documents, messages, services, REST Computable templates/profiles that work in all architectures

Make content freely available Demonstrate best practice governance


11

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

Delphi, C#, Java – more to come Connectathons to verify specification approaches Instances you can read and understand Lots of examples (and they’re valid too)

using HL7.Fhir.Instance.Model;using HL7.Fhir.Instance.Parsers;using HL7.Fhir.Instance.Support;

XmlReader xr = XmlReader.Create(

new StreamReadIFhirReader r = new XmlFhirReader

// JsonTextReader jr = new JsonTe// new StreamRead// IFhirReader r = new JsonFhirRe

ErrorList errors = new ErrorList(LabReport rep = (LabReport)ResourAssert.IsTrue(errors.Count() == 0


12

Implementer Focus is…

http://hl7.org/fhir/downloads.htm


13

Support “Common” Scenarios

The core data model is kept lean by including only those elements commonly present across systems You can extend the model for specific use cases

Communication infrastructure strives to make common things easy More complex parts only come in to play when you

need them


14

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 (REST) work the same way they

do for Facebook & Twitter Rely on HTTPS, OAuth, etc. for security

functions

http://...


15

Architectures

FHIR makes no assumptions about the architectural design of systems

You can use it for Light or heavy clients Central server or peer-to-peer sharing Push or pull Query or publish/subscribe Loosely coupled or tightly coupled environments With history tracking or without


16

Human Readable

CDA taught HL7 a very important lesson Even if the computers don’t understand 99% of

what you’re sending, that’s ok if they can properly render it to a human clinician

This doesn’t just hold for documents – important for messages, services, etc.

In FHIR, every resource can should have a human-readable expression Can be direct rendering or human entered


17

Freely available

Unencumbered – free for use, no membership required

http://hl7.org/fhir

http://hl7.org/fhir


WHAT’S IN THE BOX?

18


Molecules to build useful systems….

19

Lab

Report

Related

Person

Patient

Practitioner

Location


20

Cover all usecases - (n)ever

HL7v3 RIM

Generic

HL7 CDA

C-CCD

openEHR RM

HL7v2

IHE PDQ

FHIR

Specific

openEHR Archetypes

openEHR Templates

HL7v3 CMETS


The 80/20 rule

Design for the 80%, not 100% Only include data elements in the artifacts if 80%

of all implementers of that artifact will use the data element

Allow easy extension for the remaining 20% of elements which often make up 80% of current specs Vocabulary approach to extension definition

21(c) 2012 HL7 International04/08/2023


Kinds of Resources

Administrative Concepts Person, Patient, Organization, Device, Facility Coverage, Invoice, etc.

Clinical Concepts Allergy, Problem, Medication, Family History Care Plan

Infrastructure Functionality Document, Message, Conformance/Profiling

22


Granularity

Gender Too small

Electronic Health Record Too big

Blood Pressure Too specific

Intervention Too broad

23

100-150 total – ever


24

Design of the Resource

Have a technical identity (= url) “Things” that live on the web

can be moved and distributed

Known content and meaning just RTFM! Mappings to v2 / v3 Not dependent on context


Resources have 3 parts

Defined Structured Data The logical, common contents of the resource Mapped to formal definitions/RIM & other formats

Extensions Local requirements, but everyone can use Published and managed (w/ formal definitions)

Narrative Human readable (fall back)

25


Structure of a Resource


+ =

Extensibility


28

The Case for Extensions

Simple choice – design for absolutely everything or allow extensions

Everyone needs extensions, everyone hates them

FHIR tames extensibility Built in extensibility framework (engineering level) Define, publish, find extensions Use them

This tames the overall specification


Extensions

Built into the wire format All conformant systems can “handle” any possible

extension - Just a bucket of “other stuff” No schema changes necessary Can flag as “mustUnderstand”

Define, publish, find extensions Repository Documented just like resources Can be fetched & interpreted by clients

29


30

Extension definition


31

Extending a name

Key = location of formal definition

Value = value according to definition


Message

Document

REST

HTTP/1.1 200 OKContent-Type: application/json;charset=utf-8Content-Length: 627Content-Location: /fhir/person/@1/history/@1Last-Modified: Tue, 29 May 2012 23:45:32 GMTETag: "1“

"Person":{"id":{"value":"1"},"identifier":[{"type":{"code":"ssn","system":"http://hl7.org/fhir/sid

Transport


33

Just follow the industry...

Exchanges use XML & JSON Collections represented using ATOM

Same technology that gives you your daily news summary

Out-of-the-box publish/subscribe Support for REST: Web calls work the same

way they do for Facebook & Twitter Rely on HTTPS, OAuth, etc. for security

functions

http://...


34

FHIR on the wire

XML JSON


35

New reports in the mail


36

Paradigms

FHIR supports 4 interoperability paradigms

REST Documents

Messages Services


REST: Just a quick GET

GET /fhir/patient/@1 HTTP/1.1

HTTP/1.1 200 OKContent-Type: text/xml+fhir;charset=utf-8Content-Length: 787Content-Location: http://fhir.furore.com/fhir/patient/@1/history/@1Last-Modified: Tue, 29 May 2012 23:45:32 GMT

37

<?xml version="1.0" encoding="UTF-8"?><Partient><identifier><label>SSN</label><identifier><system>http://hl7.org/fhir/sid/usssn</system><id>444222222</id></identifier></identifier><name><use>official</use><family>Everywoman</family><given>Eve</given></name><telecom><system>phone</system><value>555-5552003</value> <use>work</use></telecom><gender><system>http://hl7.org/fhir/sid/v2-0001</system><code>F</code></gender>


Message…

38

Bundle (Atom)

Lab

Report

Patient

Practitioner

Location

Message• Source• Destination• Event

• Similar to v2 and v3 messaging: event codes, defined content for request and response.

• Sent as a result of some real-world event


FHIR Document

Similar to CDA A point in time collection of resources,

bound together Root is a “Document” resource Just like CDA header

One context Can be signed, authenticated, etc.

39

Documents


40

Service Oriented Architecture (SOA)

Do whatever you like (based on SOA principles) Ultra complex workflows Ultra simple workflows Individual resources or collections (in Atom or

other formats) Use HTTP, email, FTP, sockets…only constraint is

that you’re passing around FHIR resources in some shape or manner

Services


41

Cross-paradigms

Regardless of paradigm the content is the same This means it’s straight-forward to share content

across paradigms E.g. Receive a lab result in a message. Package

it in a discharge summary document It also means constraints can be shared across

paradigms E.g. Define a profile for Blood Pressure and use it

on resources in messages, documents, REST and services


42

Vocabulary

Support for coded data of varying complexity Some codes defined as part of resource,

others referenced from external vocabularies LOINC, SNOMED, UCUM, etc. Existing v2 and v3 valuesets and codesystems

Recognition some will differ by implementation space

Can use Value Set resource to define more complex code lists


43


Profile

A unit of distribution to package & publish HOW the FHIR resources are used in your context:

Constrain existing resources (or profiles) Binding to (more specific) vocabulary Define new extensions Define message contents Define document contents Define search operations

Subsumes: template, implementation profile, DCM (Detailed Clinical Model), etc.

44


45

Constraining resources

Demand that the identifier uses your national patient identifier

Limit names to just 1 (instead of 0..*)

Limit maritalStatus to another set of codes that extends the one from HL7 international

Add an extension to support “RaceCode”


46

Using profiles

When communicating a resource, you can indicate the profiles it should conform to.

A server might explicitly state it only accepts resources conforming to a certain profile (and verify!)

You can ask a FHIR server to validate a resource against a given profile


“Bottom-up” interop


48

Where to find a profile

A Profile is just a Resource Any FHIR server could serve Profiles (just

like Patients, Observations, etc…) So, any FHIR server is a profile repository!

A resource is simply referred to by its URI


Conformance

What parts of the FHIR specification a system supports

Defining how a software system is capable of behaving (including configuration options)

Identifying a desired set of behavior (e.g. RFP) HL7 (or IHE!) might define standard conformance sets

like “FHIR Light”, “FHIR Message router”, “FHIR PHR service”, specifying desired (minimum) behaviour

Validateable by automated testing

49


50

What’s in conformance?

Which wire formats supported? What messages does the server accept,

what does the content look like? Which protocols? http? Mllp? ftp? What documents? Which resources? Which operations (read, create, update,

search)


51

How to get conformance

Conformance is again, just a Resource Any FHIR server will publish his own

conformance at a special endpoint A FHIR server may store and publish any

number of additional Conformance resources, so you can refer to them


READING THE FHIR SPEC


53

(FHIR home)hl7.org/fhir


Resource representations

Each resource is published with several views covering different aspects UML diagram Simple pseudo-XML syntax Vocabulary bindings Notes Search Criteria Data dictionary Example instance Schema + Schematron RDF, XMI, etc. to come


IS FHIR READY TO GO?

55


56

Current state

Started may 2012 Several iterations, mostly infrastructure Cooperation of HL7 International

workgroups, including governance 1st DSTU ballot open now with full support for

content in CCDA, but much still to be done DSTU published ~Jan. 2014


Progress

Enthusiastic Community Adoption Geometric Growth in Connectathons (3

completed connectathons – growing from 7 to 25 to possibly 80 seats)

Candidate and Prototype programs ONC Data Collection / Specification DICOM exploring FHIR for their WADO-RS IHE plans for next version of MHD to use FHIR

57


58

IHE MHD

“This winter (…) the Volume 2 part of Mobile Health Documents (MHD) will be replaced with the appropriate content describing a profile of DocumentReference to meet the needs of MHD and the family of Document Sharing in XDS, XDR, and XCA.”

John Moehrke, august 16, 2013

http://www.hl7.org/implement/standards/fhir/documentreference.htm

http://www.hl7.org/implement/standards/fhir/documentreference.htm


59

Implementer support

Multiple reference implementations Auto-generated interfaces in 4+ languages Public test servers Automated test tools Draft tooling to convert CCDA -> FHIR Tooling in progress for Profile

development/maintenance


60

Looking forward

Over next 2-3 years Additional DSTUs updating existing content,

adding new resources & profiles Some projects, external SDOs & new national

initiatives start referencing FHIR After 2-3 years

Begin making FHIR and some resources Normative

Migration begins if/when a financial business case can be made


IS IT BETTER?Comparing FHIR and prior HL7 standards

61


V2 and FHIR

Similarities

Built around re-usable “chunks” of data

Strong forward/backward compatibility rules

Extensibility mechanism

FHIR Differences

Each chunk (resource) is independently addressable

More than messages Human readable required Extensions don’t collide,

are discoverable Modern tools/skills Instances easy to read Lighter spec


V3 and FHIR

Similarities

Based on RIM, vocab & ISO Data types foundations

Support XML syntax

FHIR Differences

Simpler models & syntax (reference model hidden)

Friendly names Extensibility with

discovery Easy inter-version wire

compatibility Messages, documents,

etc. use same syntax JSON syntax too


V3 and CDA

Similarities

Support profiling for specific use-cases

Human readability is minimum for interoperability

APIs, validation tooling, profile tooling

(See v3 similarities on prior slide)

FHIR Differences

Can use out of the box – no templates required

Not restricted to just documents

Implementer tooling generated with spec

(See v3 differences on prior slide)


FHIR and Services

Similarities

Encourage context neutral, re-usable structures with defined behavior

RESTful interface is a simple SOA interface

FHIR differences

Consistent data structures across services

Ease of transport across paradigms message <-> service <-> document <-> REST

Standard framework for defining/discovering services


So why use anything else?

FHIR is brand new No market share Not yet passed ballot Little track record

Business case No-one dumps existing working systems just

because something new is “better” Large projects committed to one standard won’t

change direction quickly (or even at all)


67

Simple message

Yes, FHIR has the potential to supplant HL7 v3, CDA and even v2

However It’s not going to do so any time soon

No one's going to throw away their investment in older standards to use FHIR until

1. The specification has a good track record

2. It’s clear the new thing provides significant benefits HL7 will support existing product lines so

long as the market needs them


68

Next Steps for you

Read the spec: http://hl7.org/fhir Try implementing it Come to a (European?) Connectathon!

[email protected] #FHIR Implementor’s Skype Channel EU RIMBAA meetings (november) StackOverflow: hl7 fhir tag

http://hl7.org/fhir

Health & Medicine

IHE France on FHIR