fhir intro and background at hl7 germany 2014

Out-of-the-box eHealth interoperability

Ewout Kramere.kramer@furore.com

HL7 Deutschland, October 21st, 2014

Our common problem

• Avoid speaking between lunch and afternoon coffee

• No one is interesting to listen to for more than 45 minutes

So….Please…

• I’ll break the presentation in 45 minutes

• State your questions at any time

• Read your e-mail if you need to

Fast(well, that’s relative)

HealthcareInteroperability(that’s what we need)

Resources(the web technology bit)

January 2011The HL7 Board initiated

“Fresh Look”

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

Grahame

LloydEwout

Why something new?

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

If your neighbour 's son can’t hack an app with <technology X> in a weekend…..

Focus on implementers

you won’t get adopted

Focus on implementersKeep common scenarios simpleLeverage existing technologiesMake content freely available

12

REST

WHAT’S IN THE BOX?

Slice & dice your data into “resources”

MedicationPrescription Problem

Cover 80% - Context independent - Unit of exchange/storage

Consistent documentation

Organization “ACME Hospital”National Drive 322Orlando, FL

Organization “ACME Hospital”National Drive 322Orlando, FL

PatientMRN 22235“Olaf Olafsson”01-01-1994Bergen

PatientMRN 22234“Ewout Kramer”30-11-1972Amsterdam

Thousands of examples

Structure of a Resource(XML example)

How many resources?Currently: about 68

• Administrative– Patient, Location, Encounter,

Organization, • Clinical Concepts

– AllergyIntolerance, Questionnaire, Observation

• Infrastructure– ValueSet, Composition, Profile,

Conformance

Next up…still about 100 to go

• Scheduling- Appointment, Availability, Slot

• Financial- Claim, Account, Coverage

• Consent

Full support for C-CDA

Generic Specific

Cover all usecases - (n)ever

HL7v3 RIMHL7 CDA

C-CCD

openEHR RM

HL7v2

IHE PDQFHIR

openEHR Archetypes

openEHR Templates

HL7v3 CMETS

+ =

Cover the 80% out of the box…

Organization “ACME Hospital”National Drive 322Orlando, FL

PatientMRN 22234“Ewout Kramer”30-11-1972Amsterdam

+ Haircolor BROWN

+ Taxoffice Id NLOB33233

You can extend:- Resources- Elements of Resources- FHIR Datatypes

Resources, Extensions, Profiles

+ =DiagnosticReport

Observation

"extensions"

"Profile"

Package & publish: The Profile

“My First Profile”V1.0 by Ewout

Document from the resource to the wireHTTP/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

Message

Document

REST

CORBA

SOAP ?

Packaging & transport

Yes, v2 style messagingis also supported! √Yes, v3 CDA style documentsare also supported!

√

Implementer support…

In Summary…

• Basic “80%” Resources• Extension mechanism• Publication mechanism for specs (profiles)• Package as Message, Document or “REST”• XML/JSON/HTTP protocol for transport• Examples, documentation, API’s, connectathons

Where are we?• January 2014 First Draft Standard for Trial Use ballot (“DSTU1”)

– Semi-stable platform for implementers Additional DSTU versions roughly annually to make fixes, introduce new resources

• May 2015 Second Draft Standard for Trial Use ballot (“DSTU2”)– Additional (C-CDA) resources, more workflow support, work on validation, community

feedback

• Normative is around 3 years out– We want lots of implementation

experience before committing to backward compatibility

29

Questions?

INTERLUDE: SOURCE OF FHIR

“Source” of FHIRStraight from the HL7 SVN “code” respositoryat gforge.hl7.org

Publication process

.INI

Publication tool(org.hl7.fhir.tools.jar)

Java, C#,Delphi eCoreDefinitions.xml

Website

ValidationSchema’s

Examples

DictXml Resource profiles

ResourceUML

examples

Let’s browse the Spec

DSTU1, Dev andNightly Build…

Pillars of FHIR

Exchange : Simple, Concise, ModularConformance : Capable, Comprehensive, fine-grainedOntology / Mapping : Thorough, Deep, Authoritative

FHIR EXCHANGE LAYERCombining resources into useful exchanges

FHIR server

Patient ObservationOrganization

PatientPatient Observation

Observation

REST:“Repository” model of healthcare

CreateUpdate Query

Lab System

CreateUpdate

Hospital System

CreateUpdate Query Subscribe

Play with the exchange layer

Practitioner

Patient

Observation

“Business” identifiers

FHIR server @ hospitalA.org

PractitionerPractitioner/87

Organization

Organization/1

FHIR server @ lab.hospitalA.org

DiagnosticReport

DiagnosticReport/4445

Observation

Observation/3ff27

result

In REST: Possibly distributed…

42

FHIR server @ pat.registry.org

PatientPatient/223

managing

subject

perfo

rmer

http://fhirblog.com/2014/01/24/modelling-encounters-with-fhir/

Below the Resource: FHIR Primitives

Below the Resource: FHIR datatypes

Below the Resource: FHIR datatypes

Exchanging Lists of Resources

• We call them “bundles” of Resources– Search result– History– Multiple-resource inserts (“batches”)– Documents or messages

• So, we need an industry-standard to represent lists, and a place to put our metadata

“Atom”: New reports in the mail

Let’s do a search

