Presentation is loading. Please wait.

Presentation is loading. Please wait.

Building FHIR Servers on Existing Applications

Similar presentations

Presentation on theme: "Building FHIR Servers on Existing Applications"— Presentation transcript:

1 Building FHIR Servers on Existing Applications
Robert Worden

2 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

3 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

4 Architecture for CDA Match/Compare
Patient Search Parameters CDA Handler Module: 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) Clinical Application (e.g. EHR) Candidate Matching Patients CDA Selected Matching Patient Patient Clinical Information (Updates to Clinical Information) Few clinical applications support this now.

5 FHIR-enabled CDA Match/Compare
User Searches on Patient CDA-FHIR Bridge Search, Match and Display (FHIR client) FHIR server adapter for application Clinical Application Patient Resource Candidate Patient resources search CDA FHIR data FHIR Searches on Clinical Resources Searches on Clinical Resources Clinical Resources Clinical Resources (update) (Updates to Clinical Resources) Three components simplify implementation.

6 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

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

8 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.

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

10 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 interested in Relational Database <=> FHIR

11 Mapping a Relational Database to the FHIR Patient Resource

12 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

13 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!

14 Demo of FHIR Server Farm

15 FHIR and IHE PDQ (HL7 V2.5) FHIR Search QBP^Q22 Patient Resources
Server QBP^Q22 Patient Demographics Supplier Patient Resources RSP^K22

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

17 Searching Multiple FHIR Servers

18 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

19 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

20 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

Download ppt "Building FHIR Servers on Existing Applications"

Similar presentations

Ads by Google