Medical Devices Banner

Medical Device Software Design & Engineering

Our Approach to Medical Device Software Development

Man Contemplating Software Design Plans on Whiteboard - DeviceLab's Approach To Medical Device Software Development

Device Lab uses a hybrid approach to technology and medical device software development that utilizes agile principles while satisfying our customer’s needs over documentation and providing the extensive documentation required to classify the medical device presented for approval. Our track record of obtaining approval for the healthcare & medical devices we develop for our customers is exemplary, using progressive technology and 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. 

FDA Statement on Medical Software Engineering and Development

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 device 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 data & evidence to support its claim that the healthcare device and its software meet the Food and Drug Administration (FDA) requirements for approval. Requirements are stated in FDA public law and regulation 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 data and evidence to obtain approval for the medical device.

The medical device software development process at DeviceLab is a serious endeavor performed under IEC 62304, Software Lifecycle Processes.

Following the Agile approach, we use rapid iterative software 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. We are also aware of other IEC’s that are in compliance with Medical Software Development such as IEC 60601-1-2, the IEC 60601 series, the IEC 61010 series, and the IEC 61326 series.

Skills Applied to Medical Device Software Development & Engineering at DeviceLab

DeviceLab’s medical device software engineering methods for engineering medical devices is to construct our process using Food and Drug Administration requirements embedded in Medical Devices | FDA; Electronic Signatures  21 CFR Part 11, the public laws and regulations that provide the FDA with its authority over allowing medical devices to be used in the healthcare environment. Our process achieves Food and Drug Administration compliance through the intelligent application of healthcare 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 incorporates agile medical device software design and development principles as well as traditional documentation for quality assurance, requirements traceability, risk management, and electronic signatures where required.

Specific Skills Present in the DeviceLab Medical Device Software Design & DevelopmentTeam

  • Algorithm Development
  • Operating Systems
  • Data Mining
  • Programmable Logic
  • Embedded Systems
  • Real-time Systems
  • Software Integration
  • Firmware
  • System Architecture
  • Image & Signal Processing
  • System Controls
  • Machine Learning
  • System Requirements

Software Design Tools & Links

DeviceLab uses the latest medical device software development tools and is experienced in a wide variety of platforms. We can assist you with developing your medical data, mobile app, and wireless projects as well as traditional medical device equipment.

Software Expertise

  • ASP.NET, MVC, WPF, Angular
  • C#, C (C++), Objective C
  • Java
  • OSX, IOS, Android
  • LabView (NI)
  • Web API
  • Linux
  • Xamarin
  • Microsoft and Windows Products

Testing Software for Medical Devices

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 to a patient (like waiting for your defibrillator to reboot). Adhering to IEC 62304 means that we not only have requirements for what the medical device 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.

Manufacturing

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 medical 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 Food and Drug Administration regulatory compliance efforts form the backbone of our hybrid device 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 Food and Drug Administration 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. 

 

DeviceLab is ISO 13485 certified which demonstrates our commitment to proving that we meet Food and Drug Administration rules to the letter when it comes to medical device software development process and medical device software design.

Frequently Asked Questions

What is Medical Device Software Development?

Medical device software development involves creating software systems that are integral parts of medical devices, ensuring they meet regulatory standards and perform safely and effectively. This process includes designing, coding, testing, and documenting software that will be used in devices such as defibrillators, infusion pumps, and diagnostic equipment. It requires adherence to standards such as IEC 62304, ISO 13485, and ISO 14971 to ensure the software complies with regulatory requirements for safety and effectiveness.

What is an Example of Software as a Medical Device?

Software as a Medical Device (SaMD) refers to software intended to be used for medical purposes without being part of a hardware medical device. An example of SaMD is a mobile application that analyzes heart rate data from a wearable sensor to detect potential cardiac issues. This software can provide diagnostic and therapeutic recommendations based on the data it collects and analyzes, operating independently from any specific hardware device.

What is the Difference Between Software as a Medical Device and Medical Device Software?

The primary difference between Software as a Medical Device (SaMD) and medical device software lies in their dependency on hardware. SaMD operates independently and performs medical functions without being part of a physical medical device. In contrast, medical device software is embedded within or associated with a specific medical device, such as the firmware in an insulin pump or the software controlling a CT scanner. Both types of software must comply with stringent regulatory standards, but their development and deployment processes may differ due to their hardware dependencies.

What Programming Language is Used in Medical Devices?

Medical devices often use a variety of programming languages depending on the device’s requirements, the development environment, and regulatory considerations.

Commonly Used Languages Include:

      • C and C++: Widely used for their performance and control over hardware resources, especially in embedded systems.
      • C# and .NET: Often used for applications with user interfaces and integration with Windows-based systems.
      • Java: Utilized for cross-platform applications and devices that require portability.
      • Python: Increasingly popular for its simplicity and efficiency in data analysis and machine learning applications.
      • Objective-C and Swift: Used for developing software for iOS-based medical devices.
      • LabVIEW: Frequently employed in developing control and measurement systems for medical devices.

 

Each language offers specific advantages, and the choice often depends on the device’s complexity, performance requirements, and the development team’s expertise.