FHIR Server Design Review
- 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
- 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
- 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
Editor's Notes
- Not intended to be a platform or technology selector Intended to assist in identifying your requirements and why the approaches might be appropriate and get discussions going The cover a little about the design of our sqlonfhir server
- Health Intersections Reference Implementation, Spark, HAPI, Wild-FHIR History is easy to handle in this model Great if you are in a greenfields environment, but then again, why start again?
- This is very similar to traditional messaging/integration engine scenarios. Kind of like warehousing content MyCareManager History is handled by the FHIR server
- Oridashi BP/MD fhir server, epic’s server If the underlying store has no concept of history, this is very likely not able to be provided
- Sqlonfhir Update issues still have the same issues as the façade or synch approaches
- Health Intersections Reference Implementation, Spark, HAPI, Wild-FHIR History is easy to handle in this model Great if you are in a greenfields environment, but then again, why start again?
- Formatting typically via serializers/parsers on an object model, but could be done within database
- Oridashi implements this approach
- All these things effect the flexibility of the search system
- Oridashi implements this approach