Supplemental Requests vs. Cascading Requests (LIMS-plus v3.7.6 and later)

Title:  Supplemental Requests vs. Cascading Requests (version 3.7.6)

Affected Users:  LIMS Administrators, Lab Analysts

Fielded Statements:

How do supplemental requests differ from cascading requests?

Cascaded  requests are showing up as a parent request instead of a child request. What is happening?

A supplemental request was created but it is showing up as a separate request, what is going on?



Supplemental (Hierachical) Requests

Starting with LIMS-plus v3.7.6, users are now able to add supplemental requests to an existing request that has already been started and/or completed.

NOTE: Supplemental requests should not be confused with Cascading requests.  Cascading Requests have been a feature in the LIMS-plus 3.x application since 2002.

Using the supplemental requests feature, labs can tie a child request to a parent.  When a request is created the request will follow the same numbering conventions (i.e LabCase#-request#).  An example of this would be CFD00001-0001.  The supplemental request (child) will appear with the following numbering convention: LabCase#-Parent Request# _Child Request #.  An example of this would be CFD00001-0001_0001.  The supplemental request (child) number will follow the parent request and will have an underscore when viewing requests via tree-view.


Root Cause:

Supplemental Requests are treated as child requests.  If a service is configured to use Cascading requests trigger an additional parent request.


A court case involving a vehicular homicide is being expedited to a grand jury.  The forensic laboratory has been tasked to perform preliminary testing to determine the presence of a foreign substance.  The preliminary result shows a positive trace of a foreign substance. Before the jury trial, a supplemental request arrives at the laboratory instructing the lab to perform a confirmatory test to identify specific substances that resulted in the positive result listed in the preliminary test.



The following screenshots provide an example of the supplemental requests and also show how they are different from cascading requests.


Figure 1- New case entered into LIMS-plus application.



Figure 2- Evidence entered for the new case



Figure 3- Parent request added to the Case. Notice that the request # is 0001



Figure 4- Results entered for the parent request.

 Note: The results listed in Figure 4 are not shown due to results not being selected/highlighted.


Second user (Phillip Favor) has logged into LIMS-Plus to technically review the findings entered by Duck Dodgers.  Second User right clicked on the request and selected “Show milestones”


Figure 5- Milestones


Second User selects “Add related request” (Supplemental request) to the parent request (Req# 0001)



Figure 6- Adding a related or child request

The new Request for Analysis window will appear.  Notice that the Parent request is populated in the “Supplementary Request created from Parent Request” field.  The parent request cannot be changed from this window. In this example, the same Service is being selected “Controlled Substance identification”.  Labs will most likely choose a different service as long as it is an active service.


Figure 7- Details of the child or supplemental request

Notice that the supplemental (child) request is listed with a request number (REQ#) of 0001_0001.



Figure 8- Request tab showing a parent and a child request

 Notice that the second analyst (Phillip Favor) attempts to edit findings for the first service request. The application will not allow a user to edit findings for services he/she is not assigned to unless they have a role that has the following permission:  Case - Edit Another Analyst's Findings.



Figure 9- Editing findings

The second user (Phillip Favor) has selected the supplemental request and selected edit findings. This brings up the tree view.  When selecting the results for the first service request, the information is grayed out and cannot be manipulated. Right clicking on the result associated with the parent request will not bring up the right Click context menu.



Figure 10- Example of adding results on a supplemental request


Duck Dodgers entered results for request 0001.   Phillip M. Favor is logged in but cannot right click on REQ# 0001 to modify results.  Phillip Favor is assigned to Supplemental request 0001_0001. Right Click Menu appears when Phillip Favor right clicks on the results associated to the supplemental request assigned.



Figure 11- Adding results on different nodes


Comparison to Cascading Requests

As mentioned in the beginning of this document. Cascading requests are not the same as Supplemental requests.  Listed below is a screenshot of the properties configured for the Service used in the previous examples

Service Name:  Controlled Substance Identification.

Note:  The screenshots listed below show the service being modified to include a cascading request. The changes being performed below were performed after the supplemental request had been created for case LAB-09-000001.  The supplemental request has yet to have results entered.


Figure 12

Notice that a Cascade Service has been selected.  For this example, the same service has been selected as the cascading service.  Other services can be defined by individual laboratories.  The screenshot above is purely an example.

The screenshot below shows a parent request (Lab-09-00001-00001). It also shows a child request of LAB-09-000001-00001_00001.  If a cascading service has been configured, when adding results to the supplemental request , the application will show a “Create Cascade request” window. It will ask the end user to confirm whether or not a separate request should be created.


Figure 13


 In our example, Phillip Favor selected yes when prompted about the Cascading request. When a cascaded request is created, it will have a separate REQ#.  Listed below is an example.

Notice in example below that the Cascaded Request has a REQ# of 0002.  This is completely separate from the supplemental request.  If a supplemental request is needed for the REQ#2, an end user would need to right click on the request and select “Add Related Request”.


Figure 14

Cascading requests themselves are different from Supplemental requests.  Cascaded requests are treated as a separate Parent request.  These requests will have their own REQ# where Supplemental requests will have a Child REQ# denoted with an underscore (i.e. LAB-09-000001-0001_0001).



In order to utilize the Supplemental Request feature, version 3.7.6 is a requirement.  In order for view the results of a parent request, the user logged into LIMS must be the individual assigned to the parent request or have the following permission granted:  Case - Edit Another Analyst's Findings

Cascaded requests are configured within the properties of a given Service.  Cascaded requests are kicked off once a service has reached the findings entered milestone.  Supplemental Requests are created when right clicking on a request (Request Tab) and selecting “Add Related Request”

Supplemental requests are simliar to itemized evidence. Supplemental requests relate an existing request with a "parent" request.

Supplemental Requests differ from Cascading Requests in the following ways

1. Supplemental requests are not automated. 

2. Supplemental requests relate requests/results so that reports can accomodate supplemental results.

3. Supplemental requests are not status/milestone dependent.  They can be added after the release of a parent request.

4. Supplemental requests are not dependent on the Analyst of the Original (i.e. Parent) request.

5. Multiple layers of supplemental requests can be created. However, the numbering scheme cannot be changed.


Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request


Please sign in to leave a comment.
Powered by Zendesk