A Digital Model for Incident Reporting to Support Occupational Safety and Health in Laboratories

Abstract

People in laboratories often use paper or digital formats for incident reporting. These methods make it difficult to group events, check follow-up actions, or use the data to improve safety. This article presents a conceptual model for digital incident reporting in laboratories, designed to improve occupational safety and health (OSH) by addressing the lack of standardized reporting structures. The model was developed based on a review of safety standards, laboratory procedures, and relevant studies published between 2010 and 2024. The review identified five basic functions required for an effective digital incident reporting system: structured data input, event classification, alerting, access to reports, and follow-up tracking. These five functions were used to create a modular structure that shows how incident reporting works in laboratories. The model can be used with simple tools, and it does not require specialist software. It can be adjusted to local workflows and settings. While ISO 45001:2018 describes the goals of incident management, it does not offer a structure for reporting. This model responds to that gap. It supports consistent documentation and can help laboratories review incidents. This makes it easier to track responses, especially when no formal system exists.

1. Introduction

Incident reporting is a core activity in laboratory safety management. Laboratory work includes handling chemicals, using complex tools, and performing tasks that can pose biological or physical risks. These environments need procedures for documenting and reviewing safety events in a traceable way. Reporting is both a compliance need and a way to lower repeated risk exposure [1].

Many laboratories continue to use paper forms or unstructured digital formats for reporting. This can lead to late report submissions, missing information, and a lack of documented responses [2]. Unreviewed incidents, or those not linked to corrective actions, often repeated. Institutional audits and reports by national and European safety bodies have described similar concerns [3].

Laboratory safety systems must support more than documentation. Incidents should be recorded in the same format. They need to be reviewed promptly to spot risk patterns. Digital reporting systems can help with this. When used correctly, they can organize data collection, send alerts, and group reports by category. These functions can help staff use safety information adequately [4].

Even where digital tools exist, many laboratories do not apply them to incident reporting. Some rely on generic spreadsheets, while others avoid them because of a lack of time or technical support. In most cases, there is no defined reporting structure that links input, response, and follow-up. Therefore, while incidents are recorded, they do not always prevent similar occurrences [5,6].

Available technologies can support this process. Other fields utilize tools for basic data capture, automated alerts, and visual summaries. Laboratories rarely use them because the method for using them is not clear. A practical structure for reporting may help address this gap [7].

This article describes a conceptual model for digital incident reporting. It focuses on OSH procedures and issues seen in current practices. The model operationalizes these five functions by showing how incidents can be recorded, grouped, and monitored over time in laboratory environments. It shows how to record incidents, group them, and track them over time. The structure can help organize reporting in laboratories that do not use dedicated tools. The aim is to provide a structure that can be adapted to different laboratory environments. It does not depend on specific systems or advanced infrastructure.

2. Materials and Methods

This study proposes a conceptual model for digital incident monitoring and reporting in laboratory environments, grounded in OSH principles. The method involved reviewing relevant materials and defining system components based on identified functional needs. No empirical data were collected, and no human participants were involved.

2.1. Integrative Review

An integrative review was conducted to support the identification of essential functions required in a digital reporting system [8]. The review included OSH standards, laboratory safety procedures, incident report templates, and selected scientific publications. Sources were selected based on their relevance to reporting practices, system structure, and risk management in laboratory contexts. Searches were conducted using databases such as PubMed, Scopus, and Web of Science. The review covered documents published between 2010 and 2024.

Inclusion criteria focused on sources about incident documentation in laboratories, digital safety systems, and how organizations respond to safety events. Studies were excluded if they did not describe reporting mechanisms or if they only mentioned general safety principles without specific system details. The final selection included 25 sources.

The analysis followed a thematic, function-oriented approach. Common issues identified across sources included inconsistent documentation, delays in reporting, lack of feedback, and fragmented data storage. These patterns were used to extract the functional requirements relevant to incident management. The resulting categories informed the initial framework of the proposed model.

2.2. Functional Requirements for the Digital Model

