HL7 is people , HL7 is ideas , HL7 is collaboration

1. HL7 is people, HL7 is ideas, HL7 is collaboration

2. Healthcare Standards • Complex…. Slow… • Hard to use and understand • Require specialist skills, tools • Costly

3. Healthcare Standards • Complex…. Slow… • Hard to use and understand • Require specialist skills, tools • Costly What if it didn’t have to be like that?

4. Introducing FHIR • Fast Health Interoperability Resources • Pronounced “Fire” • Based on industry best practices, with a focus on simplicity and implementability …insert your fire related joke here….

5. Resources Resources are: • “Things” that live on the web • Read/updated etc via HTTP • Known content and meaning • Identity (= location) – can be moved • Represented in XML or JSON (or others) • Molecules to build useful systems

6. Extension with reference to its definition Human Readable Summary • Standard Data Content: • MRN • Name • Gender • Date of Birth • Provider

7. 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 • Narrative • Human readable (fall back)

8. Kinds of Resources • Administrative Concepts • Person, Patient, Organization, Device, Facility • Coverage, Invoice, etc. • Clinical Concepts • Allergy, Problem, Medication, Family History • Diagnostic Report / Order, Care Plan • Infrastructure Functionality • Document, Message, Conformance/Profiling

9. Using Resources Resources • Logical building blocks for health records • Pieces that connect to each other • Molecules in a grid Exchange Framework • Interactive access to an application • Get / search / interact • Connect applications deeply

10. Using Resources • Classic Web RESTfulapproach • Simple approach led by Facebook, Twitter, etc. • Repository API approach (ex Web) • Query / Feed (i.e. web portal) • Push (i.e. classic messaging) • Subscription • Maximum Portability • Same content representation in the web, national EHRs, local institution exchange

11. FHIR Ethos • Simplicity / Web alignment • Implementation focused • Reference Implementations (C#, Java, etc) • Publically available test servers (now) • Connectathons • Freely available • http://hl7.org/fhir • Unencumbered – free for anyone to use

12. License

13. Extensions • Managing extensibility is a central problem • 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

14. Collaborations • IHE • investigating - use of FHIR for MHD (mobile XDS) • DICOM • interested - RESTful access to image metadata • W3C • Semantic health group helping us with RDF • Lots of work to be done

15. Future Plans • Internal preparation phase • Very solid infrastructure (implementation focus) • More work required still • September ballot cycle – DSTU • DSTU = Draft Standard for Trial Use • Publish FHIR as full DSTU end 2013

16. Connectathon • Boston – September • focus around PHR • Outcomes count towards DSTU • Sydney – October • Focus….? (MHD  pcEHR?) • Outcomes can make a difference to future directions here in Australia

17. FHIR • Simple…. FAST… • Easy to use and understand • Standard skills, tools • Cost-effective information sharing

18. Why do something new? • FHIR is a huge change from past practice • Almost a clean slate • Re-implementation is required • Business Sponsors ask “do you have to make this much change? Why not do something less?” • i.e. why not just “fix” v3(?)?

19. Why do something new? • Fundamental problem: • How do you make change compelling enough to justify the cost of change? • Small change = small cost, small benefit • Big change = big cost, big benefit • Backwards compatibility generates buy-in, but creates lock-in • change will be destructive

20. Why do something new? • v2 Messaging • Venerable and well understood • Inherent limitations (fixed definitions & syntax, transactional nature) not resolvable • Any important change will abandon backwards compatibility & all existing implementation stacks • Small change will never justify the cost

21. Why do something new? • CDA • Focus of much current adoption • Implementation is hard work (harder than it should be) • It’s scope limitations are baked into it’s success • No sweet spot where change is justified • V3 • Backwards compatibility prevents change • E.g. ISO 21090 very unlikely to be adopted in practice

22. What should you use… • If you are building a new iOS healthcare app (and thousands are)? • If you want to provide a cloud based health app that integrates with social networks? • If you wants a simple to use exchange standard that integrates with existing architecture? • If you want to provide a simple to use standards based API to cloud based health integration services? • If you want to implement a national EHR? What does HL7 have to offer?

23. Change Process • Ripples of change • Cost / Benefit • How quick will change come?

24. Implementation Support • Implementer focused specification • Schemas / Schematrons (code generation ready) • Extensive Mappings (v2, CDA, XDS, DICOM) + conversion scripts • Real, complete clinical records in examples • Reference Platform • Online servers • Explore (Web) + Test your implementation • Validation, public registries

25. Implementation: Profiles • A structured statement about how one or more resources are used in a context • Cardinality, definitions, invariants, terminology bindings, search parameters • Can develop your own resources • Under development • Authoring tool • Publishing framework • Validator

26. Implementation: Server • Writing a server has several challenges: • Supporting Search well • Dealing with transactions • Managing Security • Conformance Statements • You don’t have to do everything

27. Criticisms of FHIR • Change process isn’t justified • Distract from known successes • Shouldn’t standardise content • FHIR should standardise user practice • FHIR should enforce a reference model • FHIR is trying to do too much • HL7 won’t be able to steward FHIR properly

28. FHIR • Meeting new challenges more effectively • Still over the horizon • But coming quickly