14 Jul Re-Architecting Software Following the Spirit of 62304
Every medical device manufacturer (MDM) is intent on speeding up development, keeping costs down, and getting to market fast–all while delivering a safe, accurate, and reliable product.
For some projects, a device falls outside the FDA’s regulatory jurisdiction and thus will not require step-by-step compliance with FDA standards. Although a device may not be required to follow these standards, our goal is to always achieve the highest level of quality and performance. For example, with IEC 62304, the software development standard for medical devices, sometimes we can follow the “spirit” of IEC 62304 and select the most applicable parts of IEC 62304 regulations to follow when making updates, adding new features, or re-architecting software. This allows us to maximize value for our customers and improve the quality and performance of the device software, while not being formally held to the standard, which makes for a faster, more lean design/upgrade process.
This approach is most easily carried out by engaging experienced supply chain partners as early as possible in the development process. By working with systems that have similar architecture on nearly every device, Key Tech has optimized the best practices for this type of architecture which increases efficiency and design speed, while still maximizing quality and performance.
Four Key Steps
- Understand the Current System (product) and the State of Software Development Process.
The first step is determining the current documentation and design landscape that is required for the software. For example, what are the limitations of the hardware and software? What does the MDM customer want to improve? Is complete IEC 62304 compliance required, based on the device’s intended use or classification from the FDA?
For this phase, we rely on our depth of experience to quickly evaluate the product and size up software architecture needs. This is perhaps the most important step of the entire process, especially for maximizing speed and getting to market quickly. We typically have detailed discussions with our clients to understand the success criteria at the beginning of the project engagement. Because we are so familiar with these systems, we understand what can make them go wrong and we know what to focus on and what to avoid. We utilize our own internally developed IEC 62304-compliant communication tools and protocols that simplify the software re-architecture process; we also have developed code frameworks that allow for rapid bring up of the basic embedded systems. With these different tools in our “toolbox”, we can help our clients plot out an effective development strategy
- Developing Updated Architecture.
This stage involves designing new or updated architectures to fix any existing issues, in the most expeditious way possible. For example, can we reuse existing code? What else can be done to optimize maintainability, increase performance, or add new features?
This work typically relies on our internal frameworks for embedded firmware and PC software that are readily adaptable for most use cases—again speeding up the re-architecture process. We maintain a large library of document templates with built-in guidance that allows us to leverage our shared knowledge when architecting a system. These tools enable us to rapidly follow the spirit of IEC 62304, without the added time and cost of completing unnecessary steps.
- Implementation.
At this stage we rely on our internal, IEC 62304-compliant agile development process that informs us what tools can we use to support rapid deployment and implementation. One of our greatest resources are the common code frameworks we have designed that reduce the need for non-proprietary code development. This includes display drivers, low-level communication interfaces, and memory/storage controllers. Key Tech engineers also utilize a standard set of microcontroller and PC architectures so that they are not forced to relearn a new architecture environment for each project; however, we are completely open and able to work within an existing framework as well. Agile development is the primary software development process that breaks up the work effort into smaller, more manageable time windows with defined goals. This permits the rapid delivery of smaller releases to the stakeholders so that any issues or adaptations can be identified and corrected early in the development process.
- Testing and Verification.
This is the last step in the redesign process—making sure everything works.
Code analysis using off-the-shelf tools is a key part of the process. Our tools for testing include PCLint, IAR CSTAT, and ReSharper for static analysis and multiple unit test frameworks, depending on if the project involves PC or embedded firmware and the associated languages. These tools allow us to incorporate many IEC 62304 testing requirements, while still being efficient and saving time.
For formal verification, we have templates and other general guidance for how to craft software verification procedures (protocols), which streamline the process and save time. Depending on the risk profile of the project, we may recommend having some combination of white box (software code is reviewed to generate tests), black box (manipulate input and review output), and open box (device partially disassembled) protocols.
Conclusion
The maturity of our process (we have been conducting regulated medical device design for over 20 years) and constant focus on improvement allows us to create an accelerated schedule, especially since we can rely on the vast amount of data, templates, and common code we have developed over that time.
We have developed a set of document templates and tools for the identified software development steps required by IEC 62304. This gives us a rapid starting platform for building out the custom design details according to these documents. Our detailed templates include design suggestions and guidance that allow us to maximize our collective experience during the design phase.
Our expertise, proprietary tools, and libraries of code enable us to meet very tight schedules. An added value of our depth of experience is that can we can quickly define the scope of the re-architecture process so that we don’t over-design or under-design—finding that perfect balance between the re-architecture process, product performance, and speed to market. By following the spirit of IEC 62304 for devices that don’t necessarily require it, a little extra effort can improve quality and save time, resulting in a better final product.
If you have a platform in need of software updates please reach out to see how we can help make those changes quickly and efficiently at TalkToUs@keytechinc.com.
He received his BS in Computer Engineering from the University of Maryland College Park and completed his MS in Computer Science at Hood College.
- Real-World Cybersecurity Lessons in Cloud-Connected Medical Devices - January 27, 2026
- Data Processing During Medical Device Design - July 8, 2024
- Decrease Time-to-Market by Developing Medical Device Software “In the Spirit” of IEC-62304 - January 18, 2022