FHIRing on all cylinders Key benefit of early adoption of technology is that there is still room to find awful puns! Dr Dunmail Hodkinson Chief Technology Officer Black Pear Software Ltd dunmail@blackpear.com @dunmailh @blackpearsw www.blackpear.com

Black Pear Software SME Founded 2009 by David Jehring Team with a long history of HIT innovation, especially in UK primary care Goal to exploit latest technology in healthcare In England, GPSoC Supplier (Lots 1&2) for provision of mobile clinical applications Technology partner of INPS, supplying their Vision Anywhere product. Technology partner of EMIS, extending reach of partner API.

Why FHIR? Historically, we’ve been averse to using standards e.g. HL7v3, CDA, High complexity, high cost and poor match for small agile projects. Usually these have been a complicated way of doing something easy. Unusual for us to be in a position evangelising about a HIT standard.

Core components enable us to rapidly build and deploy health apps Goals Core components enable us to rapidly build and deploy health apps Enabling components enable us to construct total solutions where apps interoperate with other components of the health system Our focus is health apps. Importantly, health apps that interoperate with other parts of the health system. Not another silo. Important to achieve integrated health and social care. APIs aren’t our core business BUT are a key part of our vision GP systems are of huge interest - richest records, opportunity for changes in practice to exploit new tech The existing APIs don’t meet our needs, so need to provide our own as interim solution until the world catches up! We needed to have a common api model and common data representation.

Wish list Stateless HTTP API Compatible with JS and iOS tooling Open international standard Our wishlist for an API isn’t complicated: HTTP APIs can be accessed anywhere we can route TCP/IP traffic e.g. LAN, WiFi, 3G, GPRS, satellite. Security controls are established at network level e.g. TLS-MA, HTTP Basic, OAuth Stateless APIs scale and are easier to work with. API needs to be compatible with our existing tooling (Javascript, iOS), preference for JSON over XML. Open, international standards are preferred Standard so we don’t have to invent our own proprietary standard Open so we can use i freely, as we see fit International so we’re not constrained to just England or UK

FHIR Our shortlist had one serious entry - FHIR! In the middle of 2013, there were plenty of risks. FHIR DSTU1 had not been released FHIR not adopted by HL7 Resources were evolving BUT surely we weren’t the only people with the same needs? Gambled on the standard evolving fast enough to keep up with our needs!

Approach Our interest was in providing APIs to allow us to interoperate with UK GP systems

Plan Use existing and available proprietary APIs Adapt proprietary APIs to a common API Use common APIs to support desktop apps and web-services Use proprietary APIs - need a realistic starting point

Implementation EMIS Partner Program API (client & service) INPS Vision 360 API (client & service) TPP SystmOne GPSoC IM1 API (client) Microtest Evolution GPSoC IM1 API

Production Urgent Care Centres INPS-EMIS interop EPaCCS Urgent Care Centres - mixed economy of GPs (EMIS, INPS, TPP), booking appointments into an UCC, with transmission of a clinical precis and return of appointment outcomes pyrusConnect being deployed as a component to allow them to retrieve patient records from EMIS Web and to allow Use to allow creation of EPaCCS forms to be shared amongst palliative care teams in Worcestershire.

Lessons

Constraints FHIR maturity Encounter resources weak for GP data Existing APIs better as Documents? Different patterns to read and write? resources FHIR model is still evolving. Resources may change or disappear. For example, we used some Appointment related resources from the development version and these have now disappeared or changed. Core resources getting more settled as move towards DSTU2. Encounters don’t map well to the UK primary care data model. UK GP systems group events within encounters Not all resources reference an Encounter Order of observations within encounters can be significant e.g. observed rash, administered medicine is a different story to administered medicine, observed rash Existing APIs are not granular in the way envisaged by FHIR May be more appropriate to present GP data as profiled documents e.g. medicine statement, summary record, full record etc. May use compartments to provide a patient oriented view Existing APIs are constrained in how data can be written. This is not a unique challenge in health - write operations often require coordination e.g. CQRS design pattern May be best to avoid writing data in a granular way and instead use a message-oriented approach

Fragmentation? National guidance National adoption We’re ahead of the game, but there is a groundswell of engineers using FHIR There is a danger that we end up with many local variants and interpretations and eventually a very fragmented ecosystem. The first steps are quite simple e.g. What system do we use for NHS Number? Would benefit from national guidance sooner rather than later! Adoption and support from national programs would be good (GPSoC IM2) BUT (please!) not too prescriptive. Need to allow room for innovation (cf Non-coded CDA)

It works! Easy to implement a common API FHIR APIs are accessible to software engineers The barrier to interoperability is lowered Easy to implement a common API A more detailed analysis conducted with EMIS showed that around 95% of their proprietary clinical model could be implemented in FHIR. FHIR APIs are a good fit for modern development tools and practices. Provided a MPI using a FHIR api for the Code4Health platform. Engineers with no prior health IT experience were able to search for patients and understand the resources in less than 15 minutes using a variety of tools. Interop can be easy. Easier? By reducing the complexity of software engineering for interoperability, we free resource to deal with the areas that matter - solving interoperability at a clinical level and the provision of great UX.

Chief Technology Officer Black Pear Software Ltd Dr Dunmail Hodkinson Chief Technology Officer Black Pear Software Ltd dunmail@blackpear.com @dunmailh @blackpearsw www.blackpear.com