Towards a FHIR based API Lessons learned in supporting interoperability for OpenMRS

Suranga Nath Kasthurirathne

What we will cover

• Interoperability AKA the problem domain

• The OpenMRS story: Room for improvement

• The advantages of FHIR

• Project scope

• A short demonstration

• Our aspirations

The existing landscape

• Healthcare quality is enabled by the accessibility and effective use of clinical data

• Clinical data is being collected across the globe in numerous ways

• Modern healthcare is distributed by nature

• Clinical information systems are often implemented in an ad-hoc manner. – These limitations have led to the fragmentation of

health information

Observations

• To ensure healthcare quality, we need data

• We have enough data, but not when and where we need it

• Data must be available where needed, when needed

• We need data exchange

Interoperability and standardization

• Decades old domain

• Numerous competing standards

– HL7, DICOM etc.

• Wide range of commercial tools / API’s

– Mirth, HAPI, NHAPI, Everest

Have these accomplished their goals?

The OpenMRS story

• Open Source Medical Record System, since 2004

• Strong data model based on HL7 V2

• Interoperability not supported as a core functionality

• Users write their own modules to support interoperability

OpenMRS & Standards : Current status

HL7 V2 Import Yes ADTA08 & ORUR01 in OpenMRS core, RGRTA module(ORU,ADT), CHICA module (ADT, ORU,VXR,VXX)

HL7 V2 Export Yes HL7Query module, RGRTA module(ADT,ORU), CHICA module (ORU,VXQ, VXU)

CCD Export Yes Export CCD module (GSOC)

CCD Import No RGCCD module

CDA Export Yes… CDA Generator module (GSOC)

CDA Import No

Challenges

• Maintenance and reuse

– Multiple modules support the same requirements

– Maintenance and generalizability issues

• Problems with HL7 V2 and V3

– Abstruse, hard to understand

– Perceived as a specific expertise

– Not human friendly

OpenMRS needed a more robust approach

• But what did we need?

– Support standardized data exchange

– Support easy data exchange

– Support standardization as part of core OpenMRS

– Support a standard that’s willing to be ‘opened’

FHIR

• Fast Health Interoperable Resources

• The latest and the greatest

• Combines the best features of HL7’s Version 2, Version 3 and CDA

• Published as a Draft Standard for Trial use

• Will (eventually) become a full normative specification (in 2016?)

• Currently undergoing rapid adoption

HL7 V2 Vs. CDA Vs. FHIR

• Practical applications– CDA is restricted to clinical settings. V2 and FHIR can be used in

other contexts as well.

• Reusability– V2, CDA and FHIR are all built around the idea of re-usable

segments, but only FHIR segments maintain truly independent identities

• Human readability– V2 offers NTE segments, FHIR and CDA require human readable

content for all resources

• Messaging paradigms– V2 supports event based messaging. CDA does documents.

FHIR does both, plus REST and service models

HL7 V2 Vs. CDA Vs. FHIR Contd.

• Extensibility– V2 offers Z segments whose meaning is opaque unless prior

communication by sender. In comparison, the meaning of FHIR extensions are discoverable by resolving the URI that defines each extension

• Cleanliness– V2 messages are the most cluttered , CDA less cluttered, FHIR

least cluttered

• Relationship to non-HL7 Standards– FHIR resources can provide direct implementation of

functionality from other standards such as DICOM

• JSON– FHIR supports JSON

Why FHIR stands out…

• Is for developers

• supports JSON

• Modular by design

• In DSTU, and willing to listen to our needs

• Plenty of interest

• Adoption by major players

– Project Argonaut

FHIR

• Types of resources– Clinical

– Administrative

– Architectural

Bundles

Profiles

Supports traditional messaging and document approaches

How to imagine a FHIR resource ?

• Roughly, a FHIR Resource = V2 Segment = CDA Section

• Is ‘self- aware’

• Can be independently manipulated

• Uses references

– If a resource contains other resources, it will include only a ‘reference’

OpenMRS and FHIR

Design Considerations

What do we want ?

• A minimum implementable unit

• A minimum implementable unit that advises implementers

• A minimum implementable unit that is actually wanted

• This is NOT just a development exercise. It’s a learning, teaching and building exercise

Acceptable “excuses”

• Too difficult (for phase one)

• The scope is too broad (for phase one)

• Our implementers won’t care (for now)

• Re-use

– “Look, we can re-use that.. And that, and that and that..”

Use cases

• Develop basic import / export

– Patient, practitioner, Location, Encounter, Observation etc.

– Develop basic search patterns

• Support practical applications

– SMART on FHIR

The SMART Platform: Pediatric growth chart

OpenMRS FHIR demo

The GRAND plan

• How far can we go with FHIR?

• If there are standards, why do we need to ‘learn’ API’s?

• The EMR API is not a standard.

– Why cant it be?

– Why shouldn't’t it be?

• Why do we need a (domain specific) domain model

• Scenario 01: Making an API call

–Result: OpenMRS objects

• Scenario 02: Making a restful call

–Result: OpenMRS resources

• What if instead, we returned FHIR resources?

Thanks to…

• The usual suspects:– Dr. Paul Biondich– Dr. Burke Mamlin– Harsha Kumara (does my work for me)

• New partners in crime:– Grahame Grieve– Lloyd McKenzie– David Hay– Josh Mandel (SMART)– James Agnew (HAPI)

Resources

• OpenMRS project page : https://wiki.openmrs.org/display/projects/Building+FHIR+support+for+OpenMRS

• FHIR Documentation : http://hl7-fhir.github.io/

• Mailing lists : fhir@lists.hl7.org / dev@openmrs.org• FHIR Reference implementation :

http://www.hl7.org/documentcenter/public/standards/FHIR/fhir-0.0.81-Java-0.81.zip

Contacts : surangak@openmrs.org