-
Notifications
You must be signed in to change notification settings - Fork 20
Overview
This page provides some general information about the resources supported by the FHIR Bridge.
The FHIR Bridge is currently implementing transactions for the following resource types:
- AuditEvent
- Condition
- Consent
- DiagnosticReport
- MedicationStatement
- Observation
- Patient
- Procedure
- QuestionnaireResponse
All transactions are implemented based on interactions defined by the RESTful part of the FHIR specification.
If you want to have complete information regarding the interactions used by the applicaton, please refer to the FHIR specification: http://hl7.org/fhir/http.html.
Except for the AuditEvent
resource that only handles Find AuditEvent
transaction, all other resources support two transactions.
To get the full list of supported transactions use the metadata endpoint:
curl --request GET \
--url http://localhost:8888/fhir-bridge/fhir/metadata
The Provide [type]
transaction allows to create or update an existing FHIR resource in FHIR Bridge. It also handles the conversion between the FHIR resource and the corresponding openEHR Composition. Finally, it implements the persistence of the openEHR Composition using a remote EHRbase instance.
This transaction relies on the following FHIR RESTful interactions:
create
update
The Find [type]
transaction allows to retrieve the FHIR resources stored in the FHIR Bridge.
This transaction relies on the following FHIR RESTful interactions:
read
vread
search
A Postman Collection that contains some examples for each resources and trancatoions is available in ./config/postman/fhir-bridge.postman_collection.json
FHIR Bridge has two search modes, openehr
and database
.
openehr
specifies to execute the search on the backend openEHR server using AQL on the openEHR REST API. In this mode, mappings from openEHR COMPOSITIONs to FHIR Resources are done in the FHIR Bridge.
database
specifies to execute the search on the local FHIR repository of the FHIR Bridge, without connecting to the backend openEHR server.
This is configured in the fhir-bridge/src/main/resources/application.yaml
, on the search
entry.
Internally that value is loaded on fhir-bridge/src/main/java/org/ehrbase/fhirbridge/config/SearchProperties.java
, that is used from fhir-bridge/src/main/java/org/ehrbase/fhirbridge/camel/route/AbstractRouteBuilder.java
in the isDatabaseSearchMode()
method, which return a true
Predicate when the search is configured to database
, false otherwhise. Finally that is used in the route builder for each resource. For instance, in fhir-bridge/src/main/java/org/ehrbase/fhirbridge/camel/route/DiagnosticReportRoutes.java
, in the configuration for the Find Diagnostic Report route diagnostic-report-find:consumer?fhirContext=#fhirContext&lazyLoadBundles=false
, the method is used to configure which route the processing should take to handle the FHIR search operation request. For database
it will end up executing org.ehrbase.fhirbridge.config.camel.ProcessorConfiguration.findDiagnosticReportProcessor()
, and for openehr
it will be redirected to another route direct:search-using-ehrbase
, which will end up executing the AQL query in the backend openEHR server and mapping COMPOSITIONs to FHIR Resources to build the final response.