This post discusses four aspects of systems engineering in the medical device field that may not be covered by academic coursework. It is based on a talk that I gave to system engineering students at the University of Utah on December 2, 2024.

Topic 1: Regulation

Medical devices are heavily regulated by government agencies. In the US, the Food and Drug Administration (FDA) regulates medical devices manufactured and/or sold in the country. Most other countries also regulate medical devices, the most important being the Medical Device Regulations (MDR) of the European Union and the National Medical Products Administration (NMPA) of China. I will focus on the FDA.

About the FDA

The FDA got its start back in 1906 with the passage of the Pure Food and Drug Act. The FDA is charged with ensuring the safety and efficacy of medical devices (among other duties).

It is widely regarded as one of the best regulatory agencies in the world. There are several reasons for its success.

• Its purpose (ensuring the safety and efficacy of medical devices) is not controversial.
• Determining if a device or medication is safe and effective requires a lot of specialized expertise.
• It has over a century of experience crafting and enforcing effective regulations.

Effective regulation requires balancing risks.

Risk of too little regulation. Back in the early 1960’s doctors started prescribing Thalidomide to treat morning sickness in pregnant women. Tragically, over 10,000 children in Europe, Australia and Japan were born with birth defects (missing limbs, extra toes, etc.) before Thalidomide was determined to be the cause. But not in the United States. The FDA didn’t approve Thalidomide despite industry pressure because there wasn’t enough proof that it was safe. See Thalidomide Scandal.

Risk of too much regulation. In 1988 activists from the organization ACT UP, angered that the FDA was delaying approval for drugs to treat AIDS, occupied FDA headquarters. Their demands resulted in reforms to the drug approval process. See Before Occupy: How AIDS Activists Seized Control of the FDA in 1988.

How the FDA approaches regulation

It Approves Medical Devices before they can be sold.

The FDA requires permission to market a medical device. If the device is “substantially equivalent” to a device already on the market, the company submits a 510(k) form to show that the new device is as safe and effective as the old one. If the device is new, the company goes through a more complicated “de novo” process where it must start from scratch to prove that the device is safe and effective.

It requires manufacturers to set up and follow a Quality Assurance (QA) System

The FDA regulates medical devices by allowing companies to establish their own Quality Assurance (QA) system to implement FDA requirements. The following components of a QA system are especially important.

CGMP (Current Good Manufacturing Practice). Companies must ensure that their QA system follows widely recognized current good manufacturing practices.

CAPA (Corrective and Preventive Action). Companies must collect information about problems, analyze each problem to determine a corrective action to fix the problem. The company must also determine the root cause of the problem and take action to prevent the occurrence of such problems in the future.

It conducts inspections to ensure compliance

The FDA inspects companies periodically to determine if the company’s QA system adequately implements the requirements of the FDA and to evaluate how well the company is conforming to their own quality system. After an audit, the FDA will issue a finding, including warnings of any issues that must be fixed. If the company does not adequately address the issues in the warning letter, the FDA can shut down production and negotiate a consent decree – a legal document that obligates the offending company to remediate the problems.

Implications for Systems Engineers

The FDA is a stakeholder that represents the interests of patients, who might otherwise not have a direct voice in the design of medical devices.

Failure Modes and Effects Analysis (FMEA). Highly important!

Verification and Validation of designs. Document test results. You need to be able to prove that your design works correctly (verification) and satisfies its purpose (validation).

CAPA drives design changes and decisions. Root causes of defects can be traced to suppliers, manufacturing problems, installation problems, design problems and user interface problems. These problems should be fixed or mitigated in subsequent product releases.

Note: About 20 years ago, the FDA noticed that many problems reported as caused by operator error were actually caused by a confusing or difficult user interface. It now requires that user interface design be considered when designing a medical device.

What can go wrong – a true story

Timeline

This timeline is based on an article GE Agrees to fix X-ray systems’ manufacturing deficiencies published on the Reliable.com website.

2004: GE Healthcare, the company I worked for, had just released a hot new product: the OEC 9900 C-Arm X-ray machine. Management’s top priority was to make and ship as many of these machines as quickly as possible.

November 15, 2004: The FDA arrives to inspect our facility. They stay for two weeks and find lots of problems.

