Effective legal writing skills are essential for FDA submissions

A number of reasons make cultivation of the art of effective legal writing skills for FDA submissions important. Documents that are submitted to the FDA are deeply technical in nature, because of which they make heavy reading. Being the product of studiously and meticulously carried out research and finding, these submissions are very scientific and technical. Mastering the art of making legal writing effective and embellishing it is necessary for those who make FDA submissions because this can make these documents lucid and pleasant.

It is the habit of most law schools to prepare future attorneys by teaching them the art of summarizing and sharpening intricate and heavy textual and academic matter into crisp, concise and credible arguments. It is in situations such as drafting responses and applications to FDA that these kinds of writing skills become vital. The FDA expects responses to their queries, or for that matter, any poser that requires a response, to be very exact, scientific and technical. So, developing the art of effective legal writing skills for FDA submissions is a big need for those who prepare legal documentations.

Ridding submission documents of heavy text

Making submissions about the product apart; effective legal writing skills for FDA submissions need to be developed for another important reason. Companies have to paddle through a muddle of legally heavy, often confusing regulations, which are legally binding requirements that are based upon statutory laws and judicial opinions.

Professionals in the pharmaceutical and medical device companies are required to handle these and respond to these at the appropriate times. A firm grasp of the requirements for doing this is needed for clearly understanding how to frame persuasive arguments and to negotiate with the FDA.

Effective legal writing skills can contribute to success in FDA submissions

Effective legal writing skills for FDA submissions can stand between the success and failure of many new drugs, biologic or medical device projects, because a document that is confusing and is laden with incomprehensible jargon confuses the regulatory authorities and could become a reason for rejection of the submission.

This is why the more persuasive and articulate these arguments; the greater the chances for the company’s products of getting approvals from the FDA. All these facts make the cultivation of effective legal writing skills for FDA submissions extremely important.

Major learning on effective legal writing skills for FDA submissions

The ways of making legal writing skills effective for FDA submissions will be the topic of a two-day seminar that GlobalCompliancePanel, a leading provider of professional trainings for all the areas of regulatory compliance, will be organizing.

The Director of this highly important and rewarding session on legal writing skills for FDA submissions is Robert Michalik, a Massachusetts regulatory attorney and founder of RegulatoryPro.com.  In order to get clarity on how to develop the right tools needed for effective legal writing skills for FDA submissions, please register for this webinar by just visiting Effective legal writing skills are essential for FDA submissions

Effective legal writing skills for FDA submissions improve the chances of success

At this very valuable webinar on effective legal writing skills for FDA submissions, Robert will familiarize participants with the legal writing skills and practical techniques that will enhance their chances for success. Good regulatory writing may help to meet FDA branch-level requirements; but effective submissions that are laced with effective legal writing skills for FDA submissions can withstand scrutiny at the FDA Division level.

The seminar will be highly useful to any person working in Regulatory Affairs or Quality Management who is responsible for summarizing data and technical results, obtaining regulatory clearance or approval of a product, and selling or marketing regulated products. These include Regulatory Affairs professionals, Quality Assurance professionals, Marketing professionals, Scientific and Engineering/Product Development Managers, and Consultants to any regulated industry.

At this webinar, Michalik will cover the following areas:

• Basic communications skills that all successful attorneys use to win arguments, in legal briefs and oral presentations
• Step-by-step analysis of how to present both good and poor data in a persuasive manner
• How to train scientists and engineers to generate “good” data to support legal, regulatory and quality claims?
• Tips and secrets to framing an argument that makes even poor data look good
• Examples of good writing that can be useful templates for training and skills development
• What you should never say in a quality or regulatory document.

The Dynamic Learning Project: helping deliver on the promise of tech in the classroom

When it comes to schools, bridging the “digital divide” means more than providing access. While that gap isn’t yet closed, there’s another emerging equity imbalance that goes beyond computers or connectivity. This “second-level digital divide” is fueled by major differences in how effectively that technology is being used for teaching and learning. And it’s especially…

via The Dynamic Learning Project: helping deliver on the promise of tech in the classroom — Education

The Ultimate Guide To Design Controls For Medical Device Startups

 

---

 

What’s this guide about anyway?

Back in 1998, I started my career as a medical device product development engineer.

At that time the FDA Design Controls regulations were still fairly new — not only to me — but the industry in general.

In those days, we all struggled to understand how and what to do with respect to Design Controls.

As my career progressed, I started to understand the purpose and intent regarding Design Controls. But it didn’t happen overnight.

Over the past 17 years, I’ve been fortunate to have played a part in getting 40+ medical devices through FDA clearance as a product development engineer, through my consultancy, and more recently as co-founder of greenlight.guru.

However, for many, Design Control is still a topic that is as confusing today as it was for me many years ago.

With this guide, I plan to share valuable insights to explain what Design Controls are, how to address them, and how they benefit your medical device product development efforts.

 

You have an idea for a new medical device. Now what?

Congratulations! You have an idea for a new medical device.

Chances are you believe your idea will have a significant impact on the quality of our lives in some way. Chances are your product will help solve some current problem and address unmet needs.

What do you do now?

Throughout the world, there are agencies that govern and regulate medical devices. For example, in the United States, medical devices are regulated by the Food & Drug Administration (FDA).

These regulatory agencies have defined rules and regulations that you and others developing and manufacturing medical devices must follow.

And these regulatory agencies have defined rules and regulations about how medical devices are classified and what is required before the products are sold into the marketplace.

Most notably, since you have an idea that you want to develop further, there are regulations established for you to follow during the product development process. These regulations are known as Design Controls.

This may sound confusing and discouraging. I get that.

And I don’t want you to be confused or discouraged.

This is what drove me to create this “Ultimate Guide to Design Controls for Medical Device Startups.”

In this guide, I will share with you the necessary background about Design Controls from a global regulatory perspective.

I will provide you with knowledge and information that will arm you with more than just the basics.

---

 

Some explanation about a Quality System

Yes, I know — this guide is supposed to focus on Design Controls. And it does.

I just need to spend a few minutes explaining what a quality system is and how this relates to your medical device product development efforts.

 

What is a Quality System?

A medical device company has to establish a quality system.

A quality system is a set of processes and procedures you define and implement to describe how your company addresses medical device regulations, including Design Controls.

FDA defines the rules in 21 CFR Part 820. And if you plan to go to market in the U.S., these regulations are required.

Outside the U.S., Europe requires a quality system be established to meet the medical device directives. Many medical device companies choose to implement a quality system and have it certified to ISO 13485 to satisfy EU needs.

Canada — same thing. The expectation is that a quality system be established. Canada is a little different, requiring you to establish ISO 13485 certification and the Canadian Medical Devices Conformity Assessment System (CMDCAS).

