Architecture

Note

A FHIR Facade is your existing component. openFHIR Engine does not provide a FHIR facade.

Note

openEHR Repository is your existing component. openFHIR Engine does not provide an openEHR clinical data repository, nor does it integrate with it in order to automatically store any Composition.

openFHIR Engine exposes RESTful APIs. Through those, you can access namely mapping endpoints you can use when you want to map from FHIR to openEHR or vice-versa.

FHIR to openEHR

When a request comes in to your FHIR Facade for a creation of a new Resource, your FHIR facade (i.e. within HAPI Interceptor, Firely Plugin ..) should invoke an openFHIR engine to translate the FHIR Resource to an openEHR Composition.

Once you have the openEHR Composition within your FHIR Facade (as a result of the HTTP /openfhir/toopenehr), you should create it against the integrated openEHR Repository. openFHIR Engine does not automatically create it anywhere, so it is in the domain of your FHIR Facade to make a POST towards /ehr/rest/openehr/v1/ehr/{ehrid}/composition according to the openEHR API spec.

openEHR to FHIR

When a search request comes in to your FHIR Facade, your FHIR Facade invokes an openEHR CDR to fetch all relevant Compositions. At this point, openFHIR does not yet offer a translation from FHIR search to an AQL, but is a feature on the roadmap. Once that’s in place, your FHIR Facade invokes an openFHIR Engine to obtain an AQL and sends this AQL to the openEHR Repository.

Compositions returned back are then sent to the openFHIR Engine for a translation to corresponding FHIR Resources.

FHIR Resources returned by the openFHIR Engine represent FHIR counter parts to fetched openEHR Compositions.