Technology spreads across all aspects of healthcare helping medical institutions meet growing demand, operate efficiently, and deliver better patient care.
Software solutions for healthcare help with:
According to the Research and Markets report, the global digital health market size is expected to reach USD 295.4 billion by 2028 and is projected to expand at a compound annual growth rate (CAGR) of 15.1% in 2021-2028 (the report forecast period). The mHealth, (i.e., mobile health) technology segment accounted for the largest market share of over 47% in 2020 and is anticipated to register a lucrative CAGR during 2021-2028.
The process of healthcare software development is quite similar to developing other apps with a few exceptions. We distinguish between computer software that is an integral part of medical devices and software that performs a role of a medical device itself. Their development is completely different. Nevertheless, both require certification comparable to that of a medical device, so their development, testing, and other aspects of the lifecycle fall under strict regulations.
Defining a medical device is not so straightforward. The definitions of a medical device vary depending on the country and are set forth in the corresponding legislation.
In 2011, voluntary medical device regulators across the world founded the International Medical Device Regulators Forum (IMDRF) striving to harmonize the definition of a medical device, its classification and requirements for it across different jurisdictions, but this ambitious goal remains to be achieved. The IMDRF developed its definition of a medical device (and urges other regulators to adopt it, too): a medical device is a product, such as an instrument, machine, implant, software, or in vitro reagent that is intended for use in the diagnosis, prevention, and treatment of diseases or other medical conditions. The intended purpose is the key here as it describes the intended medical use and is essential both for the manufacturer and regulator in deciding whether or not a product is a medical device. The purpose should be clear, precise and consistent throughout the entire technical documentation and in all future documents on the device.
Software as a medical device aims at fulfilling medical purposes but is not part of a hardware medical device. For instance, software that helps radiologists and clinicians find and diagnose Covid-19 (medical purpose) by analyzing lung damage on the CT scans is software regulated as a medical device, as well as a mobile application that takes input from a blood glucose meter and patient food log to provide insulin dosage recommendations for diabetes (medical purpose).
We should bear in mind that software intended to communicate, store information, or perform a simple search does not qualify as a medical device. An application that allows users to take pictures of moles on their skin and store the pictures to show (the purpose of showing) them to a physician does not perform an action on data other than just storage, so it is not a medical device. An Electronic Health Record (EHR) system, which only replaces the paper files, would not be considered a medical device.
The IMDRF distinguishes between two types of medical purpose software (and the majority of regulators follow this classification):
Software embedded in a medical device ensures the proper functioning of a physical medical device or controls it remotely. Any software that runs or helps run things like an MRI, EKG, X-ray, insulin pump, or any other medical devices qualify as embedded.
Standalone software means that the software itself performs the role of a medical device. To qualify as SaMD, software needs to function completely independently of existing medical devices. Although SaMD works independently, it is installed on non-medical devices such as smartphones, tablets, smartwatches, laptops, or other mobile devices or wearables. SaMD does not deal with running hardware, but it often works in conjunction with hardware devices. For example, a CDSS (сlinical decision support system), which is SaMD, issues an alarm when incoming data from an electrocardiogram monitor (SiMD) fulfills certain patient-specific rules.
The US and EU are very attractive for new medical devices and software, so we’ll touch upon some medical software regulations on these markets.
First, let’s get this straight and clear. The device manufacturer who uses software in a medical device or develops SaMD bears sole responsibility for ensuring their safety and effectiveness. What exactly does that responsibility entail? The device manufacturer must comply with all required standards and needs to be vigilant and responsive to cybersecurity vulnerabilities.
Each country has its own regulations, ISO standards for medical devices, and certification procedures. Therefore, regulatory considerations are crucial for successful market authorization of medical software.
In the United States, the Food and Drug Administration (FDA) publishes guidelines and regulations to assess the safety and efficacy of new medical devices that go to market. On the FDA website, you can find instructions on how to determine if your product is a medical device.
In the EU, the main document regulating medical device certification is the new Medical Device Regulation (MDR) that replaced the former Medical Device Directive (MDD). Compliance with the MDR has been mandatory since 26 May, 2020. Under the EU MDR, the MDCG 2019-11 document is used to qualify and classify medical device software.
To safeguard product conformity and harmonize requirements both nationally and internationally, manufacturers and developers implement relevant ISO standards which are described later in the article.
The risk classification in the medical device industry ensures that the regulatory controls applied to a medical device are proportionate to its risks. The characteristics of the device, intended use, the context of the use in a specific healthcare system, and experience with similar products define the risk class of a medical device and software. For instance, the introduction of complex novel technology in a country with little prior use of similar products may require higher risk classification.
In the EU, the software could be classified as:
In the US, the FDA categorizes medical devices as one of three classes—Class I, II, or III. Class I devices generally pose the lowest risk to the patient and/or user, and Class III devices pose the greatest risk. Here is how the FDA provides guidance on device allocation to a certain risk class.
The same medical device might be considered a low-risk device exempt from regulatory clearance in the US and a high risk device in the EU and subjected to the scrutiny of a notified body.
Now that the risk classes are defined, it’s time to look at the development process and elaborate on it according to the best practices adopted in the industry. For software in medical devices, such best practices were gathered in several standards developed by the International Organization for Standardization (ISO) and its sister organization, the International Electrotechnical Commission (IEC).
ISO (International Organization for Standardization) is an independent, non-governmental, international organization with a membership of 165 national standards bodies that develop standards to ensure the quality, safety, and efficiency of products, services, and systems.
The name “ISO” is not an acronym for anything. It is instead derived from isos, the Greek word for “equal,” as in ‘isosceles triangle,’ and reflects the organization’s aim to equalize standards between countries.
These ISO and IEC standards are voluntary, but regulatory authorities often use them as a basis for legislation making them mandatory within the jurisdiction covered by the legislation. So, whatever compliance or certification you will seek, it is a good idea to start with ISO and IEC guidelines.
ISO 13485 and ISO 14971 are the topmost generic standards that apply to every medical device and don’t focus on software.
The main standard for SiMD is IEC 62304 that deals with the software development lifecycle, i.e., almost everything what software engineers do.
There are two more standards that partly apply to medical software development:
This was a high-level overview of things to consider when you plan to develop medical-purpose software. Looking for help with it? At EffectiveSoft, we have vast experience in developing medical software and are ready to help you out. Contact us.