Out-of-the-box eHealth interoperability with FHIR
•Download as PPTX, PDF•
0 likes•249 views
Ewout Kramer, Furore FHIR: Out-of-the-box eHealth interoperability? EHiN 2014, IKT-Norge og HOD
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (18)
Similar to Out-of-the-box eHealth interoperability with FHIR
Similar to Out-of-the-box eHealth interoperability with FHIR (20)
More from IKT-Norge
More from IKT-Norge (20)
Recently uploaded
Recently uploaded (20)
Out-of-the-box eHealth interoperability with FHIR
- 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
- 8. Slice & dice your 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 your partners…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 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
- 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 HL7 FHIR 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. Questions?
Editor's Notes
- It’s been said before by the “wise” Steve Ballmer….”developers, developers, developers”….
- …unfortunately we at HL7 were not at that point AT ALL
- - People were looking for comparable familiar solutions at HL7…..for mobile, for cloud….we could not offer them that…..
- 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?
- “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?”
- 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%?
- But allow publication & discovery of extensions
- 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 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
- 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.
- 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)