Over the past few years I’ve talked to a number of customers in the embedded software and medical devices industries, and I continue to see a significant number of these organizations either moving to, or planning on moving to agile development processes.

With all of the inherent challenges for agile in these organizations such as standards/regulatory compliance, hardware changes and integration, security issues, etc. I must say that I’m a little shocked that customers are moving away from their current processes towards something like agile. Add to this the fact that the Agile Manifesto specifically states “Working software over comprehensive documentation” and it doesn’t exactly sound like agile is a great fit for embedded systems in general, let alone medical device.

Now, don’t get me wrong, I am a huge proponent of agile, and I certainly realize that there are many pros for moving to agile, and these have been well documented, but I have to wonder just how agile are these specific industries going?  I would bet that most (all?) of these organizations are adopting some of the key fundamentals of agile, but to say they are going “all in” would be a bit of a stretch.

Even industries heavy on process (because of regulatory requirements) are taking the leap into agile. How agile are they?

Looking at the manifesto a little closer, some of the principles are fairly generic and feel more like common sense than anything revolutionary, so they probably apply to any industry. There are a few principles however that are fairly easy to imagine in these industries, such as:

• getting all stakeholders involved in defining requirements (Principle #4), or
• embracing more face-to-face conversations (Principle #6), and
• simplicity, or minimizing the amount of work not done (Principle #10).

But do people really think that Principles #1 (early and often delivery of software), and #2 (welcome changing requirements) really apply to the embedded or medical devices industries? Personally I don’t see it.

So what do you think? Are the embedded software or medical devices industries capable of going full out Agile?

Yesterday we did our second Medical Devices software seminar, this time in snowy and cold Minneapolis. Say what you will about the weather, but this city is built for winter…it has various overhead ‘tunnels’ called ‘skyways‘ connecting what seemed to be the entire downtown core, so you rarely ever need to go outside.

Anyways, our seminar drew the interest of over 75% of registrants, mostly software engineers and QA, so really another great turnout. The format was the same as our Boston event, with the same players from SterlingTech, Klocwork (duh) and Vector Software. There really didn’t seem to be too much separating this group from the Boston group with the exception being around the development methodologies being used. The Boston group all appeared to be using (or moving to) and Agile methodology, whereas this group was not using Agile at all. For the life of me I cannot explain this. I would have thought if Medical device organizations in one part of the country were primarily using Agile, perhaps it was becoming the norm for that market segment…but based on this sample, now I just don’t know. If anyone can share their observations on this, I would love to hear from you.

Yesterday we kicked off our first Medical Devices specific seminar in Boston, with our friends from SterlingTech and Vector Software. The day was all about software development for medical devices and more specifically, about managing software risk to help ensure you are compliant with all of the FDA regulations specific to software code. We had a great turnout, with over 75% of registrants showing up for this session. A couple of observations I found interesting from this event:

• The medical devices community seems to be fairly tight-knit. Everyone at the event seemed to know everyone else, and there was definitely a strong support system in place among the companies in attendance.
• And secondly, there appears to be fairly high adoption of Agile practices, particularly Scrum (albeit somewhat modified), with these Medical device companies, and the healthcare industry in general for that matter. From everything I heard, this adoption curve shows no signs of slowing down.

If IEC 62304 is important to your organization, you might want to check out this half-day seminar. The next one will be in Minneapolis in January. I’ll be packing my woolies for that one!

We get many questions from medical devices customers on how they should validate the use of Klocwork’s static analysis tools for the FDA. I suspect the situation would be similar for most vendors of software development tools. As we’ve done before, we thought it would be a good idea to ask Bruce Swope from SterlingTech Software to clarify this whole topic for us.

[Brendan] First, what is tool validation?
[Bruce] Tool validation is the act of demonstrating that a tool will consistently produce expected results.

[Brendan] How can a medical device company know whether they should validate a tool or not?
[Bruce] From 21CFR820.75, “Where the results of a process cannot be fully verified by subsequent inspection and test, the process shall be validated with a high degree of assurance and approved according to established procedures”. For example, if you are using a tool to perform work and you do not plan on using any other method to verify that the work was done properly then the tool will need validation. Please note that you must validate the tool for your intended use, not the entire tool.

FDA Tool Validation Checklist

[Brendan] Ok, let’s take a specific example. What would validating a static analysis tool involve? 
[Bruce] Here’s a basic list of what needs to be completed.

a) Develop a Tool Validation Plan. This should include the test environment and methods to be used
b) Develop a set of requirements that the tool is intended to meet
c) Develop a test protocol to verify that the requirements have been met
d) Develop a traceability matrix and verify that all requirements have been tested
e) Execute the test protocol
f) Write a test report summarizing the results

