Is MIS MIA?

Are today’s surgical robots enabling Minimally Invasive Surgery or just Minimally Invasive Access to surgery?

I’ve been giving the topic of this post a lot of thought recently. Throughout my career in medical device, I have always worked on designing products for Minimally Invasive Surgery. For the last 14+ years I have been focused on the surgical robotics industry. Surgical robotics, thus far, can be observed as a rather large external robot that remotely controls small instruments in the body. These small instruments fit through small cannulas in the body wall. Cannula sizes usually range from 5 mm - 14mm+ limited by the size of the instruments passing through them. This is consistent for both laparoscopic and robotic surgery. Once the instruments are in the body, the surgeon can complete the procedure as they would with their own to hands albeit controlling the smaller instruments remotely via the robotic controls. The surgery itself is performed in the same or a very comparable way as it would be open.

The reduction of incision size reduces the disruption to the body wall. Instead of one large 8cm incision, the patient now has 3-6 small incisions. Robotics surgery allows other benefits, such as the ability to enhance the surgical view through magnification, reduce the tremor of the movement of the hands, and potentially work in smaller spaces than a human hand can. And again, the reduction in the incision size allows all of this work to be performed via small incision. But is this enough to fill the definition of Minimally Invasive Surgery (MIS). I would say, maybe not. Maybe minimally invasive surgery is still yet to be defined. Maybe today’s MIS is MIA?

MIA? Yes, maybe MIS today is really Minimally Invasive Access (MIA). And if this is true then what is the true definition of MIS surgery?

Every touch to tissue by a foreign body triggers the body to respond. Grab bowel with a grasper made for manipulating bowel and it can still turn purple. Grab the bowel too hard and you may damage the surface beyond what the human eye can see. This damage can later lead to inflammation, tissue decay, and sepsis if left undiscovered. Drive needles through the wall of a 1mm vessel for re-attachment. If you drive the needle in the wrong direction and with too much sheer force the wall will tear and the anastomosed vessel will leak. Every touch, every interruption of the body by a foreign element is noticed and reacted to.

Every cancer procedure requires a margin of tissue to be removed around the tumor. This margin is not visible to the human eye. You can take more tissue but if the cancer re-occurs or if it is in a confined space, you may excise too much. Even access of the anterior lumbar spine requires retraction of all the organs that are anterior to it. Pressure on these organs during long periods of time can cause reduced blood flow, nerve damage, and increase potential for injury.

Today’s medical devices enable wonderful things and take surgical care beyond where it has ever been before. There are always risks and potential for complications in the field of medicine. The ultimate end goal is that the results of using the device outweigh the risks of doing nothing at all. But are we miss-using the term MIS for today’s products? Instead of minimally invasive surgery should we be calling it minimally invasive access?

Is MIS really MIA? And if true MIS is missing in action, then what products might we be able to build for true MIS surgery?

Reflection

I realized that today marks one year since I left industry. In speaking with friends and colleagues I often get asked “So, how did you decide to do this? You are so brave. How’s it going?”

Well……

I find with each year I strive to find new opportunities to grow. In the last 5 years that growth has been exponential with the steepest climb being this past year.

41 years old, 17 of those years in school, 17 years in industry (all in med device and most of the time in the fast paced bay area), 3 months to build up my consulting business, 6 months to decompress (maybe still decompressing….), 1 year as a successful independent consultant.

So what have I been up to?

In October of 2020, my husband and I moved our family cross country. This was heavily influenced by learning how to live with Covid and this “new normal”. Because of this I am able to spending more quality time through out the day with my 3 kids, husband, and dog. Having the ability to BE TRUELY AVAILABLE is priceless.

In November I recognized the opportunity to start something on my own, K2A2consulting. I have loved every minute. It has been quite invigorating to experience the roller coaster feeling of the day to day. Experiencing the stress and accomplishment of putting something out there for the first time solo was a great experience. It enabled me to live the joy and thrill of the successes that come with not just working hard, but being the sole owner of that work. I still miss the team environment, but through my clients I have been able to share joy in their successes, as well as shared learnings when things are less successful.

I’ve worked with small and large company entities, as well as individuals and academia. I’ve been able to build Domestic and International business relationships. I’ve mentored and been a mentee, sometimes in the same meeting.

In conclusion the move for me and my family has been net positive. In the last year I have improved my health. I became hyper focused on activities that I love such as gardening, hiking, and climbing. I learned to play chess. I signed up as a volunteer for our local rescue team. And best of all, I spent more time with my family.

I’m looking forward to continuing on with my new adventure with my eye constantly on the horizon for what’s next! Never stop learning, never stop growing, and never stop doing things that you love with people you love!

Workflow Mindset in a Digitally Driven World

In 2019 I gave a talk to a group of engineers and surgeons at USCF innovations team entitled “Workflow Mindset in a Fast Paced Digital World”. The goal of this talk was to begin introducing engineers and surgical teams to the importance of understanding each other’s daily workflow in the design of digitally enabled platforms. This topic is even more important today during the pandemic; where remote work and learning are a necessity to move forward.

The premise of the talk is the following.

Technology is exponentially changing how we learn, work and what we can do.

