Medical Device Data Systems
On the 9th February the FDA released the Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices (MDDS),’ Guidance for Industry and Food and Drug Administration Staff. The guidance document continues to reflect the FDA’s risk management approach around medical devices developed for patient self-monitoring.
In June 2014, FDA issued draft guidance explaining that its regulatory oversight of health information technology products is focused on devices that pose higher risk to patients, this follows the 2011 assessment of MDDS in which the FDA issued a regulation down-classifying MDDS from Class III (high-risk) to Class I (low-risk) (“MDDS regulation”).
This latest guidance document opens with recognition by the FDA that the ‘progression to digital health offers the potential for better, more efficient patient care and improved health outcomes.’
What are MDDS?
MDDS is hardware or software that transfers, stores, converts formats, and displays medical device data from a variety of other devices including glucose meters, blood pressure cuffs, and weight scales.
Example: The electronic storage and retrieval of medical device data. For example, software that stores historical blood pressure information for later review by a healthcare provider.
What is not an MMDS?
An MDDS does not modify the data, and it does not control the functions or parameters of any connected medical device it also excludes devices intended for active patient monitoring.
Example: When a clinical condition (disease or diagnosis) requires a timely response (e.g. a monitor that is intended to detect life-threatening arrhythmias such as ventricular fibrillation or a device used to actively monitor diabetes for time-sensitive intervention).
What does this mean to MDDS developers?
The FDA does not intend to enforce compliance with the regulatory controls that apply to the following devices:
- MDDS subject to 21 CFR 880.6310,
- Medical image storage devices subject to 21 CFR 892.2010, and
- Medical image communications devices subject to 21 CFR 892.2020.
This means that for devices that meet the definitions in the regulations listed above, the FDA does not intend to enforce compliance with the regulatory controls, including:
- registration and listing,
- premarket review,
- postmarket reporting, and
- quality system regulation for manufacturers of these types of devices.
With lighter regulatory controls around devices designed for patients to self-manage their health we may see some exciting innovation ahead. Read the full guidance document
The TGA last published its guidance on software in September 2013
In this guidance, the status of software as a medical device is clarified. Software fitting the definition of a medical device includes programs or operating instructions that control the functioning of an electronic medical device, such as:
- Smart phone apps that measure blood glucose levels and patient body temperature
- X-ray image-processing software, and
- Diagnostic software.
A software product that is limited to managing and presenting information – such as a medical records management system or a dosage calculator – would not usually come within the definition unless it also incorporates a therapeutic or diagnostic function.
If the software fits the definition of a medical device, it is subject to the full regulatory requirements, in accordance with the risk classification of the device. Because of this, requirements may differ between Australia and the USA.
The TGA acknowledged at that time that internationally, regulatory agencies are monitoring developments in medical software that might be used in diagnostic tools and other medical devices, and recognised that existing regulatory frameworks are not necessarily well structured to address the issues of standalone medical device software. During 2013 the International Medical Device Regulators’ Forum (IMDRF) established a dedicated working group tasked with developing and harmonising approaches to the regulation of standalone medical device software (including mobile medical apps). The TGA advised that once the outcomes of the IMDRF working group are developed, the TGA may update their guidance in light of the Working Group’s ultimate recommendations.
The IMDRF guidance was published in September 2014.
It introduces the concept of Software as a Medical Device (SaMD), defined as software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.
The document provides a categorization framework (which is not a regulatory classification), and sets a path towards common vocabulary and approach. Additional work is required to align existing classification rules with this framework.
It is likely than that the TGA will in time, issue further guidance on the regulation of software in medical applications, to address the increasingly wide variety of software applications now becoming available, and to foster international alignment.