Advertisement
Articles
Advertisement

Creating & Managing Requirements for Medical Devices

Wed, 06/06/2012 - 7:23am
Martin Bakal

Rising product complexity, intense market pressures and compliance to industry standards present major challenges for medical device developers. In order to stay competitive, organizations must implement tight coordination between hardware and software engineers to optimize product quality. This is especially true when controlling costs and meeting tight time lines. IBM Rational offers a solution.

In many organizations, hardware and software teams work independently once they are provided the high-level systems requirements. Any functionality changes are not migrated until next check point—months down the road—leading to major integration and optimization issues. Both teams use different tools to trace requirements/artifacts resulting in time consuming troubleshooting and often guessing where issues originated. Many requirements need to be met by both hardware and software.

There are many key elements of managing all system requirements with full traceability across the life cycle and the following are best practices to follow:

  • Build the right product because the requirements are visible at all times
  • Prove that all requirements (user, safety, regulatory, etc.) were fully satisfied
  • Understand the requirements
  • Analyze stakeholder needs
  • Evaluate coverage and impact analysis
  • Validate the requirements
  • Analyze for correctness and to determine next steps

Essentially, requirements are pretty simple things. At their basics, they are some text describing a specific need in a product. Getting requirements to fully describe a product without ambiguity is a far tougher task. Add in the critical nature of medical device development and the task gets even more daunting. Medical device requirements have to go to a very detailed level in order to meet regulatory compliance.

This problem is exacerbated when the product development includes separate teams developing hardware and software components as many times requirements blur the lines between hardware and software. Should a specific feature be a hardware button or be developed in software? These choices need to be made during requirements, but sometimes it takes some level of system analysis in order to understand the best options.

Another element that adds complexity to this whole process is the concept of developing a product line. That is the fact that one piece of functionality may be created a multiple, slightly different devices. Examples of this are devices that are used in hospitals, nursing homes, and home hospice settings. These devices have the same basic functionality but many times vary in their ease of use, extra features, complexity, etc. This makes the process of creating the set of requirements much more complex as you need to manage multiple variations of the same base requirements.

In recent years the medical device regulatory agencies have placed a stronger emphasis on software regulation. This is seen through standards like IEC 62304, which is a standard that recommends complete traceability through the entire software life cycle and defines different stages in that life cycle. This standard has been adopted worldwide and means no longer is software simply something companies can show strictly as a piece of hardware but also to show the complete traceability on the software process on its own. This places a large burden on getting the requirements right up front for both the hardware and software to make everything is an integrated whole device in the end.

Requirements engineering is critical to any good manufacturing process. This, coupled with good life cycle development, helps prioritize and overcome competitive hurdles and achieve faster time to market. In an industry like medical devices, it is critical to prepare for product audits. These requirements have to be traceable through the entire development life cycle process so everyone can see the requirements tied to the change requests and to get good and complete audit trails. The main point here is that when lives are at stake and regulatory agencies threaten heavy fines, spreadsheets and documents for requirements, change management, testing and the whole process aren’t enough to ensure quality device builds. It also isn’t an option to have to completely separate sets of requirements for the hardware and software components since the product being approved has parts from both integrated in.

Companies need one tool that manages both types of requirements at the top level. The regulatory agency fundamentally doesn’t care if a timer is met through hardware or software. They care that the timing is accurate to the necessary level. Once you create these high level requirements, then you can draw links to the ones to be implemented in hardware and software as sub-requirements and pass them to the appropriate team. But everything has to be linked together into one overarching set of requirements in order for someone to understand the base requirements of the device itself.

IBM Rational DOORS is the leading requirements management tool for the medical device industry and works very well for creating and managing requirements from both hardware and software. This along with Rational’s complete tool chain gives you traceability from requirement creation all the way through the hardware and software development process down to the tests created. This is the best way to ensure product reliability and a faster regulatory adoption process.

Creating and managing requirements is a very important process for medical device development. In order to do this well it takes the proper discipline, process and tolling. It is very important for these requirements to trace all the way through the hardware and software design.Regulatory agencies are requiring this level of rigor in order to get medical devices approved.

Martin Bakal, is the Worldwide Market Manager, Electronics Industry at IBM Rational.

Advertisement

Share this Story

X
You may login with either your assigned username or your e-mail address.
The password field is case sensitive.
Loading