HL7 FHIR - Out-of-the-box eHealth interoperability
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

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

on

  • 432 views

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

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

Statistics

Views

Total Views
432
Views on SlideShare
430
Embed Views
2

Actions

Likes
0
Downloads
17
Comments
0

1 Embed 2

http://www.slideee.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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 Presentation Transcript

  • 1. HL7 FHIR Out-of-the-box eHealth interoperability Ewout Kramer e.kramer@furore.com MIC 2013
  • 2. (well, that’s relative) (that’s what we need) (the web technology bit)
  • 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. “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. 7
  • 6. Slice & dice your data into “resources” MedicationPrescription Problem
  • 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. or shorter: “The more re-usable a standard….. …the less usable it is”
  • 9. + = Cover the 80% out of the box…
  • 10. Support “Bottom-up re-use”
  • 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. 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. Questions?