FHIR & Ice

FHIRinNew Zealand:
Establishinga solidfoundation
Dr.DavidHay,MBChB,July2015

Today
• Agenda
– Why FHIR
– Where can we use FHIR in NZ
– A FHIR primer
– Clinician Tooling (ClinFHIR)
– Terminology
– Profiling
– Where can we use FHIR in NZ
– Next steps for New Zealand
• Desired Outcome
– You can see where FHIR fits in
New Zealand
– You want to learn more
• Seminars
• Connectathons
– We think about infrastructure
– We plan some pilots

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

Drivers
• Interoperability requirements increasing
– Increasing collaborative care – need for co-ordination
– Changing Payment models
– Clinical Care delivery to an aging population
– Decision support
– Involving the patient – raising the bar
• Need for real time access (API)
– Mobile
• Vast increase in the amount, type and source of data
– Devices, Mobile
– Genomics
• Analytics, population health
– Need to collect from many different sources
• Implementer expectations
– Expect a modern standard
Current standards don’t cut it - these led to
FHIR…

• HL7 version 2
– Great for messaging between
systems
– But:
• Old technology
• Hard to customize and
extend
• HL7 version 3
– Defined common model for
interoperability
– But:
• Extremely complex to
implement
• Limited improvement
over v2
• CDA (version 3)
– Very successful
– But:
• Documents only
• Difficult to communicate
coded data
• openEHR
– Excellent for modelling
– But:
• Main focus is on internal
data modeling rather
than exchange
• (so can still participate)
Other Standards

Business Case for FHIR
• Predefined Resources & API
– Analysis already done, and can be safely extended
• All paradigms, All Architectures, All Clients
– Thick client, browser, mobile, devices
• Implementer friendly
– Simple to understand and access with examples
– Familiar tooling & familiar technologies – XML/JSON, HTTP, SSL, OAuth
– Libraries available – HAPI, Furore, reference implementation
• Mobile friendly
– Concise, REST API & JSON
• Don’t need to understand HealthCare domain to implement
– Developers or Analysts
• Already in use Internationally
– 70 Organizations, 20 Countries, all Continents (except Antarctica)
– Involvement from Providers, Vendors, Payers, Governments
• Including Orion
• Large community for support
Results in faster, cheaper deployments that are more re-usable

Fast Healthcare Interoperability Resources (FHIR)
• Focus on Implementers
• Target support for common scenarios
• Leverage cross-industry web technologies
• Support human readability as base level of interoperability
• Support multiple paradigms & architectures
• Make content freely available
• Demonstrate best practice governance
“Latest Interoperability standard from HL7”
Manifesto

FHIR Timeline
2012 20162014 2018 2020
First
Draft
2011 20152013 2017 2019
1st
DSTU
~ 2nd
DSTU
~ 1st
Norm.
~ 2nd
Norm.
. . .
Fresh
Look

Compared with other hl7 standards?
3 years10 years
1980 20001990 2010 2020
V2
1987
Fresh
Look
2011
V3 CDA
2005
FHIR
DSTU
2014
Start V3
1995

Some possible architectures
13
FHIR
Broker
v3
v2
PHR
FHIR
App
Interface
DB
FHIR

Repository model
Vendor Neutral
Repository
FHIR
HIS LIS PACS PMS
RLS
FHIR
FHIR
FHIRFHIR
openEHR
FHIR
Vendor Neutral
Repository

Where could we use FHIR in New Zealand?

Record Locator Service
• Features
– Based on IHE XDS
– Registries (indexes) that show where documents are
– Consistent document metadata (HISO standard)
– Repositories holding data
– Consumers accessing it
• But
– Complex to implement
– Complex to use

Patient Portals
• Access to Primary Care/Community data
– Vendor agnostic
• Access to Secondary Care Data
– Vendor agnostic
• Access to other Portal data
– Or the repositories behind them
• Patient access / review of Shared data repositories
– Medications, allergies, encounters, documents
– Annotate
– Who has accessed data
• Patient data entry
– Devices
– Other observations

Primary Care EMR Integration
• Incoming
– Access to appointments
– Patient Messaging
• Repeat prescriptions
• Advice
– Notifications
– Documents
• Record Locator Integration
• Outgoing
– Access/Maintain shared Repositories – eg medications
– Update consultation summaries
• Consistent coding

Mobile Devices
• Very common access medium
– Huge growth area for medical applications
– Clinician and especially Patient
• Needs Real-time API
• Structured data
– Not just document display
• Limitations
– Bandwidth
– Performance
– Processor / memory

