Software in Medical Devices, by MD101 Consulting - Tag - SOUPBlog about software medical devices and their regulatory compliance. Main subjects are software validation, IEC 62304, ISO 13485, ISO 14971, CE mark 93/42 directive and 21 CFR part 820.2024-03-29T12:42:03+01:00Cyrille Michaudurn:md5:9c06172e7cd5ed0f5b192883b657eabbDotclearMaintained software, Supported software, Required software, and SOUPurn:md5:bbb5f84c6e4f1aeff52ccfaedd569c522023-02-20T13:56:00+01:002023-02-26T00:56:03+01:00MitchStandardsCybersecurityIEC 62304IEC 81001-5-1SOUP<p>These three concepts come from IEC 62443 and were adopted in IEC 80001-5-1. SOUP isn't present in IEC 81001-5-1.<br />
What are the differences between SOUP and Maintained software, Supported software, and Required software?</p> <h4>Definitions</h4>
<p>You will find the definitions of SOUP in IEC 62304 and Maintained software, Supported software, Required software in IEC 81001-5-1:</p>
<ul>
<li><em>SOUP</em>: software of unknown provenance. Practically speaking, if you want to integrate some 3rd party sw in your medical device, that hasn't been developed with IEC 62304, that's SOUP,</li>
<li><em>Maintained software</em>: software item for which the manufacturer will assume the risk related to security,</li>
<li><em>Supported software</em>: software item for which the manufacturer will notify the customer regarding known risks related to security,</li>
<li><em>Required software</em>: software item for which the manufacturer will consider security-related risks known before release of the health software.</li>
</ul>
<h4>Required software</h4>
<p>The case of required software is easy to manage with medical device software. The definition tells us that the <em>manufacturer will consider security-related risks known before release of the health software</em>. Thus, not after release of the health software.<br />
That contradicts ISO 14971 requirement on post-production activities and more generally requirements on post-market surveillance of regulations.<br />
Thus, that's not possible to have required software in medical devices.<br />
That's possible to have required software in health software not qualified as medical devices, but this is another story outside the scope of this blog.</p>
<h4>Supported software</h4>
<p>With supported software, <em>the manufacturer [notifies] the customer regarding known risks related to security</em>. That's a way to manage risks, so that's possible to do so with ISO 14971 and MD regulations. Provided that risks are acceptable, doing it that way.<br />
Practically speaking, if we only notify about risks, that means that supported software isn't integrated into the medical device. If it were integrated in the medical device, we'd not only notify but also provide the customer with a new version of our software.</p>
<h4>Maintained software</h4>
<p>With maintained software, <em>the manufacturer [assumes] the risk related to security</em>. That's the only way to manage risks when some software is integrated into the medical device.<br />
We retrieve here a similarity between our plain old SOUP and maintained software! With SOUP integrated in our medical device software, we have to assume the risks in the design process (IEC 62304 clause 7.1) and in the maintenance process (IEC 62304 clause 6.1).<br />
Practically speaking, when some issue (bug or vulnerability) is found in a SOUP in design, we fix it. When it is found in maintenance, we fix it (usually upgrading SOUP version and rebuilding software) and we release a new version of our software.<br />
<br />
Maintained software could be expanded to software not integrated into the medical device, thus not SOUP. That's a possibility. We could sum up that by SOUP ≤ Maintained software.<br />
But, if we want to keep things simple, we can consider that the two concepts are applicable to the same set. We could sum up that by SOUP = Maintained software.<br /></p>
<h4>Some examples</h4>
<p>The sketch of theory above deserves some examples.</p>
<h5>Mobile app or PC application</h5>
<p>All 3rd party libraries (not developed and maintained according to IEC 62304) linked to these kind of apps at build time are SOUP and maintained software.<br />
The operating system (PC platform or mobile platform) is a supported software.<br />
We cannot place the OS in required software. If we become aware of some unacceptable risk coming from the OS, we would notify the customer.<br />
Conversely, the operating system is not maintained software. We don't update it, we only notify the customer to update their OS.</p>
<h5>Software embedded in hardware medical device</h5>
<p>Once again, all 3rd party libraries (not developed and maintained according to IEC 62304) linked to our embedded binary at build time are SOUP and maintained software.<br />
The operating system (PC platform or mobile platform) is also a maintained software. If we become aware of some unacceptable risk coming from the OS, we would provide the customer with a new version of our embedded software (logistics can be tricky, but that doesn't affect the concept) with a new OS version.<br /></p>
<h5>Web application - front</h5>
<p>All 3rd party dependencies (not developed and maintained according to IEC 62304) pulled by our code are SOUP.<br />
The operating system (PC platform or mobile platform) and the browser are supported software. We cannot place them in required software. If we become aware of some unacceptable risk coming from the OS or the browser, we would notify the customer.<br /></p>
<h5>Web application - back-end, and cloud software</h5>
<p>All 3rd party dependencies (not developed and maintained according to IEC 62304) pulled by our code are SOUP.<br />
Here, we have a question about where we draw the line between SOUP and not SOUP. See the article <a href="https://blog.cm-dm.com/post/2021/03/26/When-Web-meets-SOUP">When web meets SOUP</a> about the possible answers on SOUP, OTSS, which is not SOUP, and infrastructure.<br />
We have to place the OTSS and underlying infrastructure (be it containerization or virtualization) in maintained software. We cannot place them neither in required software, nor in supported software. If we become aware of some unacceptable risk coming from one of these, we would upgrade the infrastructure version.</p>
<h5>Two software devices by two different manufacturers</h5>
<p>Let's assume we develop and maintain a medical device software, which integrates another medical device software developed by another manufacturer.<br />
Here the 3rd party software is a medical device (we assume that the manufacturer did their homework with IEC 62304), thus not a SOUP. If that other manufacturer becomes aware of some issue, they will notify us and provide us with a software update (as per IEC 62304 clause 6.1). Likewise we will update our software with this dependency update. Thus, that other medical device software is for us a maintained software.<br />
That's a peculiar case where maintained software ≠ SOUP. It is shown in this article to demonstrate that maintained software and SOUP are different concepts. But, to keep it simple, in the vast majority of cases, maintained software = SOUP.</p>
<h4>Conclusion</h4>
<p>One interesting consequence of new definitions brought by IEC 81001-5-1 is to help us understanding wether to place 3rd party software in SOUP or not in SOUP. It's frequent that design teams hesitate to place an OS in SOUP. The concepts of maintained software and supported software, are not equivalent to SOUP (the word <em>incorporated</em> appears in SOUP definition, not in required / supported / maintained software definitions). But, if we simplify by assuming that maintained software = SOUP, then we have criteria to place OS, and some other borderline cases, in SOUP or not.</p>https://blog.cm-dm.com/post/2023/02/20/Maintained-software%2C-Supported-software%2C-Required-software%2C-and-SOUP#comment-formhttps://blog.cm-dm.com/feed/atom/comments/248MDCG 2020-3: Substantial change or not Substantial change?urn:md5:c8de8ccf870017399dc1ce90dd09e1392021-11-08T13:56:00+01:002021-11-08T13:56:00+01:00MitchRegulationsSaMDSOUP<p>That is the question.<br />
MD manufacturers are pressed by end-users to implement changes. Especially SaMD, where the users are used to receiving new versions weekly or monthly. Thus, Class I MDD SaMD manufacturers are pressed to find a way to qualify their software changes as non-substantial according to the MDCG 2020-3. Otherwise, they can't deliver new versions to their end-users, blocked by the deadly MDR rule 11 and its class IIa trap.<br /></p> <h4>MDCG 2020-3 Chart C or chart B</h4>
<p>The difficult step is obviously the chart C of the MDCG 2020-3, with criteria focussed on software. We have tough times, to say the least. But, contrary to what we'd thought at first, it is possible to answer "No" to questions C1 to C5 when software changes are minor detailed design changes and source code changes, leaving untouched the OS, components, general GUI layout, and so on.<br />
<br />
Yet, we have hard times with the question B2 of chart B: <em>Do new risks require control measures or are existing risks negatively affected?</em><br />
Practically speaking, when we make a change to a software behaviour, that change shouldn't bring a new risk.<br />
E.g.: it is possible to sort patients by name, surname, date of birth. We add weight and size, it doesn't bring a new risk. With can rely on the risks on sorting patients.<br />
<br />
No new risk pops out and the existing mitigation actions are not impaired. We can answer "No" to question B2.<br />
<br />
But, if we implement a new function, even a small one in terms of detailed design and source code, it can bring new risks.<br />
E.g.: it is possible to modify patient data in the sorted table. Modifying patient data was already possible in some other panel in the software. That small change is easy to implement, the software is already able to modify patient data. It adds a risk when the user modifies data, which then changes the sorted order after modification. The mitigation action is to sort data automatically after a modification, and to still leave the focus on the the previously modified line.<br />
<br />
A new risk pops out. Even though the change is minor with chart C, since we have to add a line in our risk assessment matrix, it is major according to question B2.<br /></p>
<h4>New risks, major change</h4>
<p>That's so easy to find new risks when you make changes to software! That potentially makes every change a major change.<br />
One solution is to reuse an existing risk in your risk management file, more or less similar to your new one; provided that the risk acceptance isn't changed. In this case, there's no new risk.<br />
That's a bit playing hide and seek with the MDCG. But that's a possibility.<br />
<br />
Likewise, the new change brings a risk that is evaluated at a very low or at the lowest risk priority number. In this case, we can consider that no new risk is added. We could do that with the ability to modify data in our example.<br />
Anyway, that's a bit playing hide and seek either to reuse risks or to disregard very low risks.</p>
<h4>Cybersecurity</h4>
<p>One pass-through in the MDCG is to categorise a change as a cybersecurity measure. If that's feasible, the change is allowed according to question C6. It's almost always possible to categorise a change of SOUP version as a cybersecurity measure. New versions bring closures of known vulnerabilities.<br />
Even though we have question C1: <em>New or major change of operating system or any component?</em>, changing SOUP versions is a minor change, thanks to the cybersecurity excuse. More generally speaking, it's not defensible to leave known vulnerabilities and the MDCG did take that case into account.<br />
<br />
Some SaMD manufacturers could be tempted to pass in a release some other changes, poorly or not documented, hidden in the flow of cybersecurity updates. That's a solution I don't recommend :-).</p>
<h4>Conclusion</h4>
<p>We have some small possibilities to qualify changes requested by the users as minor. Even with this small window left opened in the MDCG 2020-3, Class I SaMD manufacturers will have to release one day new versions with major changes. That day is approaching, 2024 is eternity for software.<br />
<br />
A major change of version, a change from class I MDD to class II+ MDR, a major change of paradigm.<br />
<br />
<br />
<br /></p>
<h4>Post-scriptum</h4>
<p>Should I linger on the fact that a regulation locking SaMD in a version, deprive users from their requested changes? It is a way to miss a chance to bring some benefit to the patient (the new version with requested changes) at the cost of a minor risk (the undesirable side-effects of the requested changes). Minor risk, hence SaMD not in contact with the patient, without measuring function, used by medical professionals (and sometimes lay persons), and previously classified in class I MDD, never represent a major risk to the patient or the end-user.<br />
<br />
<strong>The risk/benefit balance of class I MDD SaMD is degraded by the MDR lock-in.</strong><br /></p>https://blog.cm-dm.com/post/2021/11/08/MDCG-2020-3%3A-Substantial-change-or-not-Substantial-change#comment-formhttps://blog.cm-dm.com/feed/atom/comments/250When Web meets SOUPurn:md5:91c2f54b346ed34ddbb153b211867e452021-03-26T13:38:00+01:002021-03-26T13:38:00+01:00MitchMiscIEC 62304ISO 13485SaMDSOUP<p>The definition of SOUP, and the requirements related to their lifecycle in IEC 62304 processes, are totally independent of any technology. Making no technological assumption, that's the way the standard is thought, so that it can be applied to any health software.<br />
Cloud-based applications and web technologies make an intensive use of SOUPs. Let's see how IEC 62304 requirements can be applied to these technologies.</p> <p><img src="https://blog.cm-dm.com/public/28-SOUP-web-technos/believe-you-can-SOUP.gif" alt="believe you can SOUP, Feb 2021" style="display:table; margin:0 auto;" title="believe you can SOUP, Feb 2021" />
<br />
<strong>Remark</strong>: examples in this article are given for Javascript or Typescript (npm). It also works with Python (pip), Ruby (gems), PHP and other languages (I'm sure there are <a href="https://lhartikk.github.io/ArnoldC/">plenty of them</a>).<br />
<br /></p>
<h4>Third party software inventory</h4>
<p>Cloud applications have by definition a back-end, they have a front-end if they have a GUI. Let's make a quick inventory of the libraries, frameworks that we can find throughout the stack.<br />
Please take note that I don't talk about SOUP yet.</p>
<h5>Back-end</h5>
<p>In the back-end, we find the services developed by the MD software editor. As third party software, we find:</p>
<ul>
<li>A framework used to build these services e.g.: Express,</li>
<li>A database, e.g.: MongoDB, MySQL,</li>
<li>Generic services like message queuing e.g.: RabbitMQ,</li>
<li>Also libraries delivering specific functions you chose to implement your software,</li>
<li>Probably other things present in your dependencies JSON file,</li>
<li>Some security control of different nature, like CORS or IAM</li>
<li>The Docker runtime, combined with Kubernetes,</li>
<li>The operating system,</li>
<li>And possibly support services, like Google Cloud Logging or Amazon Cloudwatch.</li>
</ul>
<p>Outside software, we almost forget the hardware running all this stack. It's more and more frequent to have no clue about the hardware, and even the operating system, which our software is running on.<br />
<br />
The cloud platform vendors are in permanent competition to offer a myriad of services present off-the-shelf. You don't have to install them and you just instanciate them. For example with AWS RDS (Relational Database) allowing to choose between several database engines and IAM taking care of authentication. Even if you don't install them, they count as third-party libraries.</p>
<h5>Front-end</h5>
<p>On the front-end, we find the web application framework. E.g.: React JS.<br />
Just don't forget the client host: the browser and the OS. A bit like the back-end, you rely more on the type and version of the web browser, than the underlying OS. Namely, you rely on the behavior of a given browser version running on a given list of OS.<br />
The front-end can also be a mobile app, with the mobile OS, its framework, and possibly other libraries like a third-party cross-platform framework.</p>
<h4>Differentiate infrastructure, OTSS and SOUP</h4>
<h5>Back-end</h5>
<p>This inventory is fine, but it mixes apples and oranges. We can separate it in:</p>
<ul>
<li>SOUP : third party libraries used at runtime to have your software deliver its medical purpose,</li>
<li>OTSS : third party libraries or executables not mandatory to run your software, non-functional services, like monitoring, logging,</li>
<li>Infrastructure : other software or hardware, provided by the cloud service provider, usually invisible from your software.</li>
</ul>
<p>Below a diagram giving a representation of a typical back-end architecture:<br />
<br />
<a href="https://blog.cm-dm.com/public/28-SOUP-web-technos/Cloud-App-SOUP-Example.png" title="Cloud-App-SOUP-Example.png, Feb 2021"><img src="https://blog.cm-dm.com/public/28-SOUP-web-technos/.Cloud-App-SOUP-Example_m.png" alt="Cloud-App-SOUP-Example.png, Feb 2021" style="display:table; margin:0 auto;" title="Cloud-App-SOUP-Example.png, Feb 2021" /></a>
<br />
It's not made to be accurate but to give an idea of what to place in SOUP, in OTSS, and in infrastructure.<br />
<br />
In this example, we have third party items that are SOUP, others are OTSS, and some others are infrastructure.<br />
SOUPs are those with a direct relationship with your software:</p>
<ul>
<li>Either they're incorporated in your MDSW (the SOUPs present in the blue box in the diagram),</li>
<li>Or they're present off-the-shelf in the cloud services and your MDSW invokes directly their API (the DB container, for example).</li>
</ul>
<p>Conversely, other third-party software not seen by your MDSW aren't SOUP. They're part of the infrastructure not managed by you. Third-party software used or invoked by SOUPS are sometimes called SOUPs of SOUPs. There is a controversy on whether they should be in the scope of IEC 62034 SOUP definition or not.<br />
A bit of risk assessment is usually enough to place them out of SOUP category. Risks related to this kind of software are usually reduced to an interruption of service, something acceptable for MDSW (unless you develop a close-loop over the internet :-)).<br />
Otherwise we can continue with SOUPs of SOUPs of SOUPs, and so on. It wouldn't take long before we dig oil.<br />
<br />
Last, OTSS are independent software which don't contribute to the performance of your MDSW (for example, some monitoring tool used by IT administrators like Zabbix).<br />
<br />
It can be hard for some components to place them in the right category. For example, an authentication service: SOUP or Infrastructure or OTSS? This is a service delivered by the cloud provider (infrastructure), it can be directly invoked by your MDSW (SOUP), but it doesn't deliver any clinically relevant function (OTSS). The decision to place it in one or another category depends on the context.</p>
<h5>Front-end</h5>
<p>On the client side, things are easier, there's no infrastructure, and there's usually no OTSS. For web apps, the OS, the browser are SOUP. For mobile apps, the OS, the framework, the libraries are SOUP.</p>
<h4>How to manage them?</h4>
<p>Different categories mean different types of activities to perform.</p>
<h5>SOUP</h5>
<p>SOUP are under the scope of IEC 62304. "Just" manage SOUP according to IEC 62304.<br />
One question is the architectural representation of all SOUPS. You can have something like one hundred lines in your dependencies JSON file. Documenting all these tiny libraries can be burdensome and seen as a loss of time by software development teams.</p>
<ul>
<li><strong>Solution 1</strong>: Put them all in a SW item called "xxx framework", where xxx is the name of the language, of the technology. In this way we have all the SOUP in bulk. But an IEC 62304 auditor will say you don't teach an old dog new tricks, you can't make a big load of SOUP SW units into a single SW item.</li>
<li><strong>Solution 2</strong>: We refine the architecture, to reveal each SW unit and each SOUP. In this way, we make all the SOUPs appear in a very fine grained representation. But the developer will say he has no time to be jerking around, he does not have time to manage this pile of documentation.</li>
<li><strong>Solution 3</strong>: We refine the architecture for the SOUPs used by a single SW unit, and make a SW item named "xxx framework" containing all the SOUPs, which offer transversal services. In this way, we satisfy the auditor who leaves quite happy with his documented evidence of IEC 62304 clause 5.4.1 and we satisfy the developer who in a half-smile grin will express his satisfaction at being able to continue developing without spending too much of his life documenting things that they find boring.</li>
</ul>
<p>Such a life.</p>
<h5>OTSS</h5>
<p>OTSS are under the scope of QMS software requirements, either 4.1.6 of ISO 13485, or 21 CFR 820.70.i automated processes. Thus, outside of IEC 62304 claws. They shall be validated according to guidances like IEC/TR 80002-2 or AAMI TIR 36.<br />
Sad news, quality managers will have to rely on software development teams to validate these OTSS. They develop or assemble OTSS around the MDSW and their knowledge is required to document OTSS validation.</p>
<h5>Infrastructure</h5>
<p>Infrastructure is all the rest, not seen and not controlled by the MDSW editor. It comprises the hardware and software parts. Not controlled by the MDSW editor doesn't mean not controlled at all. Infrastructure is subject to requirements on ... infrastructure: section 6.3 of ISO 13485 or 21 CFR 820.70.e Environment control. The cloud service provider is subject to purchasing requirements: clause 7.4 of ISO 13485 or 21 CFR 820.50.<br />
There, we are far from IEC 62304. That sounds right, we are far as well from the MDSW source code.</p>
<h4>SOUP software safety class</h4>
<p>If your software is in class B or C, unless you have good architectural justification, SOUPs will be in the class of your MDSW. In the diagram above, it's hardly feasible to have the blue MDSW in class B, and the SOUPs inside it in another class. A failure in the SOUPs will propagate inside the blue area. Likewise, even if the SOUP DB container is totally separated, a failure in the SOUP DB will lead to a loss of or corruption of data, and possibly wrong information presented to the user leading to a delay in the appropriate medical care.<br />
Thus, you will have hard times to place SOUPs in a lower software safety class when:</p>
<ul>
<li>They're intertwined with your source code,</li>
<li>They deliver a service with an impact on data.</li>
</ul>
<p>On the contrary, authentication, containerisation, load-balancing SOUPs (if you don't place them in the infrastructure) will only lead to interruption of services, without any impact to the patient (in most cases of course). Thus, it is possible to place them in class A.</p>
<h4>SOUP anomalies, changes and obsolescence</h4>
<p>With dozens of libraries used by your MDSW, a tool like NPM is your friend to manage SOUP lifecycle according to IEC 62304. Especially clauses 6.1.f and 7.1.2.c.<br /></p>
<h5>Risk assessment</h5>
<p>Clause 7.1.2 about identification of hazardous situations coming from failure or unexpected results from SOUP is not required in class A. So you have a vested interest to isolate SOUPs in class A.</p>
<h5>Anomalies and obsolescence</h5>
<p>OK, we have a tool like NPM. But is doesn't tell us how we monitor bugs or obsolescence.<br />
Taking the example of good old technologies like C++, a yearly review of bugs is enough. Libraires like boost or std don't change often. That won't be enough with web SOUPs, which change every other day, or are replaced by new ones. Thus, a monthly review or (less stringent) a quarterly review is better.</p>
<h5>Security issues</h5>
<p>Dozens of SOUPs also means an increased number of security issues. The SOUP anomalies reviews shall also include the security issues. Contrary to anomalies not related to cyber security, security issues might need be treated in a very short timeframe. Thus, it is more advisable to have a continuous monitoring of security issues, with tools like npm or snyk, to quickly detect and investigate security issues. Please also note that managing security issues is a regulatory requirement. They have to be managed in any software safety class whatsoever.</p>
<h5>Freeze at release</h5>
<p>Be careful also to freeze the SOUP versions when releasing to production. Every change of SOUP version is a change (tautology). Every change can introduce unexpected side effects, in functionalities, and in risks. Unless you have a fully automated testing strategy (hello Selenium and co.), every change of SOUP shall be thoroughly assessed.
Don't let npm change SOUPs version in your back. It means that you'll have to use tricks like adding the version numbers to your dependency files.<br />
<br /></p>
<h4>Conclusion</h4>
<p>Web applications are built over a diverse ecosystem of development tools, libraries, frameworks, and cloud services.<br />
Infrastructure, OTSS, SOUP, it can be hard to choose in which category to place these various third-party software. But it's worth spending time on it to reduce the perimeter of IEC 62304. Even if ISO 13485 or 21 CFR 820 put some overhead on the shoulders of software development teams, it's less than IEC 62304.<br />
When IEC 62304 is applicable, designing the architecture to isolate as many SOUPs as possible in class A is also worth it. IEC 62304 in class A is very light in terms of risk management, compared to other classes.<br />
At last, applying IEC 62304 can be counter-intuitive for software development teams. E.g.: freezing SOUPs versions while you'd like to upgrade to stay in the race. IEC 62304 is seen like red tape by software developers. Having the right tools to automate the 62304 overhead is probably one key to success.</p>https://blog.cm-dm.com/post/2021/03/26/When-Web-meets-SOUP#comment-formhttps://blog.cm-dm.com/feed/atom/comments/243Validation of compiler and IDE - Why, when and how to? - Part 1urn:md5:6a2b7650f462a41be688fdf8e0edf0f52014-03-14T13:26:00+01:002016-06-07T16:24:36+02:00MitchProcessescritical softwaredevelopment processFDAIEC 62304risk managementSoftware ValidationSoftware VerificationSOUP<p>Validating the compiler used in software development is a recurring issue. To what extent a compiler should be validated, when, how and why?<br />
In the same vein, we can extend the question of validation to all tools used in the software development environment: integrated development environment, configuration management tools, compiler (and linker), automated test tools.</p> <p><br />
<em>Edit June 2016: this article remains relevant with the new requirements on software validation found in ISO 13485:2016.</em><br />
<br /></p>
<h4>Class of medical device</h4>
<p>If you're in class III FDA or in class III CE mark or in Class C IEC 62304, you have to do it thoroughly if a flaw in a development tool represents an unacceptable risk!<br />
<br />
If you're in class II FDA or in class IIa or IIb CE mark or in class B IEC 62304, you may do it but it's far from being mandatory!<br />
<br />
If you're in class I FDA or in Class I (even class IIa) CE mark or in class A IEC 62304, do it if you have spare time!<br />
<br />
In other words, thorough development tool validation, and especially compiler validation, are only relevant for very, very, very, critical software.<br />
<br />
<em>Edit June 2016: following the risk-based approach found in ISO 13485:2016, this rationale remains relevant.</em>
<br />
Perhaps it makes sense for a small subset of embedded sw used in class III MD, like pacemakers. Likewise it makes senses in automotive or airborne systems where sw failure equals dozens of casualties.</p>
<h5>Development tools are low risk</h5>
<p>The main rationale not to validate development tools is to consider them as low-risk software. Hence if there is a bug in one of these tools, then the software built will be buggey and odds are pretty good that this bug will be discovered during software tests (be it unit, integration, or functional).<br /></p>
<h4>Examples</h4>
<p>Here are some examples of bugs in development tools:</p>
<ul>
<li>My IDE has a bug in the code editor and doesn't save source files in specific conditions. I'm going to see it quickly! Or I'm going to see it in the code of a colleague during a code review.</li>
<li>My source control tool has a bug in the graphical merge function. I'm going to see it quickly as well!</li>
<li>My compiler doesn't cast the right way a floating point value to an integer value, under certain circumstances. I'm not going to see it quickly. But I'm probably going to see it during tests, with inconsistent computed values.</li>
</ul>
<p>All in all, tests in the software development process are here to find problems created in early stages of the process. Most of these problems are created by humans (we can't think of everything), and some are created by the tools we use (the guys who created the tools couldn't think of everything).</p>
<h5>Process risk assessment</h5>
<p>What is shown above is assessing the risks of the software development process.<br />
In class I, there is no use to validate thoroughly development tools hence the hazardous situations created by these tools have low severity (the final software is class A of IEC 62304) or have low probability (bugs created by these tools are fixed during code reviews or tests).<br />
In class II or III, it's useful to validate these tools hence the hazardous situations created by these tools (namely bug in built software) have high severity, or high probability (think of the <a href="https://blog.cm-dm.com/post/2012/09/14/Probability-of-occurence-of-a-software-failure">100% probability in software hazards</a>).</p>
<h4>How to validate these tools</h4>
<p>If you have to validate these tools, you may take examples from this guidance: AAMI TIR 36 Validation of software for regulated processes. It has pretty good examples (excepted compilers, see below).<br />
You may also get your inspiration from GAMP5 about computerized systems (pull out your credit card if you want to read it!).<br />
<br />
If you don't want to buy any of these documents, there are plenty of examples available on the internet. You just have to seek for IQ/OQ/PQ plans and reports.<br />
Basically the goal of a validation plan is a bit like applying the software development process of IEC 62304 with SOUP only:</p>
<ul>
<li>Assessing risks of the software development process ,</li>
<li>Writing requirements of the ideal development tool (including requirements mitigating risks and requirements about the tool vendor),</li>
<li>No architecture or detailed design, but in place selecting the right tool for your needs (don't forget interoperability with other tools),</li>
<li>Tests with three levels:
<ul>
<li>Installation Qualification (IQ), i.e. ensuring that it is deployed and well configured on the development or integration platform, and verifying that all necessary documentation is available,</li>
<li>Operational Qualification (OQ), i.e. verifying that it works and integrates well with other development tools, according to written and approved requirements (including requirements mitigating risks),</li>
<li>Performance Qualification (PQ), i.e. using the development tools in real conditions for a period of time to ensure that the tool and its vendor behave according to expected performances.</li>
</ul></li>
</ul>
<p><br />
If you are in a case where there's no urge to validate software development tools, then just write a document with the rationales that led you to choose these tools.<br />
In all cases, however, it's necessary to have a maintenance plan of the development tools, like what you have about SOUPs in IEC 62304:</p>
<ul>
<li>Monitoring published bugs, bugs fixes and new versions,</li>
<li>Assessing risks related to these bugs,</li>
<li>Deciding whether it's necessary to install a new version of the development tool.</li>
</ul>
<h4>Development vs production processes</h4>
<p>There are dozens of articles or memos or documents about validation of tools used in production processes.<br />
The validation method described above is a bit peculiar because it deals with tools used in software development processes (for software design), not production processes (for production of physical goods or for delivery of standardized services).<br />
Thus it is acceptable only for development processes. For production processes, like automated machines or test benches, this validation plan is too simple.<br />
<br />
However,if you want to validate a compiler, this validation plan is a bit incomplete.<br />
Validating a compiler once and for all is a titanic task! We'll see it<a href="https://blog.cm-dm.com/post/2014/03/28/validation-of-compiler-and-IDE-Why%2C-when-and-how-to-Part-2"> in the next article</a>.</p>https://blog.cm-dm.com/post/2014/03/13/Validation-of-compiler-and-IDE-Why%2C-when-and-how-to-Part-1#comment-formhttps://blog.cm-dm.com/feed/atom/comments/140How to validate a software medical device running on web browsers?urn:md5:c190d0a769a68342bd9aa3880e44df1f2013-10-11T14:08:00+02:002013-10-11T14:08:00+02:00MitchProcessesdevelopment processIEC 62304mobile medical appSoftware VerificationSOUP<p>Your company develops medical web apps (HTML/JS, HTML5 or any other client-side technology) and your customers would like them to run on every web browser.<br />
<br />
Web browsers are SOUP, according to IEC 62304. In case of Chrome and Firefox there are dozens of versions...<br />
<br />
Does it mean that software has to be tested - and documented - with every single browser and every single version of the browser?<br />
That's a nightmare!</p> <p><strong>It's simply not possible to test every combination of browsers versions</strong>, all the more combined with OS versions.<br />
<br />
There are roughly 3 solutions that can make things more simple:</p>
<h4>1. Assess what software class is the code on the browser side</h4>
<p>Is it possible to have it in class A, while the server side is in class B or C? If so, it would decrease the burden. No tests requirements for class A in IEC 62304 standard and less risks management, even if tests are still required at medical device system level to verify and validate it.</p>
<h4>2. Reduce the number of supported versions of OS and browsers</h4>
<p>Eg: Win 7 or higher, Mac 10.6 or higher, IE 9.x or higher, Safari 5.x or higher, Firefox 14.x or higher, with :</p>
<ul>
<li>tests made on the combinations of OS x Browsers in their lowest accepted versions.</li>
<li>a quality procedure of surveillance of all new versions of SOUP,</li>
<li>and an assessment of the release notes or change logs to ensure that they are still compatible with your web site.</li>
</ul>
<p>Provided that release notes and change logs are available on time.</p>
<h4>3. Verify on the client side on which browser+OS the code is running</h4>
<p>If this is an unsupported version, display an error to the user and a link to a page with supported versions + hotline number.
<br />
<br />
There might be other solutions. But none of them is magic.<br />
There is no golden rule, we are constrained by 8.1.2 of IEC 62304 standard, which requires to identify the version of SOUP + various paragraphs in chapter 7, especially 7.1.3 and 7.4.2, which require to assess risks related to SOUP.<br />
<br /></p>
<h4>Automated testing?</h4>
<p>Tools like Browserstack or Selenium can automate the testing. So it's possible to test a lot of versions in a short time. But they're time-consuming. It's a lot of energy spent to test every new browser version when versions are released almost every week.<br />
<br />
Automated testing doesn't change the root cause of the problem - floating configurations. Thus the idea of limiting the number of supported versions.</p>https://blog.cm-dm.com/post/2013/10/04/Web-browsers-are-SOUP-#comment-formhttps://blog.cm-dm.com/feed/atom/comments/135Got SOUP? - Further Readingurn:md5:da279966e23a64358b1af9970a7c7b7b2013-07-05T14:00:00+02:002013-07-28T10:46:45+02:00MitchStandardsSOUP <p>Further reading to complete <a href="https://blog.cm-dm.com/post/2013/05/10/Got-SOUP-Part-1-Because-every-good-software-starts-with-SOUP">this long series about SOUP</a>:
<br />
You can have a look at <a href="http://rdn-consulting.com/blog/2012/02/16/otssoup-software-validation-strategies/">this excellent article about OTS/SOUP validation strategies</a>.<br />
<br />
Next week, we'll see <a href="https://blog.cm-dm.com/post/2013/07/12/Unique-Device-Identification-for-software-medical-device-part-1">Unique Device Identification (UDI) for software</a>.</p>https://blog.cm-dm.com/post/2013/05/30/Got-SOUP-Further-Reading#comment-formhttps://blog.cm-dm.com/feed/atom/comments/108Got SOUP? - Part 6 - FDA Guidance and Conclusionurn:md5:86a2c037aec27b4f03b249ce43c1a7dc2013-06-28T14:28:00+02:002013-06-28T14:28:00+02:00MitchStandardsIEC 62304risk managementSOUP<p>This is today the last article of <a href="https://blog.cm-dm.com/post/2013/05/10/Got-SOUP-Part-1-Because-every-good-software-starts-with-SOUP">this series about SOUP</a>.<br />
SOUP is a concept that we find elsewhere than in the IEC 62304 standard. Namely in the FDA guidances.</p> <h4>FDA guidance on SOUP</h4>
<p>The FDA uses the same concept as the SOUP concept found in IEC 62304, and uses the term Off-The-Shelf Software.<br />
There is one guidance about off-the-shelf-software, the <em>Guidance for Industry, FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Devices</em>.<br />
You can find the link to download it in the <a href="https://blog.cm-dm.com/pages/The-essential-list-of-guidances-for-software-medical-devices">Essential list of guidances for software medical devices</a>.<br />
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.<br />
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.<br />
A good technical file may contain risk analysis documentation with both approaches.<br />
<br />
BTW, we found also in this guidance section 2.3 about hazard mitigation, that matches pretty well the ISO 14971 requirements.</p>
<h4>FDA guidance about 21CFR part 11</h4>
<p>To go further about COTS, we can have a look at what exists for software that are not medical devices.<br />
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.<br />
One guidance: the <a href="http://www.fda.gov/ohrms/dockets/98fr/001538gd.pdf">Guidance for Industry 21 CFR Part 11; Electronic Records; Electronic Signatures Validation</a>, 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.<br />
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.
<br /></p>
<h4>Conclusion</h4>
<p>We've seen that SOUP is a big family. It can be considered as an all-embracing concept with very different cases.<br />
That's why we tried in this series of articles to split them in sub-categories, with tips of implementation for each of them.<br />
<br />
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.<br />
<br />
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.<br />
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.</p>https://blog.cm-dm.com/post/2013/06/21/Got-SOUP-Part-6-FDA-Guidance-and-Conclusion#comment-formhttps://blog.cm-dm.com/feed/atom/comments/106Got SOUP? - Part 5 - Standalone softwareurn:md5:b8b77c8692b075f81b4e6d54810bcfa62013-06-14T13:43:00+02:002013-10-14T10:53:28+02:00MitchStandardsIEC 62304risk managementSOUP<p>After having discussed about open-source software <a href="https://blog.cm-dm.com/post/2013/05/16/Got-SOUP-Part-4-Open-Source-Software">in the last post</a>, we continue today <a href="https://blog.cm-dm.com/post/2013/05/10/Got-SOUP-Part-1-Because-every-good-software-starts-with-SOUP">this series about SOUP</a> with the case of standalone software.<br /></p> <p>The standalone software SOUP category stands for off-the-shelf software executables. They can be:</p>
<ul>
<li>Software with GUI used by humans:
<ul>
<li>mail client,</li>
<li>web browser,</li>
<li>document viewer,</li>
<li>software delivered by a supplier to manage a hardware or software component,</li>
</ul></li>
<li>Services or daemons running on a server:
<ul>
<li>mail service,</li>
<li>print spooler,</li>
<li>service delivered by a supplier to manage a hardware or software component.</li>
</ul></li>
</ul>
<p>Unlike frameworks and runtimes, they are not used to host your own software, or have it work. Unlike libraries, they are not linked to your own software. They are standalone from an architectural point of view. They are standalone from a functional point of view.<br />
So, what do we have to do, according to IEC 62304, with standalone software SOUP?</p>
<h4>Reminder - What IEC 62304 expects for SOUP</h4>
<p><em>Skip this if you've already read previous posts.</em><br />
IEC 62304 requirements about SOUP are:</p>
<ul>
<li>Software requirements: The manufacturer shall describe what requirements (functions or non-functional) are necessary to have the SOUP work.</li>
<li>Architecture: The manufacturer shall define the software architecture to have the SOUP work in appropriate conditions.</li>
<li>Maintenance: The manufacturer shall monitor the SOUP lifecycle: patches, new versions...</li>
<li>Risk analysis: It is mandatory to do a risk analysis related to the SOUP.</li>
</ul>
<h4>Standalone software is a SOUP</h4>
<p>Let's see what we have to do with standalone software.</p>
<h5>Requirements</h5>
<p>This is probably where there is the biggest job to do with standalone software.<br />
Off-the-shelf standalone software provide off-the-shelf functionalities. You don't have to develop them, they're already there in the standalone software.<br />
Thus, it is important to list what functions are used, to write them in terms of software requirements, and to finally verify these requirements (i.e. to verify that the listed functions work in your case).<br /></p>
<h5>Architecture</h5>
<p>Even if the software is standalone, there is probably an interface between that software and yours. Thus, describe how both software work together.<br />
More usual, if the standalone requires some peculiar environment, then design the software and hardware architecture the right way and document it.<br /></p>
<h5>Maintenance</h5>
<p>No big difference here with other software. You have to monitor the obsolescence and the bug fixes like any other software.</p>
<h5>Risk-Analysis</h5>
<p>Once again, no big difference here. It may be simplified, compared to other software, like libraries. If the software is really standalone, them there is little risk that it crashes your own software. But, well, it depends on the interface between both.<br />
There is a risk, however, that the standalone software goes into an infinite loop and takes all hardware resources (100% CPU, out of memory...).<br />
The classical solution is to create a supervisor that watches the behavior of the standalone software.
<br />
<br />
Standalone software are useful because they provide functions or services to the end-user, that we don't need to recreate. We don't have to reinvent the wheel! They have their specific impact on requirements, architecture, and risks. But IMHO, they are usually easier to manage than libraries, frameworks and other SOUP already reviewed.
<br />
<br />
<br />
Next time, we'll see <a href="https://blog.cm-dm.com/post/2013/06/21/Got-SOUP-Part-6-FDA-Guidance-and-Conclusion">FDA guidances about SOUPs</a>.<br />
<br />
EDIT: further reading on web browsers in a new article about <a href="https://blog.cm-dm.com/post/2013/10/04/Web-browsers-are-SOUP-">validating apps running on web browsers</a>.</p>https://blog.cm-dm.com/post/2013/06/14/Got-SOUP-Part-5-Standalone-software#comment-formhttps://blog.cm-dm.com/feed/atom/comments/107Got SOUP? - Part 4 - Open-Source Softwareurn:md5:7a482b5c978f1cfd5056f11a2e871a962013-06-07T13:52:00+02:002013-06-24T07:54:34+02:00MitchStandardsIEC 62304risk managementSOUP<p>After having discussed about frameworks and runtimes <a href="https://blog.cm-dm.com/post/2013/05/31/Got-SOUP-Part-3-Runtimes%2C-Frameworks">in the last article</a>, we continue today <a href="https://blog.cm-dm.com/post/2013/05/10/Got-SOUP-Part-1-Because-every-good-software-starts-with-SOUP">this series about SOUP</a> with the case of open-source software.<br /></p> <h4>Open-source software</h4>
<p>Open-source software is a very big family. Hence it's not its technical characteristics that make it open-source, but its legal characteristics.<br />
Broadly speaking, open-source requires to share the source code with others. It gave birth to the notion of <a href="http://en.wikipedia.org/wiki/Copyleft">copyleft</a>.<br />
From the point of view of IEC 62304, this doesn't change the way open-source software is managed. Open-source is 3rd party software, not developed with the processes required by IEC 62304. So it is a SOUP.<br />
<br />
Since open-source can't be defined by technical characteristics, there are plenty of different open-source software, here are a few examples:</p>
<ul>
<li>OS's, drivers
<ul>
<li>GNU/Linux distros</li>
<li>Free BSD distros</li>
</ul></li>
<li>frameworks
<ul>
<li><a href="http://php.net">PHP</a></li>
<li>GNU packages for C development</li>
<li><a href="http://projects.apache.org/indexes/category.html#web-framework">Apache framework</a></li>
</ul></li>
<li>specific libraries
<ul>
<li><a href="http://www.dcm4che.org">dcm4che</a></li>
<li>(post your favorite lib here)</li>
</ul></li>
<li>general purpose libraries
<ul>
<li>Math libraries, like <a href="http://www.netlib.org/lapack/">LAPACK</a></li>
<li>GUI frameworks, like <a href="http://qt-project.org/doc/qt-4.8/opensourceedition.html">Qt</a></li>
</ul></li>
<li>standalone software
<ul>
<li>Mozilla firefox, thunderbird,</li>
<li>every open-source software replacement of closed-source software.</li>
</ul></li>
</ul>
<p><em>Note: I didn't mention software development tools like IDE's. They're not SOUP, as seen <a href="https://blog.cm-dm.com/post/2013/05/10/Got-SOUP-Part-1-Because-every-good-software-starts-with-SOUP">in the first post</a> of this series.</em><br />
<br />
Technically speaking, open-source software is like any software.
The main difference is that we have access to the source-code.<br />
OK, what are the advantages?</p>
<h4>Reminder - What IEC 62304 expects for SOUP</h4>
<p><em>Skip this part if you've read previous posts.</em><br />
IEC 62304 requirements about SOUP are:</p>
<ul>
<li>Software requirements: The manufacturer shall describe what requirements (functions or non-functional) are necessary to have the SOUP work.</li>
<li>Architecture: The manufacturer shall define the software architecture to have the SOUP work in appropriate conditions.</li>
<li>Maintenance: The manufacturer shall monitor the SOUP lifecycle: patches, new versions...</li>
<li>Risk analysis: It is mandatory to do a risk analysis related to the SOUP.</li>
</ul>
<h4>Open-source software is a SOUP</h4>
<p>Let's see what are the advantages of open-source software.</p>
<h5>Requirements</h5>
<p>Having access to the source-code doesn't help much to define the requirements of the medical device. Sometimes, when open-source software lacks technical documentation, it may be harder to define the right requirements to have it work properly.</p>
<h5>Architecture</h5>
<p>Contrary to requirements, having access to the source code may help to design better the device software architecture. But this remains theoretical. Personally, I've never seen software architects diving into open-source code to define a better architecture.<br />
Likewise, having access to the source code doesn't mean that it is necessary to reverse engineer the open-source software architecture. There's nothing like that in IEC 62304.</p>
<h5>Maintenance</h5>
<p>Pros and cons of open-source software get right balanced, when thinking about maintenance.<br />
<ins>Obsolescence</ins>
Some open-source projects are maintained by a team of volunteers. They can be discontinued when the team ceases to have enough contributors. <br />
<br />
Some others are supported by private companies, for some strategic reason. They can be discontinued when the company ceases to support open-source projects, when it changes its strategy.<br />
Obsolescence of open-source projects can be problematic, when there's no more developer to maintain the source-code. However, this can be also the case for commercial software. Private companies are not eternal and they can suddenly change their strategy or their products portfolio.<br />
<br />
<ins>Fixing bugs</ins>
Having access to the source-code is definitely a huge advantage to search for causes of bugs and make patches. But, once again, this advantage remains marginal, compared to all the tasks that are necessary all along the software life-cycle.<br />
More, it can be tempting to fix a bug in an open-source software. But, given their licensing terms, it can become a legal mess.</p>
<h5>Risk-Analysis</h5>
<p>Once again, pros and cons of open-source software get balanced, when thinking about risks analysis.<br />
<ins>Functionalities</ins>
It's more the use of a library or an executable that makes it risky, than its nature or its legal framework. Think about two libraries that deliver identical functions. The first is open-source, the second is closed-source. What's the difference from the point of view of risks assessment? None. Same functions, same risks.<br />
<br />
<ins>Defects, failures</ins>
Are open-source software more prone to defects than closed source software? I let you answer this question. I don't think that there is an evidence that one is more guilty than the other.<br />
<br />
<br />
<br />
To sum-up, open-source software doesn't help much to be compliant to IEC 62304. Open source-software has its own advantages linked to the licensing scheme. Open-source allowed the software industry to do giant leaps forward, but it's another debate.<br />
<br />
Next time, we'll continue our journey in the SOUP world with a <a href="https://blog.cm-dm.com/post/2013/06/14/Got-SOUP-Part-5-Standalone-software">post on standalone software</a>.</p>https://blog.cm-dm.com/post/2013/05/16/Got-SOUP-Part-4-Open-Source-Software#comment-formhttps://blog.cm-dm.com/feed/atom/comments/101Got SOUP? - Part 3 - Runtimes, Frameworksurn:md5:087458989f65c37a2245be33989224462013-05-31T15:06:00+02:002013-06-24T07:53:45+02:00MitchStandardsIEC 62304risk managementsoftware failureSOUP<p>We saw in the <a href="https://blog.cm-dm.com/post/2013/05/10/Got-SOUP-Part-1-Because-every-good-software-starts-with-SOUP">first article</a> of this series, what is a SOUP and what is not a SOUP, according to IEC 62304.<br />
Then we continued in the <a href="https://blog.cm-dm.com/post/2013/05/24/Got-SOUP-Part-2-OS%2C-Drivers%2C-Runtimes">second article</a> by having a look at OS's and drivers.<br />
Let's now see how to deal with runtimes.</p> <h4>Reminder - What IEC 62304 expects for SOUP</h4>
<p>Requirements about SOUP are spread across IEC 62304 standard. Mainly these requirements are about:</p>
<ul>
<li>Software requirements: The manufacturer shall describe what requirements (functions or non-functional) are necessary to have the SOUP work.</li>
<li>Architecture: The manufacturer shall define the software architecture to have the SOUP work in appropriate conditions.</li>
<li>Maintenance: The manufacturer shall monitor the SOUP lifecycle: patches, new versions...</li>
<li>Risk analysis: It is mandatory to do a risk analysis related to the SOUP.</li>
</ul>
<h4>Runtime is a SOUP</h4>
<p>Runtime is a SOUP, but there is always a software development framework behind a runtime. Even the smallest runtime has its framework, like gcc to make C-runtime library linked to an executable.<br /></p>
<h5>The Framework behind the runtime</h5>
<p>Frameworks provide services for the developer and the architect (make things easier to design and code) or provide services of higher level than those provided by OS's. Most of times, frameworks impose the software architecture. It may be necessary to assess the consequences of the architectural constraints of the framework on the architecture.<br />
Contrary to OS's, services are very framework-dependent. Thus, the types of software failures and the risk analysis are very framework-dependent.<br />
This can be analyzed only on a case-by-case basis.</p>
<h5>Runtimes</h5>
<p>Runtimes are the libraries and executables provided by a framework. From the C-runtime of the very limited C standard lib framework, to the Java Runtime Environment of the plethoric Java Development Kit framework.<br />
Therefore the requirements of IEC 62304 about runtimes are mostly covered by the analysis of the framework. The risk analysis about frameworks may be completed with the analysis of problems that can be specific to a runtime (memory consumption, number of threads intanciated, deployment methods...).<br /></p>
<h5>JIT compilers</h5>
<p>JIT compilers are a very peculiar case of framework runtimes. Therefore the requirements of IEC 62304 about JIT compilers are mostly covered by the analysis of the framework and its runtime. The risk analysis about JIT compilers may be limited to the analysis of specific problems that can arise when they are activated (delayed response time, behavior on different target platforms...).<br />
<br />
That said, we can rephrase what's above to present it in the same order as we did in the previous post about OS's.</p>
<h5>Requirements about frameworks and runtimes</h5>
<p>IEC 62304 requires to define what software requirements (functions or non-functional) are necessary to have the SOUP work properly.<br />
For frameworks, we can take it in the reverse order, like for OS's. The job is to design the software to run inside the framework, and to define the hardware + software environment to have the framework runtimes work.<br />
We can then have two types of requirements:</p>
<ul>
<li>Those about services used by the software, eg. web services, databases, planned tasks, security...</li>
<li>Those about hardware + software environment, eg. OS version, HW requirements...</li>
</ul>
<h5>Architecture of frameworks and runtimes</h5>
<p>IEC 62304 requires to define the software architecture to have the SOUP work properly.<br />
Once again, we can take the problem in reverse order. We have to make the software run inside its framework. This has consequences on the architecture of the software.<br />
To make a link with software requirements, the real way to do things is:</p>
<ol>
<li>Choosing the framework,</li>
<li>Defining the software functional requirements,</li>
<li>Defining the software architecture to have software run within its functional perimeter,</li>
<li>Defining the software requirements (as such listed above about services and so on) to have the right architecture,</li>
</ol>
<p><em>Perhaps, you may find a bit early to place choosing the framework in first position. This is actually what happens in most of cases, except for brand new devices.</em></p>
<h5>Risk Analysis of frameworks and runtimes</h5>
<p>As we said above, the risk analysis of framework is always peculiar to each framework and the software implementation.<br />
Having defined a list of framework services (or libraries or else) used by the software, it is possible to guide the risk analysis about the framework with a list of <em>what if</em> questions.<br />
<em>What if this service provided by the framework fails?</em><br />
<em>What if this framework runtime component fails?...</em><br />
These questions are definitely not enough to do a risk analysis. They only consider what happens if something internal to software fails. But they are a good start to think about framework risks.</p>
<h5>Maintenance of frameworks and runtimes</h5>
<p>Frameworks versions are usually frozen at the beginning of design. Unless you know that a new version of the framework will be released during your development project. Or unless you are agile enough to change of framework version on the fly (but this is not today's discussion)!<br />
Changing of framework version poses the same problems as those for OS's. Depending on what's new in the version, migrating to a new version may impose a full verification and validation of a software.
<br />
<br />
In <a href="https://blog.cm-dm.com/post/2013/05/16/Got-SOUP-Part-4-Open-Source-Software">the next post</a>, we'll see how to deal with open-source librairies.</p>https://blog.cm-dm.com/post/2013/05/31/Got-SOUP-Part-3-Runtimes%2C-Frameworks#comment-formhttps://blog.cm-dm.com/feed/atom/comments/104Got SOUP? - Part 2 - OS, Drivers, Runtimesurn:md5:e356b245492c6d406604c87428d994c02013-05-24T14:03:00+02:002013-06-24T07:53:09+02:00MitchStandardsIEC 62304risk managementsoftware failureSOUP<p>We've seen <a href="https://blog.cm-dm.com/post/2013/05/10/Got-SOUP-Part-1-Because-every-good-software-starts-with-SOUP">in the last article</a>, what is a SOUP and what is not a SOUP, according to IEC 62304.<br />
We've also seen that a lot of 3rd party software are SOUPs, to begin with OS, drivers, runtimes, Just-In-Time (JIT) compilers and frameworks.<br />
How to deal with those to be compliant with IEC 62304?</p> <h4>What IEC 62304 expects for SOUP</h4>
<p>Requirements about SOUP are spread across IEC 62304 standard. Mainly these requirements are about:</p>
<h5>Requirements</h5>
<p>The manufacturer shall describe what requirements (functions or non-functional) are necessary to have the SOUP work.</p>
<h5>Architecture</h5>
<p>The manufacturer shall define the software architecture to have the SOUP work in appropriate conditions.</p>
<h5>Maintenance</h5>
<p>The manufacturer shall monitor the SOUP lifecycle: patches, new versions...</p>
<h5>Risk Analysis</h5>
<p>It is mandatory to do a risk analysis related to the SOUP.</p>
<h5>Configuration management</h5>
<p>SOUPs have to be managed in configuration.<br />
<em>OK, so take the right measures. I won't more discuss this requirement about config management.</em>
<br />
<br />
That said, it doesn't help to know how to comply with these requirements. Let's see what can be done.</p>
<h4>OS is a SOUP</h4>
<p>OS's deliver dozens of services, some are basic (file system, IP stack), some are of higher level (multi screen management, default archiving tool…).<br />
Depending on its safety class, integration of your software on the OS should be taken for granted or not. For class C, it may be relevant to list basic services that are used and to unitary test them. For other classes, it is a case-by-case decision based on risk analysis.</p>
<h5>Requirements</h5>
<p>IEC 62304 requires that the manufacturer describes what requirements are necessary to have the SOUP work.<br />
In the case of OS, we take the problem in the reverse order. It is more relevant to define requirements to have your software work with the services delivered by the OS. Perhaps not all services (yes, you use the file system), but only those that are relevant and/or peculiar to your software.</p>
<h5>Architecture</h5>
<p>IEC 62304 requires that the manufacturer defines the software architecture to have the SOUP work in appropriate conditions.<br />
Once again, you may take the problem in reverse order, and define your architecture to have it work on the OS. With this architecture, you may end up with hardware requirements, to make OS + software run in appropriate conditions.<br /></p>
<h5>Maintenance</h5>
<p>IEC 62304 requires that the manufacturer monitors the SOUP lifecycle: patches, new versions…<br />
There are two main possible cases:</p>
<ul>
<li>Either the OS version is frozen at design. Eg: your software works on linux debian 6.0.7 with kde desktop.</li>
<li>Or the OS version is user-dependent. For example, your software works on Windows XP SP3 or higher.</li>
</ul>
<p>In the frozen case, only updates for cyber security may impose a change of version.<br />
In the open case, the updates of the OS may be analyzed to verify that they don't downgrade software performances nor bring new safety issues.<br />
That may lead to a complete verification of your software when you update the OS. This verification depends on the types of changes in the OS. A complete verification is very probable when you upgrade to a newer version, whereas a few tests may be enough if you apply a security patch.</p>
<h5>Risk Analysis</h5>
<p>It is mandatory to do a risk analysis related to the SOUP. But how to make a risk analysis related to an OS?<br />
Risk analysis is based on the probability and consequences that the OS doesn't provide its services with expected performances.<br />
<br />
As we wrote in introduction, services provided by OS's are taken for granted. It's when your software works in limit conditions that OS failures can happen.<br />
If your software read-writes a 5kb file every minute, we know that it works on a standard PC. But if your software read-write a 5Gb file every minute, it may not work. In this case, some preliminary tests are necessary to verify that the OS can hold the load over time. And the SW/HW architecture may be updated as well.<br />
<br />
The safety class of the software is also important in the risk analysis. For class C software, it may be relevant to assess with scrutiny each OS service, whereas for other classes, a macroscopic assessment of HW + OS + SW integration may be enough.</p>
<h4>Driver is a SOUP</h4>
<p>Drivers are more or less additional services plugged into the OS. Even if the service they provide is peculiar to a dedicated hardware, drivers should be treated in a very similar way, albeit identical, to OS's.<br />
The main difference is the presence of the hardware peripheral, controlled by the driver. That means that you have to verify that the hardware works in appropriate conditions.</p>
<h5>Requirements</h5>
<p>As for the OS, it is relevant to define requirements to have your software work with the services delivered by the driver.</p>
<h5>Architecture</h5>
<p>Likewise, it is necessary to define your architecture to have it work with the driver and the underlying hardware. With this architecture, you may end up with hardware requirements, to make OS + drivers + software run in appropriate conditions.</p>
<h5>Risks Analysis</h5>
<p>Risk analysis is based on the probability and consequences that the driver doesn't provide its services with expected performances.<br />
But there is a new condition. Risk analysis shall also be based on the probability and consequences that the connected hardware doesn't work with expected performances. This hardware risk analysis may have been completed at the system level and may be an input data of software design.
<br />
<br />
In <a href="https://blog.cm-dm.com/post/2013/05/31/Got-SOUP-Part-3-Runtimes%2C-Frameworks">the next post</a>, we'll continue our journey in the SOUP territory, by paying a visit to runtimes and frameworks.</p>https://blog.cm-dm.com/post/2013/05/24/Got-SOUP-Part-2-OS%2C-Drivers%2C-Runtimes#comment-formhttps://blog.cm-dm.com/feed/atom/comments/100Got SOUP? - Part 1 - Because every good software starts with SOUPurn:md5:d625e978960c7f72eb50c8307e08859a2013-05-17T14:21:00+02:002013-06-24T07:56:13+02:00MitchStandardsIEC 62304risk managementSOUP<p>No need to reinvent the wheel when developing software. Everybody uses software made by 3rd parties, to begin with the operating system and general purpose libraries.<br />
IEC 62304 has specific requirements about 3rd party software. What are these requirements and how do they affect software development and maintenance?<br /></p> <p>According to IEC 62304 terminology, 3rd party software are Software of Unknown Provenance, aka SOUP.</p>
<h4>What is a SOUP, what is a not SOUP?</h4>
<p>Not every 3rd party software is a SOUP. Software developed and maintained with respect to IEC 62304 requirements or with respect to medical devices regulations are not SOUP.<br /></p>
<h5>Simple case</h5>
<p>If 3rd party software is designed and maintained with respect to IEC 62304, and you have contractually access to the documentation, then this software is not a SOUP. This is the simplest case. It basically happens when the 3rd party is a sub-contractor or a software library manufacturer, with ISO 13485 certification or a QMS compliant to other regulation (eg 21CFR in the US), completed with IEC 62304 compliant processes.<br />
This is the gold standard, but it is not always feasible.</p>
<h5>Other simple case</h5>
<p>At the opposite side, if software comes from an open-source repository, from a private research lab (even in your company), from a university, or from any other 3rd party that has no process complying with IEC 62304, then this is a SOUP.<br />
The source may be the most truthful one in terms of quality of software or technological advance, it doesn't matter. If this 3rd party hasn't a QMS with IEC 62304 compliant processes, its software is a SOUP according to IEC 62304.<br />
This is usually the case of the immense majority of 3rd party software.</p>
<h5>Borderline cases</h5>
<p>But in most of cases the situation isn't so simple. Here are some examples.<br />
If the software is a legacy software developed before your company implemented IEC 62304, see <a href="https://blog.cm-dm.com/post/2013/02/06/How-to-bring-legacy-software-into-line-with-IEC-62304-part1">the series on legacy software</a>.<br />
If the software comes from a 3rd party which is IEC 62304 but you don't have access to the software documentation, then try to change the contractual conditions (easy to say...) or treat it as a SOUP, or not, if you have a good justification to do so.<br />
As a matter of fact, 3rd party software can be qualified as SOUP on a case-by-case basis. It mainly depends on the type of relationship with the software manufacturer and the nature of the documentation delivered with the software.</p>
<h4>Examples of SOUP</h4>
<p>Here are some examples of SOUP:</p>
<h5>Operating Systems</h5>
<p>Almost all OS's are SOUP: Windows, MacOS, iOS, Android, Linux and so on...<br />
To my best knowledge, no OS is claimed being designed for medical purposes by their manufacturers (I heard that QNX was, but I haven't seen satisfying documentation yet).</p>
<h5>Hardware Drivers</h5>
<p>All drivers delivered by hardware manufacturers are SOUP. Unless this hardware is a medical device or an accessory of medical device, designed and maintained with respect to standards and regulations.</p>
<h5>Software Development Frameworks</h5>
<p>High level frameworks like J2EE, ASP.NET, Flash, Ruby on Rails are not SOUPs. Lower level frameworks delivered by microchips manufacturers are not SOUP either.<br />
They are used in IDE at design time and never delivered to the end-user.</p>
<h5>Runtimes</h5>
<p>Contrary to frameworks, all runtimes used to make software work are SOUP: C runtime, ADA runtime, Java runtime, Common Language Runtime, runtimes delivered by micro-controllers vendors, any runtime language interpreter...</p>
<h5>Open-source libraries</h5>
<p>Whichever the license, open-source libraries are SOUP. The licensing terms found in open-source licenses like Apache or LGPL neither help nor make more difficult the use of 3rd party software in medical devices.<br />
IMHO, Open-source is another debate.<br />
One could argue that access to source-code is a help to SOUP management. Perhaps yes, in peculiar cases.</p>
<h5>IDEs, compilers</h5>
<p>Development tools are not SOUP, compilers either. They are used in factory, not in clinical settings. They shall be validated by IQ, OQ and PQ.<br />
Just-in-time compilers can be categorized as SOUP as they run with software delivered in clinical settings.</p>
<h4>Where are we?</h4>
<p>This makes a lot of SOUP!<br />
You may think this IEC 62304 standard is a real burden, that you have far more to do than you thought!<br />
<br />
Well, not so much, IEC 62304 is not a basket case! We'll see in <a href="https://blog.cm-dm.com/post/2013/05/24/Got-SOUP-Part-2-OS%2C-Drivers%2C-Runtimes">next articles how to deal with these SOUPS</a>.</p>https://blog.cm-dm.com/post/2013/05/10/Got-SOUP-Part-1-Because-every-good-software-starts-with-SOUP#comment-formhttps://blog.cm-dm.com/feed/atom/comments/99