The good news is this… FDA 21 CFR Part 820 and ISO 13485 are very similar. Meaning you can establish a “one size fits all” quality system, encompassing Design Controls too.

 

Build your Quality System as you go

The quality system expectations is that you have all parts and pieces defined and implemented by the time you go to market.

Yes, there are parts of the FDA regulations and ISO requirements that do apply to you, even if you are pre-market.

If you are going through medical device product development, there are at least 4 parts of a quality system that you need to put in place:

1. Design Controls
2. Risk Management
3. Document Control & Records Management
4. Supplier Management

The term I use is “bootstrapping a QMS”. I encourage this approach. Early on, you don’t need to spend too much time implementing a robust quality system. You need to be focused on product development.

And as you get closer and closer to going to market, there are software tools, like greenlight.guru and others, you can use to gradually implement more and more of a QMS.

Just make sure you always keep your quality system in mind from the beginning, so you don’t have to learn how to free yourself from a quality system nightmare down the road.

---

 

What are Design Controls?

So far in this ultimate guide, I have spent very little time discussing Design Controls. Yes, this is deliberate.

The stuff I covered so far about understanding medical device product classification and quality systems is very important for you to have some grasp on as you pursue your new medical device idea.

If that information did not discourage you and you are still reading, rest assured.

The rest of this guide is devoted to Design Controls. Really more than just Design Controls.

I will share with you why Design Controls even matter and how they will help you during your medical device product development.

 

Design Controls – Comparing FDA and ISO

It is important that you design and develop a medical device that is safe. FDA, European Commission, Health Canada, and all other regulatory bodies throughout the world will want some assurances that your medical device is safe before you bring the product to market.

And this is really the essence of Design Controls. Proof that you have designed a safe product that meets user needs and requirements.

Technically speaking “Design Controls” is a FDA term and defined in FDA 21 CFR 820.30 (the 21 CFR stuff is FDA terminology to describe where in the code of federal regulations the topic is addressed).

In ISO 13485 speak, the terminology and intent is similar and covered in section 7.3 Design and Development.

The table below compares the FDA clauses for Design Controls to ISO 13485 clauses regarding Design & Development.

Both FDA Design Controls regulations and ISO 13485 Design & Development requirements expect you to keep documentation and records throughout the product development process.

The Design History File (DHF) is a great place to keep all of your Design Controls “evidence”.

As you can see, there is consistency regarding Design Controls. Although ISO 13485 does not explicitly call for a DHF, it is expected that you maintain records of design and development.

An industry best-practice is to construct a traceability matrix to show the linkages and relationship between User Needs, Design Inputs, Design Outputs, Design Verification, and Design Validation.

Building and maintaining your traceability matrix using tools like Excel or Google Docs a is fairly straightforward task during the early months of product development.

But as your project progresses, you’ll soon find using these general purpose tools often take days, and in some cases weeks, to keep your traceability matrix properly updated and maintained.

This marks a time in your project where switching to a software solution built specifically to meet the unique regulatory needs of a medical device company, like greenlight.guru, can result in significant gains in time to market while reducing risk.

 

Product Development versus Design Controls

I’d like to spend a few minutes discussing product development versus Design Controls. Is there a difference? Or are these terms synonymous?

The short answers to these questions depends on who you ask.

And I’m telling you the answers really don’t matter all that much.

When you have an idea for a medical device that you want to turn into an actual product, you will follow some sort of product development process. And I highly encourage you to map your product development process and WRITE IT DOWN.

As an example, I like to define the product development process in major phases:

 

 

During product development, you will construct some prototypes, do some testing, get some feedback, etc. Always trying to get to the next step towards launching your medical device.

As noted above, Design Controls are all about ensuring the medical device you are developing is safe.

All about making sure you have proven your medical device meets the requirements you define.

All about making sure you have proven your medical device meets the user needs and product’s intended use.

All about making sure you will be able to manufacture your medical device that you designed and developed.

But since I posed the question about product development versus Design Controls, I’ll give you my opinion.

It’s my opinion that Design Controls fits within the broader medical device product development process.

Product development includes much, much more than just Design Controls. Things like budget, timeline, business development, marketing, sales, and so on.

---

 

Maintaining a Design History File

What is a Design History File (DHF)? When you read FDA Design Controls regulations, the part about DHF is mentioned towards the end. And ISO 13485 doesn’t officially talk about a DHF.

I want to cover DHF now so that you understand what it is and why it matters.

A Design History File is, simply put, the place where you keep all your Design Controls.

A DHF should be organized and accessible to the entire project team.

A DHF is the place where you will show the linkages and relationships between all the Design Controls.

Demonstrating traceability of all your Design Controls throughout the product development process is expected and required.

Whether you use a paper-based approach, general purpose tools, or a software solution designed specifically with Design Controls traceability in mind like I mentioned before, know that the responsibility to prove this is yours.

 

Keep the DHF separate from project file

My comments about product development versus Design Controls may seem somewhat trivial.

Except that it isn’t.

And the DHF is my main reason for saying so.

Yes, Design Controls and the DHF where these documents and records are maintained are important.

The DHF is the central hub for all the things medical device regulators care about.

Which is why it is so important to keep your Design History File as a stand-alone thing.

Going through medical device product development, you seldom consider how to maintain documentation and why it even matters.

And after you launch your medical device, the DHF is important in the event the project is ever audited by the FDAor others.

The last thing you want to do when finishing up a project is to spend weeks going back organizing documentation and records, including the Design History File.

I’m telling you that if you do not keep things shipshape as you go, you will not go back to clean it up.

This is why I recommend building your Design Controls traceability matrix early and keeping it up to date as you go. With this approach, you won’t stress about the possibility of being audited because your DHF will always be up to date and audit ready.

 

 

A Traceability Matrix Using greenlight.guru (Click here to get a free demo)

Ensure the DHF is organized and accessible

Ensuring Design Controls documentation and records are stored in a DHF is very important.

Keeping the DHF in a place where your entire product development project team can access it is also important. Why? Throughout product development, your team will be contributing valuable content to include in the DHF, and accessing this same content to conduct product development.

Be sure you are deliberate in how you plan to keep the DHF organized and accessible.

Do you plan to use a paper-based approach? If so, be sure you are aware of the challenges paper systems pose.

Do you plan to store electronic records on a company server or some type of electronic document management system? There are also challenges with this approach as well.

Do your homework. Choose your solution wisely.

---

 

Why capturing User Needs sets the stage

Remember when you had the idea for your new medical device, you came up with this wonderful product because you want to address unmet clinical needs. There are two terms that you should understand: intended use and indications for use.

Intended Use is the general purpose of the medical device or its function (what you “claim” the medical device does)

