In laboratories it is common practice that when a product does not match the set specifications, the same sample is retested to confirm the result.
Usually a new record is created for the new data point. This might lead to data being scattered across two or more results. This is suboptimal from a data analysis and reporting perspective.
We can overcome this by adding a workflow that creates a new result, and copies all the in-spec values, while leaving the off-spec values blank. In the retest, the lab technician can then focus on retesting the tests that were left blank.
This will lead to a final result that contains all the values.
Setup
Form fields
We need two fields for this workflow:
- A trigger to start the retest procedure. This can be a checkbox or another form field.
- A selection list is to indicate whether the sample request is initial or if it is a retest.
Workflow
We create a workflow with a result transfer.
This workflow triggers when the Retest checkbox is checked.
The workflow is created as shown below, using the very same analysis set as the target for a new result.
The fields are very straightforward, except for the pH field.
{field_}.offspec ? "" : {field_}
This expression can be read as:
When pH is off-spec, leave blank. Otherwise, take the pH value.
This is the crux in this best practice. This expression will only carry the pH value if it is in-spec. Doing this for all your tests, will provide you with a new retest result that contains blanks for all off-spec value.
To prevent that both initial values and the retest values are calculated in the statistics or graphs, a field can be added like Incl.statistics. This field can be used as filter before performing statistical analysis. Another solution might be to use only released or signed records. Logically, samples are only approved and released once, in our case after the retest.
With the introduction of manual workflows, the retest procedure can now (also) be triggered with the toolbar button from the results overview.
