300 likes | 421 Views
HL7 is people , HL7 is ideas , HL7 is collaboration. Healthcare Standards. Complex…. Slow… Hard to use and understand Require specialist skills, tools Costly. Healthcare Standards. Complex…. Slow… Hard to use and understand Require specialist skills, tools Costly.
E N D
Healthcare Standards • Complex…. Slow… • Hard to use and understand • Require specialist skills, tools • Costly
Healthcare Standards • Complex…. Slow… • Hard to use and understand • Require specialist skills, tools • Costly What if it didn’t have to be like that?
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….
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
Extension with reference to its definition Human Readable Summary • Standard Data Content: • MRN • Name • Gender • Date of Birth • Provider
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)
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
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
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
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
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
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
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
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
FHIR • Simple…. FAST… • Easy to use and understand • Standard skills, tools • Cost-effective information sharing
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(?)?
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
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
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
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?
Change Process • Ripples of change • Cost / Benefit • How quick will change come?
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
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
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
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
FHIR • Meeting new challenges more effectively • Still over the horizon • But coming quickly