The functional requirements were defined after reviewing practical documents and procedures used in laboratory safety. The aim was to identify what a digital system must include to support reliable reporting and basic incident management. This step did not involve software development or field testing. It was focused entirely on extracting operational needs that could guide the model’s structure [7].

The documents reviewed in the previous step were read in full. Observations were noted wherever reporting forms or instructions showed recurring issues. These included missing data fields, unclear classification systems, a lack of alerts for serious incidents, and no way to record what happened after the report was filed. Based on these patterns, five basic functions were extracted. These relate to how information is recorded, how it is labeled, how attention is directed to critical cases, how data is accessed later, and how responses are documented.

Each function was then translated into a simple, platform-neutral description. For example, to record an incident, you need a digital form. This form should have specific fields like the event type, date, location, and severity. Users should fill these fields using dropdowns or fixed options to limit variation. Classification should assign each report a risk type and a severity level from a fixed list. Alerting should rely on rules, such as severity thresholds or specific keywords. Data must be stored in a way that allows users to filter or sort reports over time. Follow-up actions should be logged in the same location as the original report.

The five functions were seen as separate parts. This way, others could reuse or adapt them. The structure was designed to use common tools such as spreadsheets or online forms. It does not require any programming skills. The logic behind the model can be applied using open formats and adapted to different needs, depending on the size and type of the laboratory.

2.3. Conceptual Model Development

The conceptual model was developed in three stages on the basis of the functional needs identified in the previous step (see Figure 1). The objective was to create a structure that reflects the standard process of incident reporting and follow-up in laboratory settings [9,10].

In the first stage, the core system functions were defined. These included structured data entry, risk classification, automatic notification, access to incident records, and the ability to log follow-up actions. Each function addressed common problems found in current reporting practices, such as incomplete reports, lack of alerts, or missing feedback. The functions were defined in simple terms. They were not linked to any specific technology or platform.

Next, the functions were arranged into a modular structure that reflects the main steps of incident management. The model has two types of components: reactive components record events and trigger alerts. Proactive components find repeated risks or patterns over time. Each module handles a distinct task, but shares inputs and outputs with the others. The modular design allows institutions to adopt the model step by step. They can also adjust individual parts to fit their own procedures. This flexibility helps laboratories that already use partial systems or have limited resources. The model was built to be adaptable and does not require custom software or a specific programming language. It can be applied using commonly available tools, such as spreadsheets, shared folders, or basic digital forms.

In the final stage, diagrams were created to show how the components interact. The visuals illustrate the structure and flow of information through the system. They are meant to help others understand and apply the model in their own context, even without custom software.

3. Results

3.1. Key Findings from the Integrative Review

Using digital tools in occupational safety helps spot physical risks early. Commercially available digital human modeling platforms used in manufacturing help analyze how people interact with tools and workspaces. This supports ergonomic design and reduces musculoskeletal injuries and work-related disorders [11,12,13,14]. Simulated environments and digital human models help test work scenarios safely and cheaply. They also reduce human error in laboratory activities [15].

The review showed that many laboratory incidents go unreported, especially minor events or near misses. This leads to gaps in safety data and missed opportunities to prevent future problems. Underreporting is often linked to unclear procedures, lengthy reporting formats, or concerns about possible consequences. In most settings, incident reports are stored in fragmented formats, on paper or in spreadsheets, without a centralized structure. This makes it hard to observe trends, compare team practices, or make evidence-based decisions [16].

The classification of incidents also varies. Some reports have short descriptions. Others use different terms for the same events. Without a unified structure, comparing data or applying consistent corrective actions becomes difficult. Another recurring issue is the lack of feedback. After staff submit a report, they often receive no follow-up. This lack of response lowers their motivation to report and harms trust in the process [17].

These findings showed that five key needs are essential for a digital reporting model. These include simple data entry, consistent categories, alerts for serious cases, tools to track trends over time, and a feedback system to monitor responses and results. The recurring limitations found across the reviewed sources derived these features and formed the foundation of the proposed digital model.

