Got SOUP? - Part 6 - FDA Guidance and Conclusion
By Mitch on Friday, 28 June 2013, 14:28 - Standards - Permalink
This is today the last article of this series about SOUP.
SOUP is a concept that we find elsewhere than in the IEC 62304 standard. Namely in the FDA guidances.
FDA guidance on SOUP
The FDA uses the same concept as the SOUP concept found in IEC 62304, and uses the term Off-The-Shelf Software.
There is one guidance about off-the-shelf-software, the Guidance for Industry, FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Devices.
You can find the link to download it in the Essential list of guidances for software medical devices.
This guidance introduces the need of documenting the COTS hazard analysis differently, according to its level of concern. The level of concern defined by the FDA, is roughly equivalent to the safety class defined by the IEC 62304.
Following the decision tree found in this guidance can help defining the documentation that is needed for the risks analysis. This is complementary to what is required by IEC 62304.
A good technical file may contain risk analysis documentation with both approaches.
BTW, we found also in this guidance section 2.3 about hazard mitigation, that matches pretty well the ISO 14971 requirements.
FDA guidance about 21CFR part 11
To go further about COTS, we can have a look at what exists for software that are not medical devices.
An issue about which much was written is the electronic signature of documents, and their legal origin: the 21CFR part 11. There are a few guidances about this subject, still in draft state.
One guidance: the Guidance for Industry 21 CFR Part 11; Electronic Records; Electronic Signatures Validation, has a section about Commercial, Off-The-Shelf Software (COTS). Even if it is in draft state, it's worth reading section 6.1, especially for standalone software.
However, this guidance has been in draft state for years, and is outside the field of medical devices. Read it only to have additional information about software validation.
Conclusion
We've seen that SOUP is a big family. It can be considered as an all-embracing concept with very different cases.
That's why we tried in this series of articles to split them in sub-categories, with tips of implementation for each of them.
Theoretically, there are lots of tasks to do to be sure that SOUPS are well integrated, work in appropriate conditions, without unacceptable risks. In practice, all these tasks have to be completed with scrutiny for class C software only, down to the detailed design of software units.
For class B software, depending on the type of SOUP quoted above and the type of medical device, a macroscopic risk assessment of the SOUP may be enough, limited to the interaction of SOUPs with the software medical device. However, a deeper risk assessment may necessary, if the functions delivered by the SOUP bring risks with a high severity.
For class C software, all activities are mandatory. The best solution is to limit the number of SOUPs used by the software, to avoid overloaded SOUP management.
Comments
Hello,
After reading a lot of articles on your site, and pdf files from FDA, I still could not find an answer for my company's situation.
Basically we are developing mobile apps for patients which are connected with web applications used by doctors. Since we have multiple mobile apps, we have libraries that handle the common features of those apps like database encryption or data synchronization with the web backend. So the features provided by those libraries are very generic and could be used for any apps non related to medical stuff, but in our case, it is used to build class C S.M.D.
At the moment we are following the IEC 62304 process for both our apps and these libraries.
Theoretically that should increase the quality of our libraries, and prevent having to much work when integrating them in the mobile apps (due to bugs, risk analysis and so on that have been made 1 time for all). But in practice that does not seem to work, the documentation and verifications activities made during the development on those libraries does not really improve anything as there is no real context at the time they are written (since the context is given by the final app integrating that OTS).
So my opinion, is that it would be better for us to voluntary stop producing records on those libraries, so that they become SOUP, and we will perform all the needed activities on the final apps.
It looks like it is possible with IEC 62304 as the only thing that matters is that the whole product is safe (which sounds logical).
But reading at the FDA guidance on OTSS, it seems to be different as they want more things if we are on a Major level of concern, which I am not able to determine.
So do you think the features I described for our libraries are considered as major level of concern ?
If so what would be the minimum documentation that must be provided ?
We have software specifications, test cases, test reports... for those OTS, but all of this is not good quality when produced outside of the final app, so the less we are asked to produce at that moment, the better that would be.
Hi LiohAu,
Thanks for this very interesting question. I cannot give a final answer, since I don't know your medical devices (and I won't, this is a blog, uh).
First, you can find the definition of level of concern in this guidance: http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm089543.htm
I think that if your shared libraries deliver generic services, then I may be possible to treat them as SOUP. The only condition for that is that they deliver low-level or technical services (APIs like synchronize() or encrypt()), but not higher level or functional services (APIs like getPatientName(), findPrescriptionFromDate()).
We can also make a parallel with medical imaging software. Most of these software use SOUP like openCV, vtk, itk, dcmtk. These SOUP are huge and deliver tons of services for image processing. You can have a look at what they do and assess your case in the light of that one.
Hope it helps.
Thanks for your very detailed answer.
We do not talk about patient/medical stuff in the mobile part (this is not the same on the web side, but we could split the project in 2..).
I would say that we are between openCV and the imaging software. We are providing things as low level as encrypt() or synchronize() methods (the method names are different :D), but under encrypt() there is OpenSSL which is the OpenCV equivalent, so that's why I say we are "between".
I don't know how many documents and what kind of documents are talking about openCV when you submit a medical imaging software but, in my opinion, that should only be a paragraph in an OTS assessment and another one a a risk analysis. This is really nothing compared to what we currently do for our library..
Do you have experience in medical imaging software ?
Ok, but I can't investigate your case deeper with so few data on a public website.
And yes, I've been a bit in medical imaging software :-)
Hi Mitch,
Great website, thanks for creating this resource.
In your series on SOUP one thing that you do not pay much attention to is the verification of SOUP, which is required as reinforced by the NB 62034 FAQ 2.5.3:
Do you have any guidance in this area?
Hi Mike,
I don't have additional guidance coming from official documents.
Usually we don't test SOUP in separated test cases. We can assume that when the test of a given function is passed, the behaviour of software items, including SOUPs, integrated to deliver that function is correct.
Their example is a bit far-fetched but possible in some critical cases.