Introduction to FHIR - New Zealand Seminar, June 2014

2,340 views

Published on

An introduction to FHIR presented by HL7 New Zealand to a local audience

  • Be the first to comment

Introduction to FHIR - New Zealand Seminar, June 2014

  1. 1. HL7 FHIR What is it, and whyshouldwe care DavidHay AlastairKenworthy KorayAtalag PeterJordan
  2. 2. Page 2 • HL7 New Zealand Welcome • Purpose of Seminar • Agenda – Around the room – Introduction to FHIR – Specialized Vignettes • Models and FHIR • Terminology (SNOMED) • FHIR in New Zealand – Lunch – Deep dive • FHIR for Architects and Developers – Wrap up and next steps • Looking forward to the HINZ conference
  3. 3. Page 3 • HL7 New Zealand Around the room • Quick intro – Who are you – What company do you represent (if any) – What’s your experience with FHIR so far – What do you want to get out of this seminar • Half a minute (max) only!
  4. 4. Introduction to FHIR Acknowledgements • Lloyd McKenzie • Ewout Kramer • Grahame Grieve Agenda • Background • Business Case • Resources, Profiles & Bundles • Paradigms • REST • Documents • Messages • The Specification David Hay Chair HL7 New Zealand Co-Chair FHIR Management Group Member HISO Product Strategist Orion health www.fhirblog.com
  5. 5. Page 5 • HL7 New Zealand The acronym • F – Fast (to design & to implement) – Relative – No technology can make integration as fast as we’d like • H – Health – That’s why we’re here • I – Interoperable – Ditto • R – Resources – Building blocks – more on these to follow 5
  6. 6. Page 6 • HL7 New Zealand Why Standards • The Great Baltimore fire February 7th & 8th 1904 • Standards enable Interoperability – Power voltages – Internet – Cell phone • In Health Interoperability, standards save money and time – Maximizing reuse
  7. 7. Page 7 • HL7 New Zealand Paradigms of Interoperability REST DocumentsMessages Services
  8. 8. Page 8 • HL7 New Zealand Timeline: Where does FHIR fit? 1980 20001990 2010 2020 V2 1987 Fresh Look 2011 V3 CDA 2005 FHIR DSTU 2014 Start V3 1995 10 years 3 years
  9. 9. Page 9 • HL7 New Zealand FHIR Manifesto • Focus on Implementers • Target support for common scenarios • Leverage cross-industry web technologies • Require human readability as base level of interoperability • Make content freely available • Support multiple paradigms & architectures • Demonstrate best practice governance
  10. 10. Page 10 • HL7 New Zealand Business Case for FHIR • Simple to understand • Developer friendly – Familiar tooling – Familiar technologies – XML/JSON/Atom, HTTP, SSL, OAuth • All paradigms • Many Architectures • Many Clients – Thick client, browser, mobile, devices • Already in use – HAPI Library – 70 Organizations, 20 Countries • US (ONC, SMART), UK (referrals), NZ (Orion Health) Results in faster, cheaper deployments that are more re-usable
  11. 11. Page 12 • HL7 New Zealand Supporting an ecosystem NHI RLS Éclair GPLWHC Authentication & Auditing (eg RealMe) + Privacy Trusted App Store
  12. 12. Page 13 • HL7 New Zealand SMART
  13. 13. Resources
  14. 14. Page 15 • HL7 New Zealand FHIR Overview • Has concept of ‘resources’ – E.g. Patient, Problem, Prescription, Allergy • Each resource has a base structure of commonly used data – Build-in extensibility mechanism – Profiles for local specific requirements • Specification built like a software product – Automatic generation of artifacts apart from static files – Massive improvement in quality • Uses simple XML, and supports JSON • Each resource has specific validation schema – Automatically generated from resource definition files • Defines terminologies/code sets for specific elements – But can be altered in different domains • All resources can be versioned • Developed in conjunction with community – All work on the web and freely available - www.hl7.org/fhir – Lots of samples – “Connectathons” to test that interoperability really works – Test servers available on-line now • Currently DSTU (Draft Standard for Trial Use), normative 2016
  15. 15. Page 16 • HL7 New Zealand Resources • “Resources” are: – Small logically discrete units of exchange – Defined behaviour and meaning – Known identity / location – Smallest unit of transaction – “of interest” to healthcare – V2: Sort of like Segments – V3: Sort of like CMETs 16
  16. 16. Page 17 • HL7 New Zealand What’s a Resource? Examples • Administrative – Patient, Practitioner, Organization, Location, Coverage, Invoice • Clinical Concepts – Allergy, Condition, Family History, Care Plan • Infrastructure – Document, Message, Profile, Conformance Non-examples • Gender – Too small • Electronic Health Record – Too big • Blood Pressure – Too specific • Intervention – Too broad 17 100-150 total - ever
  17. 17. Page 18 • HL7 New Zealand DSTU Resource List
  18. 18. Page 19 • HL7 New Zealand Resource Narrative Elements Extensions Extensions Structure of a Resource Metadata
  19. 19. Page 20 • HL7 New Zealand20 Human Readable Summary Standard Data Content:  MRN  Name  Gender  Date of Birth  Provider Extension with reference to its definition
  20. 20. Page 21 • HL7 New Zealand Resource elements (structures) • Resources are defined as an XML structure based on desired wire syntax – Hierarchy of elements – Each element has • Name • Either a datatype or nested elements • Cardinality • Definition • RIM mapping • But instances in XML or JSON
  21. 21. Page 22 • HL7 New Zealand It’s all about combining resources . . . Diagnostic Report Patient Practitioner Observation Organization http://moh.govt.nz/hpi/Practitioner/87 http://lab.hospitalA.org/DiagRep/444 http://lab.hospitalA.org/Observation/3ff27 http://moh.govt.nz/hpi/Organization/1
  22. 22. Page 23 • HL7 New Zealand References between resources 23
  23. 23. Page 24 • HL7 New Zealand FHIR Repository Regardless of paradigm the content is the same Lab System Receive a lab result in a message… FHIR Message FHIR Document …Package it in a discharge summary docum National Exchange
  24. 24. Page 25 • HL7 New Zealand Data types: Primitive • Based on w3c schema and ISO data types • Stick to the “80% rule” – only expose what most will use • Data types can have extensions too 25
  25. 25. Page 26 • HL7 New Zealand Data types: Complex 26
  26. 26. Page 27 • HL7 New Zealand The Case for Extensions • Extensions are often problematic in existing HL7 specs – Z-segments in v2 • What does this mean? – ZSB|20080117|Q^57|4.30^uL – Foreign namespaces in CDA/V3 • Break schemas • And you still need to find the documentation • Simple choice – design for absolutely everything or allow extensions 27
  27. 27. Page 28 • HL7 New Zealand Extensions without the pain… • Extensions are built into the wire format – All fully conformant systems can “handle” any possible extension - Just a bucket of “other stuff” – <extension> is element – Can occur at any level • Use <modifierExtension> in the instance to flag extensions that “change things” – ‘isModifier’ in the definition • Require formal definitions of extensions to be available in interoperability space (profile) • Extensions rendered in human readable portion 28
  28. 28. Page 29 • HL7 New Zealand Profiles • Where extension definitions stored – (and other stuff) • It’s a resource like any other – Can be queried/located like any other resource – Profile registries easy Resource Profile Extension The extension points to its profile Can be (and probably are) on different servers HTTP://server/Profile/nzpatient#iwi
  29. 29. Page 30 • HL7 New Zealand Bundles • Collections of resources – And metadata • Needed for – Search – History – Document – Message • Uses Atom feed – XML is standard – FHIR has defined JSON representation • Resources in entry elements Bundle info First Resource Other Resource Other Resource
  30. 30. REST
  31. 31. Page 32 • HL7 New Zealand Representational State Transfer (REST) Client Server Request Response HTTP/S • HTTP – Verbs – Headers – Status Codes • The way the web works…
  32. 32. Page 33 • HL7 New Zealand FHIR RESTful Operations • Instance – Read GET [base]/Patient/100 – Vread GET [base]/Patient/100/{vid} – Update PUT [base]/Patient/100 – Delete DELETE [base]/Patient/100 – History GET [base]/Patient/100/_history • Type – Create POST [base]/Patient – Search GET [base]/Patient?name=eve – History GET [base]/Patient/_history – Validate POST [base]/Patient/100/_validate/{id} • System – Conformance GET [base]/metadata – Transaction POST bundle to root – History GET [base]/_history – Search GET [base]/Patient?name=eve
  33. 33. Page 34 • HL7 New Zealand Versioning 33, v12 – 2012-12-04 33, v13 – 2012-12-05 33, v14 – 2012-12-08 /server.org/fhir/Patient/33/_history/12 /server.org/fhir/Patient/33/_history/14 /server.org/fhir/Patient/33/_history/13 /server.org/fhir/Patient/33/_history/15 /server.org/fhir/Patient/33 or /server.org/fhir/Patient/33/_history/15 33, v15 – 2012-12-09 All FHIR resources can be versioned
  34. 34. Page 35 • HL7 New Zealand Conformance Resource • Server doesn’t have to do everything • Conformance resource indicates: – Supported Resources – Search parameters – Supported profiles • By paradigm
  35. 35. Documents
  36. 36. Page 37 • HL7 New Zealand FHIR Documents • Characteristics – A point-in-time snapshot of information – Intended for persistence – Organize information for human consumption • Defined rules for how to render – Attested by a particular author – Do not (directly) drive behavior • May be clinical (e.g. CDA) or non-clinical (e.g. Structured Product Labeling) 37
  37. 37. Page 38 • HL7 New Zealand Documents – are bundles 38 Observation Resource Composition Resource Section Section Device Resource Patient Resource Prescription Resource <feed> <entry> <Composition /> </entry> <entry> <Observation /> </entry> <entry> <Device /> </entry> <entry> <Prescription /> </entry> <entry> <Patient /> </entry> </feed> AttesterMetadata
  38. 38. Messages
  39. 39. Page 41 • HL7 New Zealand FHIR Messages • Messages are collections of resources sent with the intention of driving some sort of action – often replied to with another message • Not intended for persistence as a whole • Always tied to some sort of “event” • Specific originator and intended recipient • Same as v2 and v3 message model 41
  40. 40. Page 42 • HL7 New Zealand Messages – are bundles 42 Observation Resource MessageHeader source destination Device Resource Patient Resource <feed> <entry> <MessageHeader /> </entry> <entry> <Observation /> </entry> <entry> <Patient /> </entry> <entry> <Device /> </entry> </feed> event
  41. 41. The Specification
  42. 42. Page 44 • HL7 New Zealand The Spec: Hl7.org/fhir 44
  43. 43. Wrapping up (for now)
  44. 44. Page 46 • HL7 New Zealand Is FHIR going to replace . . . • HL7 v2?, v3?, CDA? • FHIR has the potential to supplant all of the above, but that’s not going to happen soon – Sunk costs don’t get thrown out easily • All HL7 standards will be maintained as long as implementers require 46
  45. 45. Page 47 • HL7 New Zealand Key takeaways • FHIR is a disruptive technology • Designed to be quick and (relatively) easy to implement – And cheaper than alternatives • Useful across all paradigms • Especially support mobile • Wide interest internationally • This afternoon we’ll go deeper – For architects and developers

×