An overview of architectural design considerations when selecting how to add a FHIR interface to your solution. Presented at a HL7 New Zealand Conference in June 2016

1. FHIR SERVER
DESIGN REVIEW
Brian Postlethwaite
June 2016
® ©

2. Server Types
• Generic Server
• Publish/Sync
• Façade
• Cache
Database Structures
• Blob Store (XML or json)
• Atomised Data (Full ER Model)
• View (Façade-ish)
• Hybrid
Overview

3. FHIR SERVER
TYPES

4. Server is pure FHIR
Not intended to handle other formats
No requirements from legacy systems
Do not require content conversions
Storage options very flexible
Can optimise storage
Can optimise indexing
Security considerations
Generic FHIR Server

5. Utilize a separate FHIR server
Content extraction
Content conversion
Storage/indexing/searching FHIR server
problem
Synchronization timing and scope
2 way changes?
Security?
Publish / Sync

6. • Expose a FHIR interface to existing system
• Content conversion on the fly as required
• Complexities of conversion of queries onto
existing structures
• Security applied by source
• If using views, updates can be challenging
• All server load is directly applied to the source
services/tables
• How to handle history?
Facade

7. Basically a Façade and a generic FHIR in one
Cache the content that was returned
Content required can be returned quickly
Security applied by source
Indexes can be:
• in replicated content
• views on the source data
• Synchronized from source data
Load an be minimized from the source data to the
cache content
History can remain in the cache
Cache

8. DATABASE DESIGN

9. Native content format (xml/json)
Extensions stored in place
No need to assemble
May require object model conversion between
formats
Indexing considerations
• dedicated index tables outside data
• Sync or async updating?
• XML content indexes?
Consider how meta updates should be done
Can still use SQL Server!
blob store xml/json

10. Traditional database design model
All entities have their own tables and full ER model
Needs to be formatted for output
Challenges with extensions
Ensure model supports history
Just façade existing schema with extensions?
Atomised data

11. • Legacy database
• Extensions for additional columns
• How to handle updates
• How to handle incoming data
• Extensions?
• History?
• Searching?
View (Façade)

12. Depends on storage model
Timing - Synch/Async
Flexibility for new indexes
Simple Index on table
Dedicated index tables (common for blob style)
Data types in index - generic table/atomized
Effect on availability in search
Impact on applying security
Indexing for Search

13. • Blob store – fhir format
• Internal replication from relational store
• Extensions may only live in fhir store
• FHIR store covers history
• Indexing from either location
Hybrid

14. QUESTIONS?

15. THANK YOU