Biopharmaceuticals And Medical Devices: A General Overview III (Medical Devices)

Drugs Part I

Drugs Part II

(Note:  As with Drugs above, this is a very high level view of a very complex and multi-year process and is only intended as an overview.)

A proposed Medical Device definition is "A contrivance designed and manufactured for use in healthcare, and not solely medicinal or nutritional".  A more "conventional" regulatory definition is here: in short if your item is intended to treat, cure, mitigate, or prevent disease and is intended to impact a human or animal system not using a chemical action internally and/or not activated via metabolic systems, it is a device.

So to answer the question, lots of things are a medical device.  A tongue depressor counts.  So does a scalpel.  So does a hospital bed.  So does an MRI machine.

But, all devices are not created equal and so there are classifications for devices.  In the United States, there are three classes (Class I, Class II, Class II) which are identified based on their risk to patient and user.  Class I is the "least" risky, Class III is the "most' risky.

There are distinct steps for designing a medical device - perhaps unlike Drugs, the process is a lot more standardized.  These steps are found in the US Document CFR 21 Part 820 (Quality System Regulations) and in the ISO Standard 13485 (Medical Devices - Quality Management Systems).

Design

All devices start with identifying User Needs:  what does the end user (patient, medical personnel, even marketing) need the product to do or be?   This is much more of an activity that it may seem, as it can involve getting input from a great many sources.   The User Need will be phrased in the form of a statement - for our purposes today, we will identify a User Need as "The product casing should be blue".

User Needs are then usef to generate Design Inputs, which are "The physical and performance requirements of a device which are used as a basis for device design" (21 CFR 820.3 (f)).  Each Design Input must be individually identified and must be clear, unambiguous, and non-conflicting with any other Design Input. As you can imagine, this will lead to hundreds or even thousands of Design Inputs.  Our example above will be translated into "The product casing must be Pantone Classic Blue Part Number #19-4052".   That may seem very specific - and it is intended to be.  Each input must be able to be objectively verified.

At this point a Design Review Team will be called together.  This will consist of personnel from all concerned departments - R&D, Engineering, Quality, Regulatory, Marketing/Business Development, Manufacturing, Supply Chain - and an Independent Reviewer who is not directly involved in the project but has the educational and scientific basis to assess the project.  All will be reviewed, unclear inputs corrected, additional needs identified.  When all agree on the User Needs and Design Inputs, the project will move to Design Output/Design Verification.

Design Outputs are "the results of a design effort at each design phase and at the end of the total design effort" (21 CFR Part 820.3 (g)).  The outputs will form the basis of the final design documentation - batch records, testing, labeling, etc.).  Each Design Input will have a Design Output which will need to be independently verified.  All of these Design Outputs will be putting into a Design Verification Protocol - again for our example, the Design Output would need to be "Product casing color is verified as Pantone Classic Blue Part Number #19-4052" - likely pulled from the manufacturing documentation for the casing in this case.

Another Design Review will take place to ensure that there are no new User Needs or Design Inputs, that all Design Inputs have Design Outputs, and that the Design Outputs are verifiable.  If approvable, it moves to Design Verification.

Design Verification is (rather straightforwardly) ensuring the Design Input meets the Design Output.  Personnel will move through the Design Verification protocol and verify and/or test every single Design Input.  Each Design Output will be recorded as meeting the Design Input, partially meeting the Design Input, or not meeting the Design Input.  At the end of this process the Design Verification Protocol will be reviewed and those Design Outputs which are found to not fully meeting the Design Inputs will be reviewed for additional clarification, correction, and testing.  In our example, if the manufacturing paperwork could not verify that Pantone #19-4052 was used on the casing, this would need to be resolved by an investigation and perhaps a remanufacture of the part - or, the User Need could be re-examined to see if that shade of blue is really needed, or just any "blue".

Assuming all items have been identified, a Design Verification Report is generated, to be presented to the Design Review Committee for approval. 

As you can imagine, there is a lot of documentation (physical or electronic) generated by this.  One of the most critical items is the Design Trace Matrix, which traces each User Need to Design Input to Design Output to Design Verification Result.  This document allows complete traceability up and down the design process.

A note:  This process takes place for each major component of the system.  For a system that has hardware/instrumentation, software and firmware, and consumables/reagents, every item will have a design history.  

