How to correctly close alerts caused by end users?

Did you know that alerts raised due to errors on the end user`s side can be closed either as a technical or a procedural error?

06b - Closed - End User - Technical error

06f - Closed - End User process error - cannot be dispensed

 

What is the difference between these two states?

A technical error denotes a pack identification issue when the system fails to find a match between the provided values of the unique identifier (scanned, or entered by hand), and the data uploaded in the repository. The pack cannot be identified because one of the values (PC, SN LOT, EXP) is different.

This could be due to a wrong keyboard setting, low scanner quality or a human error made in manual entry. Consequently, the unique identifier values will be misread, i. e. very short or very long text string, low characters, character mismatch eg. O/0, 3/E, l/I) or Y/Z mismatch.

Alerts raised as a result of a technical error:

A2 - batch not found (The serial number is unknown. The batch has not been found. An alert has been raised.)

A3 - pack not found (The serial number is unknown. An alert has been raised.)

A68 - batch ID mismatch (The batch identifier mismatches the recorded batch identifier. An alert has been raised.)

A52 - expiry date mismatch (The expiry date mismatches the recorded expiry date. An alert has been raised.)

 

In case of a procedural error, the pack is correctly found in the repository, however; the status of the unique identifier is not active, and hence the required transaction cannot be executed. The main cause of such errors are transactions that are either repeated or disallowed.

Somebody is trying to change the status of a pack that has already been dispensed or decommissioned in the system.

Alerts raised as a result of a procedural error.

A7 – pack already in the requested state

A24 – status change could not be performed (*the text informs the user that the pack cannot be supplied/decommissioned, or the pack has been supplied/decommissioned)

For the time being, it is not possible to dispense a pack in case of a procedural error, because any further attempt to dispense or decommission the pack will result in an alert. We are however preparing a new procedure that has already been approved by SÚKL and will soon be implemented to our AMS.