Indications for Use describe the disease or condition the medical device will diagnose, treat, prevent, cure, or mitigate, including a description of the target patient population

All of this relates to the User Needs for your medical device and are part of Design Controls.

Now you can do a lot of digging to try to get a better understanding of what User Needs really are. FDA doesn’t really define User Needs in the 820.30 regulations per se. User Needs are shown kicking off the Design Controls process in the classic “waterfall diagram.”

 

Classic Design Controls waterfall diagram originally published by Health Canada & published in FDA Design Controls Guidance

 

The best place, aside from this guide, for you to get some insights about what User Needs are is the FDA Design Controls Guidance.

And when you read the FDA guidance, just about every reference involving User Needs is tied directly to Design Validation. Validation proves your medical device meets User Needs and intended uses.

 

Documenting User Needs

Okay, so let me get into documenting User Needs. When documenting User Needs, think about your medical device product idea.

User needs describe how your medical device is going to be used. User needs help establish the framework for your medical device product design. Intended use describes the clinical issue your product addresses. Indications for Use pertain to clinical applications use, environment, and end user.

Here are some questions to help you better understand User Needs.

• What do you want it to do?
• Who is going to use it?
• When will it be used?
• What important features and attributes should be considered?
• How will the user and patient interact with the device?
• What type of procedures will the device be used?
• What type of environment will the device be used?
• When will the device be used?
• Is the device used one time or over and over?
• What other products will the device interact and interface with?

There likely are dozens and dozens more questions you need to ask.

And answer! Document your responses to all the questions.

Your responses become the information you should consider as the User Needs for your medical device idea, and included as part of your Design Controls.

Looking again at the waterfall diagram, you see that the proposed next major step after User Needs is Design Inputs. Logically, User Needs are the lead into Design Inputs.

And many medical device product development professionals will share with you how important Design Inputs are to the success of a new device.

Do not be too worried about whether or not your User Needs are exactly correct. Do not get too hung up on the format and wording.

Do realize that one day in the future, you will need to demonstrate that the product you develop addresses the User Needs you define.

The traceability matrix described earlier in this guide starts with the User Needs. User Needs feed into Design Inputs. Design Validation proves User Needs are met.

---

 

The purpose behind Design & Development Planning

In my experience, the topic of Design & Development Planning is very misunderstood. When most medical device product developers think about Design & Development Planning, the first thing that comes to mind is this:

Project schedule.

Since there is confusion about this, let me share what FDA and ISO state about Design & Development Planning.

FDA 21 CFR 820.30(b) Design & Development Planning: Each manufacturer shall establish and maintain plans that describe or reference the design and development activities and define responsibility for implementation. The plans shall identify and describe the interfaces with different groups or activities that provide, or result in, input to the design and development process. The plans shall be reviewed, updated, and approved as design and development evolves.

ISO 13485:2003 7.3.1 Design and development planning: The organization shall establish documented procedures for design and development.

The organization shall plan and control the design and development of product.

During the design and development planning, the organization shall determine

a) the design and development stages,

b) the review, verification, validation, and design transfer activities (see NOTE) that are appropriate at each design and development stage, and

c) the responsibilities and authorities for design and development.

The organization shall manage the interfaces between different groups involved in design and development to ensure effective communication and clear assignment of responsibility.

Planning output shall be documented, and updated as appropriate, as the design and development progresses.

NOTE – Design transfer activities during the the design and development process ensure that design and development outputs are verified as suitable for manufacturing before becoming final production specifications.

Did you come across anything that suggests project schedule? Or timeline?

Your product development schedule is definitely important. Don’t mishear me.

Remember where I shared some thoughts about product development versus Design Controls earlier in this guide?

Project schedule versus Design & Development Planning is in the same vein. Project schedule is a product development thing. Yet there is also a definite relationship with Design & Development Planning.

 

What goes into a Design & Development Plan?

Let me pick out the important aspects about Design & Development Planning from what FDA and ISO state about the topic:

• Identify Design & Development stages and activities
• Define responsibility for Design & Development activities
• Define the resources required; this includes project team members, as well as vendors
• Plans should evolve throughout Design & Development

A Design & Development Plan describes all the Design Controls, including when Design Reviews are expected. The plan describes who the team members are, including roles and responsibilities. The plan is not a “one and done” and needs to be revisited and updated throughout the project.

 

 

---

 

Understanding the role and importance of Design Reviews

Design Reviews are moments in time for you to evaluate the progress of your medical device project as it progresses through development.

During Design Reviews, you and the project team are formally reviewing — and agreeing to — Design Controls.

Design Reviews are also a time in a project to bring the team together in order to scrutinize and evaluate the state of the medical device and ensure that what needs to be done has been addressed.

 

How many? Who is involved?

How many Design Reviews does your medical device product development project need? This is a good question to ask. I do not have the answer for your project.

Here’s what I can tell you about Design Reviews.

How many Design Reviews to have depends on numerous factors. Factors like what the product is and who the players are need to be considered when determining timing of Design Reviews.

The expectation is that your Design Review include the right functions (engineering, marketing, manufacturing, etc.). Also, you need to include a resource who is independent.

When should Design Reviews happen?

All Design Controls must be included as part of a Design Review. As noted, I cannot for certain tell you exactly when to have Design Reviews. If you press me to provide a definitive response on this question, I will defer to the what is suggested by the Design Controls waterfall diagram.

I will advise you to have a Design Review when User Needs are drafted.

I will advise you to have a Design Review after Design Inputs are established.

And after Design Outputs. After Design Verification. After Design Validation…and before going to full production.

 

Design Reviews – the absolutes

Okay, let me be more helpful regarding Design Reviews.

First, you must have a record to prove that all Design Controls have been included as part of a Design Review.

Let me provide you a few “rules” when it comes to Design Review:

1. Design Verification can not happen until Design Outputs and Design Inputs are done.
2. Design Validation can not happen until User Needs are done.
3. Design Transfer can not happen until Design Outputs are done.

---

 

Becoming a Design Input artist

 

Ah, Design Inputs. It is important for you to understand Design Inputs and how critical these are to the entire success of your medical device project.

Design Inputs, in my opinion, are the most important Design Controls.

Keep in mind that throughout medical device product development, the terminology used is grossly inconsistent and highly dependent on who is talking.

What I mean by this is that very few use the terminology as described by FDA and ISO. Most have adapted their own lexicon when it comes to medical device product development.

No where is this more true than on the topic of Design Inputs.

Keep this in mind as you define Design Inputs and work with others who will contribute.

Here is a non-inclusive list of terms that is often used to mean “Design Inputs”:

• Design Inputs
• Design & Development Inputs
• Design Input Requirements
• Requirements
• Design Requirements
• Product Requirements
• Requirements Specifications

