I want to understand whether the following capability is achievable with OpenELIS Global. Specifically relating to the order interpretation and the actual test done.
In one of our context, the order is at a higher level - meaning not a specific test identified to a specific LOINC code, but indicating the higher level). For example: TB Test from Blood Sample, can be done either QFT or T-Spot. The Doctor would just order TB Test, but the lab based on its capability would decide whats the method (which leads to the actual test). If the Doctor has specified the specific method in her notes, the lab would select that, otherwise they would call the Doctor to check on specificity.
Is there a way this can be done in OpenELIS, where the lab tech at the time of accession, decides what specific test will be done?
@angshuonline if i understand you correctly i would interprete this as essentially a “reflexive or interpretive test selection” workflow meaning that the ordered concept doesn’t map one-to-one to a LOINC-coded test definition until the lab assigns the final method.
In OpenELIS Global, the test catalog is where every test is formally defined, including:
Its name
Its LOINC code (optional)
Its methodology / test section
Its sample type
Its analytes / results structure
When a clinician places an order (either manually in OpenELIS or via an interfaced system like OpenMRS or DHIS2), that order references a specific test already defined in this catalog.
So, by default:
OpenELIS expects a specific, pre-defined test to be selected at order time, not at accession time.
However, there are configurable patterns that can approximate what you want.
I know that request codes map one to one directly to the tests to be done. Would you please elaborate the “configurable patterns” that may approximate the desired behavior?
In my opinion, I would try to ;
Create a generic “TB Test” that can be ordered.
Add a “Preferred Method” field or order note.
Lab tech uses that field to decide which concrete test to run, then manually swaps it in.
We can have Parent test: TB Test (Generic) has no fixed method or LOINC, used for ordering. Child tests:
TB Test – QFT
TB Test – T-Spot
How it works
Clinicians can order TB Test (Generic).
At accession time (or immediately after), we can try to manually add the actual test to be performed QFT or T-Spot and cancels or closes the generic placeholder test.
So, is it fair to assume that if OpenELIS has such capability, that if no much field or attribute (about preference) is passed as part of order, ELIS would show option (or force user) to select a test defined with codes?
Or are you saying, that ordering the panel, both the tests will automatically be selected for “accession” and user will have to unselect one?
@ angshuonline Thanks for the follow up
OpenELIS requires manual selection of the concrete test at accession if the order is generic. It does not automatically expand the order into multiple tests, nor does it force a selection by default. if a generic test is ordered without a specified method, the system does not automatically select a concrete test. The generic test simply appears in the accession list, and the lab tech must manually choose which specific test (e.g., QFT or T-Spot) to perform. OpenELIS does not pre-populate multiple child tests or force a selection, so any guidance, like a “Preferred Method” note, is purely for the tech’s reference. This ensures that only the test actually performed is recorded and reported correct !
A Doctor’s Order in OpenELIS can include multiple tests (e.g., TB Test, HIV Test, Blood Culture, etc.).
Each test in that order can later be performed using one of several available methods
Example Workflow
Doctor places an order .
Example: “TB Test from Blood”
Note that the Order can have multiple tests for different sampletypes and each test is associated to a speific Loinc code
At testing time, the lab staff chooses the method used to perform that test, such as:
EIA (Enzyme Immunoassay)
PCR (Polymerase Chain Reaction)
STAIN (Microscopy)
CULTURE (Bacterial culture)
PROBE (DNA/RNA probe)
BIOCHEMICAL
DNA SEQUENCING
HPLC (High-performance liquid chromatography)
AUTO (Automated analyzer)
MANUAL (Manual method)
HIV_TEST_KIT (specific rapid test brand)
SYPHILIS_TEST_KIT (specific rapid test brand)
The system (OpenELIS) records:
The ordered test (e.g., “TB Test”)
The method actually used (e.g., “QFT” → EIA method, or “T-SPOT” → ELISPOT method)
The final result from the test
This structure makes OpenELIS flexible — it allows a single generic test order to be fulfilled by different test methods depending on lab setup or available equipment
Coming back to this thread again for a related question. Although not exactly for the method.
The way I understand this that an order item links to a specific LOINC coded test, which is defined in advance. Only the method is defined at the result entry time. Which means there is no change to the identification of the test, as it continues to refer the specific LOINC coded test.
What I want to understand - Is it possible to simulate LOINC Group order?
thanks @Moses_Mutesasira . One clarification, its not really a group of test to be performed (e.g a Panel like CBC) - rather a LOINC Group (a caterogization) - where from one of the tests can be done. e.g. group all variations of Sodium tests, HIV tests
Thanks @angshuonline for the clarification ,
Looks like Odering through a Multi-component test is more ideal for this use case.
This is just a new feature weve just introduced in the last 3.2.1.11Release
Thanks @Moses_Mutesasira however I am not sure if multi-component test is appropriate in this case - as its intention is - “… capture more than one result value”. Which probably is more suitable for “culture tests” or if a test has multiple value attributes to collect (e.g. % and absolute count)
What we want is Doctor to order a generic test - “Eye Microbiology” - and the lab deciding the exact test (bound to a specific LOINC code) at the time of sample collection.
Thanks for the clarification @angshuonline — that helps.
You’re right that a multi-component test isn’t the correct fit. Its purpose is to capture several result values for a single ordered test; it always expands into all its components, so it can’t defer to just one selected member.
Panels and method selection don’t cover it either:
Panel — orders a set of tests, all of which are performed.
Method selection — one ordered test where the lab records the method (EIA/PCR/STAIN…) at the bench, but keeps the same test identity and LOINC.
None of these replaces a generic ordered test with one of several specific LOINC-coded tests at collection while preserving the original order. So I agree this is new functionality rather than configuration.
One thing worth noting about your example: the two candidates aren’t different methods of one test — they’re the same investigation on two different specimens:
88167-2 = Mycobacterium on cornea
88168-0 = Mycobacterium on ocular fluid
So “Eye Microbiology” (LG50925-3) acts as a group whose members are distinguished by the specimen collected. If that holds generally, the resolution can be modelled as (test, specimen) pairs: the provider orders the generic test, and the specific LOINC resolves from the sample type registered at accession.
This is exactly what OGC-1145 — specimen-aware test resolution is scoped to address — Phase 1 makes test↔sample-type a true many-to-many and lets a specimen-scoped mapping route to its specific (test, specimen), with the per-specimen LOINC override landing in Phase 2. So I think your use case fits under that issue rather than needing a brand-new one.
@caseyi — does OGC-1145 look like the right home for this, or is there an existing approach we’re overlooking?
And one question for you, @angshuonline: are all your groups separable by specimen, or do some have members that share a specimen and differ only by methodology? That determines whether specimen-based resolution is enough on its own.
One more thing to add, Mozzy is working right now on a really excellent and comprehensive new test catalog update, which I think will help with a lot of these complexities, where you can assign a LOINC to a component of a test, or have some tests that share characteristics across sample types, and some which diverge and have their own ranges. You are right that the LOINC that gets to method-specific is different than what’s ordered from the Dr side, but we now also have the ability to use LOINCs that are broader than or narrower than a particular code.
So I think the LOINC grouping you’re looking for is to assign the test a LOINC and say it’s narrower than that LOINC, so all the tests that are narrower than that could be matched to it. But then you could just use that one LOINC on the functional level. In the workflow, part of this new work is that there will be a specimen disambiguation for the e-orders when they come in if the sample isn’t specified, rather than the first match that currently happens.
It’s great timing to bring this up now as we are currently working on these kinds of complexities.