We are frequently asked whether or not the training we offer is specifically geared to the medical device industry or if our training is generic.  The short answer – our instructors have extensive experience in providing training for the medical device industry.  We have taught both our standard courses as well as tailored classes for our clients involved in developing medical devices.

The long answer – clients involved in developing medical devices share a common characteristic – they are heavily regulated.  Many consumer product development companies are also heavily regulated, including pharmaceutical, food, and transportation companies.  In fact, being heavily regulated amplifies the need for our training, no matter which vertical market you work. 

Our most popular class, Requirement Definition (RD), is a good example of a seminar that is highly relevant to any vertical market, including the medical device industry.  During this 2 day seminar, attendees learn how to define their product’s scope and write requirements.  Specifically they will learn the following concepts:

Defining Need, Goals, and Objectives

The first day focus is on what activities you need to align everyone to a common vision and to help ensure your team has the knowledge needed to write a good set of requirements.

We call the first day “before requirements” and discuss the need to develop the scope of your project before writing requirements.  This includes understanding the problem you are solving with the product, understanding the “Need” (why) for the product, goals that need to be achieved to meet the “Need”, and objectives that clearly communicate the desired end state needed to met each of the goals.  We call these the NGOs.

Identifying Stakeholders

Another key part of Scope Definition is identifying and engaging the relevant stakeholders.  Stakeholders are a source of requirements and it is through the requirements that we communicate the stakeholder expectations to the development team.  Stakeholders include key representatives from various organizations and groups that have a “stake” or “interest” in your project.  From a verification and system validation perspective, the stakeholders that will have anything to do with verification and system validation activities need to be identified and involved from the beginning of your project.  Key stakeholders that will be “signing off” and accepting the product must agree that the planned verification and validation activities will result in sufficient “proof”  such that they will approve and accept the product.  Regulatory agencies are key stakeholders for medical device products as they are the source of the requirements contained in standards and regulations and who certifies your product for use.  Another key stakeholder is the insurance companies.

Drivers and Constraints

Given the heavily regulated nature of medical devices (and other consumer products) identification of drivers and constraints is emphasized.  Drivers and constraints are those things that are imposed from outside your project that you have little control over, but are required to show compliance.  Drivers and constraints represent a major source of requirements.

You need to make sure you include in your list of drivers and constraints the appropriate industry standards and any other standards mandated by governmental regulatory agencies.  For systems targeted for use in the United States, chemical containment and emissions requirements from the Environmental Protection Agency (EPA), operator protection requirements from the Occupational Safety and Health Administration (OSHA), clinical trials requirements from the food and Drug Administration (FDA), materials flammability requirements from the Federal Aviation Administration (FAA) or National Aeronautics and Space Administration (NASA), or accessibility requirements mandated by the Americans with Disabilities Act (ADA) are a sampling of the type of outside drivers that must be reflected in your requirement set.

If you are developing systems for use internationally, you need to find and incorporate the relevant standards and regulations in your requirement set.  Your verification and system validation planning must include producing the data required by the regulatory agencies to show compliance with their requirements for each country you plan to market your product.

For organizations developing a medical product, it is important to clearly address what verification and system validation requirements the government and medical insurers place on your product.  What extra reviews by outside experts and what liability insurance will be required before you can conduct tests involving human and animal subjects?  What is needed in order to get your project certified for use?

Other products may require outside experts for certification.  Does your product require an Underwriters’ Laboratories (UL) certification or maybe you have a pressure vessel that requires an American Society of Mechanical Engineers (ASME) Class 1 Certification?

Even if not explicitly stated by the customer or other stakeholders, be aware of and research the relevant outside drivers and constraints.  Compliance is expected and failure to address relevant drivers and constraints can result in failure during system validation and product rejection by the customer even if the customer did not explicitly communicate the drivers and constraints to you.

Define feasible scenarios and concepts to meet the stakeholder expectations

A major activity of scope definition is the development of a set of scenarios and concepts that address the expectations of all the stakeholders, each of the product’s life cycles, for both nominal and off-nominal conditions.  Scenarios and concepts for verification and system validation need to be defined and documented so you have the information needed to develop your work breakdown structure (WBS), budget, and schedule.  A major reason for a project’s cost overruns and scheduling delays can be contributed to the failure of the project to adequately plan ahead for verification and system validation activities.

What is your concept for verification and system validation? What is your concept for getting your product certified for use? For heavily regulated consumer products, planning ahead for verification and system validation is critical to successful development projects.  Remember, if your product fails certification, your company stands to lose millions.

Define product boundaries and external interfaces

An interface is a boundary across which systems interact.  Serious problems can, and all too often do, arise at the interfaces.  Your project is particularly vulnerable when interfacing with systems over which you have no control.  Because of this, your product is at most risk at the interfaces.  Identifying interfaces facilitates definition of your system’s boundaries and clarifies the dependencies your system has on other systems and dependencies other systems have on your system.  Identifying interfaces helps you ensure compatibility between your system and those with which it interacts.  Identifying interfaces also helps to expose potential project risks.

Because of this, it is extremely important that you define your concepts for how you will verify all interface requirements and validate that your system will work with all the external systems with which it must interact in the intended operational environment.

In your planning, be sure to address both internal and external interfaces.  An emulator or simulator may be needed to complete your verification and system validation activities.  As discussed earlier, these must be either developed or procured and verified and validated prior to your use during your system’s integration, verification, and system validation activities.

Key interfaces for medical devices include the medical practitioners, patients, and other medical devices (e.g. in the hospital room, intensive care unit, or operating room.)

Defining Requirements

Day two of the Requirement Development class is devoted to writing requirements that clearly, correctly, unambiguously, and consistently communicate the stakeholder expectations documented as part of the scope definition activities discussed during day one of the course.

On day two, we discuss what a requirement is, characteristics of good requirements, how to word requirements, terminology used in requirements and common defects to avoid (e.g., implementation, operations statements, and ambiguous requirements).  We also discuss categories of requirements and how to organize your requirements. Levels, allocation, and traceability are also discussed.

In order for students to focus on basic concepts and principles of requirement writing, we have found it best to use a generic product for the course examples and exercises.  However, if clients prefer, we can tailor the course to use one of their products as an example.

Training Options

ArgonDigital offers two main options for our training: Our standard training or tailored training.

Standard Training.

Our standard training reflects industry best practices applicable to any product development project.  As stated above, day one is self-tailoring in that the students use their own projects/products for the various scope definition activities.  On Day two, we use a generic product for our examples and exercises.  Click here for more information on our Standard Requirements Courses.

Tailored Training

For our tailored training, we work with the project team to understand their needs and then tailor the class to meet these needs.  As part of the tailoring, we review the projects existing documentation, including the existing requirement documentation.  We also review their processes.  From this information we reflect their processes, terminology, and focus on areas where improvement is needed.  Examples and exercises are included that reflect the project’s processes and product line. Click here for more information on our Tailored Courses.

If you have any questions on which form of training is best for your project please contact us via our Contact Us page and we will respond promptly.

Comments to this blog are welcome.

If you have any other topics you would like addressed in our blog, feel free to let us know via our Ask the Experts page and we will do our best to provide a timely response.