SFMEA analysis to the design of an app to help the user take their medication regularly.

1. Description of the application – brief overview

This app, which is quite simple in terms of functionality, is intended to help chronically ill patients in particular to take their medication regularly. Among its basic functions would be:

  • setting medication reminders for a specific date and time,
  • notifying the user of the need to take medication,
  • recording information on the use of a medicine,
  • the possibility of linking the patient’s app to an app installed by the carer, who will be able to monitor the patient’s behaviour (e.g. in the setting of an elderly, sick parent and the child being cared for).

The app was to be installed on smartphones and was to be updated periodically.

2. Purpose of the SFMEA analysis

The purpose of conducting a Software FMEA (SFMEA or SwFMEA) is to evaluate a software project in terms of seven so-called point views, among which are, for example, programme functionality, maintainability, intrusion susceptibility, serviceability or usability (here, a strong analogy can be found with the UFMEA analysis).

3. The course of the SFMEA analysis

Identification of potential software failures

Due to the specific nature of SFMEA analysis, the approach to failure analysis will vary for different view points (hereafter: VPs), and so for example:

  • VP – functionality: the programme is analysed in terms of the assumed functionalities, which have been defined as those important for the customers in view of the basic application of the programme, so examples of defects in the context of the analysed product include:
    – The programme did not save the setting for the drug: Despite this intention of the user, the information entered by the user without an failure warning was not saved. The result will be that the programme will not later remind the user to take the medication, which may affect the patient’s health. The cause could be, for example, an overfilled memory, which the programme does not check and communicate.
    – The programme did not provide information about the need to take the medication at the scheduled time: The programme did not display the required message in the form that the user had planned (e.g. no sound required, only the information displayed on the phone). The effect will be the same as in the case of unsaved – no intake. However, there are other possible causes – e.g. the unaccounted for ‘problem’ of a time change while travelling.
  • VP – maintenance: the programme is analysed in terms of its ‘behaviour’ e.g. during updates, so examples of defects in the context of the product being analysed include:
    – The programme changed the dosage of all entered medicines to one level (e.g. the level set for one of the entries or the starting level ‘default’): During the update, the programme overwrote the information previously entered by the user (creating incorrect dosage records). The result can be an impact, even a very serious one, on the patient’s health. The cause may be due to an incorrect algorithm for rewriting data between successive software versions.
    – The programme has deleted one or more entries: During the update, the programme, for example, without reading the found entry as correct, deletes it and does not ‘carry over’ to the updated version. The result is again a possible impact on the user’s health. The cause may be due to, for example, a problem with the characters used (change of encoding), where some information will not be read by the updated version.
  • VP – Vulnerability: a programme is analysed in terms of its resistance to intrusion or abuse situations, so an example of a vulnerability in the context of the product being analysed is, for example:
    – The programme allowed unauthorised access to the application by an outsider: Despite the security set, the programme does not require it when switching on. The result could be the disclosure of confidential information to an outsider. The cause may be due, for example, to a faulty algorithm for accessing the application after an emergency shutdown.

Assessing the effects, detectability and severity of failures

In the SFMEA analysis (as in any version of FMEA), risk assessment took into account:

  • Probabilities of the cause of the failure – how often a particular failure is likely to occur for a particular piece of software.
  • The severity of the impact – what will be the consequences of the failure for the wider user (this could be the individual or the systems involved).
  • Detection capabilities – whether and how easy it will be to detect a problem before the patient is affected.

Each of the above risk factors (probability of occurrence, severity and detectability) was scored on a scale from 1 (lowest risk) to 10 (highest risk). The study used a risk assessment based on the RPN indicator (the product of the three risk factors) and the SxO matrix. This allowed the required improvement actions to be identified.

Planning of improvement activities

Following the SFMEA analysis, a number of changes were made to the programme architecture, including:

  • user messages – the programme informs you if there are problems with saving or if you ‘want’ to change the entered values (waits for confirmation).
  • automatic time recalculation – when a time zone change is detected, the programme sets the new medication times (to maintain the required, for example, 12-hour interval between doses) and asks the user to confirm the changes.
  • monitoring of record deletions – when records are deleted, the programme asks for confirmation and, in addition, stores information about what has been deleted for a set period of time.

The changes concerned both the programme infrastructure itself (operating algorithms) and the interaction with the user, in order to maximise protection against the negative impact of application failures on the user’s health.

Summary

The SFMEA workshop was a very interesting experience for the team set up for this analysis. It was the first time in the history of the projects conducted by company X that someone (here first the moderator and later the participants already asked each other) about such unusual but possible misbehaviour and the first time such a structured, multidimensional and complete risk assessment was carried out, which led to real changes in the designed application.