The development of software in the medical sector brings its own particularities (e.g., the importance of the risk analysis and how it impacts the software architecture, multiple layers of software verification, specific documentation, etc). If these aspects are not considered carefully, the development can quickly become complicated to manage and can cause delays and considerable additional costs.
To avoid unpleasant surprises in your medical software projects, we have gathered in two groups some key lessons learned from our previous developments of embedded and stand-alone medical software.
Project Management Lessons Learned
-
- The software team should be involved in early stages of a system development and participate in the specification of the Design Input. Advantage: Avoids unnecessary iterations in later project stages (e.g., when the Design Input must be translated into Software Requirements Specifications (SRSs)).
-
- Experienced embedded software engineers should be involved in the definition of the hardware architecture. Advantage: Ensures a smoother and quicker development phase.
-
- The Software Quality Manager should be involved as soon as the Software Development Plan starts being written. Advantage: Ensures you are compliant with your Standard Operating Procedures (SOPs) from the start and avoid unnecessary loops between project and quality teams.
-
- A risk analysis per ISO 14971 should be one of the first tasks in the project. Advantage: Ensures to have a clear idea of the critical functionalities and the Risk Control Measures (RCMs) to define a suitable software and hardware architecture accordingly.
-
- The software architecture should be laid out before the coding starts. Advantage: Avoids significant re-engineering, late modifications to software and hardware, and delays (up to several months) in later stages.
Technical Lessons Learned
-
- Safety-ciritcal software that implements RCMs must be very well separated from non-critical software and should ideally run on a separate processor. Advantage: Ensures that non-critical software cannot negatively impact the function of critical software. Also, a good segregation means that not all the software will end up class C (which means, for instance, less documentation and verification effort).
-
-
The protective functions should be tested as soon as software system tests begin, along with the main device features. Advantage: Despite the slowdown of testing at the beginning due to immature software and/or hardware, this will ensure that the entire system works as expected and avoid significant rework later.
-
-
- Hardware RCMs should be implemented instead of software RCMs when possible: Advantage: Extremely helpful to ease the burden on software classification.
-
- Write down a first version of the SRSs before the development starts and get agreement from the software development and software testing teams. Advantage: Provides a common basis from which software and tests are developed and making it a lot easier to align expectations from the project manager, the development team, and the test team.
-
- Do NOT write the unit tests too early. The software classification should be finalized first, so the tests should focus on the critical parts only. Advantage: Avoids writing unnecessary unit tests for units that turn out to be class A or B and avoid the overhead of updating unit tests every time the code changes.
These points give you a first overview of some aspects to be considered in the software development of a medical device. If you would like to go into more detail on certain topics and/or require support, our team of top-notch engineers will guide you and take care of your medical software development at every stage, from Definition to Validation.
More information about our services can be found here.