[Brendan] Do most companies do this themselves or can they outsource this activity? 
[Bruce] If the company has the internal trained resources available then they can certainly do the tool validation themselves. Many companies lack the staffing, or expertise, to perform validation of a software tool. It is common for these companies to outsource the documentation and testing activities to a firm like SterlingTech. We’ve completed this process numerous times before and it’s a good way to reduce the cost and effort around the validation process.

[Brendan] Thanks Bruce.

Complexity of Medical Device Software Continues to Grow

IEC 62304 is becoming a hot topic amongst medical device software professionals. We asked Bruce Swope, VP Engineering at SterlingTech Software for his views on this standard and what it all means for medical device companies. Bruce has extensive experience in medical device software development and he is an expert in leading Class III medical software products to commercial release. His depth of experience also spans the development of enterprise solutions, security applications, internal applications, and process control systems. He has been an early adopter of quality practices including ISO 9000 processes, Common Criteria Certification and Capability Maturity Model implementation.

[Brendan] Thanks Bruce.

I had a chance to speak with Bruce Swope, the VP of Engineering at SterlingTech, an ISO13485 Registered full-service medical device software organization offering software development and validation services. SterlingTech has developed software for an array of medical products including implantable devices as well as external support and monitoring equipment. Their team has worked on Class I, II, and III devices that resulted in successful FDA 510(k)s, PMAs, and CE submissions.

Bruce has extensive experience in medical device software development and he is an expert in leading Class III medical software products to commercial release. His depth of experience also spans the development of enterprise solutions, security applications, internal applications, and process control systems. He has been an early adopter of quality practices including ISO 9000 processes, Common Criteria Certification and Capability Maturity Model implementation.

I wanted to talk to him more about the challenges developing software in an FDA-regulated context and what all this means to medical device software development teams.

[Brendan] Given your experience working with a variety of medical device companies, what do you see as the biggest business challenge they face?

[Bruce] The biggest challenge is developing a medical product in a cost effective manner that meets FDA and international regulatory regulations.  Most companies have very limited resources available and have boards or investors that are not used to the rigors of regulated development.  This often leads to a gap between investor expectations and the reality of getting the product ready for market.

[Brendan] What about technology challenges?

[Bruce] The hardware platforms that the systems are developed for are very expensive in time and money to update once fielded.  Often, the hardware is impossible to update without dramatic impact to the patient such as surgery.  This creates a need for software developers to find creative ways to extend the life of the hardware by introducing new functionality without updating the hardware. This can often cause the software to become much more complex than planned.

Further, device manufacturers must balance the expectations of customers against the rigor and security required with making a medical product.  Consumers are very accustomed to seeing feature rich devices reach the palm of their hand and wonder why their heart pump can’t double as a PDA or MP3 player or why they can’t plug their device into the internet to download new alarm tones.

[Brendan] What’s the most common problem your firm is hired to solve?

[Bruce] Many of our customers are looking for an organization that has experience in working with a given technology to create a product that will be approved by the FDA and international regulatory authorities. They are looking for someone that has the experience to deliver a quality product and a complete design history file without wasted effort or significant delays.

[Brendan] In your experience, do most medical device companies have a clear understanding of the regulatory environment or is there still confusion in the market?

[Bruce] Many of our customers are early stage companies that are looking for us to provide the knowledge of the regulatory environment.  Other clients may have an understanding of some aspects of the regulatory environment such as mechanical or electrical but need assistance with the software aspects.

Unless companies invest in dedicated regulatory resources early on and get the FDA or notified body involved sooner rather than later, there will always be confusion and opportunity to misdirect effort.

[Brendan] Any common misconceptions related to compliance issues you can share?

[Bruce] Companies have come to us with a misunderstanding of the impact “level of the concern” will have on the development process for their proposed device.  Companies will often put in place a Quality System that is overly burdensome on the software development process.

The result of these mistakes is often that either too much or too little is done to develop the software.  Either outcome is damaging.  In the case where too much is done, extra cost is incurred and the project completion and entry to the market is delayed.  In the case where too little is done, a rejected submission could result leading to further cost and delays.

[Brendan] What’s the #1 recommendation you give to clients as it relates to the intersection of compliance issues and software development?

[Bruce] Make sure that your company has a good solid Quality System as it applies to software development. Do not put a Quality System into place that you can not follow. This is the cause of most audit problems. Use automated tools in your process to allow your developers to focus on the creative parts of the software development.  Keep things as simple as possible.  Drive out risk early.

[Brendan] Where can people go to get more information? Any good online resources out there?

[Bruce] For an executive overview for determining whether a new device is a medical device or for ideas on how to use a static code analysis tool in medical device development, we have a library of whitepapers people can download.

[Brendan] Thanks!