Robert Worden robert@OpenMapSW.com

• 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 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)

Client A
Server B
User
Interface
User
Interface
Business
Logic
FHIR
Adapter
FHIR
Adapter
Business
Logic
Relational
Database
Relational
Database

• (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)

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.

• 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)

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

• 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

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

• 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)

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

• 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