A presentation given at the HINZ 2015 conference in New Zealand with a clinical rather than technical focus

1. FHIRinNew Zealand:
AClinicians perspective
HL7NewZealand,October2015

2. Page 2
Agenda
• Morning
– FHIR background – David hay
• Benefits and value
• Tooling
• Fundamentals
• Profiling
– A practical example: Adverse Drug Reactions (ADR)
• The clinical problem – Matt Doogue
• The AllergyIntolerance resource – Peter Jordan
• Afternoon
– Stream 1 (Clinical) : Profiling AllergyIntolerance for ADR
– Stream 2 (Developer): Mini-hackathon

3. Page 3
Objectives of day
• Provide a base level knowledge of FHIR
• Give familiarity of tooling
– On-line specification
– clinFHIR
• Example of creating a real profile
• Generate interest from Clinicians & Business Analysts
– Techies already on board
• Next steps in New Zealand

4. Page 4
• Name: David Hay
• Company: Orion Health (Product Strategist)
• Background:
– Ex Clinician
– Involved in FHIR almost from beginning
– Co-Chair FHIR Management Group
– Chair HL7 New Zealand
– Member HISO Committee
– Blog: FHIRBlog.com
Who am I?

5. Page 5
Why Standards

6. Why FHIR

7. Page 7
OVERVIEW OF FHIR
• Fast Healthcare Interoperability Resources (FHIR)
• Consistent, simple to use resources
– Domain knowledge is not required
• Well thought out, standardized APIs
• Controlled extensibility
• Familiar tools and technologies for implementers
• Improves healthcare information exchange
– Designed with implementers in mind
– Detailed spec for real time APIs
• Strong endorsement and support from vendors and
regulatory community (NITB, ONC, Project
Argonaut).

8. Page 8
Where it can add value: INTEROPERABILITY
• Resources and profiles standardize input:
– Less source system variation leads to faster integration
– Simplified validation and error detection
• Structured approach to extension & profiles
improves understanding
• Adds well defined API standards to traditional
messaging and document based exchange
paradigms:
– Critical to support standards based app innovation.

9. Page 9
Where it can add value: Application innovation
• Provision of predictable interfaces – both transport
and content
• Using industry standard technologies (REST, JSON)
lowers the barrier to entry
• Discoverability of services through conformance
statements and profiles.
• Increases commercial viability of app development:
– FHIR compliant apps should will work with different FHIR
Servers (EMRs, HIEs)

10. BENEFITS TO IMPLEMENTERS AND HCOS

11. Page 11
Benefits to Implementers
• Familiar tooling and technologies – XML/JSON, HTTP, REST, SSL, OAuth
• Predefined resources and APIs - allows implementer to focus on the core
application functionality
• Extensive documentation, samples and reference server implementation
• Active and supportive community
• Open Source code libraries: HAPI (Java) and Furore (.Net) and test servers
• Mobile friendly

12. Page 12
Benefits to HCOS
• Well supported by the vendor community
• Standards based APIs
– Connect systems
– support internal application development
• Will lead to:
– faster interoperability
– lower cost interoperability
– reduced vendor lock in
as FHIR is adopted by source systems

13. BENEFITS TO CLINICIAN AND PATIENT

14. Page 14
Benefits to Clinician
• Improved access to higher quality,
patient information
• Greater choice and variety of
applications to support clinical
workflow.

15. Page 15
Benefits to patient
• Care team has access to a more
complete patient record and
improved decision support tools:
– Better decision making
– More efficient diagnosis and treatment
• Prospect of improved patient
engagement apps, enabled through
FHIR APIs to clinical systems.

16. Page 17
Small Print
• Current status DSTU-2
• Implementer experience starting
• Health IT is hard!
• Local expertise growing
• Suggests pilots are a good approach…

17. Tools

18. Page 19
Tools
• Specification
• clinFHIR
– Visualization
– Link to spec
– Resource Builder
– Profile Builder
• Forge

19. Fundamentals: Resources

20. Page 21
Resources
• “Resources” are:
– Small logically discrete units of exchange
– Defined behaviour and meaning
– Known identity / location
– Smallest unit of transaction “of interest” to healthcare
21

21. Page 22
Resources – sample list

22. Page 23
Resource anatomy
• Resources have 4 main parts
23
Structured
Data
Extensions
Narrative
(text)
Metadata

23. Page 24
24

24. Page 25
Comprised of elements
• Each element has
– Name
– Description
– DataType
• Reference, Coded, Standard
• Can be more than one per element (the [x] in the spec)
– Terminology Binding
• If coded
– Multiplicity
• How many
MD

25. Page 26
References between resources
A web of resources that can tell any story

