What Engineers Could Learn From Doctors

Comparing two occupations where process matters

Published: Wednesday, November 12, 2014 - 16:21

You might think that the medical and engineering professions would operate quite differently from each other. Yet, as we will see, not only are they similar, but there is a lot that the engineering profession could and should borrow from the medical profession.

So what is it that they have in common, when it comes to work processes and quality control?

Let’s assume that an engineer’s day on a typical shop floor starts with project management, e.g., project planning, data collection, identifying requirements, clarifying queries and assumptions, performing risk and root cause analyses, testing hypotheses, taking corrective actions, and performing follow-ups and reviews.

Let’s assume that a doctor’s day in a typical out-patient department starts with taking a patient’s case history, diagnosing the problem and eliciting answers from the patient, prescribing the requisite tests, reviewing the reports, identifying root causes, prescribing the medication, administering the test dose, and performing a follow-up or review.

Now let’s look at these processes, and their implied importance, first from the doctor’s point of view and then from the engineer’s perspective.

1. Taking the case history is the most important step toward reaching the right diagnosis. The more elaborate and comprehensive it is, the better. Because no two ailments are the same, a doctor might rely on experience, whereas an engineer might use a check sheet, since most of the projects of a similar category could be tackled in more or less the same way. This history file forms the basis for any further investigations. This is the first step in any project planning activity, i.e., requirements management and requirements development.

2. Eliciting answers from a patient is also important and is accomplished by asking probing questions (akin to the Kano analysis tool used by engineers and designers). This helps dispel doubts or assumptions that a doctor would have otherwise made. Leaving out this step, or doing a poor job of it, might mean that information significant to the diagnosis might be overlooked. The same situation occurs when engineers assume information without getting clarification or concurrence from the customer, and which might later on turn into a nonconformance.

For example, a doctor might ask for the patient’s family history to see if a problem is hereditary in nature or not. This is similar to an engineer understanding the project and its requirements, and determining through a feasibility analysis if the task can be carried out with or without the help of other stakeholders.

3. Based on the patient’s history, the doctor diagnoses the problem. The doctor tries to arrive at the cause (not the root cause) using the process of elimination. The data generated helps the doctor determine if the illness is due to each potential factor. If not, then the next factor is evaluated. This is akin to an engineer using the is/is not method, as shown below:

Factors A, B, C, etc. are from the case history

1. Once the probable causes are identified, then further tests are prescribed to identify the problem’s root cause. This is similar to an engineer validating causes by hypothesis testing.

2. Once the problem’s root cause is identified, the medicine is prescribed, and in some cases a test dose is administered to check for its side effects. This is similar to the solution-piloting stage to check its effectiveness; if it’s OK then full-scale deployment is carried out.

3. Once the results are found to be encouraging, the full dose of the prescribed medication is administered. This is akin to the regular or horizontal deployment followed by the engineer.

4. Once the patient is on the road to recovery, he’s scheduled for some regular follow-up visits. This is to ensure that the medication is effective, and that there are no side effects. This is the same as the control phase, where SPC, in the form of control charts and process capability studies, is used.

Engineers and doctors: Same process, different language

Thus, doctors and engineers follow roughly the same process. The only difference is that doctors don’t leave anything to chance and follow set protocols. Why is this? In the medical field, 2 + 2 does not always equal 4. This means doctors must view all cases objectively, unlike engineers, who assume that because most systems follow the rules of physics, there’s no need to double check. What engineers often forget is that although systems may follow the rules of physics, customers do not. It is the painstaking history-taking and relentless root cause analysis by doctors that engineers should emulate when dealing with customer requirements and problem solving.

Although many of the best practices followed by doctors have been derived from the engineering profession, the rigor with which they are implemented goes beyond what many engineers do. Here are some of the best practices followed by doctors that engineers ought to adopt.

1. Before the start of a surgery, a nurse wheels in a tray holding all the requisite instruments and drugs. Despite this being a routine exercise for the nurse, the doctor checks the drugs before administering them to make sure there are no mistakes.

This best practice ought to be followed by engineers by conducting stage inspections, especially where manual operations are involved. There are many instances where an operation has been missed, other operations are carried out, and ultimately the parts gets rejected either during the final inspection or at the customer’s end.

2. Another best practice is mandatory regular training for doctors and nurses about homonym drugs. Some hospitals call this a LASA (looks alike, sounds alike) program. An example of this problem is when a doctor asks for a drug and the nurse hears it incorrectly and hands over its homonym. If not cross-checked before administering, these drugs could cause harm.

A similar situation in engineering would be design reviews that take place over the phone. Due to language barriers and accent issues, there are many instances where wrong inputs have been considered, and by the time the mistake is realized, manufacturing has already begun. One countermeasure would be to follow up every call with an email confirming the discussion. Yet another area of concern would be the issue of raw materials that look alike and yet are different. An inspector might accept a part after a visual inspection because it looks similar to another part when in fact it isn’t the correct one.

3. Another practice is taking an instrument count before and after the surgery and just prior to closing up, to ensure that nothing is left inside the patient.

A parallel to this is verification with respect to the customer’s requirements. This would invariably get missed in most of the cases due to various inputs—e.g., emails, customer visits, telephone conferences, and reviews—occurring at various times during the project. Unless a robust system exists to capture all these points, it would be impossible to address all the customer’s requirements.

4. Seiton, which means “straighten or set in order,” is the second element of 5S and is consistently followed in hospitals.

For an engineering project, seiton is followed when an automated tool-retrieval system is used, but it should also be an essential part of even document control. Projects would be process-driven rather than person-dependent.

Following best practices across domains adds value. We’ve looked at some of the best practices that hospitals follow, and that can be adapted to manufacturing. On a lighter note, here’s one example of how a doctor’s and engineer’s job differ:

A mechanic was removing a cylinder head from the motor of a Dodge SRT-4 when he spotted a well-known cardiologist in his shop who was waiting for the service manager to take a look at his car. The mechanic shouted across the garage, “Hey, doc, want to take a look at this?”

The cardiologist, a bit surprised, walked over to where the mechanic was working on the SRT. The mechanic straightened up, wiped his hands on a rag, and said, “Look at this engine. I open its heart, take the valves out, repair any damage, and then put them back in, and when I finish, it works just like new. So how is it that I make $39,675 a year, and you get $1,695,759, when you and I are doing basically the same work?”

The cardiologist paused, smiled, and leaned over to whisper to the mechanic, “Try doing it with the engine running.”

About The Author

Gorur N. Sridhar

Gorur N. Sridhar is a mechanical engineer and a Six Sigma Master Black Belt. He has more than 24 years’ experience in manufacturing, quality, and design. His use of value engineering methods, process improvements, and failure analysis has been instrumental in obtaining substantial cost savings. Sridhar is an internal auditor for ISO 9001 and AS9100 quality systems, and has mentored more than 100 Six Sigma and kaizen projects. He has worked on implementing and sustaining level-five Capability Maturity Model Integration (CMMI) activities. Sridhar has contributed to environmental, health, safety systems, and community development programs where he resides in Bangalore, India.