FHIR/RfH.....What is it? And what’s next?

FuroreEwout Kramer

Disclaimer

• FHIR is very early in the stages of its development– Things may evolve differently than presented here– While I’m reasonably involved, I’m not an expert

• This is an ideal time to influence outcomes

Background

• 01/2011, - HL7 Board initiated “Fresh Look”– “what would we do if we were to revisit the

healthcare interoperability space from scratch?”• 05/2011 WGM, there was an “official” meeting of the

Fresh Look taskforce, but also…• An “unofficial” meeting that took over an evening

RIMBAA session and was broadly attended, discussing v3 pain points.

V3 Pain-points

– Too steep a learning curve– Not easily adopted by out-of-box tools– Specifications get caught up in the need to do everything– Standards development process is slow– Specifications are not created in a way that is directly

implementable– We need to support “Drive By interoperability”

From this meeting the seeds were planted for RFH/FHIR

RFH/FHIR

• Prior to Sept. 2011 meeting, Grahame Grieve released the first draft of RFH – Resources for Healthcare– Not a complete specification– But complete enough to show roughly how it would

work, including example instances and model design• Reviewed at the Sept. 2011 WGM and met with a very

positive response• The three victims

RFH or FHIR?

The name on the original proposal was RFH– Duplicate of a name of a WHO project– Web domains already taken

Effort by HL7 marketing to come up with a new name– Free domain names– Available for trademarking– Easy to say/remember– Positive connotation

FHIR – Fast Healthcare Interoperability Resources

Scope of queries and updates

“How do we know where an object made up of other objects begins and ends?”

“In any system with persistent storageof data, there must be a scope for a transaction that changes data and a way of maintaining the consistency of the data”

What is FHIR?

• Build around the concept of “resources”– Small, discrete concepts that can be maintained independently– Aligns with RESTful design philosophy– Similar to the concept of CMETs, but there’s only *one* model per resource– Each resource has a unique id

• Each resource comes with built-in CRUD operations• When necessary, resources can be combined into collections

called “documents”

Storage Model

• Unit of storage– Lock, create, read, update, delete as a whole– CRUD-services

• Only the “root” is public, rest are nested objects• Explicit references to other data

– Feels like “identifiable” CMET stereotype

• Scope of context conduction• Unit of documentation

(Dis

)ass

embl

er/c

onve

rter

Reso

urce

Sto

rage

What is FHIR? - II

• Each resource is modeled using developer friendly XML– XML does not reflect RIM-based modeling– No classCodes, moodCodes, etc. visible– Strong ontology behind the scenes that does link to RIM and vocabulary

• Uses a variant of the ISO datatypes– Simplifies some things (by moving them out of datatypes)– Adds support for simplifications such as human-readable dates, human-

readable ids

What is FHIR? - III

Built-in extension mechanism– Extensions are defined using name, value, link-point

• Name is tied to robust terminology with full RIM modeling• Link point identifies what element of the base resource or other

extension the extension “attaches” to

– Idea is the elements used by 80% of implementers are part of the base resource.• All other elements are handled as extensions

– Wire format remains stable, even as extensions occur

The 5 parts of RfH

• Resource definitions with a focus on implementation - but mapped to the data dictionary for full definitions.

• A data dictionary which provides a rich ontological layer where the resources and their data elements are formally defined in a computable fashion

• Terminology Definitions of terms and value sets.• Conformance Statements that allow for interoperability between

particular implementations to be assessed• A workflow management layer that maps the resources to real world

business events.

Todo…

• Make an inventory of candidate Resources and Modules• Authoring tools. Regular UML? Custom tools?• Vocabulary binding mechanisms• ControlAct, statuses, versioning• Governance• Migration

Stick to the goal: keep it simple!

Next steps…

• HL7 Fresh Look task-force endorsed FHIR development to go ahead

• TSC has approved an MnM project to more fully define the FHIR methodology

• Funded work for a small team to move forward with FHIR design to have something to share for the January 2012 WGM