It can be very confusing. And because of this, I highly encourage you to make sure that you and your team members speak the same language when it comes to Design Controls — especially Design Inputs.

 

What are Design Inputs?

Design Inputs define all the performance criteria, requirements, and features of your medical device product.

There are numerous resources that feed into Design Inputs. From a Design Controls perspective, the primary resource that feeds Design Inputs are the User Needs.

Often times User Needs are broad statements that may be difficult to measure. User Needs include words like “easy”, “better”, “simple” — subjective, abstract concepts. And this is okay. I encourage having User Needs defined in this way.

1. Design Inputs, though, should not be subjective, abstract concepts.
2. Design Inputs should be objective. Measurable.
3. Think of User Needs as the precursor to Design Inputs. (And show how these are linked in a traceability matrix.)
4. Do not rely solely on User Needs as the only resource for Design Inputs.

There are things like industry standards, regulations, and competitive products that you should also consider when it comes to defining Design Inputs.

Plus, unless you are tackling medical device product development solo, you have other people working with you who should help define Design Inputs.

 

Think about Design Verification

I know I have not shared what Design Verification is just yet in this guide. Let me give you a preview: Design Verification proves you designed the medical device correctly.

Because of this, you should definitely consider how you plan to verify your product design at the time when you are documenting Design Inputs.

Considering how you will verify will have a profound impact on the content of Design Inputs. You should definitely put thought into how you will prove your medical device will be verified when you define Design Inputs.

Taking Design Verification into consideration when defining Design Inputs will also help your product development efforts. This approach will also help you plan and understand potential Design Verification activities. This is meaningful because Design Verification tasks can be very expensive and take significant amounts of time to complete.

 

Design Inputs become a roadmap for the product developer

Design Inputs describe everything that is important and required about your medical device.

Design Inputs become a roadmap, or set of “directions”, that a medical device product developer uses to design and develop a product.

Design Inputs provide the important criteria that must be included in the design of the actual medical device.

---

 

Defining how to make your medical device through Design Outputs

Let’s check in a bit on what Design Controls I’ve covered with you so far.

I shared what a DHF is and why is matters. I explained Design & Development Planning. And importance of Design Reviews.

I talked about User Needs. About how User Needs are the precursor to Design Inputs.

Remember Design Inputs are the roadmap used to design and develop your medical device.

Let me spend a few minutes talking to you about Design Outputs being a recipe and how these contribute to figuring out how to actually design and develop your medical device.

 

Design Outputs are the recipe

As you get into the hands-on, nitty gritty design and development, you start to identify all the parts and pieces that are required for your medical device.

What components go into your medical device? How are these components put together?

What I’m trying to say is this: Your medical device is comprised of a number of materials, components, sub-assemblies, and so on. And each of these parts need to be defined and documented.

Things like drawings, specifications, instructions.

Think of Design Outputs as the recipe for making your medical device. Design Outputs are the documents you would give to someone to assemble your product.

As you establish the Design Outputs, you need to show how these relate and link to the Design Inputs.

Once again, this can be done in Excel quite easily early on in product development but as the project nears market release, these relationships will become increasingly complex.

 

Design Outputs are the preliminary Device Master Record

Yes, this guide is about Design Controls. At the same time, it is important how various Design Controls have an influence and impact after you launch your medical device.

Design Outputs have a huge impact on the future state of your medical device. Fast forward with me for a moment.

When you have transferred from product development into manufacturing, you need to establish a Device Master Record for each product.

Device Master Record (DMR) is defined by FDA as:

a compilation of records containing the procedures and specifications for a finished device

A DMR is the recipe.

Just like Design Outputs.

---

 

Proving you designed correctly via Design Verification

Let me take you back a couple of topics. Think (or look) back at Design Inputs. I expressed that there is a strong relationship with Design Inputs and Design Verification. I encouraged you to think about how you are going to conduct Design Verification when you define Design Inputs.

When you get to Design Verification, your goal is to prove your Design Outputs meet the Design Inputs. Design Verification is all about demonstrating you correctly designed your medical device.

If you have been keeping your Design Controls traceability matrix up to date, you have a clear picture of the relationship between your Design Inputs and Design Outputs. Having this clear picture is very helpful when it comes to conducting Design Verification.

So how do you conduct Design Verification?

 

Testing, Inspection, Analysis

When you ask an experienced medical device product developer to describe Design Verification, it’s likely you will hear this described as testing.

“Yes, testing is a very common method used to conduct Design Verification.”

Remember, Design Verification is about proving Design Outputs meet Design Inputs.

Yes, testing is a completely valid way to prove this.

Although testing is not the only way to conduct Design Verification. You might also be able to employ inspection and analysis as acceptable methods for Design Verification.

1. Plan your Design Verification before you conduct tests, inspection, analyses.
2. Identify what you are going to do before you do it. Determine the best ways to prove Design Outputs meet Design Inputs.
3. And then do it! Complete your Design Verification activities, document results.
4. Update your traceability matrix to show how Design Verification proves your Design Outputs meet Design Inputs.

Preparing regulatory submissions

I want to spend a few moments now talking a bit about regulatory submissions and the relationship with Design Controls.

Generally speaking, as you successfully finish Design Verification, this means you are approaching a time when you can prepare a regulatory submission.

Specifically, this is the time in your medical device project when you should put together your FDA 510(k) submission (provided this is your path to market clearance).

If you plan to conduct a human clinical investigation in the U.S., this also marks the time when you should put together a FDA investigational device exemption (IDE) submission. (An IDE is likely for FDA PMA devices or could be of interest for clinical investigation before receiving 510(k) clearance.)

Outside the U.S. regulatory submissions and files are provided to regulatory bodies during Design Transfer.

Let me share a few links that are step-by-step examples for how to handle preparing different types of regulatory submissions.

CE Marking Process for Medical Devices – A Step by Step Example

Canadian Licence Process for Medical Devices – A Step by Step Example

FDA 510(k) or CE Marking?

 

---

 

 

Proving you have the correct device via Design Validation

Design Verification is about proving you designed your medical device correctly(e.g.: the Design Output meets the Design Input requirements).

Design Validation is about proving you designed the correct medical device.

Please understand the distinction. To do so, it helps to know that Design Validation demonstrates that your medical device meets User Needs and its intended uses.

Design Validation is the time when you revisit these User Needs. Validation is when you demonstrate that the User Needs are met.

Okay, not you per se. But actually end-users. Yes, that’s right — end users should be involved with Design Validation.

This is the whole intent and purpose: prove your medical device meets the needs of the end user.

 

Design Transfer begins

Design Validation most definitely involves evaluation of products. And because of this, the process of transferring a medical device from product development to production (often referred to as “Design Transfer”) begins during Design Validation.

