slide deck - Open Mapping Software

Download Report

Transcript slide deck - Open Mapping Software

FHIR Transform Engine
Robert Worden
Open Mapping Software Ltd
[email protected]
Summary
• NHS strategy mandates interoperability, and the preferred route uses HL7
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 (V2 to FHIR example)
V2 structure
FHIR structure
Examples
for testing
Mappings
on Nodes
Table view of mappings
Testing Mappings (V2 to FHIR)
Summary
test scores
Result of
V2 to FHIR
transform
ABA = V2 to FHIR to V2
round-trip
AB = V2 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)
– HL7 V2 ADT to FHIR
– EMIS Open XML to FHIR
Healthcare Applications as FHIR Servers
Client A
Server B
User
Interface
User
Interface
Business
Logic
Relational
Database
FHIR
Transform
Engine
FHIR
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