“Currently our computing power and sensor capabilities are starting to quantify cellular and molecular structures easily and cheaply, and our tools are able to manipulate molecules. Today small companies are creating the paradigm changes that were the domain of larger corporations, universities and government agencies” (http://www.theemergingfuture.com/)”

Developing new technology for the Medical industry can take significant time. There are strict rules and regulations that must be followed. You can build your teams with the top talent, bring in top medical advisors, and define smart strategies to try to speed things to market. The pace car is always quality, performance and safety. So, how do we speed up the process without taking on unnecessary risk?

One Answer: By shortening needs finding timelines for iterative designs.

Once a device is launched, feedback from the field is often collected too inefficiently to be effective. The information does not make it back to the designers fast enough. Product designers are busy working on the next product. Medical professionals are busy saving lives.

Your sales, service, marketing, or clinical engineering team likely collect product feedback as part of their role. But they are not the ones using the device first hand. Attending 100’s of cases in person takes a very long time, as does interpreting the data. And there is always conscious and unconscious bias in the loop. I am in no way talking myself and my colleagues out of a job! I’m just merely commenting that in today’s world we may be underutilizing a powerful tool.

What if we use data platforms to help?

Many companies are partnering with data platform companies or coming up with their own homegrown versions to collect data. But I would argue that just like good design, you cannot add these tools on after the fact. Collecting the data is only part of the process. The data you collect, how it is collected, how it is processed and ultimately how it is understood and used is what counts. Whether third party or homegrown, digital platforms need to be an integral part of your long term product vision and likely part of the product itself. And they need to fit into the workflow of not only medical practice, but also product design.

So I will leave you with following to think about:

Are we as product designers collecting and processing data smartly? Have we as businesses thought through our end to end strategies far enough to capture this crucial part of our product vision? Are we as customers open to sharing data with companies about our medical practice to make the right products? And ultimately do we understand the workflow of each other’s worlds enough to know what data is valuable and what data is just more numbers? Can we create a process, a creative space, and a combination of the workflows of our two worlds, Industry and Patient care, where we can co-create?

If we can, we may be able to orchestrate the perfect process for iterative design. A process that is not only faster, but co-defined to make better and more innovative products.

If you are interested in talking more about this topic contact: k2a2consulting@gmail.com

Customer requirements basics

One of the more challenging aspects of medical device design is documentation. Documentation serves several purposes including but not limited to archival of design history, presentation of work to notified bodies, customer facing materials, and others. Just like your product you want to understand the purpose that these documents serve and the needs of the user who will be reviewing them.

Today I want to focus on a specific document that can be more difficult to create than you might think. The customer requirement document, sometimes called a product requirement document.

Per the FDA one of the key documents in a submission is the customer requirements document. This shows the FDA that you have done your homework in understanding the needs of any and all customers that will use your product. It sets the stage for your design work and is the foundation for your technical specifications.

Here are some of my suggested Customer requirements dos and don’ts:

1. customer requirements should represent the needs of your customers and the environment(s) that the product will be used in.

2. customer requirements should not dictate design but should set a framework to design within

3. customer requirements should be objective

4. customer requirements should be testable

5. customer requirements should NOT include items that are not required for the base use of your product

6. customer requirements should encompass any items that need to be validated for intended use of your product

Let’s dive in a bit more on each of these:

1. customer requirements should represent the needs of your customers and the environment(s) that the product will be used in

This one may seem obvious as it is the definition of the customer requirements document. In order to design a new product, you need to do the work to understand the customer, the environment, and the business path of your product. I recommend doing a thorough workflow assessment as it sets the foundation for your design work and many of the documents you will need to create. If you would like to learn more about a workflow assessment please reach out! It is one of my favorite methods to teach.

2. customer requirements should not dictate design but should set a framework to design within

If you tell the engineering team exactly what to build then creative solutions and innovation can be lost. Customer requirements should capture the need of the user in just enough detail to frame the design but not over constrain it.

For example, if you are designing a new innovative smart car one of your requirements may be “The customer must be to take control of the care at anytime”. An example of over-constraining this requirement might look like, “The customer must have a red button to push to stop the car at anytime”. The requirement of “The customer must be to take control of the care at anytime” is speaking to a safety issue. How the safety issue is solved is the innovation. A red button may be the right design, but unless a red button is dictated by a standard it may be an over-constraint to the requirement.

3. customer requirements should be measurable & 4. customer requirements should be testable & 6. customer requirements should encompass any items that need to be validated for intended use of your product

These are all important ones and a good way to gauge if you have written your customer requirement correctly. One way to do this is to write your requirement and then write how you would test this requirement. If the test is too subjective, too rigorous, not testable, or does not result in testing to your intended use, then the requirement needs to be revised. These should be checked throughout the revision process of your document to insure that the intent of these is not lost.

5. customer requirements should NOT include items that are not required for the base use of your product

This one can be one of the toughest to do. Prior to developing customer requirements, typically a market and customers’ needs assessments exercise is performed. This work is summarized in what is often called a business or marketing requirements document. The business requirement document discusses not only what the customer needs but also IF a product were developed how the market would respond. In my opinion this document is critical to the business. It is the foundation of setting intended use. It is also useful for launch planning of the product as it gauges overall customer acceptance and success. It is easy to think that this business requirement document is the same as your customer requirement document, but it serves a different purpose and is read by a different audience. I would recommend that you separate the two documents.

Again as you are approaching the end of your design and unnecessary requirements may creep in. These are requirements that I call “emotional requirements”. The product must do this because I really strongly feel that it should. Watch out for these, If the requirement is not part of the baseline of your product then it may not be necessary. The key questions to ask are: Is it a true requirement of the device? Does it affect the intended use and/or safety of the device? Would you halt the submission of the device not meeting the requirement? If the answer is NO, then it is not a customer requirement.

Now this one does get a bit tricky. Because the business side may come back and say that this is a requirement to launch the product and for the overall success in the market. So, do you take the requirement out, validate and submit the product later? That depends on your strategy and launch plan. IF the addition of your feature could affect the safety, efficacy or outcome as defined by your submission then you will need to verify/validate this feature now or in the future prior to use of the feature in the field.

If you are interested in talking more about this topic contact: k2a2consulting@gmail.com