FHIRFarm –
How to build a FHIR Server Farm
(quickly)
Robert Worden
rpworden@me.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
Relational
Database
FHIR
Adapter
FHIR
Adapter
Business
Logic
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
1. FHIR Search => Search commands for internal
data structures
2. Internal data structures => FHIR resource
3. 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
M
FHIR class
model
(EMF Ecore)
B
FHIR Java
reference
implementation
FHIR
serialisation
(XML or JSON)
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)
Browser
Client
Application
http
FHIR
MultiServer
jdbc
Relational
Database 1
Relational
Database 2
Configuration
Configuration
File
Configuration
File
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.
• Write operations: The tools generate the required data
transforms, but will always require business logic
• Documentation of the Open Source Tools: Real soon now
• FHIR Server Configuration Service: ask rworden@me.com