Here you can create, review, and edit steps and sub-steps in the process.

Definitions:

• F: fraction of patients going through the step/sub-step. 100% means "all patients".
• R: average number of repetitions per patient in a step/sub-step.
• Failure modes: number of failure modes which can occur during the execution of the step/sub-step (total; with acceptable, tolerable and not acceptable risk).
• Neff: sum of the expected event rates neff of all the failure modes which can occur during the execution of the step/sub-step.

If "potential" safety measures are defined, the influenced values are displayed in the format: current what if, where the "current" value takes into account active measures only, whereas the "what if" value takes into account active and potential measures.

Create, review, and edit failure mode effects.

Definitions:

• Count: number of failure modes generating the effect.
• Severity: highest severity between the failure modes generating the effect.
• RPN: highest RPN between the failure modes generating the effect.
• Neff: sum of the expected event rates neff of all the failure modes which generate the effect.

If "potential" safety measures are defined, the influenced values are displayed in the format: current what if, where the "current" value takes into account active measures only, whereas the "what if" value takes into account active and potential measures.

The expected event rate neff is the number of patients per year which are expected to experience the effect of the failure mode.

It is calculated as follows. The probability Pocc that the failure occurs is:

Pocc=Pocc,i·Πpmiss

where Pocc,i=Pocc,i(Oi) and the product is performed over all added preventions.

The probability that the failure remains undetected and generates its effect is:

Peff=Pocc·Pmiss,i·Πpmiss

where Pmiss,i=Pmiss,i(Di) and the product is performed over all added barriers. Finally, the expected event rate is:

neff=Peff·T·F·R

Where T is the process throughput (patient/y), F is the fraction of patients going through the current step/sub-step and R is the average number of repetition per patient of the current step/sub-step.

Here you can perform a FTA analysis.

Typical procedure:

1. Set the process throughput and acceptance levels in "Settings".
2. Define the list of possible adverse effects (left hand side).
3. For every effect, create the potential failure modes.
4. Review the risk associated to failure modes using the available metrics (expected event rate, acceptability). Adjust initial risk evaluation (S, Oi, Di) if necessary.
5. Identify best placements for safety measures by looking at effect fault trees (click on "Show diagram").
6. Add safety measures (preventions or barriers) to failure modes whose risk must be mitigated.

If "potential" safety measures are defined, the influenced values are displayed in the format: current what if, where the "current" value takes into account active measures only, whereas the "what if" value takes into account active and potential measures. Similarly, the failure mode acceptability status (the "traffic light") is shown as (current)(what if).

These are the definitions of the parameters shown in this table:

• Pocc,i: failure mode occurrence probability corresponding to the initial occurrence evaluation Oi. It is determined by the cause and by the initial prevention.
• pmiss of an added prevention: probability that the prevention is not effective in neutralizing the cause.
• Pocc: failure mode occurrence probability:
  
  Pocc=Pocc,i·Πpmiss
  
  where the product runs over added preventions.
• Pmiss,i: conditional probability that the failure mode occurs and remains undetected, corresponding to the initilial detectability evaluation Di. It is determined by the initial barrier.
• pmiss of an added barrier: conditional probability that the failure mode occurs and it is not detected by the barrier.
• neff: expected event rate generated by the failure mode.
  
  neff=Pocc·Pmiss,i·Πpmiss·T·F·R
  
  where the product runs over added barriers, T is process throughput, F the fraction of patients going through the step/sub-step in which the failure occurs, and R the average repetitions per patient of said step/sub-step.
• Neff: sum of neff for all the failure modes generating the same effect.

If "potential" safety measures are defined, the influenced values are displayed in the format: current what if, where the "current" value takes into account active measures only, whereas the "what if" value takes into account active and potential measures. Similarly, the acceptability status is shown as (current)(what if).

Here you can see a comparison of costs and benefits determined by all added safety measures.
One safety measure can act on one or many failure modes.

Definitions:

• Δneff: the event rate reduction determined by a safety measure M which acts on a certain failure mode FM:

  Δneff=neff'-neff

  Where:
  • neff' is the event rate of FM calculated by taking into account all safety measures with active status and different from M.
  • neff is the event rate of FM calculated by taking into account all safety measures with active status and M (whatever its status).
  
  
• ΔNeff: the overall event rate reduction determined by a safety measure M which acts on multiple failure modes FM1, FM2…:

  ΔNeff=Δneff1+Δneff2+…