Models on the wire / CDA
• Current Standards
– HL7 CDA
– HL7 version 2
• Where does FHIR fit in?

2 aspects to FHIR
• Content
– Resources (the model)
– Informed by much past work inside & outside of HL7
• HL7: version 2, version 3 (RIM), CDA
• Other SDO: openEHR, CIMI, ISO 13606
• Others: IHE, DICOM
– Profiling & the 80%
• Exchange protocols - Paradigms
– API
– Other paradigms
• Message, Document

Content: Resources
• “Resources” are:
– The exchange models
• Small logically discrete units of exchange
• Defined behaviour and meaning
• Known identity / location
• Smallest unit of transaction “of interest” to healthcare – and that
can be exchanged.
– HL7 V2: Sort of like Segments
– Hl7 V3: Sort of like CMETs
• Can be represented in XML or JSON
• Can be individual or in bundles
– Eg query results, messages, documents

Polymorphic Properties
• Where a property can have different datatypes
• Can use a profile to restrict to specific type
– To come!

The DSTU-2 Candidate Spec
33
hl7.org/fhir/2015May

References between resources
A web of resources that can tell any story

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
– 5 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 changes to erythromycin
and advised not to take penicillin in the future.
Condition
Observation
Med
Allergy
Encounter
5 year old boy
Patient

Looking at the relationships

Visualizing FHIR
• clinFHIR
– Educational tool
• For non-techies (especially clinicians & BA)
• Beta software!
– Resource Builder
• View Resources
• Create Condition

Paradigms of Interoperability
REST
DocumentsMessages
Services
(Operations)

FHIR Message
39
Bundle
Resource 1
Resource 2
MessageHeader
• Similar to v2 and v3 messaging
• Collection of resources bound
together
• Root is a “MessageHeader”
resource
• Just like MSH segment
• Allows request/response
behavior with bundles for both
request and response
• Event-driven
– E.g. Send lab order, get back result
• Can use HTTP
• Can be asynchronous

FHIR Document
40
• Similar to CDA
• Also a collection of
resources as a Bundle
• Root is a “Composition”
resource
• Just like CDA header
• Explicit references
• Can be signed,
authenticated, etc.
Bundle
Resource 1
Resource 2
Composition

API – REST & Services
• Real-time interaction
– Application to Application
• Eg within enterprise systems
– Person to Application
• Eg Mobile access to data
• Increasingly common (ubiquitous?) outside of healthcare
– Twitter, Facebook, SalesForce
• Simple REST calls (CRUD)
• More complex Operations (RPC)
• One of the ‘selling points’ for FHIR

FHIR RESTful Interactions
• 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

FHIR Operations
• When more complex server logic required than simple CRUD
– Midway between REST & SOAP
• Some defined in spec. e.g.:
– Get all data for a patient
– Expand/filter terminology
• Can define custom services
– Still using FHIR resources
– Resources to define / inputs

API Examples
• REST & Operations
• How an app can access a FHIR server
• Against Grahames server (one of public test servers)
– Simple CRUD
– Operation ($everything)

FHIR
Repository
Regardless of paradigm, the content is the
same
Lab System
FHIR
Message FHIR
Document
National
Exchange
The same resources

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

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

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"
}

Terminology Sub-system
• SNOMED CT / LOINC / RxNORM
• HGVS, ICPC, MIMS + 100s more
• ICD-X+
• ANZSCO, METEOR
• A drug formulary
• A config table in an application
• A list of enums in a java class
• Australian state codes
Code System:
Defines a set
of concepts
with a
coherent
meaning
Code
Display
Definition

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

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

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

NamingSystem resource
• A coded element needs to
indicate the terminology
– How to know which ‘system’
value to use?
• Some standard ones defined
in the spec
– SNOMED, LOINC etc.
• Other datatypes need the
same
– Identifier
• Can define own ones
– Using NamingSystem resource
– uniqueId is key
{
"resourceType": "NamingSystem",
"id": "nznhi",
"meta": {
"versionId": "2",
"lastUpdated": "2015-07-21T19:58:39Z"
},
"text": {
"status": "generated",
"div": "<div xmlns="http://www.w3.org/1999/xhtml">New Zealand
NHI</div>"
},
"type": "identifier",
"name": "NZ NHI",
"date": "2014-12-13",
"status": "active",
"description": "The New Zealand NHI system",
"uniqueId": [
{
"type": "uri",
"value": "http://hl7.org.nz/ns/nhi"
}
],
"contact": [
{
"telecom": [
{
"system": "email",
"value": "nhiteam@moh.co.nz"
}
]
}
]
}

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)