The product is ready to move to Clinical Validation.

Risk Management

As noted above, the consideration of risk is a primary factor in determining the classification of product.  A risk - in Medical Device terms - is the combination of the probability of the occurrence of harm (injury or damage to people, property, or the environment) and the severity (measure of the consequences of a hazard) of that harm.  The ISO standard 14971 defines the risk management standard and is really the gold standard for all risk management (and largely a universal consensus standard).

A very short definition (for a very long process) is that intended use of the device and its use conditions are identified, along with what safety would look like and potential hazards and harms identified (including not just impact on the patient, but on the user (electrical hazards, chemical hazards) and the environment (spills, disposal of reagents)).  Using a numerical system, the risk are graded and evaluated.  Where risks exceed an acceptable level due to impact or frequency, risk mitigation and/or controls will need to be introduced, which may very well impact the Design Inputs/Design Outputs/Design Verification which in turn may then require another Design Review Meeting.

Another useful tool is the Failure Mode and Effects Analysis (FMEA) or the Failure Mode Effects and Criticality Analysis (FMECA).  Every potential failure mode is identified and evaluated against probability of occurrence, severity of that occurrence, and impact of the occurrence (for the FMECA, criticality of the failure is also evaluated).  Again, a rubric is used to evaluate unacceptable levels of failures.

The point of this entire exercise is to identify all risks and move them to acceptable risk levels (sometimes called "residual risk levels").  Like drugs, all medical devices entail some kind of risk; the goal is to remove as much risk of failure as possible and control the rest. 

Using our example above, the risk would be assessed under "What is the impact if the casing is not Pantone #19-4052"?  Possibly nothing - but perhaps in a clinical lab setting, that shade of blue may be not be able to be discerned for certain vision issues and could conflict with other similar pieces of equipment.

As with the Design Process, there are multiple iterations of the Risk Management Process.  The final documents will be held in a Risk Management File, which should contain every known risk for the product.  When a new risk is uncovered (either in development or in use), it should get added to the Risk Management file and assessed - in some cases, it may entail a  redesign.

(A note for general use:  Risk can only be avoided, mitigated, transferred or shared (to someone/something else), or accepted. True in real life as well as in medical devices.)

Validation

Validation (or as it is often known "Clinical Validation") is the use of the product in the potential use environment.  The difference between verification and validation, if helpful is:

Verification:  Did we make the thing right (e.g., per the Design Inputs)?

Validation:  Did we make the right thing (e.g. per the User Needs)?

A protocol will be developed and clinical sites engaged as well as all items approved by the Design Review Board.  Similar to the clinical process as identified in Drug Overview Part II, there is a whole set of processes involved to insure patient safety and control of the clinical trial. 

At the conclusion of the Clinical Validation, a final report will be generated. The results of the Design Verification will be added to the Design Trace Matrix so there is complete transparency up and down the design chain from User Need to Design Validation.  Any Design Issues or new Risks will need to be addressed, and possibly a second Clinical Validation conducted  Once all issues have been resolved and the report issued, the product will be ready for regulatory submission.

Quality Systems

Underlying all of this, of course, are Quality Systems. Just as with Drugs, there needs to be a system which ensures that all products are documented, manufactured, and released per written procedures and per the approved Design Documents. Just as with drugs, one needs a Quality Manual (corporate statement and discussion of the systems to ensure Quality), Standard Operating Procedures to cover systems like documentation, manufacture, material receiving and testing, product testing, and release.  Materials have to purchased and verified per specification.  Manufacturing facilities need to be maintained for cleanliness and environmental control.  Manufacturing equipment has to be purchased, qualified, and maintained.  Records have to be retained.  The individual Device History Records (batch records for manufacture) need to be created, approved, and executed.  The Device Master File, including the Design History, the Risk Management File, and all documents need to make the product, needs to be controlled and maintained.  Personnel need to be qualified and trained.  Variances like deviations and nonconformities need to be captured and assessed.  Improvements in the form of Corrective Actions and Preventive Actions need to be identified, investigated, and executed.

In short, everything that was done for Drugs is effectively also done for Medical Devices.

Tomorrow, we will discuss Intellectual Property, Regulatory Submissions, and Commercialization.