IHE France on FHIR

IHE France
on FHIR
Ewout Kramer
Paris, October 2013

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

Introductions




Name: Ewout Kramer
Company: Furore, Amsterdam
Background:





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

Contact:



e.kramer@furore.com
www.thefhirplace.com

2

Today’s program


Introduction to FHIR (probably the whole
morning)



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



3

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

That’s why we’re here

Building blocks – more on these to follow


Why?

5

The Need
“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?”

Genesis…
January 2011
The 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

Highrise

8


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

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

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


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 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





11


Implementer Focus is…
http://hl7.org/fhir/downloads.htm

12

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

13

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

14

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

15

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

16

Freely available



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

17

WHAT’S IN THE BOX?

18

Molecules to build useful
systems….
Location

Related
Person

Patient

Lab
Report

Practitioner
19

Cover all usecases (n)ever
Specific

IHE PDQ
openEHR
Templates
openEHR
Archetypes
HL7v2

C-CCD
FHIR

HL7v3
CMETS
HL7 CDA
HL7v3 RIM

openEHR RM

Generic
20

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

10/28/2013

(c) 2012 HL7 International

21


Kinds of Resources


Administrative Concepts





Clinical Concepts





Person, Patient, Organization, Device, Facility
Coverage, Invoice, etc.
Allergy, Problem, Medication, Family History
Care Plan

Infrastructure Functionality


Document, Message, Conformance/Profiling

22

Granularity


Gender




Electronic Health Record




Too big

Blood Pressure




Too small

Too specific

Intervention


100-150 total –
ever

Too broad

23

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

24

Resources have 3 parts


Defined Structured Data





Extensions





The logical, common contents of the resource
Mapped to formal definitions/RIM & other formats
Local requirements, but everyone can use
Published and managed (w/ formal definitions)

Narrative


Human readable (fall back)

25

Structure of a Resource


Extensibility

+

=


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

28

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

Extension definition

30

Extending a name

Key = location of formal definition

Value = value according to definition

31

Transport

HTTP/1.1 200 OK
Content-Type: application/json;charset=utf-8
Content-Length: 627
Content-Location: /fhir/person/@1/history/@1
Last-Modified: Tue, 29 May 2012 23:45:32 GMT
ETag: "1“
"Person":{"id":{"value":"1"},"identifier":[{"type":{"co
de":"ssn","system":"http://hl7.org/fhir/sid

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

33

FHIR on the wire

XML

JSON

34

New reports in the mail

35

Paradigms


FHIR supports 4 interoperability paradigms

REST

Documents

Messages

Services

36

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

<?xml version="1.0" encoding="UTF-8"?>
<Partient><identifier><label>SSN</label><identifier><system>
http://hl7.org/fhir/sid/usssn</system><id>444222222</id></ident
ifier></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/si
d/v2-0001</system><code>F</code></gender>

37

Message…
• Similar to v2 and
v3 messaging:
event codes,
defined content
for request and
response.
• Sent as a result
of some realworld event

Bundle (Atom)
Message

Patient

Lab

• Source
• Destination
• Event

Location

Report

Practitioner

38

FHIR Document



Similar to CDA
A point in time collection of resources,
bound together







Documents

Root is a “Document” resource
Just like CDA header

One context
Can be signed, authenticated, etc.

39

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

40

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

41

Vocabulary



Support for coded data of varying complexity
Some codes defined as part of resource,
others referenced from external vocabularies






42

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

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”

45

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

46

“Bottom-up” interop


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




48

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

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)

50

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

51

READING THE FHIR SPEC


hl7.org/fhir
(FHIR home)

53

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

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

56

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

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
58

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

59

Looking forward


Over next 2-3 years






After 2-3 years



60

Additional DSTUs updating existing content,
adding new resources & profiles
Some projects, external SDOs & new national
initiatives start referencing FHIR
Begin making FHIR and some resources
Normative
Migration begins if/when a financial business
case can be made


Comparing FHIR and prior HL7 standards

IS IT BETTER?

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)


Simple message



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



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


67

It’s not going to do so any time soon

The specification has a good track record
It’s clear the new thing provides significant benefits

HL7 will support existing product lines so
long as the market needs them


Next Steps for you












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

fhir@lists.hl7.org
#FHIR
Implementor’s Skype Channel
EU RIMBAA meetings (november)
StackOverflow: hl7 fhir tag

68

IHE France on FHIR

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie IHE France on FHIR

Ähnlich wie IHE France on FHIR (19)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

IHE France on FHIR

Hinweis der Redaktion