Employees should be in a good physical state when they enter the workplace, especially if they are responsible for the safety of others and not just their own productivity and ability to carry out their duties. There are many examples: public transport drivers, miners, all kinds of machine operators, aircraft crew, and security guards. A drunk computer programmer is effectively useless and, in the worst case scenario, capable of compromising information integrity. An intoxicated driver however could cause the deaths of many people.
All too often, accidents are caused by drunk or tired drivers. In hazardous workplaces such as mines, inebriated workers can be the reason for industrial accidents and occupational injuries.
Companies are required to carry out a pre-shift health checkup for workers of certain occupations set out in legislation. The standard procedure is a doctor's examination. There are, however, disadvantages to this approach:
- The number of medical staff should be proportional to the number of workers subject to the examination
- Doctors aren't perfect and can make mistakes
- A medic can be tricked or bribed
Automated health checkups will avoid these drawbacks and achieve:
- Reduction in medical personnel
- Faster health checkup procedure
- Impartiality of checkup results
Solution
An electronic health checkup system, totally automated and able to carry out mass health checkups in a matter of minutes. The system delivers the verdict on whether a worker can proceed with his work duties. Only those workers who are not drunk or otherwise intoxicated and have no medical alerts are allowed to enter the production facility.
The EHCS carries out the following tasks.
- Evaluates whether an employee is ready for work on the basis of medical measurements.
- Creates a confirmation of clearance or non-clearance for work as an entry in an electronic health checkup log.
- Prints out documents (duty slip, medical referral etc.) on receiving a medical worker's electronic signature.
- Provides access to the working area depending on the outcome of the medical report.
The EHCS uses the following technologies.
Programming languages and interpreters:
- PHP programming language, on which the EHCS server is written
- SQL (Structured Query Language) for working with EHCS server databases
- Bash shell for executing certain EHCS server maintenance commands
Application software:
- phpMyAdmin database interface
- EHCS server web interface
- Terminal station software provided by application with graphical user interface running on Debian operating system
- CryptoPro cryptographic information protection facility for subjects to provide electronic signatures at the workplace
The server runs on Linux with Apache, MySQL, and PHP (LAMP).
The EHCS system has a three-level structure.
- Client level – medical terminal station and web interface at the doctor's workstation.
- Server level – Apache web server, PHP5, and PHP modules.
- Database level – MySQL.
All clients (doctor's workstation, duty medical officer's workstation, medical terminal stations and other equipment) within the system are connected to the server allowing them to interact. The EHCS server can be hosted in the cloud or directly on the company's local network.
Each device on the network (doctor's workstation, duty medical officer's workstation, medical terminal stations and other equipment) is assigned an address from a common address space, which is entered into a common database. The EHCS server, which has information about all system devices on the local network, can wait for incoming connections and send additional information to the devices.
System elements interact over the local network via HTTP/HTTPS protocol. The type of transport protocol is chosen by the system administrator according to the network architecture and security requirements of the company. In cases where network objects are geographically dispersed a VPN can be used.
The PHP application processes client queries though the requested URLs. In the case of GET queries, the server extracts information from the MySQL database where necessary, combining the information with HTML templates and returning the result to the client. In the case of POST queries, the database is updated with information received from the user in the form of session data.
Health checkup procedure
- The employee waiting to be examined approaches a medical terminal that isn't in use.
- He or she is identified by a proximity card or any other means of identification.
- The medical terminal station receives a plan for the health checkup procedure from the server.
- The server checks if the employee in question is currently eligible for the health checkup in accordance with the company's internal regulations.
- The medical terminal station takes the employee through various medical tests in the order set out in the health checkup plan.
- The usual order is an alcohol test, temperature measurement, pupil analysis and blood pressure test.
- At the end of the health checkup the employee confirms his identity by signing a special field displayed on the sensor screen.
- The data from the health checkup and its conclusions are transferred to the central database and displayed for the duty medical officer who either approves the work permit based on the health checkup data or summons the worker for an additional personal examination.
Curious incidents
Since the ‘target audience’ for the health checkups is made up mostly of unskilled workers, it stands to reason that checks for alcohol intake are by no means a formality. Nevertheless, as the proverb goes, ‘necessity is the mother of invention’.
A group of workers from the Urals managed to find a workaround for the first version of the breathalyzer test! They had a whole range of tricks up their sleeves… Some of them tried to breathe in instead of out, but that didn't work. Others had the bright idea of blowing out in such a way that the detector would start working, but the air stream wouldn't be strong enough for any measurements to be taken and the detector would return an error message.
Developers had a tough time trying to eliminate this error. They had to learn how to reproduce the situation. Only one troubleshooter working with the project team was able to produce such an ‘underbreath‘ almost every time on request.
An interesting situation happened with the pupillometry test, which analyses the subject's physical state by measuring pupil size and reactivity. The test is intended first and foremost to identify drug-induced intoxication, though it also provides a great deal of information about the general state of the body and psyche.
Naturally, there were attempts to sabotage this test too. The employees under examination attempted various tricks: they blinked, or moved their eyes from left to right. But thanks to these ‘challenges’ the hardware and software system was debugged and reworked to a high level of resistance to interference.
Another story. Some employees, highly motivated and eager – but unfit to work – asked their friends and colleagues to undergo the medical examination in their place. Naturally, the initial system logic took a photo of the subject and compared it to employee's photo in the company database. The will to cheat the system encouraged the more inventive workers to apply a number of tricks, however. Some of them would approach the terminal together trying to capture the ‘right’ face for the photo. To prevent such violations a video recording and facial recognition module was introduced.
Medical server
The medical server provides the main functionality for the medical checkup system. The main functions of the medical server are:
- Managing medical terminal station
- Processing the data from the medical terminal stations
- Organising the management of user roles and their permissions
- Providing a web interface for the doctor's workplace and other user roles
- Providing API interfaces for system devices
Web interface
The medical server provides a web interface to conduct automated medical checkups with an option of sending collected data to the medical server database, the so-called ‘doctor's workstation’.
The web interface can also be used for managing parameters and analysing the state of the system. Other possible functions are:
- Managing users
- Managing access rights
- Server update or recovery to previous versions
- Viewing debugging data and server event logs
- Configuring the rules of medical checkups
- Viewing checkup statistics and the results of each test in the checkup plan
Additional workplaces can be added to the system if needed.
Medical terminal
The medical terminal conducts an automated medical checkup of workers and sends the collected information to the EHCS medical server database. The terminal consists of an x86-compatible PC with connections to additional devices.
Structure of the medical terminal:
- Case
- Desktop PC (x86-compatible) with 17-inch sensor screen
- Contour chair
- Breathalyser (Dingo В-01, Dingo В-02 or alcoframe device manufactured by Laser Systems)
- A&D TM-2655 blood pressure monitor
- Thermometer (JXB-183)
- Custom-made pupilometer with a IDS USB 3 uEye LE high-speed commercial camera
- MIFARE card reader
- Full HD camera
The terminal has inbuilt software providing both the user interface and API for interaction with the system. The number of terminals installed differs depending on the necessary capacity of the system and the customer's needs. The terminal station's inbuilt software provides for centralised automatic updates and the possibility of high-volume deployment.
There is a mobile version of the terminal which was developed using a Raspberry Pi processor. The project was adapted, taking into account the limited computational resources of the platform. It was necessary to change the app runtime from NW.js to Electron and debug communications with equipment in the Raspberry Pi environment. The user interface was adapted for a smaller screen size.
Integration with Active Directory
To define roles in the system and locate users, the EHCS server has a mechanism for adjusting connections between EHCS roles and groups and Active Directory groups. With the help of Active Directory, correspondence is established between corporate network user groups and EHCS user groups. This allows them to be managed centrally, simplifying network administration as administrators don't have to connect to several catalogues in order to manage user accounts.
Cluster architecture
In order to enhance the stability of the system as a whole, a solution based on the Percona XtraDB Cluster was suggested.
The database server cluster was configured for synchronous data replication. To provide the necessary system performance, database servers are directly connected to each other using a channel with communication bandwidth no less than 1Gbps.
For web server cluster implementation a group of two or three web servers is used. Access to the web servers from the company's network is organised with the help of load balancing servers. Each web server is configured to work with a proprietary database server. In case the proprietary database server is out of order the web server will switch to a standby database server.
2002–2024