The new FDA rule requires approval for certain types of medical apps. If you’re a physician or in a medical office practice you might be asking yourself how might this impact you. Will you be discouraged from using or recommending to patients or fellow clinicians the use of mobile applications? If you’re participating in telemedicine might you be affected by what’s happening in the world of medical apps? Will it be a plus for doctors who want to use mobile apps to monitor BP, blood sugar etc.?
Q1: How will this impact physicians in office practice?
A: Should not have major impact.
Q2: Will it discourage doctors from using mobile devices to educate their patients?
A: No. The big things that doctors care about is proof of effectiveness, proof that their peers buy into. FDA clearance is a type of proof, but this is not mandated here.
Q3: Will it slow down the implementation of telemedicine services?
A: No. This provides certainty, and very much limits the scope of what the FDA regulates, rather than expands it. They have regulated software for over 20 years, and mobile apps are software. They've chosen to use discretion and not demand clearance for a lot of things that they can.
Q4: Will it be a plus for doctors who want to use mobile apps to monitor BP, blood sugar etc.?
A: I don't think it has much effect. The big effects are more on reimbursement. Something that is cleared or approved by the FDA is much more likely to be reimbursed by CMS, which drives a lot of reimbursement from private insurance as well. Those drivers haven't changed.
Doctors offices that want to use mobile apps can and will, but cannot purely rely on FDA clearance to do so. This opens the door for other "Seals of approval."
One of the trends from the 2012 MHealth Summit I briefly touched on last week was the growing number of bluetooth and wifi enabled wearable medical devices. I think this trend will become extremely important over the next few years.
Body Area Sensor Networks combine pervasive wireless networks, small non-invasive sensors and ultra-low power consumption chips to enable the continuous collection of physiology data from ambulatory patients.
VitaLink, a project we recently worked on with Insight Product Development and our client VGBio, illustrates the potential power of combining body area sensor networks with mobile apps, cloud computing and machine learning based predictive analytics.
The Vitalink remote patient monitoring solution consists of:
- Wearable bio sensors that collect ECG, respiratory bioimpedance, 2-wavelenght pulse oximetry, temperature and 3-axis accelerometers
- An off the shelf Android based smartphone that collects these physiological signals from the bio sensors via bluetooth and transmits them via the Verizon Private Data Network
- A cloud-based analytics server which uses predictive analytics to identify significant medical abnormalities earlier than current systems are able to do.
This technology enables the daily monitoring of patients with chronic diseases and provides early notification to clinicians of a negative change.
We've only scratched the surface of where we can go with mobile, wearable sensors and big data.
In the future I can see the data this proactive monitoring system collects can also be combined with data from other sensors like activity monitors, intake monitors, weight and sleep monitors, as well as information on prescribed medications to help provide feedback on the effectiveness of different approaches to improving outcomes.
The FDA regulates software for medical devices, and may in future regulate mobile medical software as well. Can you speed up time to market with Agile development in an FDA regulated medical environment?
We shared our experience developing software using lean ux and agile software development best practices for medical devices and mobile medical software at a recent joint Health 2.0 and Product Management Association meeting.
This may be generic advice, but it might not be a familiar concept for those in IT working within a large organization doing validated software:
Once you adopt the practices described in my previous blogs about regulated software, you will find that you aren't working alone anymore. The tight feedback cycles allow you to regularly check-in with the business and involve them in building the software. Once this happens, priorities and features will change. Early on they will change often. Don't discourage this as its a good sign things are moving in the right direction. The people talking to your customers are directly involved in building features your customers will use. This is exactly what you want because it increases the likelihood that you will produce a better product. Now that you have left your IT bubble you must partner with your stakeholders rather than simply delivering to them on a regular basis. How do you effectively partner with business and marketing? Here are the difficulties you will likely face:
- The phases and corporate dialect are different
- The time frames and processes for decision making are different
- Required documentation will be different and address different goals
- Stakeholders will feel comfortable giving verbal requirements, but you must document them, get them formally approved and finally build them into working software
How do you partner with the business and still meet your commitments? Follow the practices
we presented earlier and stick to the following principles:
- Consistent focus on activities that add business value
- Build trusted partnerships
- Constant customer engagement
- Continual process and practice improvement
- Be collaborative and transparent
- Work together: No heroes, lone wolves, or cowboys
- Pay attention to the team and adapt as needed
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.
#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 letter and start the expensive process of FDA remediation. Getting past this will cost you a significant amount of resources and likely delay new product development. Usually just in time for your competitors to catch up. Keep good records.
#2 Do Test Driven Development (TDD) Well
By well I mean do all of the normal activities that are part of TDD ... and do one more thing. Create self documenting code that also lends itself to traceability directly back to product requirements. Imagine telling an auditor that you can prove that you tested every path of the code EVERY time you checked your code in...thousands of times. All of these tests can be directly linked back to product requirements. That would make an audit pretty easy.
#3 Create a Traceability Matrix
This may seem obvious. However, I know of many, successful, software shops that have stopped doing this. Ask a developer with 1-2 years of experience why they would need a traceability matrix and you will know what I mean. If you are planing to get audited and want to show that all of your requirements have been tested thousands of times, you need a traceability matrix.
Next Up: Partnering
Its not what you wear. Its how you wear it.
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 via documentation, but in reality do less work. However, there is a natural equilibrium via the market. If you cut steps you will likely pay for it in your product via poor quality and sales. In the end the product has to work. Also, experience shows that it generally takes just as much time to design, create the documentation, necessary traceability and tracking support as to do the actual work. Inefficient? Slightly, but we are trying to sustain human life - not make a quick buck. Its not just about the money. Finally, a big picture analysis shows that it is cheaper for everyone to document what you did rather than pay somebody from the FDA to be a part of your project on a daily basis.
Don’t cut corners, or change your process, once you define it just to save time and money!
My final thought is that in order to do good process design (the 7 step version vs the 15 step version) and thorough documentation you will need to know your organization and team well. You will also need to know the product well so that you don't design a seemingly efficient process that is blind to the needs of the market the product will be launched in.
Sorry kids. Nobody ever said it was going to be easy.
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 regulated environments like the ones for medical devices. 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 tracks: Functional
is about bring business value to the stakeholders - the validation part. On an Agile project we are testing the acceptance criteria of each story. This validates we have realized the benefit to the business and end users. If some thing cannot be tested by an end user, it doesn't exist or have significant value. This is of course untrue. However, to simplify things and keep the team laser focused on only working on tasks that provide business benefit I start with this ideal. All other testing activities are testing Technical
requirements. Or, verifying that the software is correct. Some examples of these technical requirements are things like performance criteria, common libraries to the backend and data retention rules. Those who do testing for a living are looking at the screen sideways by now I suspect. I realize that these things must be done correctly or the system will not realize business value to an end user. Both ate needed. That's why the FDA requires proof of verification and validation.
The common flow of testing in an Agile project is to create acceptance criteria for each story then do regression testing after each iteration:
On the other hand, tradition testing documents and verifies each step before it is performed. The goal is for planning to be exhaustive and cover all possible scenarios.
Traditional testing is expensive and often makes validation hard to do. On the other hand, the common Agile testing approach is going to make documenting verification activities difficult. Once you acknowledge both are needed you can find a way that works. The best tools we've found leverage and extend the automated testing you are already doing. Look at the software testing as having two "tracks".
#1 Manual Functional Testing of acceptance criteria. All of the speed and simplicity of user stories. An efficient communication mechanism for stakeholders.
#2 Test everything else via automated tools. Ensures all gets tested. In our case we use unit testing and 100% code coverage.
Here is a graphic of how we can document that we are testing against pre-approved requirements - both functional (validation) and technical (verification).
Next up: Its not what you wear. Its how you wear it.
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.
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 document management system. Once this occurs it looks like you didn't test the feature before checking it in. Worse, you moved on to the next step of features and never turned in the verification report ever. 9 months later an auditor finds it and you have to doubly prove you did the testing and that you didn't miss any other steps someplace else. Nobody wants to be in a position where they are on the defense. Often a missed step means all of the testing and tracking is nullified.
There are number of things you can do to ensure you have good lists and they get used often.
- Make them short - A 10 page checklist is not going to be used properly or use up time at the cost of efficiency. Train your staff. Don't rely on process to get quality work.
- Have less steps - Can you tighten up your process and simplify it?
- Create checklist by role rather than at stage gates - The list will be shorter and highly focused on what matters to the person doing the work.
- Have the team members create their own checklists - They can identify the handful of tasks that are at risk of getting missed. That's your checklist!
- Review checklists often for new procedures and question why each step exists often.
Finally, keep in mind that whatever you put on the checklist becomes part of your project documentaiton history. Thus, you must
do every item on the list every
time you run through a procedure. Think carefuly before adding things to a checklist.
Next up: Functional Testing vs Technical Testing
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).
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 pass an audit. Whatever cost effectiveness a company offers, make sure its not going to be at the expense of doing the project twice.Class I
Class I devices are not intended to be used for supporting life. As such, they have the least regulatory controls. Product development efforts lend themselves well to utilizing Agile practices. Do some research before you start development though. About 74% of devices are exempt from pre-market notification in the first place. Those that aren't, might fit into an existing device panel. Often a few pages of documentation will suffice to pass pre-market approval for Class I devices. To find out more go to the FDA's classification database
For Class II devices, the FDA recognizes that general commercial quality control and manufacturing practices alone may not be sufficient to assure safety. However, they state that "existing methods" are in place to prove safety. You will still have to prove this to the FDA. Simply put: If you follow a process, and document it, you will be able to prove the device you are creating is safe. Rely heavily on documenting the history of the project well. The project will be characterized by significant documentation and process compared to a "normal" Agile project. Because Agile is quite new in the FDA space, you will probably need a seasoned compliance officer with FDA experience. Plan to get audited. This doesn't mean that utilizing Agile practices is difficult or shouldn't be done. In fact, because so much time is spent on each feature of the software, I would argue that efficiency and managing waste become critical issues. Attacking risk and focus on delivering the highest value features first is key here. The team just can't be sloppy with process or documentation for this type of device.Class III
Class III devices are new or are used to sustain life. The team can't rely on existing methods to prove to the FDA that the device is safe and labeled correctly. Time to market will play a part, but software development isn't likely to be on the critical path of product development. The raw science and research are likely to take up most of the product lifecycle. Is agile right for R&D? That's a topic better covered in another blog post.
Given the wide range the FDA has in place, the life of your product development team will be greatly affected by the classification of the device you are creating. In my experience, working on Class I and Class II devices often feel like working on a "normal" Agile project - assuming your Agile process incorporates enough controls to document the process itself.
Next Up: Keeping Track with Checklists
"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:
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" take a look at what the software organization is doing now. Do an inventory of the practices they are doing compared to something like Kanban or Extreme Programming. Before changing the process for process sake, ask yourself: Are they meeting deadlines set? Are you happy with the products they are creating? Does the overall organization seem happy with the software group?
If the software group isn't delivering then using Agile practices can be a proven tool one can use to solve the problem. That being said, some organizations are extremely resistant to change. Being transparent, working collaboratively, and focuses on delivering software regularly can hard for somebody who has spent their career doing the exact opposite. In this case Agile may not something everyone can embrace easily.
How fast can the organization move?
Eventually a team that embraces Agile principles and practices is going to start moving faster than before. Make sure the rest of the organization understands clearly what is going to be expected of them. This will require open communication and and transparency by your team. There is no need to have a rockstar team that can't move forward because the backend team isn't able to deliver dependent software within your schedule.
Do I know enough about Agile?
My experience is that the most popular Agile templates out there (Scrum, Extreme Programing, Kanban, Lean) don't directly lend themselves to building software in a regulated environment. This means are you going to be bending and breaking the "Agile" rules a bit. Before you can make your own path you must fully understand the "normal" path. Make sure you have significant Agile experience or hire that experience in before you start something difficult and try to expand on it.
Next Up: Have Some Class