Building FHIR Servers on Existing Applications Robert Worden

Building FHIR Servers on Existing
Applications
Robert Worden
rpworden@me.com
Outline
•
•
•
•
•
•
•
FHIR and CDA
Building FHIR Servers and Clients
Mapping Application Databases to FHIR
FHIR Server Demo
FHIR Client for Multiple Servers
FHIR and Data Matching
CDA-FHIR Bridge
More Meaningful Use of CDA
• When reading a CDA, a physician is not just a blank slate
for new information.
• Often, he or she knows about the patient already.
• The physician needs to compare the new information in the
CDA with what they already know.
• Their knowledge of the patient may be stored in an EMR.
• Comparing requires matching of information from the CDA,
with information in the EMR:
– Match and identify the patient
– Match clinical data for the patient (e.g. allergies, medications,..)
• Then (possibly) make updates to the EMR, at the physician’s
discretion
Architecture for CDA Match/Compare
Patient Search
Parameters
CDA Handler Module:
CDA
•Extract patient data from CDA
•Search and match patients
•User chooses the matching
patient
•Extract clinical information
from CDA
•Compare with clinical
information from application
• (User choice of updates to the
application)
Candidate Matching
Patients
Selected Matching
Patient
Clinical Application
(e.g. EHR)
Patient Clinical
Information
(Updates to Clinical
Information)
Few clinical applications support this now.
FHIR-enabled CDA Match/Compare
User
Searches on
Patient
Patient
Resource
CDA
Candidate
Patient resources
search
FHIR
CDA-FHIR
Bridge
Searches on
Clinical
Resources
Clinical
Resources
Search,
Match and
Display
(FHIR
client)
data
FHIR
Searches on
Clinical Resources
Clinical
Resources
FHIR server
adapter for
application
Clinical
Application
(update)
(Updates to Clinical
Resources)
Three components simplify implementation.
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 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 IHE PDQ (HL7 V2.5)
FHIR Search
QBP^Q22
FHIR
Patient
Server
Patient
Resources
Patient
Demographics
Supplier
RSP^K22
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
• An 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)
Searching Multiple FHIR Servers
CDA-FHIR Bridge
• Enables any incoming CDA as a small FHIR server
• The CDA ‘server’ supports FHIR searches on common
resources (Patient, AllergyIntolerance,...)
• This is not a full transform from CDA to a FHIR
Composition resource; extracting specific FHIR
resources is much easier
• Transforms depend on CDA templates
• There will be a different bridge for each CDA profile
• There is no dependence on the EHR application – the
bridge is universal for each CDA profile
• Easy to build
The CDA-FHIR Opportunity
Applications
FHIR-enabled
for other
reasons
Build
CDA-FHIR
bridges
FHIR-enabled
applications can
easily make
Meaningful
Use of CDA
More applications
FHIR-enabled, to
make meaningful
use of CDA
More
takeup of CDA
Easier to make
meaningful use
of CDA
Virtuous Circle
FHIR Mapping Tools:
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