• Patient/example• Patient?name=eve

• DiagnosticReport?subject=Patient/example

Bundle: FHIR Document

50

Dr. BernardPractitioner Patient Mary

Patient

Discharge Medslist

Vital Signslist

PulseObservation

BPObservation

DyclofenacMedicationPrescription

TamsulosinMedicationPrescription

Kidney StonesCondition

DischargeSummary

Composition

Chief Complaintsection

Physicalsection

Medicationssection

subjectauthor

content

content

content

entry

entry

FHIRRepository

Regardless of paradigm the content is the same

Lab System

Receive a lab result in a message…

FHIR MessageFHIR Document

…Package it in a discharge summary document

NationalExchange

REST

FHIROrder

Management

Polling feeds in FHIR (DSTU1)

Lab System

1. Submit Order

2. Monitor new orders

3. Order update

4. Monitor placed orders

EHR

Notifications in FHIR (DSTU2)

Patient Care Device

FHIRDevice Alert

Manager

1. Register device

2. Subscribe to device events

3. Send Alert

5. Retrieve alert data

4. Send notification

THE FHIR CONFORMANCE LAYERAdapting FHIR to local needs

The need for Conformance

• Many different contexts in healthcare, but a single “core spec” with operations and Resources

• Need to be able to describe restrictions based on use and context

• Allow for these usage statements to:– Authored in a structured manner– Published in a repository– Used as the basis for validation, code, report and UI generation.

Compliance

Publication

Guidance

Implementation

Find & maintain

Retrieve & use

Repository

Tagging a profiled Resource

Patient

MRN 22234“Ewout Kramer”30-11-1972Amsterdam

http://hl7.org/fhir/tag/profile“I’m a Patient as defined in the Norwegian Profile – see http://hl7.no/Profiles/patient-no”

(Distributed) validation

App’s server

Store &Validate

Country validation serverValidate Y

Profile X

Profile Y

Profile YD

ownload &

Validate

Profile X

Profile Y

Extend/restrict the API

• Conformance Resource: describes how a client or server uses or should use the FHIR API

Which FHIR version? Which Resources? Which elements in the Resources? What search operations?

What formats (json/xml)?Is this a test server? Who can I contact?

Extend/restrict the API

• OperationDefinition Resource: describes additional operations over and above the RESTful interactions defined in the specification

What is the name, input/output parameters, what does it do? Works on which resources?

Constrain the Resources

61

Limit cardinality to 1..2(e.g. to at maximum your organizations’ identifier + the national one)

1..21..1

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

Forbid any telecom elements

0..0

StructureDefinition Resource: describes additional restrictions on a resource

Constrain the Resources

62

Fix value: Only allow “active” Patients

=“true”

If deceased is given, it must be a dateTime, not a boolean

Use our national codes for MaritalStatus

Use another profiled Resource

OrganizationNL

Extending a Resource

Key = location of formal definition

Value = value according to definition

ExtensionDefinition Resource: describes possible extensions to a resource or datatype

Ontology Support

ValueSet Resource: describes a set of codes or concepts that can be used in a context

NamingSystem Resource: provides formal definitions of system namespaces for identifiers and terminologiesConceptMap Resource: maps between terminologies and/or structures

For implementer convenience, the specification itself publishes its base definitions using these same resources!

Implementation Guide Publication

Publication tool

Website

ValidationSchema’s

Examples

DictXml Resource profiles

Profiled resources

StructureDefinition

ExtensionDefinition ValueSet

ConceptMap

NamingSystem

OperationDefinition

THE FHIRSTARTERSSome examples from early-adopters

http://www.forbes.com/sites/danmunro/2014/03/30/setting-healthcare-interop-on-fire/

Form Filler

Form Repository

EmptyQuestionnaires

1. Form Request+ Patient data in FHIR

Form Client

2. Prepopulated

Questionnaire

3. Filled out form

CompletedQuestionnaires

ONC Structured Data Capture

Patient & Provider registry

CCD Documents

Hospital System

Resources

FHIR Documents

National Patient Portal

References

PDF Documents

72

FHIR & C-CDA

• C-CDA is mandated by Meaningful Use• FHIR is a new specification• FHIR is not a replacement for C-CDA (yet)• Project to migrate C-CDA content to FHIR• In the future, FHIR may gradually replace C-

CDA

(XDS) references

• CDA documents in FHIR systems• FHIR documents stored elsewhere (i.e. registry/repository following the XDS

model)• PDF documents, and even digital records of faxes where sufficient information is

available• Other kinds of documents, such as records of prescriptions.

A DocumentReference resource is used to describe a document that is made available to a healthcare system.

It is used in document indexing systems, and are used to refer to:

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://smartplatforms.org/smart-on-fhir/

BlueButton

SMART

SMART

FHIR

FHIR

AnyFHIR

Server(PHRs!)

FHIR

Next Steps for you

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

• fhir@lists.hl7.org • #FHIR• Implementor’s Skype Channel• FHIR Developer Days (November 24 – 26), Amsterdam• StackOverflow: hl7 fhir tag

pagina 79

International HL7 FHIR Developer Days

November 24-26, 2014 in Amsterdam

Education– 14 tutorials

Connectathon– Meet fellow developers– Put FHIR to the test

Networking– FHIR experts and authors on hand

http://fhir.furore.com/devdays