The EU Medical Device Regulation uses standalone software to describe “devices in the form of software.” However, this regulation only applies to some standalone software.
Content
This page provides a brief overview and references articles for further background information.
Standalone software applications are independent devices brought to market without hardware, either as a download (e.g., via an app store) or on a physical data carrier (e.g., flash drive).
Standalone software intended for the healthcare sector is different from health software. It is also incongruent with medical device software (see Fig. 1).
Fig. 1: Standalone healthcare software is a subset of health software (all four quadrants).
Examples of standalone software are
Manufacturers must clarify whether their standalone software counts as a medical device. The article on the qualification and classification of software as a medical device sheds light on when this is the case.
If the standalone software counts (“qualifies”) as a medical device , it must meet the legal and normative requirements. These do not differ from the requirements for software that is part of a medical device.
Read more about legally compliant software development and IEC 62304 here.
With web-based medical devices in particular, manufacturers find it challenging to determine which part is part of the medical device and which is part of the runtime environment. For example, is the application server included?
It is important to document this definition explicitly.
Fig. 2: Web-based medical devices consist of many levels. One part belongs to the software (medical device), one part to its runtime environment. SOUP are part of the medical device.
If the software is made available via app stores, the question arises as to when the placing on the market actually occurs. When it is uploaded to the store? When it is activated in the app store? Or only at download?
This article on placing on the market provides answers.
The runtime environments on which the standalone software is installed differ. Hardly any two computer systems are the same. This applies to notebooks and servers as well as smartphones. There are thousands of Android-based end devices.
This makes it difficult for manufacturers to review the correct functioning of their software on these end devices. They therefore have to restrict them or test them riskbased.
This diversity affects not only the technical environment, but also the use environments and benefits. How are manufacturers supposed to ensure that only the users intended for the intended purpose use the devices? How should they anticipate under which circumstances (e.g., when driving, at night, during sport) their devices will be used?
Systematic post-market surveillance is essential here in order to track actual use and react to it if necessary.
In contrast to many physical devices, software must and can be brought to market in short development cycles. This is necessary because security patches must be installed.
However, this is offset by lengthy approval and conformity assessment procedures.
The Johner Institute digitizes the regulatory processes and works on real-time regulation.
Benefit from the support of the Johner Institute:
Contact us right away so that we can discuss the next steps. This will ensure that the “approval” process succeeds and that your software or devices are quickly launched on the market.
Understandably, laws and standards also require IT security for legacy devices. However, the way in which these requirements are formulated often leads to confusion. For example, legislators and standard committees have been unable to agree on common definitions. One definition refers to the IT security of legacy devices, another to the IT security of old…
DetailsSoftware as Medical Device (SaMD) refers to (independent) standalone software that is a medical device but not part of one. It should not be confused with Medical Device Software as defined by the EU. As a manufacturer, when do you have to qualify Software as Medical Device, and when as Medical Device Software? Find out…
DetailsMDCG published guideline MDCG 2023-4 in October 2023 entitled “Medical Device Software (MDSW) – Hardware combinations – Guidance on MDSW intended to work in combination with hardware or hardware components.” Criticism 1: Unclear scope of MDCG 2023-4 The title gives the impression that (all) types of combinations of hardware and Medical Device Software (MDSW) are…
DetailsFor manufacturers, the answer to whether and when clinical studies are necessary when using artificial intelligence in medical devices is relevant. After all, the duration and cost of bringing these devices to market depend on this. The good news in advance: there are cases where manufacturers can avoid clinical studies for devices with AI. This…
DetailsThe term “medical device PC” is not clearly defined. However, most people understand a medical device PC to be Depending on the constellation, manufacturers must fulfill different regulatory requirements. These are presented in this article. 1. Case distinctions for medical device PCs Case A: Standalone software is delivered If you as a manufacturer only supply…
DetailsLaws and standards formulate requirements on how medical device manufacturers must define and document the development process. Notified bodies check these requirements during audits. This article on the development process provides tips on how to design the process and how to align it with other processes, such as the risk management process. 1. Development process:…
DetailsMedical software manufacturers must meet the legal requirements for software components in order to “approve” their devices. This article presents these requirements and gives seven tips on how to fulfill them quickly and easily. 1. What software components / items are There are different definitions of “software component”, also referred to as software items as…
DetailsSince 2020, the German legislature has allowed the reimbursement of digital health applications (DiGA). DiGA manufacturers must fulfill several requirements for this. This article describes the steps required to do so. Step 1: Define the business case a) Determine the intended purpose of the DiGA The intended purpose is the basis for all further steps.…
DetailsThe cybersecurity standard IEC 81001-5-1 focuses on how IT security needs to be taken into account in the software life cycle. As a special standard for health software, it supplements IEC 82304-1 and IEC 62304 among others, and can close gaps that urgently need to be closed. The EU is currently planning to harmonize IEC…
DetailsThe MDR contains the Classification Rule 11. This rule is especially for software. The Rule 11 has serious implications: it bears the potential to further undermine Europe’s innovation capacity. Manufacturers should familiarize themselves with the MDCG‘s interpretation to avoid misclassifying software and to be able to follow the reasoning of notified bodies and authorities. This article…
Details