1. Creation of a FHIR facade
for a legacy database backend
René Spronk
Trainer / Senior Consultant
Ringholm, the Netherlands
Web:
Based (in part) on the work of
Brian Postlethwaithe and others.

2. 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 % 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”.

3. (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

4. 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

5. 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

6. 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

7. Other issues
Security / access control

8. Questions?