ValueSet resource
• Defines list of possible values for a particular context
• 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)

ValueSet for condition.code
{
"resourceType": "ValueSet",
"id": "valueset-condition-code",
"meta": {
"versionId": "1",
"lastUpdated": "2015-05-08T16:18:23Z",
},
"text": {
"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"
}
]
}
]
}
}

Valueset for NZ Iwi
{
"resourceType": "ValueSet",
"id": "nziwi",
"meta": {
"versionId": "4",
"lastUpdated": "2015-07-18T19:29:40Z"
},
"text": {
"div": "<div xmlns="http://www.w3.org/1999/xhtml">

<p>Valueset for Iwi</p>
 </div>"
},
"url": "http://fhir-dev.healthintersections.com.au/open/ValueSet/nziwi",
"version": "1",
"name": "New Zealand Iwi",
"publisher": "HL7 New Zealand",
"contact": [ {
"telecom": [
{
"system": "email",
"value": "david.hay25@gmail.com"
}
]
} ],
"description": "The list of possible Iwi (tribes) for New Zealand",
"requirements": "Needed for an extension on Patient",
"status": "draft",
"experimental": true,
"date": "2015-06-13",
"define": {
"system": "fhir.hl7.org.nz/valueset/nziwi",
"concept": [
{
"code": "kt",
"display": "Kai Tahu"
},
{
"code": "np",
"display": "Ngāti Porou"
},
{
"code": "nt",
"display": "Ngāi Tahu"
},
{
"code": "np1",
"display": "Ngā Puhi"
},
{
"code": "nk",
"display": "Ngāti Kahungunu"
},
{
"code": "th",
"display": "Tūhoe"
}
]
}
}

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
http://hl7.org/fhir/2015May/terminology-service.html
• Find Terms
• Get Term
Definition

Exercise: Using a Terminology Server
• clinFHIR
– Resource builder (Condition)
– Condition.code
• Explore data set
– Direct REST query from filter

Profiling
• The basic resources are not enough
– Many different contexts in healthcare
• Specific implementations need to:
– Specify resources used
– Extend resources
– Constrain resources
– Specify code sets / terminologies
• Multiple supporting artifacts in FHIR
• FHIR is a platform specification
– Profiles adapt it to specific purposes
• Discoverability
• Profiling increasingly important
– Allows clinicians to express reqirements
– Tooling supports Clinicians and Analysts involvement
• Whole spec build on profiling infrastructure

Claiming conformance
• Profiles are like a template
– Servers indicate what profiles they support
– Clients can interrogate servers
• Resource instances ‘claim conformance’ to 1 or more profiles
– Libraries developed to test this
– Can be conformant without claiming
• Cannot set defaults
– Can state what a value should be

Extensions
• Only most common elements in base resource
– Keeps the resources small
– (Adding everything was the problem with version 3)
• Extensions allow other elements to be defined
– Same capabilities as core elements
• Including resource references and terminology bindings
• Extensions are normal
– Expect all real implementations to use extensions
• ‘normal’ and modifierExtensions
– Normal extensions can be ignored by a recipient
– Unknown modifierExtensions cannot be ignored

Profiling a resource
Specify that the identifier uses the
NHI – and is required
Limit names to just 1 (instead of 0..*)
Limit maritalStatus to different set of
codes (ValueSet)
Multiple Birth indicator only boolean
Indicate photo not supported
Add an extension to support
“Ethnicity”
Note: hardly any mandatory elements
in the core spec!

Published Profiles & Artifacts (Registry)
http://registry.fhir.org
Find & maintain
Retrieve & use

openEHR & FHIR
• FHIR defines interoperability model & transport
– Internal EHR formats don’t matter as long as they can map
– openEHR strong in data modelling
• Archetypes & Profiles are where mapping occurs
– Some differences:
• Archetypes are ‘maximal’, Profiles are context specific
• NZ Team working on this
– World leading
– Contact Koray Atalag to participate

Exercise: Creating a profile
• Profile on Patient – make the New Zealand Patient
– Add an extension for iwi
– Remove Photo (& some others)
– Make identifier single only, required and fixed to the NHI
• Then, create a resource based on that profile
• Will need:
– A ValueSet for Iwi codes
• (to hold the list of values)
– An Extension Definition (StructureDefinition) for iwi in Patient
• To define what it is
– A profile (StructureDefinition) for NZ Patient

