Three steps to rapid development of high-quality medical devices within regulatory norms

Integrate software across the product development lifecycle

Medical device developers face challenges that are different from developing products in most other industries. Chief among these is the imperative of compliance with safety regulations and industry standards. Three IBM experts describe three steps that help accelerate development, yet still produce high-quality devices that comply with regulations.


Keith Collyer, PhD, Senior Solution Manager, Electronics and Medical Devices Industry Solutions, IBM

author photoDr. 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.

Martin R. Bakal (, Worldwide Offering Manager, Electronics Industry, IBM

author photoMarty 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 (, Go-to-Market Manager, Electronics Industry, IBM China

author photoParidhi 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.

08 January 2013

Also available in Spanish

How developing medical devices compares to developing other products

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.

Ways that medical device development is similar

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

Ways that it is different

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 soldor 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.

Implications and assistance

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.

Three steps for faster development that still meets quality and safety goals

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 softwarewithin 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:

  1. Enhance key process activities to prove compliance
  2. Identify the tool needs for each role
  3. Deploy an integrated toolset

Together, these steps foster innovation by enabling teams to collaborate and focus on design.

Step 1. Enhance key process activities to prove compliance

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, design, development, tests
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.

Step 2. Identify the tool needs for each role

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 engineersA collaborative environment for requirements analysis, architecture management, configuration and change management, work items, change sets
Project, development, and test team leadsWork and plan management for system delivery teams for the entire project lifecycle, team collaboration
Hardware engineersSolution for developing hardware, work items, change sets, and upstream traceability to system engineering work products and downstream traceability to system integration and validation
Software engineersComplete 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 engineersFocus on the safety requirements and assurance
Reliability engineersSystem reliability as measured by metrics, such as mean time between failures and availability.
Quality engineersCollaborative environment for defining quality needs, implementing processes, and ensuring that approvals are properly implemented
TestersCollaborative 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.

Step 3. Deploy an integrated toolset

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
diagram of open lifecycle integration elements

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 activitiesStep 2. Tools for specific team roleStep 3. Integrated solution
Requirements AnalysisReportsSystem 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.
DesignReportsSafety 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.
DevelopmentReportsProject, 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.
TestingReportsSoftware 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.



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.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Rational software on developerWorks

Zone=Rational, DevOps
ArticleTitle=Three steps to rapid development of high-quality medical devices within regulatory norms