• 90 likes • 101 Views
Learn how to create a FHIR facade for a legacy database, covering data retrieval, storage, query conversion, resource identity, and security considerations.
E N D
Creation of a FHIR facade for a legacy database backend René Spronk Trainer / Senior Consultant Ringholm, the Netherlands eMail: Rene.Spronk@Ringholm.com Web: http://www.Ringholm.com Based (in part) on thework of Brian Postlethwaitheandothers.
Scenario: FHIR Facade / Assumptions FHIR Facade GUIs Facade database Business Services API ER Legacy database • Developers of Facademaynotbethesameones as thedevelopers of thelegacyapplication. • Assume 90-100% of all “data retrievals” tobedirectlyfromthe ER database. • Assume most (but notall) “data storage” tobedone via theapplicationsown API (business ruleenforcement). • Don’tduplicate full data in a separate FHIR-based database / minimize “caching”.
(non-query) Content Conversion • On the fly conversion • Data types, terminologies, granularity of data • On export: additional ‘columns’ to FHIR extensions ? • If using database views, updates can be challenging. • Use Provenance to document what (third party) translation tool has been used
Resource Identity (resource.id) • Use primary Key • If exists (for a particular resource type), primary key should not be a business identifier (which may be subject to change) • Add resource_id table to facade database
Query Conversion, Searching • On the fly query conversion • Lossy query conversion is fine • Indexes can be either: • in replicated content • views on the source data • Synchronized from source data
History • Decide not to support history, each and every retrieval is a ‘new’ version • Cache the content that was returned • History can remain in the cache • If a subsequent retrieve results in the same (byte wise) data, the cached version can be returned
Other issues Security / access control