HARA Workflow Questions

---

​

What is a Risk Record?

A Risk Record (riskRecord) is the central work item type in the HARA analysis. Each risk record represents a single row in the HARA risksheet, combining:

• A Use Step (what the user is doing)
• A Hazard (source of potential harm)
• A Hazardous Situation (circumstance of exposure)
• A Harm (injury or damage that could occur)
• Pre-mitigation and post-mitigation probability and risk level evaluations
• Links to Risk Controls that reduce the risk
• Optional benefit-risk analysis for residual risk justification

Risk records are edited exclusively through risksheet — they are read-only in the standard Polarion work item form.

---

​

How does the 4-level HARA hierarchy work?

The HARA risksheet organizes risk records into a 4-level tree structure: This hierarchy enables drill-down navigation: expand a use step to see its hazards, expand a hazard to see hazardous situations, and expand a situation to see the potential harms.

---

​

What are P1 and P2 probabilities?

The solution uses a two-factor probability model per ISO 14971:

• P1 (Hazard Probability): The probability that the hazardous situation occurs. Scale: 1 (Very Unlikely) to 5 (Very Likely).
• P2 (Harm Probability): Given the hazardous situation, the probability that it leads to actual harm. Scale: 1 (Rare) to 5 (Almost Certain).

The combined probability P is calculated as bucket(P1 x P2): This bucketing formula is computed automatically by the risksheet using JavaScript functions defined in risksheetTopPanel.vm.

---

​

How is harm severity determined?

Harm severity is not set on the risk record itself. Instead, it is resolved from the linked harm work item via the hasHarm link role. Each harm in the Standard Harms catalog has a pre-assigned severity value (1-5): The severity column in the risksheet displays this value as read-only (cellCss: creadonly), ensuring consistency with the catalog definition.

---

​

What are the three risk evaluation stages?

The HARA implements a three-stage risk evaluation pipeline aligned with ISO 14971:

1. Pre-mitigation (ISO 14971 Clause 5): Initial risk before any controls. Field: preRisk. Values: Acceptable, Investigation, Unacceptable.
2. Post-mitigation (ISO 14971 Clause 7.1): Residual risk after risk controls. Field: postRisk. Values: Acceptable, Investigation, Unacceptable.
3. Final risk (ISO 14971 Clause 8.3): Overall risk determination after benefit-risk analysis. Field: finalRisk. Values: Acceptable, Unacceptable, Benefit-Risk Acceptable.

The benefitAcceptable value is unique to the final stage and implements ISO 14971 Clause 7.4.

---

​

How does the final risk formula work?

The finalRisk column is computed automatically by the risksheet using this decision logic:

1. If postRisk is acceptable -> finalRisk = acceptable
2. If additionalControlsPossible is not “no” -> finalRisk = unacceptable (forces explicit evaluation)
3. If riskBenefitResult is benefitAcceptable -> finalRisk = benefitAcceptable
4. Otherwise -> finalRisk = unacceptable

---

​

How do I link risk controls to risk records?

Risk controls are managed in a separate document (Risks/RiskControlPlan) and linked to risk records via the mitigates link role. In the HARA risksheet:

1. Navigate to the Risk Control columns (RC ID, RC Name, RC Type)
2. Use the task link picker to select or create a risk control from the Risk Control Plan
3. The risksheet automatically resolves the mitigates link

Each risk control has a riskControlType multi-enum field following the ISO 14971 hierarchy:

• InherentSafetyDesign — Eliminate or reduce the hazard by design
• ProtectiveMeasure — Add protective barriers or features
• InformationForSafety — Provide warnings, labels, or training

See Assign Risk Controls to Hazards for the step-by-step procedure.

---

​

How does the HARA connect to DFMEA?

The HARA risksheet includes a FMEA cross-reference column that shows backlinks to failure mode work items via the analyzedIn link role. This column:

• Displays failure modes that are analyzed in the context of each risk record
• Uses a custom onClick handler for in-document navigation
• Bridges HARA (risk-based) to DFMEA (failure-based) analysis

This means engineers can see which design failure modes contribute to each hazard scenario, creating bidirectional traceability between the two methodologies.

---

​

How does traceability work from risk controls to test cases?

The HARA risksheet provides two server-rendered columns that traverse the traceability chain:

1. Requirements column: Follows back-links from risk controls to find linked sysReq and desReq work items. Shows which requirements implement each risk control.
2. Verification Evidence column: Performs a two-hop traversal: risk control -> requirements -> test cases. Shows which test cases verify the requirements that implement each risk control.

This creates a complete traceability path from risk identification through control implementation to verification evidence.

---

​

What views are available in the HARA risksheet?

The HARA risksheet provides 5 predefined views: Switch between views using the view selector in the risksheet toolbar.

---

​

What happens to the risk color coding?

Risk levels are color-coded throughout the risksheet and reports: The row header also displays this color using the rowHeaderRpnNew renderer, providing at-a-glance risk status for each record.