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

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

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

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

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

13. 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!

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

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

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

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

23. Lessons

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

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

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

31. Chief Technology Officer Black Pear Software Ltd
Dr Dunmail Hodkinson
Chief Technology Officer
Black Pear Software Ltd