In most ways, developing medical devices is no different from developing any other type of product. So let's first take a look at these similarities.
All product development involves these necessities:
- Understanding the needs of the stakeholders and associated constraints
- Implementing a way of meeting the needs
- Proving that you have met the needs
- Ensuring sufficient revenue to remain in business
Medical device development faces specific challenges that also affect most companies these days:
- Increased competition
- Need to sell to global markets
- Need to shorten development time and time to market
The most obvious difference between the world of medical device development and the general world of product development is the highly regulated environment in which medical devices are developed, sold, and used. From its earliest days, the industry has been working within strict compliance frameworks. This has implications that need to be considered carefully:
- Strict regulatory agencies demand proof of compliance and, to make life more interesting, regulations vary between markets.
- Significant damage can result from conflicts with regulatory organizations.
- Engineers need to show traceability from user needs through to delivered products.
- Manufacturers need to have systems in place to ensure that customer requests and complaints are managed and, if necessary, changes made to products.
- Everything needs to be documented and reported.
- Product failures can cause injury of even loss of life.
Safety always has been one of the most critical elements in developing medical devices. In addition to this, software is emerging as the key differentiator. Innovations powered by software range from robotic surgery to automation of laboratory work and reporting of results. Embedded software has the ability to overcome the challenges of rapid product development, because users can add functionality more quickly to software than to hardware. The challenge is to balance the use of software to produce new devices with the constraints of safety standards and the complexities of working in a safety-critical, interdisciplinary environment. If a company cannot integrate its disciplines to enable team collaboration, the time to launch new products increases. Therefore, it is vitally important to link software development to systems design and the rest of the development processes.
It's essential to consider whether there are plans to sell a device in just one country or internationally. Even when selling only in one country, you need to consider regulations in places where the manufacturing occurs. For example, the United States Food and Drug Administration (FDA) regulations apply to medical devices or parts of medical devices sold or made in the USA.
Almost everyone needs to consider multiple sets of regulatory requirements. This gets trickier because these regulations are often based on different philosophies. National regulations, such as those from the FDA, are typically based on outcomes, not on prescribing specific activities. However, many international standards, such as ISO or IEC, prescribe ways of working. Medical device companies need to find a balance. And that's not all, many national bodies are moving towards the use of international standards. All this adds to the complexity of ensuring compliance with applicable regulations.
As if all of that is not enough, remember that failure to comply with these regulations can have severe consequences, including large fines, closure of the company, and even jail for responsible executives.
In practice, this all means that the people responsible for processes in medical device companies have to be aware of multiple standards, but if they do their jobs well it will not significantly affect developers.
The medical device extension to the IBM® Rational® Solution for Systems and Software Engineering helps medical device companies meet these challenges.
We recognize the issues for medical device developers. In response, we created the Rational solution for medical device development (see resources for links to more information). It provides support for all of the key activities of development: requirements, modeling, verification, validation and testing, configuration, and collaboration management. This solution consists of these elements:
- An integrated tool set
- Systems engineering and specific medical device practices
- Support from experienced field engineers.
The medical device practices concentrate on support for the FDA's Design Control approach and IEC 62304, as well as material to support Intended Use Validation of IBM® Rational® DOORS® requirements management software within your process. The practices provide a basis for developing content that is specific to an organization. Many people look for "best practices" in industry areas, but there isn't really a single set of best practices for medical device development. Essentially, best practice in engineering consists of delivering what stakeholders want, within the necessary constraints of time, resources, regulations, and so forth. You could say that it comes down to the same advice commonly given to presenters, which we can rephrase as "Say what you are going to do, do it, and then show that you have done it."
We have identified two common themes as important for medical devices:
- Traceability. Not just for requirements, but also including design, design decisions, verification, validation, tests, and so on.
- Documentation. Any regulated industry must be able to produce documentation that shows what has been done. But many people think the need to produce comprehensive documentation means using a waterfall-like approach of creating full documentation for one "stage" before moving on to the next. The important thing is that enough documentation is produced to justify the work being done at any point. This supports a wide variety of development lifecycles, from waterfall to agile approaches.
The IBM Rational solution for medical device development provides access to context-specific content that you can customize at any point. For example, while writing requirements in DOORS, engineers can find the recommended practices to ensure that requirements fit into the company lifecycle, determine how these practices are implemented in DOORS, and review higher-level guidance on topics such as traceability. The sections that follow explain further.
We believe that by adopting the following three steps, you can develop medical devices rapidly, while staying within regulatory guidelines:
- Enhance key process activities to prove compliance
- Identify the tool needs for each role
- Deploy an integrated toolset
Together, these steps foster innovation by enabling teams to collaborate and focus on design.
In the classic waterfall process, requirements are created first. Development (coding) is expected to follow the requirements. Agile methods such as scrum project management work in an iterative fashion and have proven successful in understanding and delivering what users need. Users can choose to follow these or other process workflows, because there is no specific process mandated in standards such as IEC 62304 and 21 CFR Part 820. However, to meet these standards, companies need to examine their development process to determine its compatibility with various regulatory mandates.
The point of the FDA's Design Control requirements in 21 CFR Part 820 is to ensure that the delivered product is compliant with both the stated user needs and the regulatory needs. The design control requirements are based on outcomes rather than prescribing how things should be done.
Creation of a product involves several processes. These can be divided in various ways, but those shown in Figure 1 are typical. The processes shown can all happen in parallel, and the arrow indicates the general flow of information. For example, you cannot design until you have some requirements, you cannot develop anything until you have some design, and you cannot test until you have some product. But none of these processes need to be "finished" to start the next one.
Figure 1. Processes involved in creating a product
- Requirements analysis
- Requirements must start with what the stakeholders need. From these, it is possible to iteratively develop higher-level system requirements and the derived lower-level requirements, using an agile process. Regardless of the process used, it is important to use a tool to create records with a defined workflow and approval. The regulatory standards dictate that requirements link to artifacts in all other phases of the process. It is vital to validate requirements against the source material.
- This process starts with turning the requirements into a coherent architecture so that engineers and developers can understand how each requirement will be met and ensure that there are no overlaps or gaps in the requirements. Note that this architecture does not need to be complete. This process recurs throughout development, through all levels. Similar to requirements analysis, it is a good practice to validate the outputs from these tasks by using techniques such as simulation and executable models.
- Development is the process of taking the design and turning it into a product with hardware or software. As design decisions are made and implemented, those decisions have implications at lower levels. Developers must either work within the constraints imposed or discuss relaxation of those constraints.
- Testing is carried out throughout development and manufacturing. Testing against system (or component) requirements verifies the system and checks that it has been built correctly. Unit level testing verifies that each component works, whereas integration testing ensures that different components work together and do not cause adverse side effects. Testing against stakeholder requirements validates the whole system as a black box to make sure that it has the correct functionality. Each testing discipline is critical for meeting the requirements of the system and making sure that it meets relevant standards.
- Reporting is not included in Figure 1 because it is present in all processes. Demonstration of regulatory compliance is far easier with automated reporting. This is especially important when regulatory agencies request data periodically. Many medical device producers view reporting not just as a way to prove traceability but also as a way to insulate their development systems from non-project members, thus eliminating any tampering or loss of data. In addition, they use reporting to pull all of the documentation together in a repository. An option is to print and sign these documents individually, but this is time consuming, expensive, and tedious. It is becoming more popular to use e-signatures, instead. This can only be achieved through strong reporting capabilities.
Examining these key activities provides insights into which require enhancement. The team that is reviewing each process is then able to specify what needs that you must fulfill to satisfy the regulatory norms. After those needs are established, the appropriate tools need to be deployed, which leads us to Step 2.
Each team role has specific tool needs associated with it. Unless these needs are met, the product development team members are not able to completely fulfill their roles.
Table 1. Tool needs for roles involved in product development
|System engineers||A collaborative environment for requirements analysis, architecture management, configuration and change management, work items, change sets|
|Project, development, and test team leads||Work and plan management for system delivery teams for the entire project lifecycle, team collaboration|
|Hardware engineers||Solution for developing hardware, work items, change sets, and upstream traceability to system engineering work products and downstream traceability to system integration and validation|
|Software engineers||Complete software development solution for coding (perhaps model-driven), configuration management, work items, change sets, upstream traceability to system engineering work products, and downstream traceability to system integration and validation|
|Safety engineers||Focus on the safety requirements and assurance|
|Reliability engineers||System reliability as measured by metrics, such as mean time between failures and availability.|
|Quality engineers||Collaborative environment for defining quality needs, implementing processes, and ensuring that approvals are properly implemented|
|Testers||Collaborative environment for test planning, construction and execution, management of system validation and acceptance testing, and improvement in efficiency of the testing and resource allocation|
However, having the best tools will not be very effective without proper linkage between them. This leads us to Step 3.
Without integrations across the system delivery lifecycle, teams are left to operate in silos. In order to deliver medical devices that respond to changing market needs, engineering teams must perform efficiently and manage all artifacts through collaboration. Figure 2 shows how the IBM Rational Solution for Systems and Software Engineering provides this integrates requirements, architecture, design and development, change and configuration management, and quality assurance
As the diagram in Figure 2 shows, the Rational integrated solution helps fulfill the needs for each team role. It is the combination that makes this solution so powerful.
Figure 2. Rational Solution for Systems and Software Engineering
The three steps — enhancing key process activities, identifying the tool needs for each role, and deploying an integrated toolset — require a complete solution rather than point-based tool adoption. Table 2 summarizes the steps and maps the integrated Rational solution to the activities and needs, and highlights the tool linkage.
Table 2. Mapping activities, tools and Rational solutions
|Step 1. Enhance key process activities||Step 2. Tools for specific team role||Step 3. Integrated solution|
|Requirements Analysis||Reports||System engineers:|
Rational DOORS, IBM® Rational® Rhapsody®, IBM® Rational Team Concert™
|Rational DOORS integrates with Rational Rhapsody software for system engineering tasks. Rational Team Concert software is used for lifecycle management of the change artifacts.|
|Design||Reports||Safety engineers or reliability engineers:|
DOORS, Rational Rhapsody
|Rational DOORS software and Rational Rhapsody software with the Safety Analysis profile are used for identifying and classifying hazards, faults, and safety measures.|
|Development||Reports||Project, development, and test team leads: |
Rational Team Concert, IBM® Rational®
Quality Manager Software engineers: Rational Team Concert, DOORS, Rhapsody, Rational Quality Manager
|Rational Team Concert software and Rational Quality Manager software help with live transparency through collaboration, automation, and reporting to the system delivery work products Rational Rhapsody software, along with Rational Team Concert in the Eclipse IDE,integrates model-driven development, using UML.|
|Testing||Reports||Software and system testers:|
Rational Quality Manager
|Rational Quality Manager software provides a collaborative environment for management of system validation and acceptance testing and creates traceability across the lifecycle.|
The three steps that we have discussed here can help accelerate the development of your products. To produce medical devices that meet changing healthcare needs and standards, the team that engineers the medical device systems must collaborate to manage all of the development work products. IBM Rational software provides an integrated solution for these engineering teams so they can address the challenges of developing medical device software. The solution offers a process based on the principles of agile development and adds modeling the architecture, sophisticated requirements management and automated reporting capabilities to help medical devices not only meet various regulatory standards like 21 CFR Part 820 and IEC 62304, but also reduces the effort of proving this compliance by linking the development tools.
- Find out more about Rational solutions for medical device development:
- IBM Rational solutions for medical device development overview. Also see the links to additional relevant webcasts, demos, and downloads, as well as the links at the bottom to Rational software mentioned in this article.
- Solution brief for IBM Rational systems and software solutions for the medical device industry: Improve processes, manage IEC 61508 and IEC 62304 standards, develop quality products (IBM, 2011, PDF)
- White paper: Challenges and opportunities for the medical device industry (IBM, 2011, PDF)
- Brochure: Three steps to accelerate medical device product development (IBM, 2012, PDF)
- Webcast: Achieving Medical Device Software Compliance under IEC 62304, requires registration, free of charge (IEEE Spectrum Online, May 2012)
- Podcast: Saving you pain while you save lives by Keith Collyer and Paridhi Verma, IBM, co-authors of this article (IBM, 2012)
- Demo: IBM Rational solution for medical devices by Keith Collyer, IBM, co-author of this article (YouTube, June 2012)
- Video overview: Regulatory Compliance with Smarter Medical Devices by Martin Bakal, IBM (YouTube, March 2012)
- Video case study: IBM Rational helps Waters Corporation streamline compliance processes by Don Cunningham, Waters Corporation (YouTube, November 2009)
- Article: Using agile methods in medical device development by Martin Bakal, IBM (EE Times, October 2012)
Get products and technologies
Download free trial
versions of Rational software.
- Evaluate other IBM software in the way that suits you best: Download it for a trial, try it online, use it in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement service-oriented architecture efficiently.
Join the Rational
software forums to ask questions and participate in discussions.
- Ask and answer questions and increase your
expertise when you get involved in the Rational forums, cafés, and wikis.
- Join the Rational community to share
your Rational software expertise and get connected with your peers.
- Rate or review Rational software. It's quick and easy.
Dr. Keith Collyer is a subject matter expert in requirements and systems engineering. He trained as an electronic engineer and later moved into software development. His interest in the "people" aspects led him into project management, quality assurance, and processes, never losing sight of the need to develop systems that meet real needs. Throughout much of his career, he has concentrated on helping both large and small organizations introduce requirements management. The key aspects of this are ensuring that the client understands the needs for and benefits from requirements management, clarifying and defining with the client the processes involved, including the necessary information and inter-relationships, and defining an IBM Rational DOORS implementation to best support the client's needs.
Marty has more than a decade of experience working in various capacities in the embedded systems and software industry, with extensive customer experience worldwide in multiple industries, including consumer, telecomm, medical device, and automotive. He is currently the offering manager for the electronics industry at IBM Rational software. In that role, he leads the initiative to serve that industry. He has presented at many conferences and written magazine articles.
Paridhi Verma is an electronics industry market manager for IBM Rational software. She has extensive experience in electronics, automotive, aerospace and defense, and mobile development. She also has 10 years of experience working at IBM Research as a network and security software engineer, where she designed and implemented secure electronic commerce systems. She has an MS in electrical engineering from the Polytechnic Institute of New York University and holds a patent for the Internet emergency alert system.