External FHIR orders arrive at accessioning with neither patient nor specimen data pre-filled

[Bhupesh_Gupta]

Summary

When an external EMR places an order via the FHIR Task/ServiceRequest import path (org.openelisglobal.remote.source.uri), the resulting order reaches OpenELIS’s accessioning UI (SamplePatientEntry) missing two things that were already correctly resolved during import: the patient link, and the specimen/sample type. Both look like the same underlying pattern — fields OpenELIS resolves correctly during FHIR import don’t get threaded through into every screen that needs them.

Environment

• OpenELIS-Global-2 (develop branch), docker-compose deployment
• Remote FHIR source: public hapi.fhir.org test server (reproducible against any HAPI FHIR server)
• Both issues confirmed via direct source inspection and live testing, not just observed behavior

Gap 1 — Patient never re-attached to the order at accessioning

Opening an imported order for accessioning (pencil icon on a row in “Test Requests Matching Search” → SamplePatientEntry?ID=<serviceRequestId>&labNumber=...) always lands on a blank “Patient Info” screen with 0 search results — even though the correct patient (name, DOB, gender, National ID) was already created by the FHIR import.

Root cause, in SamplePatientEntryRestController.setupForm() (~line 570): the method correctly resolves Priority, Referring Site (from Task.location), and Provider (from Task.owner) from the ElectronicOrder — but then unconditionally does:

form.setPatientProperties(new PatientManagementInfo());   // always blank
form.setPatientSearch(new PatientSearch());                // always blank

There’s no code path reading electronic_order.patient_id (a real, correctly-populated column) to hydrate the form. Workaround: manually search by name and re-select the patient that already exists.

Gap 2 — Specimen/sample type never reaches “Add Sample”

Separately: electronic_order.data only ever caches the raw Task JSON — never the associated ServiceRequest or Specimen, regardless of what’s sent. And AddSample.jsx (line 21) hardcodes sampleTypeId: "" with no pre-fill logic from any order source at all. So “Select sample type” is always blank at accessioning, for every electronically-submitted order, no matter how complete the FHIR payload is.

We also checked and ruled out:

• Task.input — not read anywhere in FhirApiWorkFlowServiceImpl, TaskInterpreterImpl, or TaskWorker.
• sample_type_terminology_mapping — populated it via the real Admin → Sample Type Management → Terminology feature; made no difference to the Add Sample screen.
• The “accept as is” action (attemptAutoSave=true) routes to the exact same setupForm()/AddSample.jsx code, so it doesn’t sidestep either gap.

What does work correctly, for contrast — so this isn’t read as “FHIR import is broken”: the Test Requests Matching Search list can show the correct Test Name, Referring Lab Number, and some patient identifiers, but only when the “All Info” checkbox is checked (RestElectronicOrdersController.convertToDisplayItem, useAllInfo branch) — that path does a live fetch of the ServiceRequest from the FHIR store and resolves the LOINC code via testService.getActiveTestsByLoinc. So the resolution logic exists and works elsewhere; it’s specifically setupForm() (patient) and AddSample.jsx (sample type) that don’t use it.

Minimal reproduction

Attached Postman collection (2 requests): upserts a Practitioner, then submits a transaction Bundle with Patient + Specimen + ServiceRequest (referencing the Specimen) + Task (referencing the ServiceRequest) to a public HAPI FHIR test server. Set remote_fhir_base to whatever your instance’s org.openelisglobal.remote.source.uri points at, and practitioner_id to match org.openelisglobal.requester.identifier.

After OpenELIS polls and imports the Task: check “All Info” in Test Requests Matching Search (Test Name resolves correctly), then click the pencil icon on that row — Patient Info opens blank, and Add Sample’s “Select sample type” is blank, despite both being fully specified in the submitted bundle.

Question for the community: is this expected/by-design, or a genuine gap worth a PR? Happy to help scope one — looks like it’d mean extending setupForm() to resolve patientProperties from electronic_order.patient_id, and doing the equivalent for AddSample.jsx/sample type, reusing the same FHIR-fetch pattern that already works in the useAllInfo branch.

[Moses_Mutesasira]

Specimen data from external FHIR orders is never available at accessioning (Add Sample sample-type always blank)

Hello @Bhupesh_Gupta . Here is an actual complete FHIR bundle generated from OpenMRS to OpenELIS The Loinc System code associated to the ServiceRequest.code must match an existing Loic assoctiated to an actual test. You can try out the OMRS-LIS set up preconfigured out of the box. Full HIE setup with the Exchange going through OpenHIM to view and log the trasnactions Minimal setup with the direct exachange between OpenMRS and OpenELIS

[Bhupesh_Gupta]

Figured it out, refer:

@Bhupesh_Gupta

Figured it out! It wasn’t a bad FHIR bundle after all—just a silly configuration mistake on my end.

ACCEPT_EXTERNAL_ORDERS was set to false in SystemConfiguration.properties. Looking at the front-end code, the Add Order page only pulls the order ID from the URL when ACCEPT_EXTERNAL_ORDERS is enabled. Since it was disabled, the entire external order workflow was skipped. Front End Debugger snapshot (for reference):

AI wasn’t much help here; it kept hallucinating fixes for reading patient data on the page instead of flagging the configuration setting. Manual debugging did the trick! Setting ACCEPT_EXTERNAL_ORDERS to true completely fixed it.

@ELAI It will be good if above video can be updated to point out configuration settings that need to be enabled to run that workflow.

[Moses_Mutesasira]

Glad it has worked .