Medical Device Software Design & Software Engineering
Our Approach to Medical Device Software Development
Device Lab uses a hybrid approach to medical device software development that utilizes agile principles while satisfies our customer’s needs over documentation and provides the extensive documentation required to classify the medical device presented for approval. Our track record of obtaining approval of the medical devices we develop for our customers is exemplary, using progressive techniques to get successful results.
Device Lab is a progressive thinker in the way medical devices and their associated software must be developed. The prevailing standard, IEC 62304; Medical Device Software – Software Life Cycle Processes,” strongly leans toward a traditional waterfall project management approach with ISO 13485; Medical Devices Quality Management Systems and ISO 14971; Application of Risk Management to Medical Devices, are in step with 62304, using documentation heavy traditional methods.
The Federal Drug Administration (FDA) is the governing authority to approve any medical device and associated software in healthcare. This statement is the publicly declared FDA stance on medical software engineering/software development.
“IEC 62304:2006 is recognized by the US FDA medical device program as a consensus standard for which a person may submit a declaration of conformity in order to meet a premarket submission requirement or other requirements to which a standard is applicable. US FDA by recognizing IEC 62304:2006 is acknowledging that the process activities and tasks identified in this standard when used with a good quality management system and risk management system can help assure safe design and maintenance of software used in medical devices.”
The bottom line is that any company must present evidence to support their claim that the medical device and its software meets the FDA requirements for approval. Requirements are stated in FDA public law for each of the classification categories for medical devices we develop. Whatever project management method you use, be it traditional or agile, you must supply the required evidence to obtain approval for the device.
Medical device software development at DeviceLab is a serious endeavor performed under IEC 62304, Software Lifecycle Processes. Following the Agile approach, we use rapid iterative design / review / code / test sprints. Evaluation of the deliverables with each sprint provides better visibility of the development progress with the Product Owner setting priorities and making decisions with the team.
Skills Applied to Medical Device Software Development & Engineering
Device Lab’s method to do software engineering for medical devices is to construct our process using FDA requirements embedded in Medical Devices | FDA; Electronic Signatures 21 CFR Part 11, the public law that provides the FDA with its authority over allowing medical devices to be used in the healthcare environment. Our process achieves FDA compliance through the intelligent application of software tools and processes based on best practices proven to be effective from decades of industry process management work using all frameworks and methods. Our process is hybrid management for medical devices that incorporate both agile software development principles and traditional documentation for quality assurance, requirements traceability, risk management, and electronic signatures where required.
Specific Skills Present in the DeviceLab Software Development & Design Services Team
- Algorithm Development
- Operating Systems
- Data Mining
- Programmable Logic
- Embedded Systems
- Real-time Systems
- Software Integration
- System Architecture
- Image & Signal Processing
- System Controls
- Machine Learning
- System Requirements
Tools & Links
DeviceLab uses the latest development tools and is experienced in a wide variety of platforms. We can do your medical data, mobile, and wireless projects as well as traditional medical equipment.
- ASP.NET, MVC, WPF, Angular
- C#, C (C++), Objective C
- OSX, IOS, Android
- LabView (NI)
- Web API
- Microsoft and Windows Products
The difference between software for medical devices and commercial devices is that there’s a much higher tolerance for failure in commercial products. Things that are a nuisance in the office (like waiting for your laptop to reboot) can be life-threatening in medicine (like waiting for your defibrillator to reboot). Adhering to IEC 62304 means that we not only have requirements for what the software should do but a test plan that lets us prove that it really does it. If software revisions are needed after product release, we have established processes to manage changes and validate them.
Software is not a tangible thing, but it does need to reside on some sort of hardware, and the process by which it gets loaded is important to product quality. Our engineers will assure that this is done right in the prototypes and is properly transferred to the client or contract manufacturer.
Documentation & Compliance
IEC 62304 also requires extensive software documentation, considerably above what’s typical for a commercial product. Examination of this documentation is a part of getting your product approved, and fixing deficiencies in that documentation can delay the start of validation testing or cause unnecessary retests. Software documentation is also important to maintain design intent when responsibility changes from DeviceLab to a CM or the client’s factory. Our documentation ensures that our code is understandable so that future changes can be easily and safely done.
Our FDA regulatory compliance efforts form the backbone of our hybrid software development approach. We develop the software using agile methods and principles so that we can get new and updated software to market quickly. That ensures our customers have the latest capabilities to make diagnosis and treatment more relevant and accurate.
That doesn’t mean that we shortcut the documentation process that FDA regulations impose. Our regulatory process is more fully described on the website at this link while the “Our Approach” section on this page shows you where many of those documentation products are derived from.