Dale Feldman*
Department of Biomedical Engineering, University of Alabama, USA
*Corresponding author:Dale Feldman, Department of Biomedical Engineering, University of Alabama at Birmingham, Birmingham, AL 35294, USA
Submission: August 18, 2025; Published: September 05, 2025
ISSN 2637-8078Volume7 Issue 4
Part of the primary motto of this journal is to provide engineering approaches to enhance the power of the scientific method. The engineering approach is essentially the engineering design process. The scientific method is similar but is hypothesis driven vs. design driven. The issue is too often a paper written by a bioengineer is not that different from one written by a bioscientist. It boils down to whether the engineering design process is used or not. In reality, even bioscience papers that claim a better treatment should use the engineering design process. For most medical treatments the actual problem is typically inadequate return of a specific amount of function in a given timeframe. Too often the paper is about proving a statistically significant improvement of something that can affect the actual problem (proving the hypothesis) without showing how this change is enough to allow solving the problem. The paper, however, will then claim that the change shown will lead to a better clinical result and is therefore preferred over the current treatment and should be used or claiming a pre-clinical proof of concept to allow moving on to a clinical trial. If it goes to a clinical trial, it most likely will prove the hypothesis, improve clinical outcome, but not likely solve the actual problem.
Part of the primary motto of this journal is to provide engineering approaches to enhance the power of the scientific method. The engineering approach is essentially the engineering design process. The scientific method is similar but is hypothesis driven vs. design driven. In the scientific method a hypothesis is generated as a potential answer to an important question. An experiment is tested to prove or disprove the hypotheses. The results of the experiment are discussed in the context of the original question and whether the hypothesis was proven or not. The results are also compared to other studies looking at the same or similar questions. Therefore, the study is looked at whether it follows from previous studies, what are the ramifications of the results related to the original question and what needs to be examined next; further test the hypothesis or test a different hypothesis. Again, the design process is similar, but different in some important ways. Instead of a question there is a problem or need. Instead of a hypothesis there is a design constraint(s) of what the solution has to be able to do. Experiments are done to determine if the solution meets the design constraint(s), which is similar to testing a hypothesis; in fact, a design constraint can be written as a hypothesis.
The big difference is that design constraints are quantitative and hypotheses are typically not. Hypotheses are typically proven or not proven based on statistics and whether something leads to a statistically significant difference. However, a statistical difference does not mean the difference is significant enough to matter; with hypotheses not normally quantifying how big a difference is required.
However, too often a paper written by a bioengineer is not that different from one written by a bioscientist. It boils down to whether the engineering design process is used ornot. Although this is true in many areas of bioengineering, I will restrict it to the area of healing-regenerative medicine and tissue engineering with the goal of picking a treatment to eventually be commercialized. Why does this happen? Engineers do pretty well if they are designing something vs. doing a research project. Part of this is probably funding, since it is difficult to get funding for applied projects or ones to be commercialized. Even if it is an SBIR proposal the projects tend to still be hypothesis driven. Even when they require a commercialization section, they still tend to be hypothesis driven vs. design driven and do not really do a proof of concept to show that their treatment solves a problem not currently solved.
They typically will give a problem, since that is required; however not that their solution solves the problem, but is statistically better than what we do currently. Therefore, most PhD projects or bioengineering conference presentations (which usually require funding) are hypothesis driven. This feeds into the idea that we need to continually improve things and tend to obsess over whether we made the best choice-I call this scientific method thinking; essentially thinking that statistically better means clinically better.
In reality, even bioscience papers that claim a better treatment should use the engineering design process. A good way to do this is by building a design constraint hierarchy. The top is the Level 1 problem and what an acceptable solution should do. Each lower Level is what causes the Level above it. There are “problems” with healing at multiple levels, but only the ones at complete healing in a human model matter, if the claim is to be proven. The other problems are at the mechanism level and need to be correlated to the clinical Level (the Level 1 problem). A statistical change at a mechanism Level does not mean it makes a clinical difference at Level 1. Also, at each Level there are acceptable values (design constraints). Improvement is only useful if it solves a problem not solved by current treatments at Level 1.
A possible example of a design constraint hierarchy for a degradable/regenerative scaffold for damaged tissue will help illustrate this:
Level 1: Reduce function for a specific tissue below the acceptable value(s) (with the acceptable value[s] given at least one timeframe).
Level 2: What causes the Level 1 problem? Probably longer healing time leading to complications or incomplete healing. The acceptable healing time and/or completeness of healing needed to meet Level 1 has to be determined.
Level 3 and below are the bioprocesses that are needed to meet Level 2 and therefore Level 1.
In tissue engineering/regenerative medicine the Level 1 problem is typically inadequate return of a specific amount of function in a given timeframe. Unfortunately, too often even from engineers the goal is duplication of structure not recovery of function. I went to a Bioengineering conference recently where the panel discussion was “Is it better to regenerate in vitro or in vivo”. Essentially asking is it better to have a graft substitute or a degradable/regenerative scaffold. This misses the point since it is about function not structure. Also, we are not very good at making graft substitutes. In addition, the closer to native tissue structure does not mean closer to normal function. In fact, 99% structure recovery could be only 50% or less of function recovery. Which is why the degradable/regenerative scaffold was chosen in this example. Too often the paper is about proving a statistically significant improvement at Level 3 or below (typically not even in the actual clinical case), without showing how this change is enough to allow meeting the Level 1 requirements that are not currently being met (the actual problem).
The paper will then claim that the change in Level 3 means that this new treatment is preferred over the current treatment and should be used or claiming a pre-clinical proof of concept to allow moving on to a clinical trial. The logic fallacy is that there are usually many Level 1 design constraints (acceptable values). To justify the need for the study there has to be at least one that is not currently being met (the problem). The proposed treatment has to not only meet the Level 1 design constraint currently not being met, but still meet all the other design constraints. An improvement in a lower-level bioprocess does not guarantee that it meets any of the design constraints that are currently not being met or all of the ones that are being met.
Man-made global warming is a good example of what happens when you don’t use the design hierarchy to look at solutions. First, the Level 1 problem is not really quantified nor what a successful solution would need to do and obviously not why spending $T would solve the problem.
The hierarchy is probably something like:
Level 1: People (and polar bears) are dying at too high a rate (now or in the future related to man-made global warming).
Level 2: What causes this problem? The claim is: Increases in extreme climate change, rising sea levels, lack of natural resources, etc.
Level 3: What causes Level 2? The claim is: Increased global temperature.
Level 4: What causes Level 3? The claim is: Increased greenhouse effect due to an increase in CO2.
Level 5: What causes Level 4? The claim is: Increase due to manmade CO2.
Besides, a number of controversies related to what a greenhouse gas does, whether CO2 is important relative to the main greenhouse gas (water vapor), what fraction the man-made component is etc, the debate hinges around whether problems are happening at Level 3 and above (now or at some later date), first, we need to know what the acceptable values are at each level and whether they are not being met now or in the future. The only real acceptable value given is for CO2,/ (without much evidence to support this is actually a tipping point). The solution is to reduce Level 5 the man-made component. The arguments are given that each Level is increasing and caused primarily by the Level below (this is controversial except Level 5). We are not given any consistent desired values for any of the Levels above Level 5, nor is it proven that changes in the lower Level are enough to cause sufficient changes in the Level above all the way to the Level 1 problem (which is not actually stated). Why should we spend $T to reduce Level 5 when its effect on the Level 1 problem is not really known. The models used have not been very predictive over the time frame they have been used. Even if one claims to show a potential Level 1 problem in 50 years, they do not show that reducing Level 5 will solve the problem.
© 2025 Dale Feldman, This is an open access article distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and build upon your work non-commercially.