The global medical device market is booming, with sales reaching $381 billion in 2015, according to Kalorama Information.
Many companies are jumping into the market, creating software and mobile apps for use with the wide variety of devices on the market. Mobile apps and software are changing the face of healthcare, putting more information and control into the hands of users.
Popular medical apps such as MyChart and ZocDoc are driving demand for innovative ways to manage healthcare needs and the market is only expected to grow.
Just like the medical devices themselves, all software must meet the FDA Design Control requirements. Design Control, a section of the Good Manufacturing Practice requirements, is defined in the FDA’s Quality Systems Regulation.
The regulations are designed to protect users of the medical devices, and give manufacturers a structured, yet flexible, framework to follow when developing all new products, software and apps. Comprehensive documentation must be kept to show the specific design requirements have all been met. Developers must factor in the time and resources it will take to comply with these regulations when planning their projects.
Design Control covers seven key areas:
- Users’ needs
- Design input
- Design process
- Design output
Using Design Controls In Medical Device Software Development
Companies looking to create innovative medical device software and apps have to balance their drive to develop new products with the FDA’s comprehensive guidance.
When the FDA introduced the Design Control requirements in 1996, they wanted to give medical device manufacturers a system of checks and balances.
These requirements help manufacturers spot problems in design, development and production sooner, making it easier and less expensive to correct. It also helps manufacturers ensure that the completed software or app delivers value to the market and patients and can be manufactured consistently in a safe manner.
Design Control requirements extend past production, through the life of the medical device software and apps. They must cover all changes made once it’s launched, including new features, enhancements, fixes and other updates.
Here’s how the process works:
Just like any software project, the users’ needs must first be defined. What will the software or mobile app do for the user? How will it work with the medical device to provide value to the user? How will it deliver information to the user?
This information, along with critical market research, shapes the development of the medical device software. It ensures that not only is it going to meet users’ needs, but that it will also be a financially viable product once it’s released for sale.
Once the users’ needs have been defined, developers can put together a requirements document to ensure the software or app will address those needs. With all the user needs mapped out, developers can start planning how to structure and develop the app or software.
Working off the requirements document and with input from graphic designers, business analysts and engineers, developers start planning how to bring this together with the device design, interface and overall user experience. The design inputs are translated into actual software code, or design outputs.
The design outputs are tested to ensure they meet the stated goals of the design inputs. Once accepted, the developers move on to the next part of the project, until all design outputs are completed and tested.
Once finished, the final technical documents are collected into the Design History File. This file describes all the pieces of the medical device software and serve as proof that the software was created in line with the users’ needs and meets all requirements. This serves as a roadmap for the software’s production and maintenance.
At each stage of the process, formal reviews are conducted to ensure all requirements are met and the Design Control process is being followed. These reviews need to be documented as proof that the Design Output meets the Design Input and User Needs.
Once the reviews are completed, formal verifications are created to show that the software is in compliance with the design plan.
Once the software or app is verified, it is produced and tested under real or simulated user conditions. This process ensures that the software is operating properly, meets the requirements and functions safely for users.
Risk management should be part of each step of the Design Control process. As each part of the design and development is completed, new risks may be found. Monitoring for risks at each step allows developers to identify and remedy risks before they become costly, potentially serious, complications for the end product.
Managing Design Control Compliance
With some careful planning, meeting the FDA Design Control requirements can easily become part of the development process for any medical device software or app. Training the team, along with consistent documentation, will make compliance seem like second nature and doesn’t need to slow down a company’s drive to release innovative products and capture a piece of the $381 billion market.
How does your organization handle Design Control requirements? Do you have any recommendations on how to improve the process? Share your experiences with us below.
Ready to learn more about how to use custom medical software to improve user satisfaction? Download our free guide to see how software and apps are creating more innovative, effective patient care.