FHIR Transform Engine Robert Worden Open Mapping Software

FHIR Transform Engine Robert Worden Open Mapping Software Ltd rpworden@me. com

Summary • NHS strategy mandates interoperability, and the preferred route uses HL 7 FHIR. • FHIR is supported by NHS England, providers, and suppliers • Hundreds of healthcare applications will need FHIR interfaces, to interoperate • This requires two-way transforms between FHIR and local or proprietary APIs • Transforms can be developed in one of two ways: – In code – By a mapping and transform toolkit • Mappings have many advantages: – Quicker, cheaper to develop – Mappings are visible and maintainable – Mature test tools • The FHIR Transform Engine has the required capability • It is easy to adopt and use now: – Open Source runtime translator – Development tools free to NHS organisations – Training and support are available

Transforms by Mappings • Eclipse-based mapping toolset • Capture automatically the structure you are mapping from (e. g. XML, RDBMS) • Capture automatically the FHIR profiles you are mapping to • Manually map nodes from the structure to FHIR (graphical mapping tool) • Tools auto-generate transforms in both directions • Rapid iterative map/test/map/test cycle • Complex structure transforms are handled by mappings (e. g. flat => nested) • Escape to code for tricky local requirements (e. g. map to Snomed codes) • Open source runtime (Java, XSLT, more to come. . ) • Need to know foundation concepts of mapping – training is available.

Making Mappings (V 2 to FHIR example) V 2 structure FHIR structure Examples for testing Mappings on Nodes Table view of mappings

Testing Mappings (V 2 to FHIR) Summary test scores Result of V 2 to FHIR transform ABA = V 2 to FHIR to V 2 round-trip AB = V 2 to FHIR transform All test Result files Example files used in this test A, B = codes for test files Mappings being tested

Benefits of FHIR Mapping • Defining one set of mappings is quicker and cheaper than writing code – to transform in 2 directions. • Design decisions in mappings are open and reviewable; not hidden away in code • Fast iterative development cycle (map/test/map/test. . ) • Mappings are easy to maintain (e. g. as profiles evolve) • Round-trips (FHIR => Native => FHIR) are free, self-consistent and testable • Reduces costs of development, testing, maintenance • Existing Implementations: – PAS (FHIR mapped to Relational Database) – HL 7 V 2 ADT to FHIR – EMIS Open XML to FHIR

Healthcare Applications as FHIR Servers Client A Server B User Interface Business Logic Relational Database FHIR Transform Engine Business Logic Relational Database

FHIR RESTful Search • FHIR servers have to support many RESTful searches • By mapping FHIR directly onto a Relational DBMS: – Mappings automatically translate RESTful search strings into SQL (RDBMS) or HQL (Hibernate), to do the required search. – This supports many different types of search, without coding – Uses database indexes for efficient retrieval • You can still map to a higher-level API to use the application’s business logic (e. g. for updates) • The runtime Transform Engine runs in a web server (e. g. Tomcat) • This is the fastest way to create a FHIR server on an existing healthcare application