Medical Device Software Segregation and Detailed Design

R

rumplefish

Hi guys,

I'm writing the software architecture and detailed design documents for a class c medical device.

I have two questions:

1. In the architecture document, it says I need to identify segregation needed for risk control. Is that only for cases when some of the software components are not Class C?

2. In the detailed design, one of the component is the software logic, i.e the algorithm. What's the level of detail I need to go to? Do I need to write down the code, all the rules the algorithm, or is a general description of the workflow, the inputs and outputs is enough?

The company I'm doing this is pretty reluctant on publishing the entire algorithm....

Thanks!
 

yodon

Leader
Super Moderator
1. In the architecture document, it says I need to identify segregation needed for risk control. Is that only for cases when some of the software components are not Class C?

You want to architect the software to segregate safety-critical portions from non-safety-critical portions. What they're getting at, I believe, is HOW do you segregate to ensure isolation? Take a look at the note in that section describing an example. If you say that units are segregated by class yet they share data, you may not have adequate isolation.

2. In the detailed design, one of the component is the software logic, i.e the algorithm. What's the level of detail I need to go to? Do I need to write down the code, all the rules the algorithm, or is a general description of the workflow, the inputs and outputs is enough?

The company I'm doing this is pretty reluctant on publishing the entire algorithm....

Yeah, not too prescriptive, huh!?! If you drill down into the Annex B (guidance on implementation), you'll see:

It is necessary to document the design of each SOFTWARE UNIT and its interface so that the SOFTWARE UNIT can be implemented correctly. The detailed design fills in the details necessary to construct the software. It should be complete enough that the programmer is not required to make ad hoc design decisions.

So you need to do so to a level where you feel comfortable defending it. (I know, not much better than "do detailed design"). The need for additional detail would (should) come out in the review of the detailed design documentation. Your developers should be part of the review process and be able to affirm that they have sufficient information to implement (and not have to make ad hoc decisions).

I would think the algorithm would be exactly something that WOULD need to be documented. It's ok to mark it and manage it as confidential information. Regulators / inspectors, in my experience, have been good about protecting IP. You'll need to (absolutely) verify the algorithms were implemented correctly and so you'll need some basis on which to make that claim.
 
R

rumplefish

Thanks!

About the segregation again, are there situations where there's no need to identify segregation?

The software I'm working on is pretty simple, the components are a communication module for external interfaces, UI, Logic module aka "the algorithm" and an Alert module.

I can't really think of any segregation in this case.
 

c.mitch

Quite Involved in Discussions
The software I'm working on is pretty simple, the components are a communication module for external interfaces, UI, Logic module aka "the algorithm" and an Alert module

What you describe is probably a sketch of segregation expected by IEC 62304.
Eg: if there is a default in UI, it won't affect logic module ... and so on.

Verify however that external interfaces, UI, Logic module and alert modules are really segregated, during verification reviews of architecture and detailed design, and by software tests (probably low-level unit tests)!
 
Last edited:

sagai

Quite Involved in Discussions
Rumplefish,
Can i have a dumb question why are you torturing yourself with this standard rather than focusing on the product you are up to?
Many thanks.
Cheers!
 
R

rumplefish

Rumplefish,
Can i have a dumb question why are you torturing yourself with this standard rather than focusing on the product you are up to?
Many thanks.
Cheers!

:D

The product is ready, I need to write all the documents to be up to the standard so the company will be able to sell the product oversees. :cool:
 

sagai

Quite Involved in Discussions
Okey-dokey ... so than, why do you think that you need to have even a read of this standard, nevertheless to do the rigmarole described therein?
With other words ... in what extent do you think this standard has anything to do with the sale of the device?
Cheers!
 

yodon

Leader
Super Moderator
... to do the rigmarole described therein?

Um, with all due respect, the OP claimed the software falls into class C (per 62304) - which would indicate there's the possibility for death or serious injury if the software does not perform correctly.

I, for one, don't think 62304 is imposing any rigamarole in the SDLC; I subscribe to the validity of the approach as sound software engineering practices.

All that aside, it *is* the harmonized standard so compliance *will* help get into the market through a smoother regulatory process.

There's been plenty of cases in recent history of malfunctioning software contributing to death or serious injury. While it's impossible to say that complying with a standard will eliminate software failures; the extra focus is intended to reduce the likelihood.
 

sagai

Quite Involved in Discussions
:D
I am okay with this journey ;)

I have some skepticism over the real value of any market clearance process.
Regulators are looking into these documentation like augurs in ancient Rome to bird traces on sky to say whether or not the device is okay to be sold on that particular market.
Reeealy??? How does a bunch of paper commensurate with the actual behavior of the device? I would risk a statement that we could gain market clearance for a device had never been developed and never existed in its own nature, purely based on our capability of writing the documentation that is expected to be seen by the regulators. That would be fun actually :tg:
On the other hand, even though every aspects are evolving of these devices, than please can someone enlight me how on earth is it possible to have still the exactly same elementary type of failures for software causing a massive recalls due to data loss, patient mixup, left-right inversions, etc. Every month, same story coming out from recalls.
Are these companies forget to provided these paper works for the ones required for Class B, C whatever? Surely they did a comprehensive documentation.

The problem I see recently is the increasing focus on the industrial standardization of the medical software development and that worries me, because we do the development with human brain and sensibility rather than by unified industrial production lines.

In this original example, as mentioned, the product is ready. And actually this is not a rare example. So what is the added value of the retrospective documentation? Yes there are some, not many, especially because the maturity of such hurry up documentation could be rather vague.

Coming back to this standard vs. its relevance to market clearance.

May be it is my ignorance, but I have never ever seen any exact definition that in what extent the IEC/EN62304 provides the presumption of conformity to ER or to the cGMP.

Regards
 

yodon

Leader
Super Moderator
Without intending to hijack this thread and take it further away from the OP's question, I would say look beyond the required documentation and look at the intent. For a Class C product (death or serious injury possible), the intent is to try to force the developer to structure and review the design to help minimize the likelihood of failure of safety-critical software.

The examples you gave (probably the most egregious in your list being data loss / exposure) would not be considered Class C software. Regardless, don't you think that a focused, security review might prevent data loss?

Implementation is still done by humans (until the machines take over :) and so there will be mistakes. The intent of the standard is to push the developer to increasing levels of scrutiny / introspection for increasing levels of risk.

The intent of the standard is not to perform these tasks retrospectively. The intent is to build in the controls, checks, and balances DURING the SDLC (safety by design). However, even taking a retrospective view - say an examination of the architecture to determine if non-safety-critical portions could interfere / influence safety-critical portions - could provide benefit, but ONLY if done according to the intent.
 
Top Bottom