The project already holds an actuality: a routine check-up of the patient James Miller, treated by an objective and planned in the default planning. It is the work the hospital intends to do, before any incident.

1. In r-ioga, load IMT Albi Healthcare from the Projects workspace, then open Project List.
2. Launch r-iocal from the Applications column of the project row.
3. Launch r-ioda the same way and stay on the Objectives tab, with only the Active status filter checked.

ResultThree active nodes: My default planning, which plans Treat Routine checkup of James Miller, which treats the actuality Routine checkup of James Miller. No risk is visible yet.

The Electrical Voltage Detector replays a dataset of ten measurements: 230, 205, 180, 150, then 110 volts. Three CEP rules watch it, each one firing when the voltage crosses a threshold downwards: 215, 195 and 170 volts.

1. Launch r-iosemit from Project List and click the Electrical Voltage Detector sensor card.
2. Click Play selected dataset step by step (the swipe_right_alt icon) in the Selected dataset action row.
3. The sensor is not started yet: answer Yes to the confirmation.

ResultThe first measurement, 230 V, is sent. It crosses no threshold, so no CEP rule fires.

A live sensor is enough to make a danger possible. The Generated_By relation between the danger and the sensor carries a 2L activation condition: as soon as the sensor reports a value, the danger becomes active, and the Is_Susceptible_To relation of the healthcare software activates the risks it generates.

1. Go back to r-ioda, still on the Objectives tab.

ResultThe tree appears: Danger of Electrical Failure, generated by the detector, then Risk of software unavailability and its two children, one per function: … for Blood Test Request Function and … for Preparation of equipment Function. All three risks are at probability 0: the children copy the probability of their parent.

Each threshold crossed makes the outage more likely. The CEP rules do not create a new risk: they update the probability of the same risk node, and the 2L conditions propagate it to the two function-level risks.

1. In r-iosemit, click Play selected dataset step by step once, then look at r-ioda.
2. Click it a second time, then look at r-ioda again. Stop there for now.

ResultAt 205 V the first rule sets the probability to 0.33, at 180 V the second one sets it to 0.66, on all three risks. The rule also renames the parent risk Risk of software unavailability at École des mines d'Albi-Carmaux. The risk is likely, but it has not occurred.

The routine check-up still has to be done. The deduction builds a process for it, and because the two functions it uses are exposed to an active implementation risk, it attaches a recovery to each of them.

1. Launch r-iota from Project List: the routine check-up is counted as a sure alert.
2. Click FIND SOLUTION(S) and keep the preselected strategy.
3. Leave Deduce and run on YES and click Find, then wait for Deduction, deployment and supervision completed.

ResultThe strategy Drools - Healthcare Satisfaction Strategy is preselected because it matches the Health domain of the project. The deployed solution counts 8 tasks: the nominal chain from Blood test Request to Receipt of Test Results, and three recoveries carried by Exception_Flow edges.

Before the outage, the recoveries are deployed but idle. Only the first nominal task is running.

1. In r-iota, open the second tab of the dashboard, Execution graph, and zoom out until the first tasks are visible.
2. In r-ioga, click the checklist icon to open the To Do List, in list view.

ResultIn the graph, Blood test Request is orange; Paper Record and White Board Centralisation, its two recoveries, and Edition by Handwritten note, the recovery of Preparation of equipment, are neutral. The to-do list shows the same 8 tasks: one started, seven expected.

The fourth measurement crosses the last threshold: the probability reaches certainty, and a certain risk is no longer a risk but a fact.

1. In r-iosemit, click Play selected dataset step by step a fourth time.
2. Look at r-ioda.

ResultAt 150 V the third rule sets the probability to 1. The risks are frozen and leave the active view; the actualities they generate appear instead: Sofware unavailable, Healthcare software unavailability for Blood Test Request Function and Healthcare sofware unavailability for Preparation of equipment Function.

The Exception_Flow conditions of Blood test Request become true while the task is running. The workflow engine interrupts it and starts both recoveries, without any page reload.

1. Look at r-iota: the map and the execution graph.
2. Look at the r-ioga to-do list.

ResultBlood test Request turns red: it is marked in error and replaced. Paper Record and White Board Centralisation turn orange: they run, and appear as started in the to-do list. On the map, the software outage now carries a blue pulsar, next to the routine check-up: both are handled by the solution. Edition by Handwritten note stays neutral, because Preparation of equipment had not started.