HOUP – Hardware of unkown provenance

One of the key topics over the last few years in the medical device sector is the introduction of Software as a Medical Device SaMD. The activities initially driven by the International Medical Device Regulators Forum (IMDRF) then finding its way into standards such as IEC 82304-1 and will feature in the next version of IEC 62304. In this blog we look at the safety challenges associated with unknown hardware platforms.

SaMD

The term in itself is interesting as it tends to suggest in some way a lack of hardware, or that the hardware is not part of the medical device, which is simply not the case, nor can it be. The definition in the scope IEC 82304-1 is probably the most appropriate as it refers to ‘dedicated’ hardware:

“SAFETY and SECURITY of HEALTH SOFTWARE PRODUCTS designed to operate on general computing platforms and intended to be placed on the market without dedicated hardware.”

Figure 1 shows the reality of the medical device challenges. Software either under development or as software of unkown provenance (SOUP) run on some form of hardware platform which then connects (may not be a physical connection i.e. imaging) to a patient and at some point an operator will be involved even if only collecting the data.

Figure 1: Medical Device Interfaces

Hardware Failures

Hardware in comparison to software, has over and above the systematic failures that come from requirement and design flaws, the additional concern around random failures. Random failures particularly in memory such as static random access memory (SRAM) can occur at a relatively high rate in comparison to other hardware components. For safety relevant products, memories such as SRAM utilise error correction codes (ECC) where typically single bit errors are automatically corrected and dual bit errors are detected. Without such protection key variables or data in the software can contain erroneous values that may result in a hazardous situation.

In SaMD applications it is often unknow if the hardware will have such ECC mechanisms or how good they are, hence increasing the risk associated with that hardware platform.

The Great Hardware Challenge

If we are looking at an embedded medical device with dedicated hardware, we have the luxury of being able to define risk control mechanisms in hardware. In IEC 62304 architectural design and verification the interfaces to that hardware are defined in the process. If we don’t have dedicated hardware not only can we not define these but we have to treat hardware as being of unknown provenance.

Hardware of Unknown Provenance (HOUP)

With an unknown hardware platform, in IEC 62304 we have to treat HOUP in exactly the same manner as SOUP. Risk management activities, architectural design, functional and performance requirements all need to be evaluated accordingly. The classic black-box analysis of only knowing what you can feed in and read out, but not ultimately the operation of what lies inside the box.

Over and above these points the risk control mechanisms in software and generally the topics such as graceful degradation, failsafe functions in the presence of a hardware failure need to be thoroughly thought through. Freedom from interference or segregation as defined in IEC 62304 need to consider hardware as well as software aspects.

In summary SaMD does not reduce the requirements on hardware analysis, quite the contrary, for medical devices without a dedicated hardware platform and element of risk associated with them, the hardware activities have an increased importance. Assessing the HOUP activities becomes a key part of the IEC 62304 process.

By Alastair Walker, Consultant