For risk management, the approach in "Systems in Medical Technology – Setting Reasonable Limits" is a useful tool. However, the system boundary itself is not enough; we must look beyond it.
The first question that arises from the blog post is: "Can I identify risks based solely on the architecture?" – This is, of course, incorrect, as the collection of risks and risk situations should begin before the architecture. However, these risks then relate to the intended purpose and product use and are therefore above the system boundaries. When identifying these risks, I advise you to review the existing questions on hazards and also the well-known hazard catalogs from EN ISO 14971, IEC 8001, IEC TR 80002, and IEC 60601-1, and determine which ones apply to you. Hazards that do not apply should be documented with justification. This will make your work with the test laboratories easier later on. And from here, we need to use the architecture to descend to the product.
The more you think about a system, the more complex and blurred the risks become within the system as a whole. This is due to the ambiguity of definition described by Goran and the associated use of the term "system." For the risk manager, however, it doesn't matter which definition applies, because they view the system/device/product from the outside, i.e., from all of the designated interfaces and the system boundaries described in the blog, and must evaluate them. Yes – I recommend all To evaluate interfaces, I also recommend that you write down your evaluation. For example, according to the following scheme:
| interface | Risk-relevant | Reason |
| ECG cable | Yes | Contact with the patient |
| Special update interface | No | Update function, interface is only active under certain conditions. |
| Ethernet | Yes | Patient data is transferred |
| USB port | Yes | Storing patient data and log files |
| SD card | No | Only active with special update interface and only in update mode |
| Housing | Yes | Patient contact |
As soon as you have difficulty finding the reason for the “no,” you should classify it as relevant.
Why is this flight altitude and sharpening the interface profile important?
As a risk manager, you don't need to focus on the internal structure for the time being, but rather on the factors influencing the device and the impact of the device on people or the environment. This happens via interfaces. Furthermore, you also receive information from the architecture about which products actually communicate with your device or system and other devices or systems, making it possible to verify the implementation of the intended purpose. Analogous to the construction industry, the risk manager now acts as the structural engineer and must review the architect's design for load-bearing capacity.
Once the interfaces and the existing risks from the intended purpose have been linked, a comparison of the interfaces against the risks should be performed. Do all interfaces involve at least one threat? Have all interfaces been assessed? If not, the process is not yet complete. If so, I recommend freezing and backing up the architecture.
The assessment of risks from this interface analysis follows the same process as the risk analysis itself. Do not deviate from your process here, but expand it as new findings emerge.
Verification of interface risks and their risk control measures
The architecture must provide you with a specification for each interface and also with corresponding verification for this specification. For your risks, you now need to adapt the testing to the hazard situations and describe the verification accordingly.
If one of your interfaces is or contains a risk control measure, I consider it essential that it be addressed in a separate verification and given appropriate importance in your risk analysis and system architecture. In this verification, you are expected to address the hazards arising from the causal interface and that your control measure actually counteracts the hazard. Examples include the enclosure in terms of electrical safety, air/creepage distances, and touch protection, or even a separate grounding contact.
And from here on, you're in risk management for your subsystem, subproduct, or product within the system. Perhaps this will come in the next blog ;-)
Additional tips:
Create a dedicated risk verification plan. You should always implement this whenever a new version or product change is released. This way, you'll stay on the safe side.
Assign the relevant hazards to the interfaces, including in the modeled form or the specification. Risk analysis and system architecture often overlap at the interfaces.
Check every architectural change for new interfaces. This is very easy with the risk management interface list and the architecture image.
Many of the system interfaces give you clues about “first errors” within your product/system.
Stefan Bolleininger
Left
Blog: Systems in medical technology – setting sensible limits