March 31, 2005: The FDA sends us a warning letter listing several CGMP and CAPA deficiencies. Management hired a consultant to advise us on how to fix the problems. I was not impressed with him. He sent out emails with misspelled words and, occasionally, grammatical errors. I was snobby enough to think that this was not a good look for an expert on product quality assurance systems! Worse yet, he seemed focused on cosmetic fixes that wouldn’t disrupt our production schedule rather than on systemic fixes that would really address the FDA’s concerns.

July 31, 2006: The FDA returned for another inspection to see if we had adequately addressed the issues documented in their warning letter. They stayed 4 weeks. They were so unimpressed with our refurbished CGMP and CAPA processes that they closed down the factory and had us sign a consent decree.

January 12, 2007: Our new managers sign the consent decree. Our factory is to be shut down until the FDA is satisfied that our processes are in compliance with the law.

Results

• Several very high-level managers were fired, down to the level of the manager of engineering.
• People who had falsified manufacturing records were also fired.
• The factory was shut down for 16 months, costing us approximately $200M in lost revenue.
• The engineering staff spent those 16 months remediating the QA system. Not nearly as much fun as designing systems! In fact, it was the most tedious and dismal period of my entire career.
• We lost market share. We had very loyal customers, but some customers couldn’t wait for over a year and bought competitors’ systems instead.

Conclusions

I don’t think we were selling unsafe products, but I do believe that if the FDA had NOT inspected us when they did, management would have been tempted to take more shortcuts that would eventually have compromised product safety.

If you work in the medical devices field, you must be comfortable with being regulated. You should respect the FDA (and other regulatory bodies) not only because they can punish you, but because they are the voice of the most important stakeholders – the patients who are made healthy again because of our devices.

One could say that this disaster was ultimately caused by a lack of ethics.

Topic #2: Ethics

Like other professions, Systems Engineering has a code of ethics. INCOSE Code of Ethics. It covers the basics in a general way, but the Project Management Institute (PMI) did a much better job. The PMI Code of Ethics has the following advantages:

• PMI studied codes of ethics from similar non-profit organizations from all over the world to determine best practices for codes of ethics.
• PMI obtained input from working program managers all over the world.
• The code of ethics is organized by four values recognized as essential to the ethical practice of program management: responsibility, respect, fairness and honesty.
• Each value is elaborated with a description, a list of aspirational standards and a list of mandatory standards.
• PMI also developed tools to help program managers think through ethical decisions, e.g. Ethical Decision-Making Framework.

Topic #3: Iterative Improvement

Very few products are completely new. Most are based on previous products, or are a variation of an existing product.

Pattern Based Systems Engineering focuses on identifying and modeling patterns common to a set of designs which can support either iterations of one product or a family of products. When a new iteration of a product or a new device in a family of products is needed, the pattern is used to model the common parts and configured or tailored to meet the parts that are unique to the iteration or family.

Pattern Based Systems Engineering is an excellent approach for making iterative improvement easier and for supporting families of similar products.

We never used it.

Note that the FDA approval process encourages companies to make iterative improvements because the 510(k) approval process is easier than the De Novo process.

See Recommended Reading: A Pattern Language by Christopher Alexander.

Topic #4: Communication

First, another true story! Mr. Gilbert vs. Mrs. Silcox.

Mr. Gilbert was my high school calculus teacher. Mrs. Silcox was my high school AP English teacher. They were both superb teachers. They maintained a friendly rivalry. One day a student asked Mr. Gilbert “Mrs. Silcox says that English is the most important subject. What do you think is most important, Math or English?” Somewhat to our surprise, he immediately replied “English”. He went on to explain “If you can’t communicate with other people, it doesn’t matter how good your ideas are.”

With other engineers

Become fluent in your own language, whether it be SysML or Java! Make your models as clear as possible. Put a lot of thought into the content but be aware of the presentation too. For models – layout. For programs – white space and comments.

With Users

Learn how to speak their language!

Example: Our users were medical professionals specialized in medical imaging. We needed to understand enough of their medical language to write stakeholder requirements and validation procedures.

For written communication, consider taking a course in technical writing.

For oral communication, recall what you may have learned in speech, debate or theater.

Learn how to present data in meaningful ways: charts, graphs.

With Managers

(Tell story of Weber State SE project presentations)

Tell a story! Avoid technical language unless they are comfortable with it.

Use empathy to understand what is important to them. Will a new technology decrease development time, lower costs, allow access to a new market? Is it something that they can brag about to their manager?