Ergonomics aims to improve worker safety, health, and task efficiency. It requires easy-to-use assessment tools that look at risk factors for musculoskeletal issues [18]. Digital human modeling helps by simulating how users interact with tools and environments. It uses anthropometric data for accuracy. This method brings in ergonomic principles early in workstation design. It also helps different stakeholders communicate during planning [19].

Using digital human models to simulate tasks also reduces the need for extended observation periods. This makes evaluation more efficient. This contributes to shorter design cycles and improved usability [20]. Testing changes in a digital space helps limit disruptions in laboratory workflows [21]. DHM 1.2.2 version software is now commonly used in the early design stages of vehicle interiors and industrial workplaces. It helps achieve better results while reducing the need for physical prototypes [22,23].

3.2. System Design and Features

The functional requirements defined during the design process formed the foundation of the model. Each requirement was derived from practical needs observed in existing safety procedures [24]. These needs were turned into five main functions. Later, each function was assigned to different system parts.

A key requirement identified was the need for an easy way to report incidents. Existing documents showed that open formats often led to inconsistent or incomplete entries. The model added fixed fields for key data. This includes incident type, time, location, and possible causes. Structured inputs reduced the chance of variation and made the information easier to use later [25].

Another result of the analysis was the need for consistent classification. Many reporting tools did not have a standard way to categorize events. This made it hard to compare data over time or between departments. The model addressed this by including a predefined set of risk types and a basic severity scale. This allowed incidents to be tagged in a uniform way [26].

The review also pointed to delays in how critical incidents are handled. In several procedures, there was no mechanism for escalation or alert. To improve this, a notification function was included in the model, based on simple rules. High-risk events or certain keywords can trigger alerts for the right people [27].

Incident data was often stored in ways that limited later use. In many cases, paper forms or spreadsheets made it hard to find or group related events. The model addressed this by including a data access function. It includes filters, date ranges, and easy visual summaries. The goal was to help users find information quickly without needing complex analysis tools [28].

Finally, the analysis showed that corrective actions were not always recorded or connected to the original report. This weakened accountability and reduced opportunities for learning. As a result, a feedback function was added. Users could document their responses and store them with the original record [27,29].

Together, these requirements shaped the structure of the model. They reflect a practical interpretation of identified problems. They also offer a way to create a modular and adaptable digital system.

Table 1. Summary of the core functions for the conceptual model and the issues addressed.

Function	Purpose	Operational Issue Addressed
Data entry	Standardize incident reporting with fixed fields	Incomplete, inconsistent, or vague reports
Classification	Categorize incidents using type and severity	Lack of comparison and trend identification
Notification	Automatically alert the responsible staff	Delayed response to high-risk events
Analysis	Enable filtering and basic trend visualization	Difficult access to grouped or historical data
Feedback	Document corrective actions linked to reports	No record of follow-up or learning steps

provides a brief overview of these functions and the specific problems they aimed to solve.

This study’s conceptual model directly addresses the issues found in the review. It includes five functional components: data entry, classification, notification, analysis, and feedback. form a modular structure. It mirrors a typical incident lifecycle in laboratory safety management.

The model is designed to be platform-independent. It can be implemented using basic digital tools, such as spreadsheets and e-mail, or developed into a more advanced application using open-source software and web interfaces. Figure 2 presents an overview of the system architecture and the interaction between components.

The data entry component (Figure 3) uses a digital form. This form collects structured details about each incident. The form includes required fields such as date and time of the event, location within the facility, type of hazard involved (e.g., chemical, mechanical, biological), and a short summary of the incident. A separate field lets the user estimate how serious the incident is. This is done on the basis of the impact, such as injury, equipment damage, or operational disruption. The form helps identify root causes. It includes a checklist of common factors, such as equipment failure, lack of training, procedural issues, and environmental conditions. Users can select one or more options or add a brief comment if none apply. Optional fields allow attachments, including photographs, scanned forms, or sensor-generated data (e.g., environmental conditions recorded during the incident). The form layout aims to reduce manual text entry. It uses dropdown menus, radio buttons, and yes/no toggles. This reduces input errors, speeds up completion time, and simplifies report processing later. The structure of the form makes sure all important details are recorded the same way for each incident, even if different users submit them. The system helps users follow a set sequence of fields. This cuts down on variability and makes the collected data more reliable. The reports using free-text fields often missed key details. This form structure was added to reduce that risk and help standardize how incidents are recorded.

