An occupational safety and health system supports the people responsible for identifying hazards, controlling work and reporting incidents. Software can organise evidence and enforce configured approval steps; it cannot guarantee safe work or replace a competent safety assessment.
For a Malaysian deployment, define the workplace, activities and applicable duties before choosing modules. A construction-site workflow and an office incident register will not require the same implementation.
Start with the regulatory and operating scope
Review the Occupational Safety and Health Act 1994 and its amendments, relevant regulations and current DOSH guidance. MS 1722 and ISO 45001 describe management-system approaches; they are not blanket certifications of a software product. DOSH, ISO 45001 overview.
For incident records, distinguish JKKP 6 accident/dangerous-occurrence notifications, JKKP 7 occupational poisoning/disease notifications and the JKKP 8 register. Some events require immediate notification followed by a written report. Generating a PDF does not complete submission or establish that deadlines were met. Record responsibility, submission status and receipt evidence. DOSH reporting FAQ.
Design modules around decisions
| Module | Workflow to support | Important boundary |
|---|---|---|
| Hazard assessment | Identify hazards, assess risks and assign controls | A matrix score does not replace competent judgement |
| Incident management | Record events, escalate and support reporting | Reporting duties depend on the event and applicable rules |
| Permit to work | Define work, authorise controls and close the permit | Approval must reflect current site conditions |
| Inspection | Record findings, owners and corrective actions | Photos and timestamps are evidence, not proof of a safe site |
| Training and contractor records | Check qualifications needed for assigned work | Requirements vary by role and industry |
CIDB registration concerns construction personnel in its applicable scope. Do not require a Green Card for every worker in every OSH system simply because it is a common construction credential. CIDB personnel registration.
Keep elevation and fall exposure separate
Construction drawings may use TOG for Top of Grating, TOS for Top of Steel and TOC for Top of Concrete. Confirm each abbreviation and datum against the project’s drawing legend. These are elevations, not standalone fall-protection thresholds.
For example, a work surface’s height above a drawing datum does not establish the distance a person could fall. Nearby surfaces, openings, edge protection, task position and rescue arrangements affect the assessment. The permit logic should use a competent assessment of actual exposure and required controls; it must not approve work solely because a TOG or TOS number falls below a configured limit. DOSH work-at-height guidance.
Define field reliability explicitly
Offline capture can help workers record observations where coverage is poor. It also introduces stale information, duplicate submissions and conflicting edits. Decide which actions can be captured offline and which need current authorisation. A queued permit request should not appear approved while the authoritative system is unreachable.
Specify synchronisation status, conflict handling, attachment limits and a recoverable local queue. Define outage procedures with operations staff. Availability targets should reflect the workflow’s consequences and recovery arrangements; 99.9% is a possible service target, not a universal OSH mandate.
Protect incident and worker data
Incident records may contain health information and other personal data. Assess access, retention, encryption, supplier processing and audit integrity. Separate original observations from later corrections, and restrict access by responsibility. Hashing or timestamping a record alone does not make the whole ledger immutable.
Encryption at rest and transport security are separate decisions. Specify protocols, key handling and operational controls rather than calling AES-256 a complete minimum for every situation. Our Malaysian PDPA guide explains the broader privacy assessment.
Trace a hazard to an accountable closure
In an illustrative field workflow, a worker records a damaged guard with a photo and location while offline. A supervisor receives the synced report, assigns an action owner and restricts work according to the organisation’s approved procedure. The responsible competent person determines the required control; the system records that decision. Closure requires evidence of the action and authorised verification, with history retained when someone reopens the issue.
If two devices edit the same action offline, preserve both submissions and flag a conflict for the designated owner. Do not silently accept the last upload as the correct safety decision. Acceptance covers queued photos, failed upload, stale status, duplicate submission and restricted access to incident information.
Frequently asked questions
Can software approve our safety procedure or certify compliance?
No. The organisation’s responsible and competent people own those decisions. The implementation should support the approved workflow and evidence, with applicability reviewed by qualified advisers.
What is enough for a first scope?
Bring one hazard-to-closure journey, roles, sample forms, offline conditions and retention decisions. Enterprise application development can scope those requirements; the delivery guide helps record acceptance and handover.
Choose architecture after the workflow is understood
For a hypothetical field observation, record the location, task, worker, drawing reference and actual exposure separately. If the device is offline, the submission can be queued as pending; it must not display a permit as approved. A competent safety person determines the controls and authorization path, and the system records that decision and its evidence. This is a design example, not safety approval or a Nodesify client result.
A modular application may be enough. Microservices, geofencing, IoT and BIM integration should solve a demonstrated requirement, not be prerequisites for calling the system enterprise-grade. For each integration, define the data owner, freshness, failure mode and how users recognise uncertain information.
Before handover, agree acceptance criteria for essential field workflows and reporting responsibilities. Our mobile development service and architecture audit service can help scope the implementation with your safety team.
