Ihic preso v2

Future Directions:
FHIR in New Zealand
(a personal opinion)
Dr David Hay
Chair HL7 New Zealand
Orion Health Product Strategist
October2013

Agenda
• Interoperability Architecture
• Progress
• (possible) place for FHIR

Page 2 • Copyright © 2013 Orion Health™ group of companies • All rights reserved

Interoperability Reference Architecture

Interoperability Reference Architecture
• Developed at the end
of 2011
• Supporting the Vision
– A patient
focused, integrated
healthcare
model, based on
shared care

• Scope of document
– An architecture for
inter-system exchange
of Health Information


• 3 Pillars
– CDA documents as units of exchange
– XDS as the registry/repository
infrastructure
– openEhr Archetypes as models

Health Information Exchange

Regional Data
Store

FHIR Resources

FHIR
REST/Service

Clients:
Browser
Other system (HSA, GP PMS)

Progress since then
• Some completed projects
–
–
–
–
–

GP2GP
eReferrals
ePrescribing
Canterbury eSCRV (Shared repository Clinical Data)
Auckland testsafe (Shared Lab data)

• Currently developing CDA ‘profiles’
– Highly constrained
– Common templates
– Medications & Allergies

• XDS
– Recent EOI
– Not actual users at the moment

• Archetypes
– Pilot using CKM for medications (Thanks to Ocean Infomatics)


Where FHIR could make a difference

Possible Use Cases for FHIR
• Will consider 3 possible scenarios for FHIR
– Identity Service
– XDS Document Registry / Repository
– Master List of Medicines

• High level only
– Eg security/privacy not discussed

• Not official NZ policy!


Quick techie summary
• Examples using REST
– Real time interaction
– Would use messaging / documents where appropriate

• HTTP Verbs (CRUD)
–
–
–
–
–

POST: Create
GET: Retrieve (specific resource & search)
PUT: Update
DELETE: Deactivate
OPTIONS: Conformance

• Profiles
– Statement of use

• Conformance
– What can a server support

• FHIR supporting an ecosystem


1. Identity Service
• Existing Patient and Provider Registries
– Patient identity Service
• National Health Identifier (NHI)
• First established in 1993
• Recently re-platformed
– IBM Initiate
– Exposing some web services
– Provider Identity Service
• Health provider Identifier (HPI)
• Part of the NHI re-platforming

• Why FHIR
– Simple lookup (90% of use)
– Increase uptake – especially in community care

• Current progress
– Just an idea


Architecture


Identity Service: possible FHIR interfaces
• Resource
– Use Patient resource with extensions (Iwi, Hapu...)

• Interfaces
– Find (search for) a patient
• GET /patient?name=eve
– Get details for a known patient
• GET /patient?identifier=PRP1660
– Notify of updates
• PUT /patient?identifier=PRP1660
– Likely have workflow not direct update
– Register new patient
• POST /patient
– Likely have workflow not direct update


2. Document Registry: IHE XDS
• An architecture to support distributed document repositories within an
‘affinity domain’ managed by a single registry/index
– Allows repositories to maintain stewardship with common governance
– A number of existing repositories
– Many ways to extend if needed

• Well accepted internationally
• In NZ, we only need 1 Registry
– And we already have the Identity registry

• Why FHIR
–
–
–
–

‘Native’ XDS interfaces are complex. FHIR interfaces are simpler to implement
Other deployment possibilities
Resource tags for fine grained privacy
Other functionality – eg Notifications, Audit trail to consumers

– Current project to develop pilot


The standard IHE Model


Document Registry: FHIR Equivalent


3. My List of Medicines
• Key importance of a common view of current medications and
medication history
• Some existing infrastructure
– Testsafe & eSCRV (Auckland & Christchurch) with dispensing data
– Is an ePrescribing pilot

• Why FHIR
– CDA model is complex – especially with local extensions
– No obvious alternative transport (other than CDA documents via XDS)

– Concept of the shared repository of medication data well established
– Working on model for medications
• Archetypes
– CDA templates for medications
• Constrained to our models
• Mapped to FHIR resources (experimental)


Big Picture
Resources
• Medicine
• MedicationPrescription
• MedicationDispense
• MedicationAdministration

• Order
• Provenance
• List


Interactions / Use Cases: Examples
• Get current list of medications (MLOM)
– GET /Patient/<patient ID>/List?code=meds (if you have the patient ID)
– GET /List?code=meds&subject.identifier = <identifier> (if you don’t)

• Update the MLOM
– PUT /List/<listID> (with an updated List)

• Get history of changes to the MLOM
– GET /List/<listID/_history

• Get all dispensings
– GET /MedicationDispense?patient=<patient ID>

• Get all administrations
•

•

GET /MedicationAdministration?patient=<patient ID>

Prescribe
•

POST /Order (Containing MedicationPrescription in Order)


Local Activity
• Vendors
– Orion Health
• Putting significant resources into FHIR developments
• Attendance at connectathons
• XDS interfaces
• Mobile Medication Administration project
– Sysmex
• Attendance at connectathons
• XDS interfaces
• Lab Order interfaces

• HINZ 2014 Developer challenge
– Encourage innovative development, especially new entrants
– Encompass connectathon concept
– In planning stage now...


Conclusion
• The ‘shared repository’ model is established in NZ
• FHIR
–
–
–
–

Adds missing parts (especially the transport & query)
Much easier to implement
Enables the ecosystem
Enables the patient

• Progressing with a number of pilot implementations
– XDS
– Some internal projects

• HINZ Developer Challenge
• Shameless self-promotion
– www.fhirblog.com


Ihic preso v2

Recommended

Recommended

More Related Content

What's hot

What's hot (13)

Similar to Ihic preso v2

Similar to Ihic preso v2 (20)

More from David Hay

More from David Hay (9)

Recently uploaded

Recently uploaded (20)

Ihic preso v2

Editor's Notes