The woman at the ticket counter casually mentioned the plane was a bit late. I went to the gate and after some time the plane approached. I marveled at the turbine blades as they slowly and smoothly spun to a standstill. What kind of tolerances are needed to have these turbines spin so smoothly at such speeds and temperatures? Soon mechanics were lifting the engine cowlings on the right engine. Hmm, I don’t see them doing anything on the left. My colleague and I watched as several mechanics climbed around the engine, cleaning, inspecting, cleaning, inspecting. The voice was heard on the PA that the flight was delayed some more. I looked around the gate’s seating area and everyone simply went back to their phones, books or conversations. There were several technicians and what appeared to be a Quality Assurance supervisor surrounding the engine. More of the engine cowling went up and soon a truck was tactfully put in front of the engine to obscure my view. Again, everyone else waiting for the plane at the gate was oblivious and unconcerned. Jumping to the point, eventually, we loaded onto the plane and the captain informed us (as I suspected) the plane experienced a bird strike to the engine. There was more paperwork to complete, and we would be leaving soon. How much cleaning was required to get the blades running smoothly? Did any turbine blades get bent; bearings get mucked up? Why did no one else in the waiting area seem to care? The reason is the airline industry has established public trust. No one doubts that safety is number one. We all trusted that the plane was fit to fly again and loaded our bodies into its belly for the ride. (Note: the FAA, associated regulations, and the airline industry are not foolproof – anytime people and processes are involved there is an opportunity for lapses like the 737 MAX and in this case, much was required to rebuild “trust” for mishaps with people/process.)
The Medical Device Industry likewise strives to maintain public trust. Few would ask the hospital, “when was that diagnostic imaging device last serviced?” “How do I know this monitor you are hooking me up to won’t injure me?” The medical device industry utilizes regulations and standards to guide the industry through realizing safe and effective products. Let’s take a moment to walk through a very specific example of how safety is realized and doesn’t just happen. There are many more safety aspects to our hypothetical product, but we will only be looking at one. Note, the same can apply to effectiveness but in this example, we will focus on one safety element.
Medical Device companies live in a regulated world and are required to have a Quality Management System (QMS). Within the QMS is an area-specific to Product Design and Development (21 CFR 820.30 and ISO 13485 7.3) referred to simply as design controls. Design controls provide a rational methodical means of putting into practice good engineering principles and risk management (EN/ISO 14971). All medical device risks and benefits are assessed with the goal to have the benefits outweigh the risks. A perfectly safe product with no benefits (ineffective) is of no use. Likewise, a perfectly effective product that always harms the patient or user is of no use. The key is to find the optimal balance, maximum effectiveness, minimum risk. Design controls with risk assessment are intended to guide the organization in achieving this balance.
Product development design controls start with user needs. As we are talking about safety, I will say I have not seen a user need that stated that the product needed to be safe. Safety is generally assumed at this level, just as we have all come to expect with airplanes. So, if safety is assumed where and how does it get rigorously addressed? Let’s examine the following example:
Suppose our product is to be a diagnostic instrument for assessing coronary artery disease. And suppose we want to sell it in the USA and the EU. Again, in our example, we will only focus on one narrow aspect of a user need that inherently has a significant safety element. Therefore, the conceptual relevant user need at a high level is: “Physicians need a tool to help assess the significance of a coronary lesion” and we want to market this product in the USA.
Note, user needs tend to be more qualitative. They should be written so they can be validated. The user need is generally a “What we want” document in user terms. Once the user needs have been agreed to and the product development is agreed to proceed, the next step is for the engineering team to translate the user need into a product requirement. This step involves taking the higher level wants of the user and translating them into more quantifiable requirements. Moreover, this is where the nature of the company, its domain knowledge, and technological capabilities start to come in. For example, there may be a few ways to assess coronary lesions; external image analysis, internal image analysis, internal physiological measurements, etc.
The company will decide an approach based on their “know-how”. For our example, we decide we can best assess the clinical significance of a coronary lesion using our company’s intravascular technology. It has good clinical evidence and aligns with our company’s core competencies. Since we are only focusing on one specific safety aspect for this blog, we will only highlight a narrow list in the design decomposition. Our product will use a disposable sterile element connected to an instrument to measure physiological parameters within the coronary artery. Since it uses an electrical-based instrument, and it is to be sold in the USA & the EU the product must meet EN/IEC 60601-1 Electrical Safety.
The product requirement now has taken the Assess Coronary Lesion in the user need to a more specific intravascular measurement. (I am purposely being vague, in general, the product requirement would specify what parameter (pressure, flow, temperature, etc.) is being measured, what is being calculated, what the performance, resolution, accuracy, etc. are to be.) The product requirement will also call out the relevant standards that are to be met in order to be marketed in the user need’s geographies and what is required by the FDA product code and the MDR.
Often at this stage, a product architecture is being generated in parallel. It helps inform the product requirement. It helps the review process (BTW: document design and phase reviews are held throughout the process) with those (i.e. Marketing) that generated the user need to see if it aligns with their vision (form follows function etc.) This architecture calls out the various components and how the design is partitioned between hardware, software, mechanical and disposable elements. This is a “How” document i.e., how the product is to be realized. These two documents also set up the product’s documentation structure/organization – what I like to call topology (software related, hardware related, RA, V&V etc.)
Given we now have a product requirement and an initial plan on product architecture, we should conduct our initial hazard analysis. Hazard analyses go through the concept of the product and ask what possible hazards the product can present to a patient and/or a user. The EN/ISO 14971 standard contains a list of probing questions on potential hazards. A hazard is something that can cause harm to the patient and/or user. In our example, we have an electronic instrument connected to a disposable element that is measuring inside a coronary vessel of the heart. Among others, this product has the hazard of electrical shock. Moreover, if we don’t do anything, this electrical shock could occur right at the heart. Any electricity is dangerous to heart function so having an electrical element right next to the heart creates an even more concerning situation and can cause death. Death is the highest level of harm and despite how well we mitigate it, this hazard needs special attention throughout the product’s lifecycle.
The EN/IEC 60601-1 standard has specific requirements for electricity near the heart.
The patient applied part, in this case, needs to have electrical isolation at a level called cardiac floating. Cardiac floating means the amount of tolerable leakage current is very small. This is the most rigorous level of isolation. Moreover, since our device could be positioned in the heart and connected to the instrument under a situation whereby the patient experiences a heart attack requiring a defibrillator applied, the patient applied part needs to be defibrillation proof! (No guarantees the device will get disconnected during such an emergency.) This level of protection is given the symbol. The cardioid with the paddle symbol needs to be applied to inputs on the system that meet this level of isolation protection. The leakage threshold protects the patient from the extraneous currents that can disrupt the heart. The high voltage isolation protects the patient and the user (high voltage of defibrillation paddles, zapping a nurse who happens to be touching the instrument when the paddles were applied to the patient).
Ok, so now the part of the architecture that is the patient applied part will mitigate the electrical shock hazard by being designed to meet the cardiac floating, defibrillation proof requirements of EN/IEC 60601-1.
The above are all considered design inputs in the design control process. Next comes design output. Design output is the actual design artifacts which include specifications, drawings, schematics, software code, etc.
In our example, the safety aspect of the patient applied part near the heart of the patient will need to be realized at that applied part connection. The lower-level specification therefore for this element will now call out the level of leakage current and isolation voltage to achieve this. These current and voltages are hard numbers (uA, Volts) with definite limits.
Now we put together the schematic and pick the parts. One of the parts needs to transfer the signals from the cardiac floating side to the non-isolated side. This is a “critical to safety” component. If it were to fail in the wrong way, it could cause significant harm.
We picked one that meets isolation requirements including creepage and it will have its own component specification within our organization to help manage its criticality.
The physical layout of the circuit board includes this critical part but the PCA itself must meet spacing requirements (creepage - see red arrow) between the non-isolated and the isolated (cardiac floating) side. Hence the component and the circuit board both provide the necessary isolation and need to be controlled. Often, we may consider conformal coating in case fluids were to ever splash on the circuit board (mop man!).
We have now implemented mitigation to electrical shock to the heart intent to meet the standards established for safe operation in or near the heart. We need to formally verify that it indeed meets the standards, and we need to assure we always build our product with these mitigations fully intact.
Verification: After initial testing, formal testing is performed on design-controlled “Pre-Frozen” traceable hardware during verification. For our design, functionality and basic isolation are tested at the low-level circuit board level. A formal report tracing to the lower-level specification captures this. We next combine the lower-level circuit board with the rest of the product at system-level testing. System-level testing generally maps to the product requirements. (Note I’m not including software in this example, perhaps a walk-through next time.)
It is at the system level that we go out to a Nationally Recognized Testing Lab (NRTL) to conduct Electrical Safety Testing. It is here that the cardiac floating Isolation is designed type tested. The unit is soaked in high humidity for an extended period and then the leakage current is measured to be sure it meets cardiac floating. Additionally, defibrillation level voltages are applied across the isolation barrier and tested for breakdowns. These successful results serve as mitigations in our design FMEA. They reduce the probability of the hazard –the level of harm cannot be reduced!
This design type testing alone is not enough. The isolation IC is now considered a “critical component” and must be managed accordingly. The company’s QMS purchasing practices (including the classification of the vendor, vendor management & review), plus incoming inspection and manufacturing processes are designed to address the criticality of this component and the circuit board. An isolation diagram shows NRTL’s, service, and production where the critical safety barriers are located. In manufacturing the circuit board, Hipot testing during production is performed and the results are captured in the device history record (DHR) for the product being built. Note it is not tested at the same level in production as type testing as this would stress the part. Also, the Operator and Service Manuals include recommended retesting by preventive maintenance in the field and after any repairs. Most US hospitals want to see that the product is part of an NRTL program (this is your UL, TUV, etc. marks on the product label). The hospital is advised by the manufacturer how often this isolation should be checked (every month, 6 months, annually). With respect to NRTL’s, besides the initial safety/EMC testing they provide, they also audit on-going production of the device. They check the safety-critical parts are being managed correctly (no changes that have not been vetted through additional testing or qualification). NRTL’s audit that production safety test equipment is calibrated and being used correctly etc.
Phew, all this is a byproduct of picking a particular means of satisfying a user's need which assumes safety. And this was just one aspect of the product. From the regulations regarding QMS to design controls to standards for risk assessment and verification and validation studies, Qserve can help with all aspects across the design and development process to help assure safety and efficacy. We’ve all heard the adage; safety is no accident. With Medical Devices, it is rigorously focused on commensurate with the risks. All components play together to instill public trust so patients and users can remain unconcerned (as with a delayed flight) about medical devices that touch their and their loved one’s lives.