HL7 FHIR - Out-of-the-box eHealth interoperability


Published on

A high-level overview of the characteristics of HL7 FHIR, which makes it especially amenable to eHealth interoperability

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • We don’t actually have a formal manifesto, but these are the principles we adhere to.
  • TheyprobablycraftsomethingthemselvesWe want HL7 to have ananswerto these.If we don’t => someoneelsewill do itand we willlosecredibility.Youcould do itusingv3, but notsolelybased on the downloadable UV-version. Andprobablynot on some country-specificImplementation Guide either (different focus, priorities)
  • Readilyuseable, contain “the 80%” (What’s the 80%...what’s maximum reuse? That’s HL7’s core business!)Independent of context, fixeddefined behaviour and meaningCanreferenceeachotherUnits of exchange – suggests units of storage forimplementersAddressed through HTTP or other methods
  • Youcanconstrainaway stuff youdon’tneedYoucanadd stuff to the basic modelsforyourusecase“Removeandaddbricks as necessary”
  • “Drive-by” or “bottom-up” operability: “Communicate first, standardize later”But allow publication & discovery of extensionsFirst, business partners. Then, collaborations, communities. Maybe, finally,nation-wideIt’s a naturalprocessthatpeoplewill want to make itwork first, thenonlycoordinatewhattheyreallyneedto, andthenrealizetheycanbroadentheir approach to a community.“Support”, of course top-down shouldstillbepossible! Maybe even a combi in the long-term
  • Document every resource,everyattributeProvideexamplesDefinehowtouse in REST, Document and MessageManageableby a project lead in a weekend, or you’llbeignored (in favor of localsolutions)
  • HL7 FHIR - Out-of-the-box eHealth interoperability

    1. 1. HL7 FHIR Out-of-the-box eHealth interoperability Ewout Kramer e.kramer@furore.com MIC 2013
    2. 2. (well, that’s relative) (that’s what we need) (the web technology bit)
    3. 3. FHIR Manifesto (abridged) • Focus on implementers • Keep common scenarios simple • Leverage existing technologies • Make content freely available If your neighbour ‘s son can’t hack an app with it in a weekend….. you won’t get adopted
    4. 4. “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?”
    5. 5. 7
    6. 6. Slice & dice your data into “resources” MedicationPrescription Problem
    7. 7. Generic Specific Cover all usecases - (n)ever HL7v3 RIM HL7 CDA C-CCD openEHR RM HL7v2 IHE PDQ FHIR openEHR Archetypes openEHR Templates HL7v3 CMETS
    8. 8. or shorter: “The more re-usable a standard….. …the less usable it is”
    9. 9. + = Cover the 80% out of the box…
    10. 10. Support “Bottom-up re-use”
    11. 11. Document from the resource to the wire 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"},"identifi er":[{"type":{"code":"ssn","system":" http://hl7.org/fhir/sid
    12. 12. What’s Next? • September 2013 Draft Standard for Trial Use Ballot – Coverage of C-CDA contents • January 2014 First Draft Standard for Trial Use ballot (DSTU) – Semi-stable platform for implementers Additional DSTU versions roughly annually to make fixes, introduce new resources • Normative is around 3 years out – We want *lots* of implementation experience before committing to backward compatibility 14
    13. 13. Questions?
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.