• Event-Related Savings: monetary savings induced by Δneff over a certain number Ny of years (default Ny=5). These are costs related to events which will not occur if the safety measure is in place. If the measure acts on one single failure mode FM which generates the effect e with event cost Ce:

  (Event-Related Savings)=Δneff·Ce·Ny,

  If the measure acts on more failure modes FM1, FM2…:

  (Event-Related Savings)=Δneff1·Ce1·Ny+Δneff2·Ce2·Ny+…

• Non-recurring cost: the cost component of a safety measure, independent from how long the measure is used. Example: the initial cost necessary to purchase new equipment.
• Recurring cost: is the cost component of a safety measure which is proportional to the time it is used. Examples: SW subscriptions; service contracts; periodic calibration; time needed to operate QA equipment and to perform reviews.
• Total cost: the overall cost paid to implement and operate a safety measure over a certain number Ny of years (default Ny=5).

  (Total cost)=(Non-recurring cost)+(Recurring cost)·Ny.

You can add a prevention to this failure mode:

• A new prevention. Relevant fields are
  • Name (required)
  • Status (required): three options are possible: active (a prevention already implemented), potential (an idea under evaluation), not active (a prevention neither implemented, nor under examination, e.g., an old, discarded idea)
  • pmiss (required): the probability that the prevention does not stop the cause from activating the failure mode; e.g., a prevention with "pmiss=20%" reduces the occurrence probability to 20% of its initial value Pocc,i.
  • Non-recurring cost: the cost component of a safety measure, independent from how long the measure is used. Example: the initial cost necessary to purchase new equipment. This cost will be used in cost/benefit analysis.
  • Recurring cost: the cost component of a safety measure, proportional to the time it is used. Examples: SW subscriptions; service contracts; periodic calibrations; time needed to operate QA equipment and to perform reviews. This cost will be used in the cost/benefit analysis.
  • Key/Note: a text field to add annotations, remarks, or a reference key.
• An existing safety measure: a barrier or prevention which is already mitigating one or more other failure modes, will be applied as barrier to this failure mode. You just need to specify its pmiss. Values for costs and status which have been already defined will be re-used.

You can select 2 or more steps to be merged.

Selection order is important. If S1 is the first selected step, S2 is the second etc:

• The content (failure modes and sub-steps) of all selected steps is moved into S1.
• The final order of items (failure modes or sub-steps) inside S1 reflects the step selection order.
• Other steps S2, S3... will be deleted.

Special cases:

• If at least one step has a sub-step and at least one step has failure modes without sub-steps, these failure modes will be assigned to the first sub-step in the merged step.
• If different steps have sub-steps with the same name, these sub-steps will remain distinct after merge

You can select 2 or more effects to be merged.

Selection order is important. If E1 is the first selected effect, E2 is the second, E3 is the third, etc:

• All failure modes which before merge generated effects E1, E2, E3…, after merge will generate the effect E1.
• Effects E2, E3…… will be deleted.

Initial detectability: it reflects the likelihood that the failure is detected after occurrence, before it generates an adverse effect. It depends on the initial barrier in place. You can define one of these parameters (the other will be automatically calculated):

• Detectability score Di: a number ranging from 1 to 10 (see scales table).
• Pmiss,i: conditional probability that the failure mode occurs and remains undetected.

Initial occurrence: it reflects the likelihood or frequency that the failure mode occurs, in view of the cause and initial prevention in place. You can define one of these parameters (the other will be automatically calculated):

• Occurrence score Oi: a positive number ranging from 1 to 10 (see scales table).
• Pocc,i (%): probability that the failure mode occurs during the execution of the step/sub-step.

Severity: severity of failure mode effect.
A positive number ranging from 1 to 10 (see scales table).

F: fraction of patients going through the step/sub-step. 100% means "all patients".

R: average number of repetitions per patient of the step/sub-steps.

Analyze the reported issue and identify the cause, failure mode and effect

Here you can perform a FMEA analysis of the process.

Typical procedure:

1. Set the process throughput and acceptance levels in "Settings".
2. Describe your process (left-hand side), either as a list of steps/sub-steps, or as a flowchart.
3. For every step/sub-step create the potential failure modes.
4. Review the risk(s) associated with the failure modes (right-hand side) using one or more of the available metrics (RPN, expected event rate, acceptability). Adjust initial risk evaluation (S, Oi, Di) if necessary.
5. Add safety measures (preventions or barriers) to failure modes whose risk must be mitigated.

