In the May 10th Pre-Cert webinar the FDA addressed an interesting risk matrix that was previously seen in the Software as a Medical Device (SaMD) guidance document, which we discussed here. While a risk matrix involving severity and probability is familiar to many, the SaMD matrix is different in that it addresses the significance of the state of health of the subject of the software and the importance of the information that the  software would provide. There are three levels for health: critical, serious, non-serious. There are also three levels for significance given as Treat or Diagnose, Drive Clinical Management, and Inform Clinical Management.

Software as a Medical Device risk matrix.

When arranged in a 3x3 matrix the 9 intersections are divided into four categories that then define the appropriate level of regulation. Category IV is the one in which the software has the greatest importance and it occurs only for situations in which the health condition is critical and the software is intended to be used (or perhaps will be used regardless of intent) to take an immediate or near term action. Included here is the idea that the information provided will in fact be relied on, and that the time scale does not allow for significant second guessing. This situation would be contrary to any sort of "do not rely on" disclaimer.

The lowest category (I) occurs for three situations, Non-serious/Drive or Inform; and Serious/Inform. Drive occurs when the information provided will be used to aid in treatment, aid in diagnoses, to triage or identify early signs of a disease or condition that will be used to guide the next stage of  diagnostics or next treatment interventions.  Inform implies that the software output will not (or is not intended to) trigger an immediate or near term action. Categories II and III fill in the spaces for Critical/Drive or Inform; Serious/Treat or Drive; and Non-serious/Treat.

The connection between software as a medical device risk categorization and Pre-Cert is that the risk category might inform the appropriate route to market which in Pre-Cert is envisioned as either direct to market, streamlined review, or full review.

This type of analysis suggests the developer, and/or the FDA will in effect be making decisions about how important the product is. In this regard it allows for the assessment that what you are doing, or proposing to do, isn't very important. This is different from the implications of the FDA's three device classes which does not inherently include a value assessment. Value also does not come up directly in traditional risk management, although what is acceptable or not acceptable might be tied to risk, and the FDA has in the past addressed risk-benefit considerations for PMAs and DeNovo applications and for post-market actions.

While an assessment of "not very important" may ease the route to market, it is also one that might not generate a great deal of enthusiasm. This then raises the question of whether the risk category would be publicly reported, and how one might market around a determination that the software isn't very important, in fact so unimportant that the FDA let us go to market without even seeing it. I already have a copyright on the motto "Proudly Making Products That Aren't Important."

UPDATE: FDA releases new information on the Pre-Cert program.

On June 19th the FDA posted a 45 page update to its Working Model of the pre-cert program. In lieu of the user friendly 350 character URL, you can try http://tinyurl.com/ydaq2dh2.

An unusual feature of the update is that they actually marked where changes have been made, although there remains a significant question of “Okay, but what does this really mean?”