Introduce Dedicated Root Cause Analysis (RCA) Module Separate from Actions

Problem statement:

• There is no dedicated facility to conduct Root Cause Analysis (RCA) within audits and safety reports.

• Current behaviour in AM captures RCA inside Action pop-ups, which is incorrect. RCA should precede and inform actions, not be captured as part of an action.

Required changes:

1. Introduce a dedicated RCA module/section for audits and safety reports

   • RCA should be a first-class component linked to the specific finding/non-conformance/observation.

   • Provide structured RCA fields (example set; confirm framework):

     • Problem statement / finding reference

     • Immediate cause(s)

     • Underlying/root cause(s) (e.g., 5 Whys analysis)

     • Contributing factors

     • Evidence and data considered

     • Selected RCA method (5 Whys, Fishbone/Ishikawa, Etc.) and its artifacts

     • Verification/validation notes

     • RCA owner, participants, dates, and status

   • Support attachments and diagrams (e.g., fishbone diagram images).

2. Decouple RCA from Actions

   • Remove any RCA inputs from Action creation/edit pop-ups.

   • Actions (corrective/preventive) should be created as outcomes of a completed or in-progress RCA and must reference the RCA record.

   • Allow multiple actions to be linked to a single RCA.

3. Workflow and permissions

   • RCA lifecycle: Draft → In Review → Approved/Closed (confirm exact states).

   • Permission controls: who can create/edit/approve RCA vs who can raise actions.

   • Prevent action approval/closure if the referenced RCA is missing or not in an appropriate state (configurable).

4. UI/UX integration

   • On each finding within an audit/safety report: “Start RCA” or “View RCA.”

   • RCA workspace with guided templates (5 Whys, Fishbone) and autosave.

   • Linkage panel to create/manage related actions from the RCA view.

   • Clear separation in the UI between RCA content and Actions.

5. Data model and integrity

   • New RCA entity linked to Finding/Observation (1:N: one finding may have zero or many RCAs; confirm desired cardinality).

   • Actions reference RCA ID (N:1 to RCA).

   • Enforce referential integrity; prevent deletion of RCA if actions depend on it, or require reassignment.

6. Reporting and audit trail

   • Include RCA fields in reporting and exports.

   • Maintain full change history (who/when) for RCA records.

   • KPIs: time-to-RCA completion, actions per RCA, recurrence rates.

Acceptance criteria:

• RCA can be created and managed independently of Actions, directly from findings in audits and safety reports.

• Action pop-ups contain no RCA fields; actions must reference an RCA when required by configuration.

• Multiple actions can link to a single RCA; links are visible in both directions.

• Role-based permissions and state transitions function as designed.

• All RCA activity is captured in audit logs and appears in reports.