If "potential" safety measures are defined, the influenced values are displayed in the format: current what if, where the "current" value takes into account active measures only, whereas the "what if" value takes into account active and potential measures. Similarly, the acceptability status (the "traffic light") is shown as (current)(what if).

6. Validate the failure mode evaluation with reported incidents (possible with "retrospective module" only).

To track how a risk analysis progresses:

• Set the progress stage of individual failure modes (ranging from "Analysis needed" to "Failure mode validated") using failure mode edit dialog.
• Set the progress stage of the whole risk analysis (ranging from "created" to "validated") in the blue ribbon.

Here you can:

1. Adjust the initial evaluation of detectability (Di or Pmiss,i).
2. Add barriers.

Definitions:

• Pmiss,i: the initial conditional probability that the failure mode occurs, and it is not detected. Pmiss,i is an invertible function of the initial detectability Di. You can calculate D from Pmiss and Pmiss from D.
• Barrier: a safety measure aimed to detect an occurred failure mode before it has an impact on a patient.
• Initial barriers: barriers which are already implemented in the clinic the first time the risk analysis is performed. Their effect is included in the initial evaluation of detectability Di.
• Added barrier: a barrier added during risk analysis as additional safety measures. You can add as many as necessary.
• pmiss of an added barrier: the conditional probability that the failure occurs, and the barrier does not detect it.
• Status of an added barrier: three options are possible: active (the barrier is already implemented), potential (the idea is under evaluation), not active (the barrier is not implemented, nor under examination, e.g., an old, discarded idea)
• Non-recurring and recurring costs: cost necessary to implement a barrier.
• Detection step: process step during which the barrier allows to detect the failure mode (in general, it is a step subsequent to the step where the failure mode occurs). Available with retrospective module only.​
• Pmiss of a failure mode: the conditional probability that the failure mode occurs and that it remains undetected, despite all available barriers.

Pmiss of a failure mode: the conditional probability that the failure mode occurs and that it remains undetected, despite all available barriers. It is calculated as:

Pmiss=Pmiss,i·Πpmiss

Where Πpmiss is the product of the probabilities pmiss of all added barriers.

Pmiss is an invertible function of mitigated detectability D; You can calculate D from Pmiss and Pmiss from D.

Note: if at least one potential barrier is defined, Pmiss and D values, as well as all the functions in which these values are used (RPN, neff, Neff, Δneff) are printed in the format:

current what if,

where the "current" value takes into account active barriers only, whereas the "what if" value takes into account active and potential barriers.

You can add to this failure mode:

• A new barrier. The relevant fields are
  • Name (required)
  • Status (required): three options are possible: active (the barrier is already implemented), potential (the idea is under evaluation), not active (the barrier is neither implemented, nor under examination, e.g., an old, discarded idea)
  • pmiss (required): the conditional probability that the failure occurs, and the barrier does not detect it.
  • Non-recurring cost: the cost component of a safety measure which is independent from how long the measure is used. Example: the initial cost necessary to purchase new equipment. This cost will be used in the cost/benefit analysis.
  • Recurring cost: the cost component of a safety measure which is proportional to the time it is used. Examples: SW subscriptions; service contracts; periodic calibrations; time needed to operate QA equipment and to perform reviews. This cost will be used in the cost/benefit analysis.
  • Detection step: the process step during which the failure mode will be detected with this barrier. In general, it can be a step subsequent to the step where the failure occurs (available only with "retrospective module").
  • Key/Note: a text field to add annotations, remarks or a reference key.
• An existing safety measure: a barrier or prevention which is already mitigating one or more other failure modes, will be applied as barrier to this failure mode. You just need to specify its pmiss. Values for costs and status which have been already defined will be re-used.

Here you can:

1. Adjust the initial evaluation of occurrence (Oi or Pocc,i).
2. Add preventions.

Definitions:

• Pocc,i: the initial probability of occurrence due to the cause and the initial prevention. Pocc,i is an invertible function of the initial occurrence Oi; You can calculate Oi from Pocc,i and Pocc,i from Oi.
• Prevention: a safety measure aimed to reduce failure mode occurrence.
• Initial prevention: preventions which are already implemented in the clinic the first time the risk analysis is performed. Their effect is included in the initial evaluation of occurrence Oi.
• Added prevention: a prevention added during risk analysis as additional safety measures. One can add as many as necessary.
• pmiss of an added prevention: the probability that the prevention does not stop the cause from activating the failure mode; e.g., a prevention with "pmiss=20%" reduces the occurrence probability Pocc,i to 20% of its value.
• Status of an added prevention: Three options are possible: active (a prevention currently implemented), potential (an idea under evaluation), not active (a prevention neither implemented, nor under examination, e.g., an old, discarded idea)

