A summary of two online articles that I have found interesting in the past week.
Software as a medical device
The background behind this story is one which already feels very familiar to me: software is becoming increasingly common and increasingly complex in a certain safety related industry, and there is now a need to create a standardised set of guidelines to be adopted when developing these systems. Similar rationale was given during the introduction of IEC 61508, which covers the functional safety of industrial control systems, and also ISO 26262, which covers the functional safety of road vehicles.
This particular article by Rick Merritt discusses the concept of Software as a Medical Device (SaMD), which is a type of software used in the diagnosis and treatment of patients, but which is independent of any particular hardware platform. Examples of SaMD could be software which is installed on a desktop PC to perform diagnostic analysis of images that leads to treatment decisions; or software that analyses fluid samples in order to detect illnesses.
SaMD poses several interesting challenges not typically found in more traditional medical devices. Firstly, the software may perform differently when deployed on different types of hardware; secondly, in-the-field updates are often carried out by healthcare professionals (i.e. the users), rather than a trained engineer or technician; and finally, insecure licensing may lead to unauthorised copies of the software being circulated outside of the manufacturer’s control.
In order to address these issues, the International Medical Device Regulators Forum have issued a document that offers guidance on how to assess the risk category of a SaMD based on the criticality of the situation or condition being treated and the intended use for the information provided by the system. Relevant considerations for each category are then described.
http://www.eetimes.com/document.asp?doc_id=1324861
Safety critical RTOS certification kit
Developing safety critical software is hard. More specifically, it is both time and cost intensive due to the rigorous verification and validation activities that are required, along with the need for meticulous documentation. These are facts that could easily be overlooked by an organisation new to software development in general, but who are keen to produce the next major innovation in their industry.
I have heard of an example of this myself, where a company* that created primarily mechanical safety systems invested a great deal of time and money in the development of a new software intensive vision system. This system was intended to place industrial machinery into a safe state when the presence of an operator was detected by a video camera. The device was however developed as a ‘normal’ product with no special consideration given to its safety aspects and, as a result of this, the company were unable to achieve the required level of certification.
This type of problem could be eliminated if organisations opt to base their development around a pre-certified real-time operating system (RTOS), such as the newly released Micrium uC/OS-II ‘cert-kits’ described in this article by Bernard Cole. These kits contain a RTOS kernel, complete with verification evidence and user manuals, which comes with TÜV type approval.
Although this approach will not completely eliminate the work required for final product approval, it promises to greatly streamline the process.
* Thankfully not a company that I worked for!
Conclusion
Both of this week’s articles highlight an important point in that as software becomes more prevalent in systems that may be considered to have some safety related functionality, there is an increasing need to treat its development as an engineering activity and not simply a ‘hack-a-thon’.
DW.