Medical Device Software Standards (Part 1)

            Ensuring Safety and Reliability Through International Standards

Medical devices and medical device software play a crucial role in modern healthcare — saving lives, improving patient outcomes, and supporting physicians in diagnosis and treatment. Because these devices directly impact human health, their performance must be accurate, reliable, and safe.

To ensure this, medical device manufacturers are subject to strict quality and regulatory control by each country’s Food and Drug Administration (FDA) or equivalent authority. These regulations are based on international standards that govern design, manufacturing, and testing. Among the most widely recognized are:

  • ISO 13485 – Quality Management Systems for Medical Devices
  • ISO 14971 – Risk Management for Medical Devices
  • IEC 60601 – Safety and Performance of Medical Electrical Equipment

For medical device software, additional standards apply — particularly IEC 60601-1, Clause 14 and IEC 62304, which define processes for developing, testing, and maintaining safe software systems. Manufacturers seeking international compliance must also understand Software Verification and Validation (V&V)principles to ensure that software functions correctly, precisely, and safely when used on humans.


Purpose of This Series

This article, the first in a series, provides an overview of IEC 60601-1 Clause 14 and IEC 62304, and introduces the principles of software verification and validation. It aims to help medical device software developers gain foundational knowledge to prepare for compliant software production and certification.

 

รูปที่ 1 ระบบ

Figure 1: Key organizations supporting product quality and standardization.

 

   The digital product quality ecosystem involves multiple organizations working together to ensure the quality and safety of medical devices:

  1. Schema Owner – Defines frameworks and reference models for product certification.
  2. Promoter – Provides support measures, including financial aid for testing or standard compliance.
  3. Regulatory Body – Establishes and enforces standards, reviews product registration, and authorizes market release.
  4. Testing Laboratory (Testing Lab) – Conducts product testing according to relevant standards.
  5. Certification Body (Certified Body) – Certifies products using test results from accredited laboratories.

After passing testing and/or certification, manufacturers submit documentation to the Regulatory Body for product registration and approval to market their devices.

In Thailand, this role is held by the Food and Drug Administration (FDA), which defines medical device standards and recognizes specific Testing Labs and Certification Bodies authorized to issue compliant test reports and certifications.


Medical Device Standards: An Interconnected Framework

Medical device development draws on several interconnected international standards, including:

  • ISO 13485 and ISO 14971 for design and risk management
  • IEC 60601 for electrical safety and performance
  • IEC 60601-1 Clause 14 and IEC 62304 for software development and life cycle management
 

Figure 2: Relationship among standards related to medical device software.

(Source: ANSI/AAMI/IEC 62304:2006 – Medical Device Software—Software Life Cycle Processes)

 

In addition, several complementary standards support IEC 62304 implementation:

  • IEC/ISO 12207 – Defines software life cycle processes (the “what” of development).
  • IEC/ISO 90003 – Provides guidelines on software engineering practices (the “how”).
  • IEC 61508-3 – Covers functional safety for electronic and programmable systems, often referenced for safety-critical software testing.
 

Understanding IEC 62304

IEC 62304 establishes a structured framework for developing medical device software through six key clauses (4–9):

  • Software Development Planning
  • Risk Management Integration
  • Software Design and Implementation
  • Verification and Validation
  • Maintenance Processes
  • Problem Resolution Management

These requirements collectively ensure that software products meet safety, quality, and traceabilityexpectations throughout their entire life cycle. Each clause will be discussed in detail in Part 2 of this series.

What Counts as “Software”?

Under IEC 62304, software is defined broadly to include:

  1. Program instructions (code) – both compiled and uncompiled.
  2. Data structures and related data.
  3. All documentation and artifacts produced during software development, such as:
    • Software Development Plans
    • Software Requirements Specifications
    • Risk Analysis Reports
    • Design Documents
    • Source Code
    • Test Cases and Test Reports

This holistic definition reinforces that software quality depends not only on the code itself but also on the surrounding engineering and validation processes.

 Types of Medical Device Software

 

Figure 3: Examples of medical device software (source: Micrel Medical Devices)

Medical device software typically falls into two main categories:

  1. Embedded Software – Integrated into the hardware of a medical device, responsible for sensor data acquisition and control functions. Example: Infusion pumps that regulate intravenous fluid delivery.
  2. Application or Standalone Software – External applications that interact with embedded systems to display, control, or transmit data. These may take the form of webmobile, or desktop applications, communicating with devices via Wi-FiBluetooth, or cloud platforms.
 
 

Challenges in Software Development

Common challenges in medical software projects include:

  • Delayed delivery
  • Budget overruns
  • Low-quality or unsafe software
  • User dissatisfaction

To overcome these, organizations increasingly apply Software Engineering principles — structured methodologies, tools, and processes that bring consistency and accountability to software development. These help ensure that software meets quality requirements, stays within budget, and delivers on schedule.

Ultimately, achieving the desired level of software quality relies on robust Software Quality Management — the focus of Part 2 in this series.


Coming Next:

Part 2 – Software Quality Management and Compliance with IEC 62304

Author : Panita Meananeatra

Cover Picture : https://bit.ly/3tNrlHJ