The classification component (Figure 4) assigns each incident to a specific risk category and severity level using set criteria. Categories are based on commonly used OSH domains, such as chemical exposure, mechanical failure, biological contamination, ergonomic strain, and procedural errors. These terms are selected from a customizable list defined by each institution. If no suitable category is available, users may select “other” and provide a brief description. This choice helps prevent confusion and keeps reports consistent. Severity is determined using a simple decision model aligned with existing safety matrices. The user selects the potential or real outcome of the incident. This could be a minor injury, temporary equipment damage, or a laboratory shutdown. Then, they combine this with the estimated frequency or chance of it happening. The system assigns a severity level: low, moderate, or high. This level helps with prioritization and alerts later on. The form includes brief definitions and examples for each category and severity option. This helps reduce differences in interpretation. In advanced versions, rules in the reporting interface can help with classification. For instance, an incident can be tagged as “high severity” if it involves hospital treatment or evacuation. Using consistent labels on all reports helps sort and compare incidents. This includes type, severity, and location. This supports analysis over time, helps detect recurring hazards, and helps in making better decisions. The fixed categories and severity scale were introduced to avoid differences in how similar events are labeled across reports.

The notification component (Figure 5) sends automated alerts. This happens when an incident report meets set risk criteria. These criteria depend on factors like hazard type, severity level, and specific keywords. For example, keywords include “chemical spill”, “equipment failure”, and “injury”. When a report meets one or more of these triggers, the system immediately marks it for attention. Alerts go to set recipients. These usually include safety officers, laboratory supervisors, or OSH personnel. Depending on the system setup, notifications are sent through institutional e-mail, internal messaging platforms, or SMS. Each alert has key details: type of incident, location, time, and severity. It also includes a link to the full report for quick access. The alert system helps reduce response delays. It achieves this by notifying the right people about urgent cases automatically. It also provides a digital record of when alerts were sent and to whom, which can support follow-up and accountability. The system can check if alerts have been acknowledged or acted on within a set time. This function flags incidents needing urgent review based on set rules. It also sends alerts automatically, without any manual steps. As the number of alert conditions grows, it may become harder to manage them manually. The model assumes that rule changes are made by safety personnel, but this process could become less practical over time. A future version of the system could include a basic interface for editing rules or could use incident history to suggest changes.

The analysis component (Figure 6) offers a dashboard. Authorized users can review incident data easily and in an accessible format. The interface has simple filtering and sorting options. You can view reports by incident type, severity, location, or time period. This helps users concentrate on certain risk categories or areas with repeated events. Visualizations such as bar charts, line graphs, and frequency tables can be generated automatically from the stored data. These tools make it easier to detect trends that may not be obvious when reviewing individual reports. For example, an increase in equipment-related incidents in a specific lab can be seen across several months, even if each event on its own appeared minor. The dashboard includes export functions to support reporting, audits, or meetings. Data can be exported in a spreadsheet or PDF format for further use. Access is usually limited to specific roles in the organization. This helps keep data confidential and secure. This component helps teams make decisions. It shows incident patterns clearly. This way, teams can prioritize preventive actions. They can also track how safety measures affect outcomes over time. Filtering records by type or date is helpful. It makes it easier to manage incident data stored in different files or systems.