In order to validate the design of your medical device, you need to build products. These products are to be built using production equivalent documentation and processes.

So all those Design Outputs (the preliminary DMR) need to be converted to the production environment and used by production personnel to assemble devices.

These production units (maybe the first) are then put in the hands of end users.

 

Have a plan of attack

If you remember the discussion about User Needs, I shared that sometimes User Needs have a tendency to be a little ambiguous, using words like “easy” and “better”. With Design Validation, you need to figure out how to prove that your product accomplishes this.

You need to establish a Design Validation plan. This plan needs to identify how many end users, what type of testing is required, and so on.

The end goal of Design Validation is to have objective, documented evidence.

Completing Design Validation is an important step in closing the loop on your traceability matrix too. The traceability matrix started with User Needs and ends with Design Validation.

---

 

Completing Design Transfer

As I noted, the Design Transfer process actually starts earlier in your project. It begins when you build products for Design Validation.

I also shared how Design Outputs are the preliminary Device Master Record. And the DMR is used by production to make medical devices.

Once you complete Design Validation, you are anxious to officially wrap up product development.

It’s time for you to have a final Design Review. This one may be a doozy (and may be a good idea to break it up in chunks).

The goal of this Design Transfer Design Review is to make sure everything that is needed for production is ready and done.

Completing Design Transfer signifies your medical device is ready to exit product development and officially enter into production.

This is significant because up until this point the “control” of the medical device has been the responsibility of the project team. Once Design Transfer occurs, the control shifts to production resources.

 

Button up the DHF

I hope you are keeping your Design History File up to date and current as you go through the medical device product development process. This is the best option by far!

Nothing is worse than getting to the Design Transfer stage and discovering that the DHF needs work. It happens. And if your DHF needs work, take the time and do it.

Don’t fall into the trap of saying that you will get to it later.

You won’t.

I’ve shared throughout this guide tips and pointers regarding the need to create and maintain a Design Controls traceability matrix. Keeping your traceability matrix current and up to date makes Design Transfer a much simpler process.

After you complete Design Transfer, the DHF is the ultimate record proving you have satisfied Design Controls.

And your DHF might be reviewed, audited, and/or inspected one day. Keep that in mind.

---

 

Launch!

After you complete your Design Transfer Design Review, you are almost ready for market launch. You also need to ensure that you have all the necessary regulatory clearances.

Then, at least from a Design Controls perspective, it’s time to sell your medical device.

 

The Ultimate Guide To Design Controls For Medical Device Startups

---

 

Summary of the Ultimate Guide to Design Controls for Medical Device Startups

Design Controls should be a systematic way to demonstrate the progress of your medical device product development efforts.

In this guide, I have shared with you what is expected for Design History File, User Needs, Design & Development Planning, Design Reviews, Design Inputs, Design Outputs, Design Verification, Design Validation, and Design Transfer.

I hope this guide helps answer all your questions about Design Controls (let me know in the comments!) — even the questions you didn’t know you had.

Medical device product development should follow a structured, methodical approach with traceability throughout. But we all know nothing always goes according to plan.

That’s why in addition to this guide, we’ve also created greenlight.guru, an easy to use, cloud-based software platform designed specifically to help medical device startups better managing their Design Controls & Quality System.

Quality Assurance Auditing for FDA-regulated industries

An effective audit constitutes the heart of an effective Quality System. The FDA and other regulatory agencies have emphasized this principle time and again. The purpose of an audit program is to ensure proper and thorough compliance with the guidelines set out by the regulatory agencies. A Quality Assurance audit should also ensure that the activities the company that is being audited is carrying out are within the legal guidelines and frameworks laid out by the respective regulatory authorities.

Two types of audits

An organization that is in an FDA-regulated industry is required to carry out internal and external audits. The purpose of this dual type of audit is that one complements the other and the two together reinforce the audits. As the two terms indicate, an internal audit may be thought of as being a tool for self-examination. It is an audit that the organization’s own employees carry out to scrutinize the usefulness of the systems. An external audit, on the other hand, is one that is performed by an independent person who has the qualification and purpose for this kind of work. The purpose of both these types of audits is the same.

Audits based on process

The core principle on which audits for the FDA-regulated industries are carried out as part of a Quality System is that since testing alone is not sufficient to ensure quality; quality should be inbuilt into the product. This approach, called the process based to auditing; has to, naturally, be based on an in-depth understanding of the entire set of processes that go into a Quality System before the commencement of the audit. A complete understanding of the processes relating to the business, control and production on the part of the auditors should be the basis to the process-based audit. Auditors then go about defining the criteria for the audit and the scope of the purpose they expect it to serve.

So, what to audit?

Since Quality Assurance auditing is generic to any FDA-regulated industry; a definition of what has to be audited is quite expansive. Based on the kind of the business, these are the important areas in which audit is carried out:

• Product
• Process
• Quality System
• Regulatory
• Supplier
• System
• Management

The four phases of auditing

Four self-explanatory phases go into an auditing process:

• The preparation stage
• The performance stage
• The Reporting stage
• The follow-up and closure stage

Auditing of management systems

The ISO 19011

The ISO introduced the ISO 19011 management systems audit. The ISO makes it mandatory for companies to also audit the management systems along with Quality Systems. This is done to ensure completeness of the audit.

Passed in 2011, the ISO 19011 is the guiding principle for auditing a company’s management systems and the ISO standard for auditing a company’s management systems.

Full understanding of all elements of audits

A detailed explanation of the ISO 19011 and all other aspects of an ISO audit will be given at a two-day seminar that is being organized by GlobalCompliancePanel, a leading provider of professional trainings for the areas of regulatory compliance.

At this seminar, David Dills, Global Regulatory Affairs & Compliance Consultant who provides regulatory affairs and compliance consultative services for early-stage and established Class I/II/III device, IVD, biopharmaceutical, cosmetics and nutraceutical manufacturers on the global landscape, and has an accomplished record with more than 27 years of experience in the areas of Regulatory Affairs, Compliance and Quality Systems; will be the Director.

Please log on to Quality Assurance Auditing for FDA-regulated industries to enroll for this seminar. This webinar has been pre-approved by RAPS as eligible for up to 12 credits towards a participant’s RAC recertification upon full completion.

Benefits of participation at this seminar

Participants who attend this seminar will benefit in a myriad of ways. David will offer the following at this seminar:

• Clear Understanding of Auditing Fundamentals
• Understand Audit Preparation and Planning
• Learn best techniques for Audit Performance
• Learn best practices for Audit Reporting
• How to address Audit Follow-up and Closure efficiently and effectively
• Understand the requirements and expectations for being an effective auditor
• How to develop into an even better auditor
• How to structure, plan and manage your audits
• How to develop your technical and non-technical skills
• How to perform your best audit ever.

