Basics of software development in healthcare

How does medical software advance healthcare?

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:

• Hospital management: electronic health record software (EHR/ EMR) streamlines day-to-day hospital operations, including administration, patient engagement, procurement, supply chain management, and billing functionalities, such as process payments and insurance information.
• Diagnostic and research activities: medical database software collects information about certain diseases; 3D visualization software provides visual representations of scanned body parts via virtual models; IoT enables remote patient monitoring; VR technologies allow doctors to train in hands-on procedures.
• Telehealth and telemedicine: the former focuses on remote monitoring of the patient’s health (measuring the vital signs, blood pressure, etc.), and the latter allows patients to consult with doctors remotely.
• Health and lifestyle tracking: mobile technology such as wearables and health apps (mHealth) allow us to monitor and share our health information whenever we need it.

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 software development in healthcare 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.

What is a medical device?

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.

What software is regulated as a medical 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.

Medical device software classification

The IMDRF distinguishes between two types of medical purpose software (and the majority of regulators follow this classification):

• Software in a Medical Device (SiMD) (sometimes referred to as “embedded” or “part of”);
• Software as a Medical Device (SaMD) (also called “standalone”).

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.

Regulatory requirements in the US and EU markets

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.

Why should you bother about the risk classes of medical devices?

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:

• Class I – (low/medium risk)
• Class IIa (medium risk)
• Class IIb (medium/high risk)
• Class III (high risk)

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.

What international standards help SiMD achieve compliance?

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.

Fun fact

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:

• IEC 60601-1 contains requirements mainly about network, software interfaces, and hardware.
• IEC 62366 contains requirements about ergonomics.

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.