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 the work of Brian Postlethwaithe and others.

Scenario: FHIR Facade / Assumptions GUIs Facade database Business Services API ER Legacy database Developers of Facade may not be the same ones as the developers of the legacy application. Assume 90-100% of all “data retrievals” to be directly from the ER database. Assume most (but not all) “data storage” to be done via the applications own API (business rule enforcement). Don’t duplicate 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

Questions?