He will cover the following areas at this seminar:

• The fundamentals of process based auditing
• Four Phases of Auditing: Preparation, Performance, Reporting, Follow-up & Closure
• ISO 19011 is the standard that sets forth guidelines for auditing management systems
• Different Types of Audits: Product, Process, System, Quality System, Supplier, Regulatory, Quality System, etc.
• More robust methodologies for preparing and conducting audits
• Auditor competence
• Enhanced audit criteria that consider efficiency and effectiveness
• Applied statistics for auditing when it’s necessary.

 

 

 

Which universities are pushing the boundaries in life sciences?

If you had to name the branch of university research that has the most tangible impact on mankind’s day-to-day activities, it is likely that the life sciences would be near the top of the list: not many days go by without the announcement of a new drug or gene discovery that has the potential to change lives or tackle disease.

Much of the best research in these fields takes place in the ultra-elite universities that excel in subjects across the board.

Tech challenger universities lead the way on industry links

 

But analysis by Times Higher Education of the institutions that make up the World University Rankings reveals that there is a cluster of institutions just below this elite that are particularly strong in the life sciences and in driving forward innovation.

The 120 “life science challengers” tend to pitch much higher in the subject rankings related to clinical research and life sciences, as might be expected, with the bulk of them achieving overall scores in the middle to upper ranges (see below).

However, they also perform very strongly in terms of the citation impact of their research, something that can be credited to their excelling in fields where journal article activity is key. Unlike the “technology challengers” (another cluster in the rankings), they also tend to be older universities, with few having been established less than 50 years ago.

Beyond these similarities though, the factors that drive the individual successes of the institutions are varied. In some cases excellent strategic decisions taken by the university are a factor; in others the local or regional ecosystem for research plays a part.

Sweden, which has five institutions in the list (headed by the medical research specialist Karolinska Institute), is one example where the ecosystem for life sciences appears to be a key factor.

Ulf Landegren, professor of molecular medicine at Uppsala University, another of the Swedish institutions in the list, said that the country had historically excelled in many life science fields, but that it was now taking its performance to another level with the help of collaborative programmes. The Science for Life Laboratory is one such programme – government-funded, it is based in Uppsala and also in Stockholm.

The SciLifeLab, as it is known, allows researchers from across Sweden to use cutting-edge and often expensive technology without paying for the privilege (apart from the costs of “disposables” used in lab work). Companies and scientists based outside Sweden can also use the facilities, but must face the full cost of doing so.

Professor Landegren, who was heavily involved in setting up Uppsala’s SciLifeLab site, said the effect of the scheme “has been that Swedish scientists now have ready access to advanced techniques that they may not themselves have the economy or the skills to set up”.

“Increasingly we see that life science is going the way of physics, in that technology is getting a little too expensive and complicated for individuals to have all the resources they need to answer their research questions so you might as well centralise it,” he explained.

He added that as well as making “generic” technology and techniques available to all Swedish scientists, SciLifeLab went a stage further by also identifying emerging “beyond state-of-the-art” approaches to research and capitalising on them before they spread to other countries and universities.

Access to expensive technology and the latest techniques is a theme carried across to other institutions that make the list.

Ross Coppel, director of research in the Faculty of Medicine, Nursing and Health Sciences at Australia’s Monash University, puts its success down to past strategic decisions to invest properly in the best academic staff and equipment, but also to the skilled technicians who operate facilities.

He said universities’ research strategies “are often very similar and it [success] comes down to your capacity to implement and execute your vision. I think we were in the fortunate position of having the financial resource to do it [and] the determination to do it and it’s worked out for us very well”.

On the role of technicians, he said Monash had focused on their field being a career path in its own right, with good job security and benefits. In return, in terms of testing new techniques and advancing research technology, “we look to them also to be pushing the boundaries of what is achievable”, explained Professor Coppel.

Beyond smaller research nations like Sweden and Australia, the life science challengers cluster is dominated by institutions in the US and UK.

With 35 institutions of the 120 (the UK has 24), the US is out in front, with a number of private institutions excelling in research. Here, the unique position that some American universities occupy – having strong ties to hospitals and the general healthcare system – is an obvious explanation for their success.

Emory University in Atlanta, for instance, is behind the state of Georgia’s biggest healthcare system – not-for-profit Emory Healthcare – while the US’ Centers for Disease Control and Prevention has its headquarters adjacent to the university’s campus. This geographic proximity between researchers and the practical application of their findings has obvious collaborative benefits.

But the university is also keen to stress the importance of its global reach through its success in spinning out research into the healthcare market and its academic links overseas.

David Stephens, vice-president for research at Emory, said that the institution had “realised its greatest success in commercialising research discoveries in the field of infectious diseases. For example, nine out of 10 US HIV/Aids patients, and thousands more globally, are on life-saving drugs discovered at Emory”.

Meanwhile, an effect of its international collaborations can be seen in the recent joint set-up with the University of Queensland – another life science challenger institution – of a multimillion-dollar biotech company developing cancer treatments.

simon.baker@timeshighereducation.com

Implementing ICH guidelines-compliant validation

Professionals in the field of statistical analysis need to possess clarity on understanding and interpreting statistical concepts used to investigate quantitative ICH Guidelines, such as:

• Analytical methods validation
• Procedures and acceptance criteria in calibration limits
• Process and Quality Control
• Process and quality controls
• ICH Q8 and Q9.

The ICH tripartite-harmonized ICH Guideline on Text, which was previously coded as Q2A guideline, is the guideline the ICH has set out for analytical methods validation. It was finalized in October 1994 under Step 4. Identification of the various validation parameters that are required for a number of analytical methods is the aim of this guideline. It also lays down the characteristics and parameters that have to be taken into consideration when validating the analytical procedures that are included in the registration applications.

ICH tripartite-harmonized ICH Guideline on Methodology, which used to be previously coded as Q2B is the ICH guideline for procedures and acceptance criteria in calibration limits. Finalized in November 1996 under Step 4; this guideline extends the ICH guideline on Text, or what is called Q2A (mentioned above). It comprises the actual experimental data required, along with the statistical interpretation, for the validation of a variety of analytical procedures.

Current Step 4 for process and Quality Control

The Current Step 4 version of the ICH-harmonized Tripartite Guideline is the current guideline for process and Quality Control. The regulatory bodies of the three biggest pharmaceutical markets in the world, namely the US, the EU and Japan have recommended the final draft of this guideline for adoption.

Professionals who want to achieve harmonization in Quality Meeting are required to meet critical milestones. These milestones include conducting stability studies, understanding the way the studies define relevant limits for the testing of impurities, and following a more flexible approach to pharmaceutical quality that is based on the principles of Good Manufacturing Practice (GMP) risk management. The ICH’s Quality guidelines on harmonization relating to Quality cover the following areas:

