Workplaces that want to manage breath alcohol test results by person cannot choose the configuration they need by comparing breathalyzer performance alone. Identity verification is the process of identifying the person being tested, for example by tapping a card or selecting an account, and linking that person's test result so it can be found later. When there are situations where the results will be used, such as sites that check results before the start of a shift or sites that manage pre-trip test data, this linking method becomes a product selection criterion.
Option names such as card, account, camera, and fingerprint are only a starting point. The right configuration depends on whether existing access cards can be used as they are, where test results are kept after verification, and who handles lost cards or changes to HR information. So identity verification options should be compared not by the verification method itself, but by the usage flow that runs from registration to result lookup and user changes.
First decide what the results will be used for
The phrase "identify the person tested" alone is not enough to decide which functions you need. The information and lookup screens required differ depending on whether a manager only needs to confirm whether someone was tested that day, needs to find a particular user's past results, or needs to view them alongside existing access control data. It is also best not to treat the function that stores test results and the function that links stored results to a specific user as the same thing.
Writing the actual work down in one sentence in the purchase review documents makes decisions easier. For example, you could set it as: "After a shift worker takes a test, the manager checks the user and test time together in that day's data." Based on this sentence, you can ask about each candidate configuration separately: how the user is identified, where results are stored, and who looks them up and when.
Compare the work from registration to information changes
Even if initial user registration is simple, the operating burden continues if the same information must be entered in several places every time someone joins, changes department, loses a card, or leaves. You need to look at whether user information is registered directly on the device, whether existing card or account information can be used, and what management tools and permissions the internal staff need.
| Usage stage | What to compare | Why it affects the choice |
|---|---|---|
| User registration | Whether existing card or account information is used or separate registration is needed | The amount of initial registration and duplicate entry work changes |
| Verification before testing | What the user actually does and what peripheral devices are needed | It affects movement and waiting at the test location |
| Result lookup | Whether user information and test results can be found together | Managers must be able to check the records they need |
| Information changes and error handling | Who handles lost cards, user changes, and failed verification, and in what order | The same procedure can continue even when staff change |
The items in the table do not end with checking whether a feature exists. For example, even if existing cards can be used, whether the system only reads the card number, or whether that number can be seen together with user information and on the result lookup screen, is a separate thing to confirm. When registering a new user, you also need to confirm who enters what information to estimate the workload after introduction.
Distinguish the verification method from the result-linking function
Cards, accounts, cameras, and fingerprints are ways of identifying users. These methods alone do not tell you whether the device or management program can look up test results by user, or which fields are kept with the results. Some configurations require a separate program or peripheral device to manage results, so it is best not to judge what is included from equipment photos or option names alone.
When considering a configuration that handles information identifying individuals, such as faces or fingerprints, first define the business purpose that requires that information. If existing cards or accounts can link results at the level needed, choosing them can reduce the scope of registration and management. Conversely, if the purpose is to additionally check whether someone is using another person's card, you need to confirm through the functional specification and a demonstration whether the proposed configuration actually includes features related to that purpose.
Look all the way to the lookup step at a hypothetical site
As a hypothetical example, consider a workplace where 30 people work in shifts and already use access cards. The scene to observe is a user presenting their card and taking a test, followed by the manager finding that user's test time and result in that day's data. Even if the card is recognized, if the user cannot be found in the result data, the configuration may not fit the goal of managing results by person using existing cards.
The possible actions also depend on how you interpret this observation. You can confirm in a demonstration which screen or stored data links the card information to the result, and consider assigning who handles new registrations and lost cards. Set the completion criterion as the manager directly looking up the result of one test user and judging that user information can be handled in the set order even when a card is changed.
In a demonstration, it is better not to look only at normal verification and testing. Also look at who checks what when registering a new user, changing user information, or when verification fails. The key is not a method that links a test result to an arbitrary person because verification failed, but whether what to check at the site and who handles it have been defined.
Include the usage flow in the quote request
If a quote request lists only the number of people, it is hard to compare identity verification configurations. It is best to also provide the number of test locations, the flow of people testing at each location, the cards or accounts currently in use, who will look up results, and when results by user need to be checked. Even with the same number of people, testing in order at one location and testing spread across several locations may need different verification steps and peripheral devices.
For each candidate, list separately the confirmed standard functions, the separate options or peripheral devices, and the items needing a demonstration or an answer. If you are considering a PC-connected or kiosk-type configuration, look not only at the functions of a single breathalyzer but at the user registration tool, the result lookup screen, and the scope of support for connecting to the existing access control system as one configuration. Do not assume functions whose support has not been confirmed are included in the quote. Keep them as conditions to confirm.
The right identity verification option is not the configuration with the most verification methods attached. The selection criterion is a configuration that links testers and results at the level needed and whose registration, lookup, and change tasks the site can handle. Confirming that registration, verification, result lookup, and information changes connect in the actual order of the site reduces both excessive options and inadequate configurations.
