I wanted to reach out to the community to see if I could get some guidance on integrating OpenEMR and OpenELIS. The ideal workflow needed would be the ability to transmit orders from OpenEMR to OpenELIS and receive the result back once finalized in the LIMS. I have seen a couple of posts saying to use the FHIR endpoint for OpenELIS but I also see that the FHIR server shipped with OpenELIS isn’t bidirectional, so orders or patients created using the endpoint won’t appear in the UI.
Hi @destrada, I think the distinction being missed here is between writing to the raw HAPI FHIR server / a shared FHIR store, and calling OpenELIS’s application-level FHIR endpoints that create OpenELIS orders.
In the current OpenELIS codebase, direct FHIR write support is absolutely there. The code implements FHIR resource providers for ServiceRequest, Patient, Observation, DiagnosticReport, Specimen, Practitioner, Organization, Device, etc. For example, the ServiceRequest provider does create/update logic and turns a ServiceRequest into an OpenELIS order: ServiceRequestProvider.createServiceRequest
That method requires a valid ServiceRequest, resolves the patient, resolves the test(s) from the codeable concept, builds the sample/order data, calls samplePatientService.persistData(...), then returns a created ServiceRequest resource.
So the statement “OpenELIS does not accept FHIR resources directly” is not accurate for this codebase. What matters is that the request must be processed by the OpenELIS FHIR layer, not just inserted into the raw HAPI DB.
There is also a second, more common architecture: the EMR pushes Task + ServiceRequest + Patient to a FHIR server, OpenELIS is configured to read that server via org.openelisglobal.remote.source.uri, and OpenELIS polls that source and imports orders. This is documented in the repo and is the pattern most often used in OpenMRS/OpenELIS integrations.
Evidence:
- Remote-source configuration
- OpenMRS/OpenELIS integration docs
- Direct FHIR communication docs (curl + certs)
Also relevant: the FHIR write handlers require a valid system user context, resolved via getSysUserId(request), so authentication matters: FhirProviderUtils
To make the order appear properly, you still need external orders enabled in OpenELIS, a system/user mapping and auth setup, the incoming code to resolve to an OpenELIS test (LOINC/code mapping), and a valid patient and order payload.
Practical guidance:
If you’re doing direct OpenELIS FHIR integration: POST/PUT a valid ServiceRequest (or Bundle containing Task + Patient + ServiceRequest) to the OpenELIS FHIR facade, make sure the call is authenticated and gets a sysUserId, and ensure the order code maps to an OpenELIS test.
If you’re doing the shared-store/poll pattern: have OpenEMR create the Task + ServiceRequest + Patient in a FHIR server, point OpenELIS at that FHIR server using org.openelisglobal.remote.source.uri, enable external orders and make sure LOINC mappings are correct — OpenELIS will import it on polling.
So yes: the “raw HAPI store is not bidirectional” comment is only partly true. The HAPI store is part of the architecture, but the OpenELIS app layer is what actually ingests and turns FHIR orders into UI-visible electronic orders. If the resource is only sitting in the raw FHIR datastore without OpenELIS processing/importing it, the UI won’t show it.
If OpenEMR isn’t producing FHIR bundles or can’t easily authenticate, the cleanest solution is usually a small adapter/middleware layer or a Lab-on-FHIR-style translator that converts EMR-side data into the Task/ServiceRequest/Patient bundle OpenELIS expects.