• Stability
• Analytical Validation
• Impurities
• Pharmacopoeias
• Quality of Biotechnological Products
• Specifications
• Good Manufacturing Practice
• Pharmaceutical Development
• Quality Risk Management
• Pharmaceutical Quality System
• Development and Manufacture of Drug Substances
• Lifecycle Management.

Complete learning on the areas of Validation in accordance with ICH guidelines

Considering the complexity and the breadth of the issues associated with these techniques, which cover both the pharmaceutical and clinical applications, and considering that these techniques apply to a number of area such as stability testing, outlier analysis and risk management; it is important and necessary for professionals in this area to get proper guidance on validation.

GlobalCompliancePanel, a leading provider of professional trainings for the areas of regulatory compliance, will offer this learning at a seminar that it is organizing. The Director of this seminar is Dr. Alfred Bartolucci, who serves as Emeritus Professor of Biostatistics at the University of Alabama. To register for this seminar, please visit Implementing ICH guidelines-compliant validation. This seminar has been pre-approved by RAPS as eligible for up to 12 credits towards a participant’s RAC recertification upon full completion.

A thorough understanding of statistical concepts

The statistical concepts used for investigating quantitative ICH Guidelines, such as analytical methods validation, procedures and acceptance criteria in calibration limits, and process and Quality Control, as well as with ICH Q8 and Q9, will all be covered in depth at this seminar.

Although not a formal course in statistics, this seminar will offer an applied approach to the statistical techniques used and will show how to reasonably interpret them. This learning will help participants to address the various challenges facing pharmaceutical and biotechnology companies when they are required to quantify results in a meaningful interpretable manner through tabulations and graphical presentations.

The expectations of different regulatory agencies regarding the quantification and development of a sound statistical monitoring of a properly utilized, effective, and efficient process control will also be taken up for discussion at this seminar. Dr. Bartolucci will familiarize the participants with the critical aspects of the statistical methods. He will explain the practical application of these guidelines.

This seminar will offer the following learning objectives:

• Evaluate linear quantitative measurement procedures and sources of error
• Distinguish the difference between confidence and tolerance intervals
• Evaluate the appropriateness of the effect of sample size in given procedures
• Evaluate laboratory/clinical quality control based on risk management
• Interpret statistical process control
• Distinguish between FDA requirements and ICH guidelines.

 

 

 

 

 

An integrated approach is needed for Complaints Handling, Adverse Event Reporting, and Recalls

The fact that medical device manufacturers work and operate in various regulatory systems whose requirements are different and not always consistent with each other is recognized and empathized by the new ISO version, the ISO 13485:2016. Because of the divergence in the requirements of each regulatory system; manufacturers are required to identify their roles, as well as the regulatory requirements for that role, and then incorporate them into their Quality Management System.

When it comes to post-market device issues; the various jurisdictions, however, deal with these in different ways. Three interlocking, interrelated processes need to go into the QMS:

• Complaint management
• Adverse event reporting
• Recalls

Supporting QMS processes such as corrective action and design changes also need to complement these three processes. Over and above the QMS processes come the regulatory requirements, which usually involve areas such as recordkeeping and reporting.

A complete learning on how to implement an integrated QMS

A highly educative and valuable learning session on these primary and secondary QMS processes and the way they need to be understood and implemented vis-à-vis the US, EU, and Canadian regulations is being organized by GlobalCompliancePanel, a leading provider of professional trainings for all the areas of regulatory compliance.

The Director of this two-day seminar is Dan O’Leary, who is President of Ombu Enterprises, LLC, a company offering training and execution in Operational Excellence, which focuses on analytic skills and a systems approach to operations management. Dan brings more than 30 years’ experience in quality, operations, and program management in regulated industries including aviation, defense, medical devices, and clinical labs.

To understand the way in which to implement an integrated QMS in which the various aspects of complaints, adverse reporting and recalls are built; please register for this seminar by visiting An integrated approach is needed for Complaints Handling, Adverse Event Reporting, and Recalls This seminar has been pre-approved by RAPS as eligible for up to 12 credits towards a participant’s RAC recertification upon full completion.

Alignment with the FDA’s QMS is a major point

One of the highlights of the final version of the ISO 13485:2016 standard, which has now become available, is the extent of its alignment with the FDA’s Quality Management System (QMS) requirement. Although the degree of alignment set out in 2016 version of 13485 is significantly higher than that of the previous version of 2003; there still do exist a few points at which it deviates from the FDA’s QMS. Companies that are required to comply with this standard have to keep this in mind.

Now that the ISO 13485:2016, the Medical Device Single Audit Program (MDSAP), and the new EU Medical Device Regulation have been introduced; companies need to update their QMS and integrate all of the elements if their implementation has to be effective and compliant. At this two-day session, Dan will provide the tools that the participants will need for this.

The agenda of this learning session will be the following:

• The Regulatory Structure
• FDA QSR
• ISO 13485:2016 and regional variants
• ISO 14971:2007 and regional variants
• Implementing MDSAP
• The EU Medical Device Regulation
• Servicing
• Identification of problems
• Servicing data analysis
• Input to the complaint process
• Complaints

Identifying complaints

• Evaluating complaints
• Investigating complaints
• Complaint data analysis
• Input to the corrective action process
• Input to the risk management process
• Corrective Action
• Developing the process
• Analyzing product and process information
• Determining subsequent actions
• Input to the design process
• Input to the risk management process
• Design and Design Changes
• Determining the need for a design change
• Documenting design changes
• Design change verification and validation
• Input to the risk management process
• Input to the pre-market submission process
• Risk Management
• ISO 14971:2007 and regional variants
• Incorporating post-market information
• Updating Pre-market Submissions
• US – The 510(k) guidance
• EU – Technical files and design dossiers
• Canada – License changes
• Adverse Event Reporting
• US – MDR
• EU – Vigilance Reports
• Canada – Mandatory Problem Reporting
• Recalls
• US – Corrections and Removals
• EU – Field Safety Corrective Actions
• Canada – Recall.

 

Development of technical training in the life sciences

Source: Development of technical training in the life sciences

Development of technical training in the life sciences

Training and Development is a highly developed and evolved, broad body of knowledge. Many employees place themselves at a disadvantage vis-à-vis their colleagues in the absence of the right professional training and development. If employees have to consistently close gaps in their learning, they need to keep upgrading their knowledge and skills. They should also use training and development to understand how to meet the regulatory requirements the organization is required to comply with.

Difficulties of training and development in the life sciences