26. Page 27
Clinical Scenario
• First consultation
– Complaining of pain in the r) ear for 3 days with an
elevated temperature. On examination, temperature 38.5
degrees and an inflamed r) ear drum with no perforation.
Diagnosis Otitis Media, and prescribed Amoxil 250mg
TDS for 5 days
• Follow up consultation
– 2 days later returned with an itchy skin rash. No
breathing difficulties. On examination, urticarial rash on
both arms. No evidence meningitis. Diagnosis of
penicillin allergy. Antibiotics changed to erythromycin
and advised not to take penicillin in the future.
Condition
Observation
Med
Allergy
Encounter
5 year old boy Patient

27. Page 28
Resource view
(All refer to patient)

28. Page 30
Screen dump

29. Fundamentals: Exchange Patterns

30. Page 32
Exchange Patterns
32
REST
Documents Messages
Services
(API)

31. Page 33
Document
33
Bundle
Resource 1
Resource 2
Composition
 Use for ‘point in time’ record
 Discharge Summary
 Referral
 Analogous to CDA
 Collection of resources bound
together
 Root is a “Composition”
resource (Just like CDA header)
 Explicit context

32. Page 34
Message
34
Bundle
Resource 1
Resource 2
MessageHeader
• Used to inform or instruct
– Patient Admitted
– Lab result available
• Analogous to v2 messaging
• Also a collection of
resources as a Bundle

33. Page 35
REST
• Use for simple ‘Real time’ interactions
– Current Medication list
– Update Problem list
• “Representational state transfer” – an architecture for how to
connect systems
• Used by Google, Facebook, Amazon
• Simple interfaces
• Easy to build / debug / support
• Especially good for mobile
3

34. Page 36
Services & Operations
• More complex real-time interaction
– Eg Prescription with Decision support
– Suitable for workflows
– Only constraint is that you’re passing around FHIR resources in some
shape or manner
– Examples in spec
• Get Patient record
• Expand ValueSet
• Fetch Encounter data
36

35. Page 37
FHIR
Repository
Regardless of paradigm, the content is the same
Lab System
FHIR
Message
FHIR
Document
National
Exchange

36. Page 38
Re-visiting the consultation…

37. Page 39
As a document…

38. Page 40
…or a Message

39. Fundamentals: Terminologies

40. Page 44
Terminology
a discipline that systematically studies the “labeling or
designating of concepts” particular to one or more subject
fields or domains of human activity
Wikipedia

41. Page 46
FHIR Resource Datatypes
• Resource element datatypes of different ‘categories’
– References to other resources
– Non-coded data
– Coded data
• Coded data
– Code
– Coding
– CodeableConcept
– (Quantity)

42. Page 47
Coded data: Examples
• Code: "status" : "confirmed"
• Coding: {
"system": "http://www.nlm.nih.gov/research/umls/rxnorm",
"code": "C3214954",
"display": "cashew nut allergenic extract Injectable"
}
• CodeableConcept: {
"coding": [{
"system": "http://snomed.info/sct",
"code": "39579001",
"display": "Anaphylactic reaction“
}],
"text" : "Anaphylaxis"
}

43. Page 48
Terminology Sub-system
• SNOMED CT
• LOINC
• ICD
• NZ-ULM
• Iwi & Hapu
• New Zealand DHB
Code System:
Defines a set of
concepts with a
coherent meaning
Code
Display
Definition

44. Page 49
Terminology Sub-system
Value Set:
A selection of a
set of codes for
use in a particular
context
Code System:
Defines a set of
concepts with a
coherent meaning
Code
Display
Definition

45. Page 50
Terminology Sub-system
Code System:
Defines a set of
concepts with a
coherent meaning
Code
Display
Definition
Element
Definition:
Type and
Value set
reference
Value Set:
A selection of a
set of codes for
use in a particular
context
Binds

46. Page 51
Terminology Sub-system
Code System:
Defines a set of
concepts with a
coherent meaning
Code
Display
Definition
Element
Definition:
Type and
Value set
reference
Value Set:
A selection of a
set of codes for
use in a particular
context
Binds
Element:
code/
Coding/
CodeableConcept
Conforms

47. Page 52
Binding Strength
• How closely the options in the value set should be followed
• Values
– Required (must come from set)
– Extensible (may use alternate if have to)
– Preferred (don’t have to, but should)
– Example (set isn’t specified)
• Can use extension to vary
– (Make stronger not weaker)

