PLAN FOR IMPROVISATION

Very few people in the software development community have issues with maintaining good attention to the details. However, I bet those who live in the regulated software community view the “normal” software world as quite sloppy. Attention to detail is a matter of life and death for a medical device. Because of this, the entire software community does a good job maintaining checks and balances. I have three suggestions that will make a tremendous difference when you start a regulated project or when you finally get near to releasing your medical device. Photo by: myguerrilla #1 Plan to get audited It is a good bet you are going to get audited sooner or later. Its even possible to get a product out into the market only to have it get audited a second time. An FDA auditor will keep asking “why do you think that works?” type questions and continue to drill down until they find something or are satisfied there is nothing to find. If they find something you are going to get a warning lett

Its not what you wear. Its how you wear it. Photo by country_boy_shane I have to thank Tavi Scandiff-Pirvu for coining this expression as it relates to regulated software development. As long as you use industry standard methods, the FDA allows you to determine the rules that you are going to follow. If you want to have 15 exhaustive steps in order to build each piece of functionality the FDA will say, “Go do it. Just document each step as you go.” If you can reach the same quality in only 7 steps the FDA will say, “Go do it. Just document each step as you go. The FDA isn’t going to test your software in detail. They are going to test your process to ensure that you did what you said you were going to do. This may appear that the FDA is interested in the product but only the process! But, the FDA also wants to see (via documentation) that you built the product features you claimed you had. The criminally minded will see an opportunity to claim they did more than they actually did vi

Testing is a crucial part of all software development. If you don't believe this you are likely just starting your career or haven't had to support an application in production with users.  It becomes doubly important in a regulated environment. This is because testing for regulated software serves multiple purposes. There is the usual software product development reasons to consider (i.e. professional integrity and no one wants a bug in production). But it is also because the FDA, in particular, wants to make sure you are performing validation and verification of the software. Verification (Was the product built right?) Validation (Was the right product built?) While I acknowledge there are a number of useful and important ways to describe software testing techniques, I strive to keep things simple, and understandable, by the whole team. To that end, I split testing into two tracts:  Functional  and  Technical . Functional  is about bring business value to the stakeholders - t

Lets be honest: Checklists aren't the most exciting topic to blog about. However, in the context of regulation they become interesting. Everybody loves checklists and hates them at the same time. It's really easy to make them and just as easy to forget to use them. Later on, after the emergency and/or reason they were created has subsided, using the checklists becomes a ceremony - something that must be done rather than a helpful tool. Checklist also may foster an anti-change mentality and allow people to cruise through their jobs without think about them. This is why we all hate them. Photo By: adesigna All feelings about checklist aside: If each detail of your project's history is going to be scrutinized, checklists are essential. On a regulated project their are a lot of steps to follow. It's hard to remember each step of each procedure followed. Its really easy to finish delivering a feature then forget to check the software verification report in to your documen

The FDA states that a medical device is a product that is used for medical purposes in patients, in diagnosis, therapy, or surgery. As opposed to a pharmaceuticals, who use the body's metabolism, medical devices act mechanically or chemically. The FDA's role in this is to assure the safety and effectiveness of devices. Keep this in mind while going through the process (they are not just to make your life hard). Photo By: birlewphotography From a software developer's perspective, there are three classes of medical devices the FDA regulates. You should know what kind of product/device you are making very early on - before you start planning the work. Their are legends of companies that have outsourced development only to find that their partner had yet to take a device to the point where the FDA would audit it. An even worse scenario: they had done the work with an offshore partner who didn't fully understand FDA requirements and couldn't prove traceability nor pas

Methodology "The analysis of the principles of methods, rules, and postulates employed by a discipline" For software companies these day it seems that its not a hard choice to follow Agile  principles . With some practice, or hiring a consultant, you can learn Agile  practices  and employ them as well. Its an entirely different animal to decide you are going to use Agile practices in a regulated environment though. If you choose this route you must understand that you are on the leading edge of the rest of the industry. Here are some questions you should know the answer to before you can get started: Photo By: susanrudat What is Right for My Organization? Most companies operating in a regulated environment are comfortable utilizing traditional software practices. This is often a waterfall approach. However, it may not be. Most Agile practices are not new - they are what good software organizations have been doing for years. Before you decree "We will be Agile"

Photo Credit: LucaDeravignone.com We have all heard that developing software utilizing Agile principles yields high quality, working software in customers' hands quickly. It is widely believed that utilizing Agile practices leads to better, cheaper software than waterfall methods in most instances. However, those who write software that must be reviewed by the FDA know that, at first look, the FDA regulations run counter to this approach. They lend themselves well to a heavyweight waterfall process with big design upfront and heavyweight documentation. How can you gain the benefit of optimizations such as minimal documentation, a lot of verbal communication, rapid feedback loops, collective code ownership, rapidly pivoting the product based on customer development, reduced waste and increases speed of development? Can you get the benefits of agile in an FDA regulated environment?  Yes. We are doing it right now. I'm going to be talking about how over the next few weeks. Ne