Fhir seminar hinz 2015

FHIR in New Zealand:A Clinicians perspective

HL7 New Zealand, October 2015

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

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

• 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?

Why Standards

Why FHIR

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).

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.

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)

BENEFITS TO IMPLEMENTERS AND HCOS

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

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 inas FHIR is adopted by source systems

BENEFITS TO CLINICIAN AND PATIENT

Benefits to Clinician

• Improved access to higher quality, patient information

• Greater choice and variety of applications to support clinical workflow.

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.

Small Print

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

Tools

• Specification• clinFHIR

– Visualization– Link to spec – Resource Builder– Profile Builder

• Forge

Fundamentals: Resources

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

Resources – sample list

Resource anatomy

• Resources have 4 main parts

23

StructuredData

Extensions

Narrative(text)

Metadata

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

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– 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

Resource view

(All refer to patient)

Screen dump

Fundamentals: Exchange Patterns

Exchange Patterns

32

REST

Documents Messages

Services(API)

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

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

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

35

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

FHIRRepository

Regardless of paradigm, the content is the same

Lab System

FHIR Message

FHIR Document

NationalExchangeREST

Re-visiting the consultation…

As a document…

…or a Message

Fundamentals: Terminologies

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)

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

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

CodeDisplay

Definition


Value Set:A selection of a set of codes for

use in a particular context


coherent meaning

CodeDisplay

Definition

Selects



coherent meaning

CodeDisplay

Definition

Element Definition: Type and Value set reference



Selects Binds



coherent meaning

CodeDisplay

Definition

Element Definition: Type and Value set reference



Selects Binds

Element: code/

Coding/CodeableConcept

Refers toConforms

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– 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)

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

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

Profiles: An overview

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

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

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!

Profiles: Constraining Resources

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.

Profiles: Extending resources

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

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

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

66

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 definitionCan be (and probably are) on different servers

HTTP://server/StructureDefinition/nzpatientwi

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

Establishing the ecosystem

Terminology

Security

Identity Data

FHIR API and Resources

Conformance

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?

Fhir seminar hinz 2015

Healthcare

Transcript of Fhir seminar hinz 2015