1. FHIRFarm – How to build a FHIR Server Farm (quickly)
Robert Worden

2. Outline FHIR Current Status Building FHIR Servers and Clients
Mapping Application Databases to FHIR
FHIR Server Demo
FHIR and Data Matching
FHIR and NHS Technology Strategy

3. FHIR – Current Status
FHIR is a new HL7 standard for healthcare interoperability
Designed with implementers in mind
‘80% rule’ limits complexity of FHIR core
Broad (but still shallow) coverage of healthcare domains
Currently finalising first DSTU
Much easier to implement than other recent HL7 standards.
Rapidly being adopted by suppliers, providers, national programmes, e.g:
Statement of direction for US ‘Meaningful Use’
Adopted by NHS for e-Referrals (Choose and Book)
Providers will want to adapt multiple existing applications to be FHIR servers and clients (a FHIR Server Farm)

4. Building FHIR Servers and Clients from Existing Applications
Client A
Server B
User Interface
User Interface
Business
Logic
FHIR
Adapter
FHIR
Adapter
Business
Logic
Relational
Database
Relational
Database

5. What FHIR Adapters Do
(Client) compose a FHIR search request (e.g. for a Patient Resource, with given NHS number).
(Client) send the FHIR search request
(Server) translate the FHIR search request into search commands for its internal data structures (e.g. SQL)
(Server) translate the results of internal searches (e.g. SQL ResultSets) into FHIR resources
(Server) send a bundle of FHIR Resources
(Client) translate the FHIR resources into its internal data structures (e.g. RDBMS records)

6. Three Kinds of Data Transform
FHIR Search => Search commands for internal data structures
Internal data structures => FHIR resource
FHIR resource => Internal data structures
Do you need to write software to do this? No:
All three types of data transform can be generated
from one set of declarative mappings.

7. Mapping and Transformation Toolset
Define a Logical Model of information to be exchanged (UML, expressed in Eclipse Ecore)
Define Mappings of any physical data structure onto the Logical Model
Mappings state precisely how the physical data structure represents information in the logical model.
Mappings are declarative and easily testable.
Open Source tools are used to define, validate, and test the mappings.
The same tools generate any-to-any transforms between the data structures (in Java or XSLT)
Generated transforms are precise and testable (e.g. round trip tests)

8. Mappings, Transforms, and FHIR
CDA XML Structure
M = mappings
B = Bridge M
V2 XML Data Structure
FHIR class model
(EMF Ecore)
FHIR Java reference implementation
FHIR serialisation (XML or JSON) M B M
Relational Database Structure
Any-to-any transforms can be generated from the mappings.
We are mainly interested in Relational Database <=> FHIR

9. Mapping a Relational Database to the FHIR Patient Resource

10. FHIR Server Farm Web service under Tomcat
Currently two FHIR servers, created by mapping Relational Databases to FHIR resources:
PAS system database
‘Noddy’ patient database (1 table)
Jdbc access to the databases
Read-only FHIR servers for the Patient resource
Support a range of Patient searches
Each server is defined entirely by configuration files
No database-specific or resource-specific code

11. FHIR Server Farm Architecture
Web server (e.g. Tomcat)
Relational
Database 1
Browser
jdbc
http
FHIR
Multi-Server
Relational
Database 2
Client Application
Configuration File
Configuration File
Configuration File 3
Relational
Database 3
No Database-specific or Resource-specific code!

12. Demo of FHIR Server Farm

13. FHIR and Data Matching
As soon as a provider has two or more FHIR servers for the Patient resource, they can compare the Patients across them (in the common FHIR representation).
An application can interrogate the different FHIR servers, and compare the results
The Open Source Comparative Query Tool can compare across the servers, in terms of the FHIR Patient class model
Bulk data matching and de-duplication can be done across databases (proprietary tool)

14. Comparative Query Tool Demo

15. FHIR and the NHS Technology Strategy
Connect All – retain existing applications, but make them talk to each other
Open APIs - to let one application request data from another
NHS Number - as unique patient identifier across all applications
FHIR is the best candidate standard Open API
The fastest route to do this: enable all key applications as FHIR servers, using FHIRFarm with configuration files
Scope – PAS, MPI, Patient Portal, e-dispensing, lab, ....
Proposal: Implement Spine Mini-Services as a FHIR server (then SCR,...)

16. FHIRFarm: Work In Progress
Deployment: currently deploying a FHIR Patient server for an NHS Trust; more are planned
Searches: extend capability to more types of search, e.g. date range, alternative values,...
Extensions: can hide the extra complexity of FHIR extensions – extensions are identical to core features, in the Ecore class model and in mappings.
Resource Narrative: defined in xhtml configuration files
Write operations: The tools generate the required data transforms, but will always require business logic
Public Demo Server Farm: Real soon now
Documentation of the Open Source Tools: Real soon now
FHIR Server Configuration Service: ask