• Pocc: the probability of failure mode occurrence in view of Pocc,i and all added preventions.

Pocc: the probability of failure mode occurrence in view of Pocc,i and all added preventions. It is calculated as:

Pocc=Pocc,i · Πpmiss

Where Πpmiss is the product of the probabilities pmiss of all added preventions. Pocc is an invertible function of mitigated occurrence O; You can calculate O from Pocc and Pocc from O.

Note: if at least one potential prevention is defined, Pocc and O values, as well as all the functions in which these values are used (RPN, neff, Neff, Δneff) are printed in the format:

current what if,

where the "current" value takes into account active preventions only, whereas the "what if" value takes into account active and potential preventions.

This table shows an overview of all available risk analyses.
If more versions of a risk analysis are available, data relative to the most recent version are shown, including:

• Accessible to: all users or the member of a specific department/group (function available with "multi dept/group module" only).
• Failure modes: no. of failure modes in the risk analysis: total and with acceptable, tolerable, and not acceptable risk.
• Version: number of the most recent version
• Stage: a label (from "created" to "validated") showing how the risk analysis is far from completion. The stage is set by the user.
• Released: this field shows "yes" if the last risk analysis version has been released.
• Last update: last time the most recent version was updated
• Due date: due date of the risk analysis (if this information has been defined by the user).

Clickable links in Risk Analyses table include:

• Note: see the notes available for this risk analysis (the same effect is achieved with the expand button ">" on the left).
• : open the risk analysis (FMEA tab) in view mode
• : open directly the risk analysis (FMEA tab) in edit mode
• : open the risk analysis and go to the version management tab

• Name: name of the risk analysis. For a FMEA study it is typically the name of the process/workflow you are going to investigate.
• Patients per year: no. of patients per year which are (or will be) treated with the process under study. It is indicated with the symbol T ("throughput") in formulae.
• Cost calculation period (years): the period over which the total cost of safety measures, inclusive of non-recurring costs and recurring costs, is calculated. It is indicated with the symbol Ny in formulae.
• Next due-date: the next deadline for this risk analysis. Due dates are shown in the risk analyses library dashboard.
• Accessible to: who can access this risk analysis. Either "all users" or the members of a specific department/group (only available with "multi dept/group module").
• Note: any annotation and remark you may want to add to the first version of this risk analysis. If you will create subsequent versions, you will have the chance to add a different note to each of them.

An incident form template is basically a list of questions.

• Add questions in "Designer" view:
  • Select the type of question from the left sidebar. Use "dynamic panel" if the user can answer multiple times (e.g., to specify multiple incident causes).
  • Set question properties using the right sidebar. Typical properties are question text, or if an answer is required or optional. You can also define a "logic", so that a question pops up only if specific answers are given to other questions.
• Review the form in "Preview" view
• Review questions logic in "Logic" view
• Navigate through a complex form by clicking on "Survey"

Here you can manage departments/groups.

A department/group is an entity which can be used to represent any unit in your organization. It can be for instance a department, a team, an operative unit, a satellite, a site etc. You can:

• Create a new dept /group ("+ Department/group"). Note that the maximum number of allowed depts/groups is defined in your license.
• Edit (name and description) a department/group ().
• Delete a department/group. If you do so, all risk analyses associated to it will be accessible to all myQA PROactive users.
• Manage the members of a department/group (expansion button "+" or "team" icon).

A risk analysis can be associated to a department/group using its settings. If you do so, it will be visible only to members of that dept/group.

