FHIRFarm – How to build a FHIR Server Farm (quickly) Robert Worden robert@OpenMapSW.com

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

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)

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

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)

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.

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)

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

Mapping a Relational Database to the FHIR Patient Resource

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

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!

Demo of FHIR Server Farm

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)

Comparative Query Tool Demo

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

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 robert@OpenMapSW.com