48. Page 53
ValueSet resource
• Defines list of possible values for a particular context
– Eg Medication codes in New Zealand
• Can reference external Terminology/s
– Or define own sets
• Why?
– A common valueSet improves recording consistency
– Improves user experience (pick lists)
• Examples in New Zealand
– ED diagnoses (derived from SNOMED)
– NZ POCS (Pathology Observation Code Set) (derived from LOINC)
– List of NZ Iwi (defined in ValueSet)

49. Page 54
ValueSet for condition.code
{
"resourceType": "ValueSet",
"id": "valueset-condition-code",
"meta": {
"versionId": "1",
"lastUpdated": "2015-05-08T16:18:23Z",
},
"text": {
"status": "generated",
"div": ”Condition.code sample ValueSet"
},
"url": "http://hl7.org/fhir/vs/condition-code",
"version": "0.5.0",
"name": "Condition/Problem/Diagnosis Codes",
"publisher": "FHIR Project team",
"contact": [
{
"telecom": [
{
"system": "url",
"value": "http://hl7.org/fhir"
}
]
}
],
"description": "Example value set for
Condition/Problem/Diagnosis codes",
"copyright": "This value set includes content
from SNOMED CT, which is copyright © 2002+
International Health Terminology Standards
Development Organisation (IHTSDO), and
distributed by agreement between IHTSDO and
HL7. Implementer use of SNOMED CT is not
covered by this agreement",
"status": "draft",
"experimental": true,
"compose": {
"include": [
{
"system": "http://snomed.info/sct",
"filter": [
{
"property": "concept",
"op": "is-a",
"value": "404684003"
}
]
}
]
}

50. Page 55
Terminology Server
• Provides ‘services’ for consumers to access terminology
– Hide the complex stuff from a consumer
• Uses Operations framework
– Get definition for a concept
– Find a concept
• Within a ValueSet • Find Terms
• Get Term
Definition

51. Profiles: An overview

52. Page 57
The need for Profiles
• Many different contexts in healthcare, but a single set of
Resources
• Need to be able to describe restrictions and extensions 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.
• 2 main aspects:
– Constraining a resource
– Adding an extension
• Profiling is going to be very important
57

53. Page 58
Examples of Profiles in New Zealand
• Patient
– Fix identifier to NHI
– Add Iwi, Hapu ?Usual GP
• Condition (Problem)
– Code is SNOMED
– Different disciplines could have different profiles
• MedicationOrder
– Use ULM
– Fix identifier to HPI

54. Page 60
Profiling a resource. For example...
60
Require that the identifier uses the NHI – and is
required
Limit names to just 1 (instead of 0..*)
Limit maritalStatus to another set of codes that
extends the one from HL7 international
Don’t support photo
Add an extension to support “Iwi”
Note: hardly any mandatory
elements in the core spec!

55. Profiles: Constraining Resources

56. Page 62
When constraining you can:
• Remove an element completely
• Make an optional element required
• Change ‘many’ to one
• If ‘many’, specify the permissible values
– Slicing (e.g. BP Observation)
• Specify a different ValueSet
• Change the possible datatype
– Not add new ones
• Overall, a recipient can still understand a constrained resource
– Still ‘wire’ compatible.

57. Profiles: Extending resources

58. Page 64
Why are there extensions?
• A consequence of keeping resources small
– Lesson of HL7 v3
• The 80% guideline
• Allow new information to be added
– In a discoverable way
• Extensions are normal

59. Page 65
Key features of extensions
• Used to add a new property, or refine existing
• Any element can be extended
– The path
• Normal or modifier
• Same capability as ‘core’ properties
• Properties defined in an ‘Extension Definition’ resource
• Instance points to definition
– Recipient can always find out what an extension means

60. Page 66
Governing Extensions
• Extensions are not a silver bullet
• FHIR has a sliding scale governance for
extensions
– HL7 published extensions
– National Standards (e.g. New Zealand Extensions)
– Domain standards (e.g. Best Practice Cardiology)
– Local Projects
6

61. Page 67
The ‘Conformance Server’
• 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 in the instance points to its definition
Can be (and probably are) on different servers
HTTP://server/StructureDefinition/nzpatientwi

62. Page 68
Example: AllergyIntolerance
• Use clinFHIR to profile AllergyIntolerance
– Extension for Encounter reference
– Change other elements
• Then show in resource builder
– Patient ‘encounter HINZ’
– Note:
• Resource ‘claims conformance’ to Profile

63. Page 71
Establishing the ecosystem
Terminology
Security
Identity Data
FHIR API and Resources
Conformance

64. Page 72
Wrapping up
• FHIR enables innovation by standardizing interoperability
• It can be understood by Clinician and Techie
• It is being widely adopted internationally
– (early days)
• It offers a real opportunity to revolutionize health IT in New
Zealand if we work together.
• What should we do next?