Functions available is risk analysis` "Settings" tabs:

• General: general settings of the risk analysis (name, patients/y, next due date, stage, accessibility etc.)
• Acceptance criteria: they are used to define the acceptance and tolerance levels for failure mode risk. These criteria are used to determine the color of the "traffic light" indicators associated to failure modes. Acceptance criteria are specified with a risk matrix, and two options are available: (S vs neff) and (S vs OxD).
• Version management: create a new version of the risk analysis, delete an old one, release the most recent.
• Incident forms: define which forms shall be used to report and analyze incidents (only available with retrospective module). Options are all the forms defined in the "incident form library" in general settings
• Keyword management: manage the keywords associated to failure modes (only available with the retrospective module).

General settings of the risk analysis version which is open:

• Name: name of the risk analysis.
• Patients per year: process throughput, used for the calculation of expected event rate.
• Period for cost calculation: period over which the total cost of a safety measure is calculated, taking into account recurring and non-recurring costs). It is used in the cost benefit analysis.
• Currency: currency used in the cost benefit analysis
• Next due date: by when the risk analysis should be completed. It is a reminder shown in the risk analyses dashboard.
• Start of validation date: date from which the number of expected events and near events are compared with the number of reported incidents (available only with the "retrospective module").
• Version note: text annotation to record additional information about a risk analysis version.
• Accessible to: who can see and access the risk analysis. It can be "All users" or a specific department/group (available only with the "multi-dept module").

The incidents table provides a summary of incidents reported for this risk analysis:

• Date: date on which an incident was reported with a terminal or created in the application. If the incident is appended with an xls spreadsheet this is the incident date in the file.
• Terminal name: name of the terminal used to report the incident. This field remains blank if the incident is created in the application or appended from a spreadsheet.
• Step name/Failure mode: if the incident has been associated to a failure mode, failure mode name, step/sub-step are indicated in this field.
• Type: type of incident: event, near event or inconvenience. If the type has been not specified yet, (not specified) appears in this field.
• Text comment/Voice comment: text description and/or voice comment associated to the incident. A voice comment can be added only when the incident is reported with a terminal.
• Stage: progress stage of the incident. It is a tag ranging from "Incident created" to "Analysis completed", which can be set by the user.
• Accomplished tasks: a set of flags indicating:
  • If a failure mode has been associated to the incident;
  • If the incident type has been specified;
  • If all forms required for incident reporting and analysis has been completed. If no form is required, this field is automatically checked.
  • If all forms optional for incident reporting and analysis have been completed. If no form is defined for this type of incident, this field is automatically checked.
  • If at least one remark has been classified as public (which will be shown in the webpage "Feedback for reports")

• Forms: forms used to provide additional information during incident reporting, or to analyze the incident. Beside forms already defined in risk analysis settings, the user can add any form from the "form library" to analyze the incident.
• Attachment: files attached to the incident.
• Remarks: text remarks added to the incident during the analysis. An arbitrary number of remarks can be created. Remarks are by default "internal", but they can be marked as public, in which case they are shown in the webpage "feedback for reporters".
• Changes: list of changes made to the incident starting from its creation.

In this web page you see an overview of what is going on with the incident reported within the access group specified above:

• Date: date on which the incident was reported.
• Process: name of the process/workflow during which the incident occurred.
• Reporting terminal/process step: if the incident has been reported with a myQA PROactive reporting terminal, its name is indicated here. The process step is the one during which the incident occurred.
• Processing stage: the current stage of incident analysis. It can range from "Incident created" to "Analysis completed".
• Accomplished tasks: it indicates if the main milestones in incidents analysis have been achieved:
  • Failure mode: the incident has been recognized as the manifestation of a failure mode in the risk analysis of the process.
  • Incident type: the incident type (event, near event, inconvenience) has been specified;
  • Required forms: all forms required for incident reporting and analysis have been completed.
  • Optional forms: all forms optional for incident reporting and analysis have been completed.
  • Public remarks: at least one remark has been classified as "public" during incident analysis. The full list of public remarks, which have a degree of confidentiality low enough to be shown in this page, can be visualized by clicking on the expand button on the left ("+").
• Most recent change: the most recent modification made to this incident during its analysis.

To validate a failure mode:

1. Select the failure mode by choosing a step/sub-step and a failure mode within it.
2. First look at "occurrences" plot on the right.
   • If expected () and reported ( ) occurrences match, your evaluation of occurrence O is correct.
   • If they do not match, change either the initial occurrence or the Pmiss of any active added prevention. Adjust these values until the fit () is superimposed to reports ().
3. Second, look at either "near events" or "events". Do this only if occurrences match! We consider "events" as an example.
   • If expected and reported events match, your evaluation of detectability D is correct.
   • If they do not match, change either the initial detectability or the Pmiss of any active added barrier.
   • Adjust these values until the fit () is superimposed to reports ().
4. Save, so that the risk analysis is updated with new values.

• To see an overview of incidents assigned to failure modes, select "All steps". "All failure modes" will be set automatically.
• To see an overview of incidents assigned to failure modes in a specific step/sub-step, select the step/sub-step and "All failure modes".
• To see an overview of incidents not yet assigned to any failure mode, select "Unspecified step". "Unspecified failure mode" will be set by default.

Here you can manage incident form templates:

• Create your own template using the myQA PROactive graphic editor ("+Incident form template").
• Import a form template file, for instance an example file you have received from IBA or from colleagues ("Import").
• Edit a form template using the myQA PROactive graphic editor ("").
• Export, delete or duplicate a form template ("…").

The form templates available in this library can be used to document and analyze incidents associated to any risk analysis. Which forms are required or optional is defined in the risk analysis settings.

Here you, as the safety officer, can specify in which cases you receive an email notification if an incident is reported. For every risk analysis you have access to you can specify:

• If a notification is sent for incidents of type inconvenience, near event and event, or for incidents whose type has been not classified at the time of reporting ("(not specified)").
• If incident details are shown in the email. Check this box if you want to see in the mail body possible text comments added by the incident reporter. Otherwise you will see only standard information: reporting terminal, failure mode associated to the incident (if any), incident type (if any)."

Here you can review and edit the process description as a flow chart.

Flowchart editor components:

• The canvas: it is the main area (in the center) where the flow chart is displayed.
• The left hand-side toolbar, from which new shapes can be selected. To add a shape to the diagram, simply drag and drop it from here to the canvas. This toolbar appears only if editing is activated. The shape "Predefined process" can contain a child-flowchart, which become visible in the canvas by double-clicking on it.
• The top toolbar: here you have generic tools to zoom, export, save and print the flowchart. Use the "eye" icon to show/hide the information about how many failure modes are in a step, and their risk level.
• The right hand-side property bar. It is shown if editing is activated and if a shape in the canvas is selected. Here you can set graphical properties of a shape, like color, text, font size etc.

Shape controls. If you select a shape in the canvas, a set of icons appears around it. They allow you to:

• Drag a link to connect this shape with other shapes.
• Clone the shape (i.e., create a replica in the main canvas, without connections).
• Clone the shape and keep the new shape connect to the original one with a link.
• Associate a step to the shape. This will open the "New step" dialog. A corresponding entry is created in the process list.
• Delete the shape. If the shape corresponds to a step, the deletion will delete both the shape and the entry in the process list.

1. Every step/sub-step in the list is automatically associated to a shape in the flowchart.
   • If a step is created in the list, a shape of type "process" is added to the flowchart.
   • Every step with sub-steps in the list is described by a "Predefined process" with a child flow-chart. For every sub-step created in the list, a shape of type "process" is added to the child flowchart.
2. Any shape in the flowchart can be "associated" to a step in the list:
   • If a shape in the flow chart is "associated" to a step, the new step is added to the list.
   • If a shape in a child flow-chart is "associated" to a sub-step, the new sub-step is added to the list.

Note that when a shape is added to the canvas, by default it is not associated to any step. These shapes are not reflected in the list unless they are "associated" to a step. All the artwork (connections, colors, comments) is not reflected in the list too.

Fault tree construction rules:

• A fault tree is associated to every failure mode effect. The effect represents the top event of the tree.
• Every failure mode with that effect is represented by a branch in the tree.
• Every branch has a standard structure, describing the following logical relationships:
  • A cause generates a failure mode if i) it activates and ii) all preventions acting on it are ineffective.
  • A failure mode generates the effect if i) it occurs and ii) all the barriers acting on it fail.

A tree can be visualized as a table (view and edit) or as a diagram (view only). You can decide to visualize all safety measures, or only those which are active, not active or potential.

Here you can release the last version of this risk analysis. The release can be useful to "freeze" a version for formal documentation purposes. A released version cannot be deleted or edited anymore. You can however create a new version based on it, which can be edited.

Example: if you release the version 3 of a certain risk analysis, it cannot be deleted or changed anymore. You can however create an editable copy of it, which will be the version 4.

You can print a pdf report of this risk analysis version. The content of the report is customizable:

• The report consists of 5 sections: cover, risk management plan, results, validation and conclusions. "Validation" is available only with the "retrospective module".
• In every section you can decide which information shall be included in the report, by clicking on the check boxes of the corresponding items.
• There are two types of items:
  • Data (dark gray boxes): if included, they are automatically generated by the application.
  • Text comments (white boxes): if included, you will need to type the text.