Online editor Jonathan Vanian interviews Jonathan Kohl on what it's like to work on software development and testing for mobile medical devices in light of the recent news that the Food and Drug Administration is working on a set of guidelines to regulate the mobile medical device app market.
In part two of an in-depth discussion on what exactly it’s like to work on software development and testing for mobile medical devices, Jonathan Kohl, a contributor to StickyMinds, explains the challenges of working with a government agency, meeting goals and marks when working under regulations, and the acceptance of mobility as important technology for health care.
Jonathan Vanian: You mentioned how challenging it was dealing with the fast environment of mobile in contrast with the slow moving government agency using old technology. What were some of those challenges and how did you reconcile them?
Jonathan Kohl: Here's an example: Our biggest fear when we were getting close to a release was a new operating system release appearing out of nowhere, which would require a lot of extra work. We have to try it out on devices, go through a regression suite, and determine if we can move to it or not. If it looks solid, then we update all the devices, analyze what risks the new OS brings to our app, do a full regression, and focus on some of the new risks that are introduced. Invariably, there are failures and code rework, so it is almost like doing a new feature release. We would want to move on and get closure on a release, but the agency is like other similar agencies. They have a huge responsibility, are trying to do the right thing for the public that they represent, and they aren't as well staffed as a new social-gaming startup might be. Their work takes time.
We reconciled this by being as lightweight as possible. We were using a modified version of Scrum, which is quite lightweight as a methodology, but with more roles and documentation overhead, with sprints dedicated to regulatory compliance or to testing and bug fixing and related processes. We had to work hard with our internal auditor to make sure that we had just enough process and documentation to satisfy the auditors, but our primary focus was on working with the technology and staying current. Our burden was to make something safe and usable that could enhance people's work and improve patient care. In some cases, what we were providing might even save someone's life. So we wanted to make sure we were developing and testing the absolute hell out of these things; we moved rapidly and used a ton of models of coverage and user scenarios in all sorts of situations.
Take network testing for an example. A hospital is a terrible place for network communication, so we tested wandering around a large concrete and steel building, and tested different network strengths, and transitions from different network types, such as various WiFi strengths, transitioning between WiFi beacons in a large building, and moving from WiFi to different cellular networks. Imagine that you are a doctor on rounds, you have to rush around a building, and you need to be connected to get information at any given time in different locations. You go from an underground parking lot, which is surrounded by concrete and steel, and you may have no connection, or a slower cellular connection such as EDGE. You move into an elevator and lose your connection altogether.