Knowledge Center

Explore our library of blogs, short videos, virtual event recordings and training topics

How Does Software as a Medical Device Relate to Unique Device Identification?

Feb 4, 2022 | Medical Device Safety and Quality, Medical Devices, Unique Device Identification

Determining Software as a Medical Device

It is critical to first determine if the software article is a Device Component, a Device Accessory, or a Standalone Device.

  •  A Device Component is any raw material, substance, piece, part, software, firmware, labeling, or assembly intended to be included as part of the finished, packaged and labeled device.
  • A Device Accessory is intended for use with one or more parent devices and/or is intended to support/supplement and/or augment the performance of one or more parent devices.

Software as a Medical Device (SaMD), however, is a Standalone Device technology intended to be used for medical purposes without being part of the hardware medical device, defined by the International Medical Device Regulations Forum (IMDRF). The software can quickly synthesize large amounts of data and the creator can enable adjustments to the medical device in real-time, due to the software’s connectivity to the internet.

IMDRF notes that SaMD can:

  • Include in-vitro diagnostic (IVD) medical devices
  • Perform on non-medical purpose computing platforms
  • Be used in combination with other products (including medical devices)
  • May be interfaced with other medical devices (hardware medical devices, other SaMD software, general purpose software)

Examples of SaMD

  • Software that allows a smartphone to display medical imaging for diagnostic purposes, such as an MRI
  • Software that performs image post-processing to help detect cancer
  • Software that regulates an installed medical device, such as a pacemaker
  • Sleep data app using a smartphone’s camera and microphone to transmit the user’s data back to the sleep lab

Not SaMD

  • Generic aids/apps, such as a magnifying glass or web-based chat platform that allows patients to converse with doctors
  • Electronic copies of books and reference materials like medical dictionaries
  • Online portals for patient awareness and education
  • Automation for office-related hospital operations, such as medical accounting calculations and doctor shift scheduling

FDA Draft Guidance Recommends Documentation Include Premarket Submissions for SaMD

The US Food and Drug Administration (FDA) has published draft guidance, deemed as an “A-list” priority for FDA’s 2022 fiscal year, recommending documentation be included in premarket submissions for Software as a Medical Device. The documentation depends on four risk factors and must determine a submission’s documentation level as either Basic or Enhanced.

For Basic or Enhanced premarket submissions, FDA recommends the documentation include:

  • Level evaluation, justifying the submission’s designated documentation level (either Basic or Enhanced)
  • Software description, including features, analyses, inputs and outputs
  • Architecture design chart covering the software’s modules, layers and interfaces
  • Risk management documentation providing risk management plans, assessments and reports
  • Software Requirements Specification (SRS) describing software expectations

How Does Unique Device Identification (UDI) Apply to SaMD?

Unique Device Identification information must be provided on all SaMD, as stated by the FDA UDI Final Rule (Section 801.50) and FDA Guidance of Industry on UDI: Small Entity Compliance Guide (Section V.B.5). It should include readable plain-text statements shown each time the SaMd is started and/or plain-text statements on its menu command/about page, or similar presentation. The labeling requirements differ depending on whether the SaMD is distributed in packaged form (21 CFR 801.50) or not:

  • For software not distributed in a packaged form (such as an electronic download), the UDI labeling requirements are met if the UDI’s version number is conveyed in the Product Identification (PI) portion of the UDI as a Lot/Batch and/or the UDI is provided through an easily readable plain-text statement, displayed when the software is started and/or displayed through a menu command (21 CFR 801.50(a))
  • For software distributed in a packaged form (such as a CD), the UDI must appear on the product and packaging label in both easily readable plain-text and Automatic Identification and Data Collection forms (21 CFR 801.20(a) and 801.40(a)).
    • The Device Identifier (UDI-DI) on the physical label may be the same or different than the displayed Device Identifier (UDI-DI)
    • If a version number is on the label, it must be included in the Production Identifier (UDI-PI) portion of the UDI as Lot/Batch
    • If other production controls are on the label (Manufacturing Date, Expiration Date, Serial Number) they must be included in the Production Identifier (UDI-PI) portion of the UDI
When Software Changes Occur

Changes identified by the manufacturer can be classified as either a Minor Change or Major Change. Minor Changes include a bug fix, usability enhancement, security patch, feature improvement (not a safety change) and does not require a new DI. These minor revisions are frequently identified by just a new Production Id (PI) or Catalog Number with the revised product considered another child in the same Major Version family.

A Major Change includes significant affecting specifications, performance, safety, intended use, performance, or effectiveness beyond the limits set by the Manufacturer and is considered a “new version or model” triggering a new DI. Major functional changes include different algorithms, database structures, architecture, new user interfaces, etc.

  • Triggers a new DI and Major Version
  • New DI and Version need to be reported to Health Authority as a new device record
  • New DI and Version need to be applied to the software (and the software physical UDI label if applicable)

US FDA UDI SaMD Requirements Compared to EU EUDAMED UDI Requirements

When comparing US FDA UDI requirements to EU EUDAMED UDI requirements, US FDA requires software DI and physical media DI to be the same (or different), downloaded software must use version as ‘Batch’ PI value and the UDI must be displayed in ‘About’ screen. EU EUDAMED UDI requires software DI and physical media DI to be the same.

If you have questions about UDI requirements for Software as a Medical Device, get in touch with the experts at Reed Tech. [email protected] or call +1-215-557-3010.