FHIRFarm – How to build a FHIR Server Farm (quickly) Robert Worden
Transcription
FHIRFarm – How to build a FHIR Server Farm (quickly) Robert Worden
FHIRFarm – How to build a FHIR Server Farm (quickly) Robert Worden [email protected] 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 [email protected]