This said; the need for technical training in the area of life sciences has not got the attention that many other areas have. Technical training and development skills in the field of life sciences is extremely important in helping professionals in that important area get proper guidance of the regulations in the areas of life sciences and benefit from them.

Technical training in the life sciences applications, however, has its challenges.  Mention needs to be made of two of them: A) The field of life sciences consists of activities such as formulating Standard Operating Procedures (SOPs), work instructions, and having to carry out tests and clinical trials, all of which are pretty complex. B) Regulations are often considered complex to grasp and implement.

A full understanding technical training for the life sciences

GlobalCompliancePanel, a leading provider of professional trainings for all the areas of regulatory compliance, will be organizing a two-day seminar, at which professionals in the life sciences will become more familiar with training and development. It will also ease the complexity of their training needs.

The Director of this seminar is Charles H. Paul, who is the President of C. H. Paul Consulting, Inc., a regulatory, manufacturing, training, and technical documentation consulting firm that is celebrating its twentieth year of existence in 2017. Want to understand the importance of technical trainings for the life sciences and know how to implement legally compliant life sciences training programs for your organization? Then, please register for this seminar by visiting Development of technical training in the life sciences.  This course has been pre-approved by RAPS as eligible for up to 12 credits towards a participant’s RAC recertification upon full completion.

Kindling the interest in training for the life sciences

Charles will essentially seek to ignite the training and learning needs of talented and technically competent training professionals who may need more focused instruction and direction in the area of technical training in the Life Sciences. He will examine the guidance that all training professionals need at all skill levels to truly build and sustain a training organization in today’s difficult corporate environment, and show how to effectively identify gaps in workforce training and compliance documentation and build effective and inexpensive training materials with the tools that are available.

A very important takeaway of this seminar is the learning of how to integrate Training & Development with compliance, so that the participants can leverage the benefits of compliance to improve the performance of the workforce and the overall performance of technical operations.

Personnel in the life sciences industries that are associated with training, such as Directors of Training, Training Supervisors, Training Coordinators, Training Developers, Instructional Designers and Instructors will benefit from this seminar. The following is the agenda of this seminar:

• Introduction to Training and Development in the Life Sciences and the Relationship between Training and Regulatory Compliance
• Training and Development Basics
• The Building Blocks of Human Performance
• Building a Training and Development Organization – Leverage what you have and Negotiate for What You Don’t
• Perform a Documentation and Training Analysis – Discover the Gaps
• Training Materials – SOPs and Work Instructions as Training Materials – It’s not as easy as you think! Leverage the Opportunity!
• Working with Subject Matter Experts and Outside Consultants
• Case Study Review and Discussion – This Approach Works!

The ways of applying ISO 14971, IEC 62304 and IEC62366-1 to medical device software

Diligence, complete and proper examination and assessment of the gaps, and correction of the gaps right from the very start of product development are the core characteristics that need to go into implementing risk management of software used in medical devices.

These are the reasons for it:

1. Lack of proper and complete implementation and gaps in them lead to major drawbacks such as production delays or deficiencies. Getting the necessary regulatory certification or approval or both for such products is almost impossible

 

2. Because of the inseparable bond between most activities and the development lifecycle; a medical device manufacturer will find it extremely difficult to separate any single activity and perform it with retroactive effect after a gap is detected. The detection of gaps in the midway stage of production neutralizes all the activities performed till then, causing the company to have to start from the beginning, no matter at which stage the gap is detected. The delays and cost overruns from such a scenario are extremely high.

Is there a way out? Yes. Embedding software risk management into the bigger scope of overall risk management is the solution. This is the cure to defective product development. This is why companies need to implement globally applicable standard requirements such as ISO 14971 and IEC 62304. These are important guidelines for helping medical device companies overcome the impediments associated with risk management of software used in medical devices.

Regulatory agencies around the world expect medical device companies to implement these global standards, which make risk management mandatory to almost any activity in the medical device industry.

The IEC 62366-1: 2015

There is also the IEC 62366-1: 2015 in addition to ISO 14971 and IEC 62304. The IEC 62366-1: 2015 specifies a process that a manufacturer has to use to consider, state, develop and assess the safety aspect of the usability of a medical device. It relies on human factors engineering in its usability process to help the manufacturer in evaluating and mitigating the risks associated with normal use, for which correct use and use errors are taken into consideration. The IEC 62366-1: 2015 standard is used for identifying, assessing or mitigating risks associated with normal use, but not abnormal use.

Getting it right from beginning till the end

It is necessary for medical device companies to implement the regulatory requirements set out in ISO14971 and IEC62304, as well as IEC 62366-1: 2015 standards that deal with risk management of software used in medical devices in the right manner to get regulatory approvals and meet quality standards.

How do medical device companies do this? This is what a seminar that is being organized by GlobalCompliancePanel, a popular provider of professional trainings for the regulatory compliance areas, will teach. The course Director, Markus Weber, Principal Consultant with System Safety, Inc., who specializes in safety engineering and risk management for critical medical devices, will explain the ways of designing, implementing and testing critical medical device software in a regulatory compliant environment.

To register for this learning, please visit The ways of applying ISO 14971, IEC 62304 and IEC62366-1 to medical device software. This course has been pre-approved by RAPS as eligible for up to 12 credits towards a participant’s RAC recertification upon full completion.

The requirements of globally applicable standards

The requirements set out by international consensus, reflected in globally applicable standard requirements such as ISO14971 and IEC62304, which has led to risk management being a mandatory component of almost any activity in the medical device industry, will be explained.

Since embedding software risk management into the larger framework of overall risk management is a critical aspect; this will form the basis of this seminar. Markus will explain all the steps needed to design, implement and test vital medical device software in a regulatory compliant environment in a way that adheres to the principles of risk management. He will also take up system level risk management and the ensuing interfaces to software.

A look at the safety case method

A well-established method used to collect and consolidate all safety related information together in one location is what is called the ‘Safety Case’ or ‘Assurance Case’ document. This step has the purpose of helping in comprehensively summarizing all the risk related activities and demonstrate the safe properties of a device.

The FDA currently requires this method for only infusion pump submissions. But it hoped that this system of documentation will become standard practice across all devices that come up for approval in the future. Markus will offer an introduction to the basic concepts and content of safety assurance cases. He will also describe their utility for internal and external review of safety related information.

Applying risk management principles in practice

The Director of this seminar will lace the session with real-life examples and proven tips. The aim is to help participants derive the benefits of the practical application of risk management. The system level issues of risk management will be explained, along with the increasingly important software-related issues of critical systems.

An assurance case, which will be introduced at this seminar, will be an add-on in making the effort needed for designing, implementing and verifying a safe device transparent. One of the outcomes of this two-day learning is that participants will be able to comply with regulatory requirements at a much lesser cost and with reduced spending on resources.