Process
1.Build/Find registry resources
1. Show the ValueSet in XML editor (Oxygen)
2. PUT it to the registry using POSTMan
3. Create and save NamingSystem for NHI
2. Start clinFHIR
3. Select Patient as base
4. Create new Extension
1.Generally search first
2.Set to ValueSet
5. Show preview
6. Save
7. Create resource in Resource Builder

Exercise: Create a Profile
• Then use it to create a resource…

Conformance resource
• Indicate Server capability
– Also a desired solution or software capabilities
• API Details
– REST Interfaces
• Supported Resources
– Query Parameters
– Operations
• Messaging / Document Capability
• Supported Profiles

Implementation Guide
• Pull together all the artifacts for an implementation
– Eg New Zealand Patient
• Computable and directly renderable
• These include (eg from our exercise):
– Resources
• ValueSet
• StructureDefinition
• Conformance
• NamingSystem
– Documentation / other
• example resources
• pages
• Images
• Under active development

A Digital Ecosystem supported by FHIR
• Many independent systems
• Common understanding of things, and ways to share them
• FHIR is the way of organizing and sharing
A digital ecosystem is a distributed, adaptive, open
socio-technical system with properties of self-
organisation, scalability and sustainability inspired from
natural ecosystems.
Wikipedia

Establishing the ecosystem
Terminology
Security
Identity Repository
FHIR API and Resources
Registry

SMART: An ecosystem example
Included in project Argonaut

FHIR supporting the Ecosystem
• A common way to represent data
– Building blocks (resources)
– Rules for connecting them (references)
• Defines ways to move data around
– API (Simple & Complex)
– Messages
– Documents
• Links to supporting infrastructure
– Terminology
– Identity
– Security
• A large supporting community

Tooling
• Demo Servers
– Open Source
• Libraries
– Client & Server
– Java, c#, python
• Reference Implementations
• clinFHIR

The community
• Heaps of open source software
– Clients and servers
• Specification feedback welcomed
– Including update requests – tracker.
• Training events
– On-line webinars (eg FHIR academy)
– Connectathons – at WGMs and elsewhere – eg Aus
– ?demand in New Zealand
• Support channels
– Skype
– Stack Overflow
– Blogs
– Email / List servers

Where can we use FHIR: Revisited

Record Locator Service
Can also use messaging

Patient Portals
• Access to Primary Care/Community data
– Vendor agnostic (RESTful interfaces)
• Access to Secondary Care Data
– Vendor agnostic (RESTful interfaces)
• Access to other Portal data
– Or the repositories behind them (RESTful interfaces)
• Patient access / review of Shared data repositories
– Medications, allergies, encounters, documents (Resources)
– Annotate (Observation)
– Who has accessed data (AuditEvent)
• Patient data entry (Observations to Shared repository)
– Devices
– Other observations

EMR Integration
• Incoming
– Access to appointments (Appointment, Schedule, Slot,Operation)
– Patient Messaging
• Repeat prescriptions (Order, MedicationPrescription)
• Advice (Questionnaire)
– Shared Repositories (General REST - GET)
– Notifications (Subscription)
– Documents
• Document (DocumentReference, Binary)
• Outgoing
– Update repositories (General POST/PUT)
• Consistent coding (ValueSets)

Mobile Devices
• Very common access medium
• Real-time (REST/AJAX interaction, server side Operations for more
complex)
• Structured Data (Resources)
• Limitations
– Bandwidth (only include needed elements. Compress well.)
– Performance
– Processor / memory (apps focussed on specific functionality)

Convert v2-> FHIR Message
Or just extract individual resources…

Convert CDA -> FHIR Document
Or just extract individual resources

Where next in New Zealand
• Interoperability Reference Architecture update
• Think about Governance (Implementer support)
– Extensions, StructureDefinition, ImplementationGuide, ValueSets,
NamingSystem
– How best to structure with a community focus?
• Infrastructure
– Identity, Security, Terminology
• Funding
• Pilots
– What’s a good one to start
• ?Terminology Service
• ?Record Locator

Success Markers
• I’ve stirred your interest in FHIR
– Review the spec on the web
– Consider FHIR in your own projects
• FHIR features prominently in the Interoperability
Architecture refresh
• We have demand for more training or connectathons
• We have real pilots
• The MOH starts to think about FHIR in key interfaces
– NHI, NPI
• We consider a FHIR based national terminology service
• We start to think about the other ecosystem services

FHIR & Ice

More Related Content

What's hot

Viewers also liked

Similar to FHIR & Ice

More from David Hay

Recently uploaded

FHIR & Ice