HL7 FHIR - Out-of-the-box eHealth interoperability
•Als PPTX, PDF herunterladen•
0 gefällt mir•1,270 views
A high-level overview of the characteristics of HL7 FHIR, which makes it especially amenable to eHealth interoperability
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie HL7 FHIR - Out-of-the-box eHealth interoperability
Ähnlich wie HL7 FHIR - Out-of-the-box eHealth interoperability (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
HL7 FHIR - Out-of-the-box eHealth interoperability
- 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)
- 4. 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
- 5. “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?”
- 7. 7
- 8. Slice & dice your data into “resources” MedicationPrescription Problem
- 9. 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
- 10. or shorter: “The more re-usable a standard….. …the less usable it is”
- 11. + = Cover the 80% out of the box…
- 13. 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
- 14. 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
- 15. Questions?
Hinweis der Redaktion
- 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)