When you run alcohol checks before work, before a task, before driving, or before entry, the procedure sometimes does not end with a single test. The device may show an error because not enough breath was collected, or the person tested may dispute a valid result after it appears. Site supervisors and safety, health, or HR staff need to use the same standard in both situations to decide whether to keep testing or move to the next procedure.
The end condition in a retest rule is the standard for stopping repeated testing on site and handing the case to the person responsible for the follow-up decision. This is different from a decision that confirms there is no problem or approves entry, work, or driving. Without an end condition, testing may be repeated until the desired result appears, or each staff member may judge differently and keep the person waiting for a long time.
First, separate error retries from result disputes
A case where no valid result was obtained must be kept separate from a case where someone disagrees with a valid result. A situation where the device shows no result, such as insufficient breath, is an error that occurred during the test process. On the other hand, a person saying they cannot accept a reading or judgment after it has been displayed is a dispute about the result.
If you lump both situations together as a retest, the problem the on-site staff must solve becomes unclear. When an error occurs, the test can be tried again following the device's usage instructions. When a valid result is disputed, the appropriate approach is to keep the original result and route the case to the dispute intake and confirmation procedure set by the workplace. It is best to avoid rules that erase an earlier valid result just because it is disputed, or that repeat testing until a different result comes out.
The number of retries and the waiting time between attempts cannot be set arbitrarily as figures common to all devices. Set them after reviewing each device's usage instructions and the workplace's procedures, and also decide what the test staff and the person responsible for work assignment each do when the set limit is reached.
The end condition defines the end of the testing stage
It is best to treat the end condition not as a "normal" judgment but as meaning that the actions possible at the on-site testing stage have been completed. Obtaining a valid result, failing to obtain a valid result even after retries following the usage instructions, and receiving a dispute about a valid result are each different reasons for ending.
In repeated error situations, a boundary is needed so that on-site staff do not arbitrarily mark the test as completed normally or demand the same attempt endlessly. Once the set retry procedure is finished, end the procedure at the test screen and hand the case over to the person responsible for further confirmation or the work assignment decision. If nothing is defined for what happens after testing ends, the person is left waiting and several staff members put off the decision to one another.
| Situation confirmed on site | Standard for ending the testing stage | What to do next |
|---|---|---|
| A breath sampling error occurred | The actions in the usage instructions and the set retries have been completed | Record the error indication and time, and report whether further support is needed |
| A valid result is displayed | The result has been checked and the necessary details recorded | Route to the set judgment procedure or the dispute intake procedure |
| A valid result is disputed | On-site testing ends with the original result preserved | Log the dispute and pass it to the staff member responsible for confirmation |
| Still unresolved after retries | The set retry limit or the scope of on-site support has been reached | Ask the person responsible for the work assignment decision for the next action |
The key point of the table is that even the same unfinished state leads to different next actions depending on the reason. For example, when an error screen repeats, you can record when the error occurred and what guidance was given, and link that to further confirmation. A dispute after a valid result, by contrast, is not a test failure, so the starting point is to preserve both the original result and the fact that a dispute was raised.
Completion criteria in a hypothetical case
Suppose a worker took a pre-entry check, the first attempt showed an insufficient breath error, and after guidance the second attempt showed a valid result. If the worker then disputes the second result, the observed facts are the first attempt's error, the second attempt's valid result, and the dispute about the result. If you simply record this as a case with two retests, it is hard to tell whether the error was resolved or whether the result needs confirmation.
You can interpret this situation as follows: the test process error ended with the second attempt, but separate handling of the result has begun. A possible action is to record the time and device indication of the first error, preserve the second valid result as the original result, and record the content of the dispute and the staff member it will be passed to. The completion standard in this case is not whether the person agrees with the result. It is a state in which on-site testing has ended and the person who will confirm the dispute and the next guidance have been decided.
Dividing things this way means on-site staff do not have to rule on the spot whether the result is right or wrong. After finishing the test support assigned to them, they can pass the next decision along the set route.
Attempt-by-attempt records show the reason for ending
If you keep only the last result and overwrite earlier attempts, it becomes hard to check whether there were repeated errors or whether a dispute followed a valid result. You can consider linking, within one check for one person, the order of attempts, the time of each attempt, whether each was an error or a valid result, and whether a dispute was raised. An attempt that showed no result on screen must be recorded as an error or incomplete, not as a result with a reading of 0.
The purpose of records is not to collect a lot of information but to distinguish the facts needed for follow-up decisions. If testing was ended because of repeated errors, the record must show what guidance was given and who was asked to take the next action. Automatically classifying a device error and a deliberate refusal to test under the same item can lead to a response that does not match the actual situation, so it is better to record device indications and observed behavior separately.
Separate the end of testing from the decision to put someone to work
Ending on-site testing does not immediately mean entry, work, or driving is approved. Conversely, even if a valid result has been obtained, confirmation of or an answer to a logged dispute may still be pending. This is why the procedure document should not merge the end of testing, the designation of who makes the next decision, and the decision on whether to put someone to work into a single item.
Operationally, you can design the process so that selecting the reason for ending also sets the next person in charge and how the person will be informed. For someone whose test ended because of repeated errors, decide in advance where they wait, who decides whether further support is needed, and whom the on-site staff notify. It is also necessary to pass on status separately so that people in a retest or dispute process do not enter or start work through the same flow as people who completed normally.
The purpose of an end condition is not to test more. It is to decide at which stage to stop, and to whom to hand over, for error resolution, result disputes, and repeated unresolved cases. With this boundary in place, retest rules reduce arbitrary judgment by on-site staff and help ensure that the actions needed after testing are not cut off.
