#Risk probability of occurrence software#

In the absence of (for lack of a better term) 'standardized code' with a well-understood set of properties for the code.Д«atteries may be too modern of an example, because of somewhat rapid technological changes.

#Risk probability of occurrence software#

Contrast software with batteries (or most other physical components): a priori, with the design choice of a physical battery it is possible to say that 'only occasionally (P1<1) will a specific hazardous situation occur' and so some hazards and hazardous situations might not require controls (or the rigor of testing commensurate with controls). There are subtleties, but 62304 explicitly mandates this sort of approach (requirements -> architecture -> implemented design -> testing) whereas other components of medical device design do not. The only way to effectively reduce this P1 is implement requirements to address that risk and perform testing that proves the implemented control (for software this is usually active code, occasionally it is something else) is doing what is required. Whether you look at this as 'the hazard situation is always going to be occur' or (in a software risk analysis context) 'the software is always going to have this defect' it really makes no difference. This will come across as simplistic, but for software you should always assume that P1 = 1.

Not everybody uses P1/P2, but even folks that don't use it should be familiar with the concept. I believe is referring to P1 (probability of a hazardous situation occurring) and P2 (probability of a harm occurring because of the hazardous situation).