Creation of a FHIR facade for a legacy

  • Slides: 8
Download presentation
Creation of a FHIR facade for a legacy database backend René Spronk Trainer /

Creation of a FHIR facade for a legacy database backend René Spronk Trainer / Senior Consultant Ringholm, the Netherlands Based (in part) on the work of Brian Postlethwaithe and others. Ringholm e. Mail: Web: Rene. Spronk@Ringholm. com http: //www. Ringholm. com Learn * Share * Connect

Scenario: FHIR Facade / Assumptions FHIR Facade database GUIs Business Services API ER Legacy

Scenario: FHIR Facade / Assumptions FHIR Facade database GUIs 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”. Ringholm Learn * Share * Connect 2

(non-query) Content Conversion • On the fly conversion – Data types, terminologies, granularity of

(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 Ringholm Learn * Share * Connect 3

Resource Identity (resource. id) • Use primary Key – If exists (for a particular

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 Ringholm Learn * Share * Connect 4

Query Conversion, Searching • On the fly query conversion • Lossy query conversion is

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 Ringholm Learn * Share * Connect 5

History • Decide not to support history, each and every retrieval is a ‘new’

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 Ringholm Learn * Share * Connect 6

Other issues • Security / access control Ringholm Learn * Share * Connect 7

Other issues • Security / access control Ringholm Learn * Share * Connect 7

Questions? Ringholm Learn * Share * Connect 8

Questions? Ringholm Learn * Share * Connect 8