FHIR intro and background at HL7 Germany 2014
•Download as PPTX, PDF•
2 likes•1,177 views
A thorough overlook of FHIR, starting out with a general intro and discussing FHIR exchange patterns, architecture and profiling
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (14)
Similar to FHIR intro and background at HL7 Germany 2014
Similar to FHIR intro and background at HL7 Germany 2014 (20)
Recently uploaded
Recently uploaded (20)
FHIR intro and background at HL7 Germany 2014
- 1. Out-of-the-box eHealth interoperability Ewout Kramer e.kramer@furore.com HL7 Deutschland, October 21st, 2014
- 2. Our common problem • Avoid speaking between lunch and afternoon coffee • No one is interesting to listen to for more than 45 minutes
- 3. So….Please… • I’ll break the presentation in 45 minutes • State your questions at any time • Read your e-mail if you need to
- 4. (well, that’s relative) (that’s what we need) (the web technology bit)
- 5. January 2011 The HL7 Board initiated “Fresh Look” “What would we do if we were to revisit the healthcare interoperability space from scratch?” Grahame Lloyd Ewout
- 8. “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?”
- 9. Focus on implementers If your neighbour 's son can’t hack an app with <technology X> in a weekend….. you won’t get adopted
- 10. Focus on implementers Keep common scenarios simple Leverage existing technologies Make content freely available
- 11. 12
- 13. WHAT’S IN THE BOX?
- 14. Slice & dice your data into “resources” MedicationPrescription Problem Cover 80% - Context independent - Unit of exchange/storage
- 15. Consistent documentation Patient MRN 22235 “Olaf Olafsson” 01-01-1994 Bergen Organization “ACME Hospital” National Drive 322 Orlando, FL Organization “ACME Hospital” National Drive 322 Orlando, FL Patient MRN 22234 “Ewout Kramer” 30-11-1972 Amsterdam Thousands of examples
- 16. Structure of a Resource (XML example)
- 17. How many resources? Currently: about 68 • Administrative – Patient, Location, Encounter, Organization, • Clinical Concepts – AllergyIntolerance, Questionnaire, Observation • Infrastructure – ValueSet, Composition, Profile, Conformance Next up…still about 100 to go • Scheduling - Appointment, Availability, Slot • Financial - Claim, Account, Coverage • Consent Full support for C-CDA
- 18. Cover all usecases - (n)ever Generic Specific HL7v3 RIM HL7 CDA C-CCD openEHR RM HL7v2 IHE PDQ openEHR Archetypes FHIR openEHR Templates HL7v3 CMETS
- 19. Cover the 80% out of the box… + =
- 20. Organization “ACME Hospital” National Drive 322 Orlando, FL Patient MRN 22234 “Ewout Kramer” 30-11-1972 Amsterdam +Haircolor BROWN You can extend: - Resources - Elements of Resources - FHIR Datatypes + Taxoffice Id NLOB33233
- 21. Resources, Extensions, Profiles + = DiagnosticReport Observation "Profile" "extensions"
- 22. Package & publish: The Profile “My First Profile” V1.0 by Ewout
- 23. 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
- 24. Packaging & transport Yes, v2 style messaging √is also supported! Yes, v3 CDA style documents are also supported! √
- 26. In Summary… • Basic “80%” Resources • Extension mechanism • Publication mechanism for specs (profiles) • Package as Message, Document or “REST” • XML/JSON/HTTP protocol for transport • Examples, documentation, API’s, connectathons
- 27. Where are we? • January 2014 First Draft Standard for Trial Use ballot (“DSTU1”) – Semi-stable platform for implementers Additional DSTU versions roughly annually to make fixes, introduce new resources • May 2015 Second Draft Standard for Trial Use ballot (“DSTU2”) – Additional (C-CDA) resources, more workflow support, work on validation, community feedback • Normative is around 3 years out – We want lots of implementation experience before committing to backward compatibility 29
- 28. Questions?
- 29. INTERLUDE: SOURCE OF FHIR
- 30. “Source” of FHIR Straight from the HL7 SVN “code” respository at gforge.hl7.org
- 31. Publication process .INI Publication tool (org.hl7.fhir.tools.jar) Java, C#, Delphi eCoreDefinitions.xml Website Validation Schema’s Examples Resource UML DictXml Resource profiles examples
- 32. Let’s browse the Spec DSTU1, Dev and Nightly Build…
- 33. Pillars of FHIR Exchange : Simple, Concise, Modular Conformance : Capable, Comprehensive, fine-grained Ontology / Mapping : Thorough, Deep, Authoritative
- 34. Combining resources into useful exchanges FHIR EXCHANGE LAYER
- 35. REST:“Repository” model of healthcare Create Update Patient Observation FHIR server Organization Patient Patient Observation Observation Diagnostic Report Query Lab System Create Update Hospital System Create Update Query Subscribe
- 36. Play with the exchange layer
- 37. Diagnostic Report Patient Practitioner Observation
- 40. In REST: Possibly distributed… Patient/223 FHIR server @ hospitalA.org Practitioner/87 Practitioner Organization/1 Organization FHIR server @ lab.hospitalA.org DiagnosticReport/4445 Diagnostic Report Observation/3ff27 Observation 42 FHIR server @ pat.registry.org Patient subject
- 42. Below the Resource: FHIR Primitives
- 43. Below the Resource: FHIR datatypes
- 44. Below the Resource: FHIR datatypes
- 45. Exchanging Lists of Resources • We call them “bundles” of Resources – Search result – History – Multiple-resource inserts (“batches”) – Documents or messages • So, we need an industry-standard to represent lists, and a place to put our metadata
- 46. “Atom”: New reports in the mail
- 47. Let’s do a search • Patient/example • Patient?name=eve • DiagnosticReport?subject=Patient/example
- 48. Bundle: FHIR Document 50 Dr. Bernard Practitioner Patient Mary Patient Vital Signs Discharge Meds list list Pulse Observation BP Observation Dyclofenac MedicationPrescription Tamsulosin MedicationPrescription Kidney Stones Condition Discharge Summary Composition Chief Complaint section Physical section Medications section entry entry
- 49. Regardless of paradigm the content is the same FHIR Repository Receive a lab result in a message… Lab System FHIR Message FHIR Document National Exchange …Package it in a discharge summary document
- 50. Polling feeds in FHIR (DSTU1) FHIR Order Management Lab System 1. Submit Order 2. Monitor new orders 3. Order update 4. Monitor placed orders EHR
- 51. Notifications in FHIR (DSTU2) Patient Care Device FHIR Device Alert Manager 1. Register device 2. Subscribe to device events 3. Send Alert 4. Send notification 5. Retrieve alert data
- 52. Adapting FHIR to local needs THE FHIR CONFORMANCE LAYER
- 53. The need for Conformance • Many different contexts in healthcare, but a single “core spec” with operations and Resources • Need to be able to describe restrictions based on use and context • Allow for these usage statements to: – Authored in a structured manner – Published in a repository – Used as the basis for validation, code, report and UI generation.
- 54. Guidance Implementation Repository Find & maintain Retrieve & use
- 55. Tagging a profiled Resource Patient MRN 22234 “Ewout Kramer” 30-11-1972 Amsterdam http://hl7.org/fhir/tag/profile “I’m a Patient as defined in the Norwegian Profile – see http://hl7.no/Profiles/patient-no”
- 56. (Distributed) validation App’s server Store & Validate Country validation server Profile X Profile Y Profile Y
- 57. Extend/restrict the API • Conformance Resource: describes how a client or server uses or should use the FHIR API Which FHIR version? Which Resources? Which elements in the Resources? What search operations? What formats (json/xml)? Is this a test server? Who can I contact?
- 58. Extend/restrict the API • OperationDefinition Resource: describes additional operations over and above the RESTful interactions defined in the specification What is the name, input/output parameters, what does it do? Works on which resources?
- 59. Constrain the Resources StructureDefinition Resource: describes additional restrictions on a resource 61 Limit cardinality to 1..2 (e.g. to at maximum your organizations’ identifier + the national one) 1..2 1..1 Limit names to just 1 (instead of 0..*) 0..0 Forbid any telecom elements
- 60. Constrain the Resources 62 =“true” Fix value: Only allow “active” Patients If deceased is given, it must be a dateTime, not a boolean Use our national codes for MaritalStatus Use another profiled Resource OrganizationNL
- 61. Extending a Resource ExtensionDefinition Resource: describes possible extensions to a resource or datatype Key = location of formal definition Value = value according to definition
- 62. Ontology Support ValueSet Resource: describes a set of codes or concepts that can be used in a context NamingSystem Resource: provides formal definitions of system namespaces for identifiers and terminologies ConceptMap Resource: maps between terminologies and/or structures
- 63. For implementer convenience, the specification itself publishes its base definitions using these same resources!
- 64. Implementation Guide Publication Structure Definition Extension Definition Publication tool Website Validation Schema’s Examples ValueSet ConceptMap Profiled resources DictXml Resource profiles NamingSystem OperationDefinition
- 66. Some examples from early-adopters THE FHIRSTARTERS
- 68. ONC Structured Data Capture Form Filler Form Repository Empty Questionnaires 1. Form Request + Patient data in FHIR Form Client 3. Filled out form Completed Questionnaires
- 69. Patient & Provider registry CCD Documents Hospital System National Patient Portal References
- 70. FHIR & C-CDA • C-CDA is mandated by Meaningful Use • FHIR is a new specification • FHIR is not a replacement for C-CDA (yet) • Project to migrate C-CDA content to FHIR • In the future, FHIR may gradually replace C-CDA 72
- 71. (XDS) references A DocumentReference resource is used to describe a document that is made available to a healthcare system. It is used in document indexing systems, and are used to refer to: • CDA documents in FHIR systems • FHIR documents stored elsewhere (i.e. registry/repository following the XDS model) • PDF documents, and even digital records of faxes where sufficient information is available • Other kinds of documents, such as records of prescriptions.
- 72. IHE MHD “This winter (…) the Volume 2 part of Mobile Health Documents (MHD) will be replaced with the appropriate content describing a profile of DocumentReference to meet the needs of MHD and the family of Document Sharing in XDS, XDR, and XCA.” John Moehrke, august 16, 2013
- 74. BlueButton S M A R T S M A R T F H I R F H I R Any FHIR Server (PHRs!) F H I R
- 76. Next Steps for you • Read the spec at http://hl7.org/fhir • Try implementing it • Come to a (European?) Connectathon! • fhir@lists.hl7.org • #FHIR • Implementor’s Skype Channel • FHIR Developer Days (November 24 – 26), Amsterdam • StackOverflow: hl7 fhir tag
- 77. 79 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
Editor's Notes
- It’s been said before by the “wise” Steve Ballmer….”developers, developers, developers”….
- They probably craft something themselves We want HL7 to have an answer to these. If we don’t => someone else will do it and we will lose credibility. You could do it using v3, but not solely based on the downloadable UV-version. And probably not on some country-specific Implementation Guide either (different focus, priorities)
- Readily useable, contain “the 80%” (What’s the 80%...what’s maximum reuse? That’s HL7’s core business!) Independent of context, fixed defined behaviour and meaning Can reference each other Units of exchange – suggests units of storage for implementers Addressed through HTTP or other methods
- Even when you think your target will understand all the encoded data, reality is data often gets shared beyond the originally intended context Allow for exceptions for things like automated device readings, etc.
- “The more re-usable a standard….. …the less usable it is” “The more specific a standard is….. …the smaller it’s scope of use”
- You can constrain away stuff you don’t need You can add stuff to the basic models for your usecase “Remove and add bricks as necessary”
- Luckily, our building blocks – Resources – are already less "finegrained". Slightly less flexibility – but easier to compose meaningful stuff. If you need flexibility, you can add extensions. Profiles are our building books. When just given the spec (which is still quite flexible), there's still a lot of flexibility in combining those. Profiles express what communicating partners expect to exchanging within their context and usecase.
- “Drive-by” or “bottom-up” operability: “Communicate first, standardize later” But allow publication & discovery of extensions 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
- 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)
- Resource Id’s (=URLs) are infrastructural id’s, they differ from “business” identifier. Many Resources also have business identifiers, they are explicitly modeled, like Patient.identifier (even more than one identifier possible!) Business identifiers are completely separate from technical resource id’s
- 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.
- A server might defer validation to another server (because it doesn’t know the profile) A server may fetch the “unknown” profile and validate it itself There may be several servers sharing the work
- Note: something that’s mandatory in the core definition cannot be made optional in a profile