Download to read offline
Uploaded byEwout Kramer
FHIR overview at EHiN 2014, Oslo
The document discusses the importance of eHealth interoperability and the FHIR (Fast Healthcare Interoperability Resources) framework, emphasizing simplicity for implementers and leveraging existing technologies. It covers the different types of resources in FHIR, ongoing developments, and upcoming events for developers to gain experience with the standard. The document outlines the need for a stable platform and conformance guidance to facilitate broad adoption of FHIR.
More Related Content
Similar to FHIR overview at EHiN 2014, Oslo
FHIR overview at EHiN 2014, Oslo
- 1. Out-of-the-box eHealth interoperability? Ewout Kramer e.kramer@furore.com EHiN, november 4thm 2014
- 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
- 5. Focus on implementers If your neighbour 's son can’t hack an app with <technology X> in a weekend….. you won’t get adopted
- 6.
- 8. Slice & diceyour data into “resources”
- 9. How many resources? Currently: about 60 • Administrative – Patient, Location, Encounter, Organization, • Clinical Concepts – AllergyIntolerance, Questionnaire, Observation • Infrastructure – ValueSet, Composition, Profile, Conformance Next up…still about 60 to go • Scheduling - Appointment, Availability, Slot • Financial - Claim, Account, Coverage • Consent • Devices – Metric, DeviceComponent • Care Transfer Full support for C-CDA
- 10. Flexibility vs. useability Generic Specific openEHR RM HL7v3 RIM HL7v2 HL7 CDA openEHR Templates C-CCD IHE PDQ openEHR Archetypes FHIR HL7v3 CMETS Re-useable Single purpose
- 11. Cover the 80%out of the box… Race Middle name + = Lunar Hijri birthdate
- 12. FHIR Repository Standard FHIR REST Custom Operations Read Update Search Check Drug Interaction Merge Patient
- 13. Standardize with yourpartners…not the world Conformance & Profile
- 14. Guidance Implementation Repository Find & maintain Retrieve & use
- 15. Packaging & transport Yes, v2 style messaging √is also supported! Yes, v3 CDA style documents are also supported! √
- 16. Document from theresource 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
- 17. What’s Next? •Februari 2014 First Draft Standard for Trial Use (DSTU) – Semi-stable platform for implementers Additional DSTU versions roughly annually to make fixes, introduce new resources • June 2015 Second Draft Standard for Trial Use (DSTU2) • Normative – 2016? – We want *lots* of implementation experience before committing to backward compatibility 17
- 18. 18 International HL7FHIR Developer Days November 24-26, 2014 in Amsterdam Education – 14 tutorials Connectathon – Meet fellow developers – Put FHIR to the test Networking – FHIR experts and authors on hand http://fhir.furore.com/devdays
- 19.
Editor's Notes
- #4 It’s been said before by the “wise” Steve Ballmer….”developers, developers, developers”….
- #6 …unfortunately we at HL7 were not at that point AT ALL
- #7 - People were looking for comparable familiar solutions at HL7…..for mobile, for cloud….we could not offer them that…..
- #8 Documents are not compatible with how mobile and interactive apps work. If you want to find the lab results for all patients showing up tomorrow at your desk, how to you do that?
- #11 “Then again, we’re not Facebook or Twitter…..we do not write an API just for our own needs….we need to be everything to everyone…..now, how can we do that?”
- #12 Base spec has lots of optionality…..You can constrain away stuff you don’t need But you can also add stuff to the basic models for your usecase “Remove and add bricks as necessary” Who’s 80%?
- #13 But allow publication & discovery of extensions
- #14 How bad is it that not the whole world speaks Esperanto? That we use English for our basic needs? For the generic context In fact, even in your mother tongue, you don’t know much jargon….only of interest when you need to communicate in a certain context So, if a doctor talks jargon to his colleagues, and the IT guy does the same to his colleagues, why can they still converse when having a beer? You only need to learn each others jargon depending on your communication needs. Likewise chaos won’t automatically occur when everyone uses extensions within his own context of exchange. That moment either of you have to flex: you learn some jargon, he uses lay-man or you end up in something between In the mean time, our mother tongue evolves too and develops new words for new concepts….bottom up AND top down “Drive-by” or “bottom-up” operability: “Communicate first, standardize later” First, business partners. Then, collaborations, communities. Maybe, finally, nation-wide It’s a natural process that people will want to make it work first, then only coordinate what they really need to, and then realize they can broaden their approach to a community. “Support”, of course top-down should still be possible! Maybe even a combi in the long-term
- #15 A profile can be published on a FHIR (based) server (it’s a Resource, after all) Or in a version-management system, or by e-mail, or… As long as people can *find* them, because publishing your profile should help others to find & adhere to it.
- #17 Document every resource, every attribute Provide examples Define how to use in REST, Document and Message Manageable by a project lead in a weekend, or you’ll be ignored (in favor of local solutions)