ihic preso v2

Future Directions:FHIR in New Zealand (a personal opinion)

Dr David HayChair HL7 New ZealandOrion Health Product Strategist

October2013

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

Agenda

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

Click icon to add picture

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:BrowserOther 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)

Click icon to add picture

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

• Current progress– 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

www.orionhealth.com

ihic preso v2

Technology

new patient post patient

fhir cda model

known patient

fhir equivalentpage

fhir native xds interfaces

identity registry

server support fhir

fhir simple lookup