The feedback component (Figure 7) lets safety staff record actions taken for each reported incident. This includes corrective measures, such as equipment repairs, procedural changes, or additional training provided to staff. Each action goes in its own section and stays linked to the original report. The system keeps all follow-up details with the incident record. This creates a clear timeline of events from when the incident was reported to when it was resolved. This linkage helps with traceability. It makes it easier to check that the necessary actions were undertaken. Then, the user can see their impact over time. Users can see feedback in the system. They can quickly check which incidents were fixed, what actions were taken, and if similar issues happened again. This reinforces accountability and improves transparency. Beyond individual cases, the feedback history also supports organizational learning. Responses can show patterns that guide future planning. They also help improve safety procedures. This field includes documentation of what was done after the incident and keeps that information linked to the original report.

The results describe a structured model based on common safety needs in laboratories. The components are designed to be practical and adaptable, depending on the available tools and context.

3.3. Key Features

The model includes several features that can support rule-based alerting without requiring custom software. Safety personnel can set up notification rules. These rules can connect to any field in the incident form. This includes fixed selections and calculated fields. Rules can be adjusted as needed without technical assistance.

The model can include multiple levels of notification priority. The laboratories may choose to set up basic notices or urgent alerts, each linked to a delivery method and a group of recipients. Where digital tools allow, rules can trigger follow-up alerts if the first one is not confirmed in time. Some systems may also let users confirm receipt by clicking a link or selecting a response. These confirmations can be linked to the original report to support traceability.

The model also supports predefined message templates. These can match the incident type or severity. When available, templates help keep communication consistent across cases.

4. Discussion

This study proposed a functional model for digital incident reporting in laboratory environments. It assumes that a structured digital approach can improve data consistency, response time, and traceability in occupational safety workflows. The results show that organizing basic safety functions, such as reporting, classification, alerting, and follow-up, into a simple, modular system can fix gaps in traditional reporting practices.

The analysis of institutional procedures and regulatory documents revealed common problems: incident data are often incomplete, classification is inconsistent, and follow-up actions are rarely documented in a centralized format. These findings are in line with previous studies on laboratory safety management. They noted a lack of standardized tools and reliance on manual processes or local spreadsheets [17,27]. Research shows that incident learning and root cause analysis are often limited. This is due to how information is captured when reports are made [30]. The present model was designed to respond directly to these limitations.

The proposed structure introduces five separate but related functions. Fixed fields in the reporting component solve the problem of missing or unclear entries. They do this by standardizing the data collected. Compared to open-text reporting, this structure makes it possible to group, sort, and compare events over time. The classification component uses set risk types and severity scales. These are typical in OSH frameworks, but labs do not always follow them. This supports uniform interpretation and improves the potential for trend analysis.

Unlike many existing systems, the model includes a simple alert system. This lets users quickly review events that match specific criteria. This can be implemented through rule-based triggers in form systems or spreadsheets. Its simplicity supports adoption in laboratories that lack access to safety software. Previous research has explored solutions such as automated monitoring systems and integration with institutional platforms [31,32]. Other studies have focused on emergency response using IoT-based architectures and context-aware computing to detect and process laboratory incidents in real time [33]. These approaches are typically designed to support immediate intervention.

The model proposed in this study addresses safety management in a new way. It focuses on structured reporting, classification, and follow-up tracking. These can be undertaken with standard tools, so there is no need for special infrastructure. The feedback component was added in response to frequent gaps observed in institutional documents, where actions taken after an incident were often handled informally or not recorded. Linking follow-up to the original report reinforces traceability, which is required in most OSH audits but rarely operationalized in basic reporting systems [34].

One contribution of this model is that it aligns with international standards, such as ISO 45001:2018 [35]. These standards support organized incident management. They include finding hazards, assessing responses, and improving continuously [35]. While the standard outlines what should be achieved, it does not provide technical guidance on how to structure reporting. This model shows a way to implement using common digital tools. Most institutions already have these tools.

The structure is designed to be applicable across different laboratory contexts. In academic laboratories, reporting often lacks formal oversight. Therefore, this model can help define roles and basic procedures. In industrial settings, it can add missing parts to current systems. For example, it can include structured follow-up. Because each function is independent, the model allows partial adoption on the basis of local constraints. The findings also suggest that a structured model can improve communication among safety staff. It may also support better recordkeeping and reduce the time needed for audits and internal reviews. It is hard to measure these effects without field testing. Still, they match the goals of OSH strategies. These strategies aim to improve data quality and response coordination.

