adding fhir interfaces to legacy systems · designed by mike lapshin, health samurai (lesson #1,...
TRANSCRIPT
HL7®, FHIR® and the flame Design mark are the registered trademarks of Health Level Seven International and are used with permission.
November 20-22, Amsterdam | @HL7 @FirelyTeam | #fhirdevdays | www.devdays.com
Adding FHIR Interfaces to Legacy Systems
Pavel Smirnov, Health Samurai
Why do you need an API facade for your healthcare app at all?
•Extend existing legacy solution with new modules• Share data with external services•Perform operations by external requests
FHIR facade - how?
• Storage-less API facade•API facade with an intermediate FHIR server
Storage-less API facade
Translate FHIR REST calls to queries to the underlying database or services of the original system.
Storage-less API facade: Pros
No duplication of data (single source of truth) -> Minimal computing resources
Storage-less API facade: When to use
• Simple use cases when you need to implement a few individual API endpoints.
API facade with an intermediate FHIR server
Data is translated to FHIR and synced with a FHIR server that exposes it over API
API facade with an intermediate FHIR server: Pros I
Full control over the performance of every call - excellent performance
• even on complex FHIR search queries• even if the original data is distributed among several legacy
systems• even if legacy systems sometimes are not accessible
API facade with an intermediate FHIR server: Pros II
Data is synced from the legacy system only once, even a high-load of FHIR calls will not affect the users of the legacy system
API facade with an intermediate FHIR server: Pros III
Using a full-blown FHIR server allows you to build the whole new ecosystem of modern FHIR-first apps on top of it
You can ultimately move from legacy to the FHIR-first ecosystem
API facade with an intermediate FHIR server: Cons
Data is stored twice
• Double cost of computer resources• FHIR data can be different than at the source at times
API facade with an intermediate FHIR server: When to use
Any time unless you have a simple use case and confident about the success of storageless approach
Translation of data to FHIR
Open source mapping language called JUTE (JSON Uniform TEmplates)
https://github.com/HealthSamurai/jute.clj
Designed by Mike Lapshin, Health Samurai (lesson #1, always to have a valid international passport for traveling)
JUTE mapping example
Show demo!
We use it for other translations too e.g. HL7 v.2 to FHIR
JUTE qualities & benefits
• Declarative• Readable• You do not need to be a programmer to use• Open source
Amazing things happen with FHIR
Thank you!
Pavel Smirnov, CEO, Health Samurai
Phone: (818) 731-1279
Email: [email protected]
Website: https://health-samurai.io
@paul_smirnoff
www.devdays.com