While the model remains conceptual, it may be used in various ways This depends on the tools available in the laboratory. Some configurations may work for teams that do not use dedicated safety systems. The following examples are based on common setups already used in many organizations.

Users can submit incident data using platforms such as Microsoft Forms or Google Forms, while structured storage and basic filtering can be managed using Excel spreadsheets or SharePoint lists. Rule conditions can be defined using basic formulas, and scripts (e.g., Power Automate or Google Apps Script) can evaluate new entries at regular intervals. When a condition is met, alerts are generated and sent through simple communication tools, using Microsoft Outlook or integrated into Microsoft Teams channels. This configuration supports the model’s main functions without requiring specialized infrastructure.

For more complex datasets, laboratories may use lightweight databases such as Microsoft Access or Airtable, where incident records and rule definitions are stored in structured tables. Queries or scheduled checks can create alerts on the basis of severity or keyword flags. This setup offers more flexibility but may require moderate technical knowledge.

Some laboratories may prefer to use visual automation platforms, such as Power Automate, Zapier, or Integromat, which support rule-based workflows. These platforms allow users to create logic flows. This connects data collection, storage, and notification steps. When an incident meets certain conditions, the system automatically sends alerts. It uses available channels such as e-mail or internal messaging. This setup is accessible and compatible with widely available institutional software.

These configurations offer a basis for applying the model. In practice, it could be introduced gradually using a staged approach. The first phase may focus on high-risk events, followed by near misses and general observations. Alerts at this stage may be directed to a small group of responsible staff and expanded later as reporting routines are established. For data collection, simple tools may be sufficient, while notifications involving severe cases might require more reliable delivery methods.

Moreover, any implementation of the model must ensure compliance with applicable data protection regulations and institutional rules for handling employee information and confidential records.

This research has some limitations. The model was not tested in a real environment and has not been evaluated with end users. It does not address interface design, user interaction, or data integration with other safety systems. These aspects should be considered during implementation. They depend on the laboratory’s technical capacity and organizational structure.

Future research may examine how well the model helps with incident classification, follow-up documentation, and using feedback in regular reports. It could also assess how the structure fits into existing systems. This is important, especially where tools still use paper forms or unstructured files.

There is also potential to connect the model with simple digital tools, such as Internet of Things (IoT) sensors or institutional dashboards. This may allow basic automation, such as alerts or summary views. Future work could compare the model’s performance in laboratories with various risk types. This includes laboratories that handle chemicals, biological agents, or radiation. Small-scale pilots could be used to test practical use. In future research, the model could be tested in real laboratory settings to assess its usability and effectiveness. User feedback will help improve the model and support its adaptation to existing safety systems. Additionally, future research may explore how the conceptual model can be adapted for integration with laboratory information systems (LIS), depending on technical compatibility and institutional context.

The results back the idea that a structured digital model can enhance reporting and managing laboratory incidents. The model does not replace safety frameworks. Instead, it offers a useful tool. This tool helps turn general principles into daily processes. These processes can be copied, reviewed, and adjusted to fit local needs.

5. Conclusions

This model was developed to support laboratories that aim to improve how incidents are reported and reviewed. It was built to work with minimal resources and can be adapted to various institutional settings. The functions described are based on operational needs and do not depend on a specific digital platform.

Safety officers, managers, and institutional teams can use this structure to review internal procedures. It can serve as a guide for creating new reporting tools. It also helps integrate basic OSH functions into current workflows. Because the model is modular, it can be applied in full or in part, depending on available capacity and context.

The model may also be useful for training purposes. Each function shows a step in incident management. It helps clarify what is expected from those handling safety tasks. In educational laboratories, the structure could support consistent reporting and improve communication between staff and students.

The approach outlined in this paper is intended to be practical and adaptable. It is flexible and can adapt to any laboratory’s needs. Laboratories can adjust it without needing significant technical investment.