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.
The EU AI Act has been published. Many manufacturers of medical devices and IVD, as well as other healthcare players, are faced with the major task of understanding the 140+ pages of legal text and complying with the requirements. Note: Infringements/violations of the AI Act are punishable by a fine of up to 7% of…
DetailsAccessibility refers to the design of products and services that can also be used by people with physical limitations. The term “products and services” encompasses both physical and digital products and services. This also includes medical devices (physical devices, apps, other standalone software). This article explains which accessibility requirements manufacturers of medical devices should be…
DetailsThe incorporation of AI in medical devices has made great strides, for example, in the diagnosis of disease. Manufacturers of devices with machine learning face the challenge of having to demonstrate compliance of their devices with the regulations. Even if you know the law – what are the standards and best practices to consider in…
DetailsPDMS stands for patient data management system. These clinical information systems are typically used in hospitals, especially in departments that treat patients in intensive care. PMDS are experiencing a new boom in Germany as a result of the funding provided by the Hospital Future Act (Krankenhaus-Zukunftsgesetz, KHZG). This article provides 1. PMDS: Functionalities and requirements Patient data management systems (PDMS)…
DetailsWhat is the difference between verification and validation, and how are these terms defined? Even standards and regulations use the terms incorrectly or misleadingly. This article 1. Verification a) Definition This definition does not explain what type of “requirements” need to be confirmed by verification. Limiting these requirements to product or component requirements is recommended to avoid…
DetailsLaws require risk management in hospitals, especially in order to improve patient safety. Nevertheless, many hospitals find this difficult. This article presents the most important regulatory requirements and provides tips for implementation. 1. Typical risks in a hospital a) Risks for patients The most important risks for patients include: b) Risks for all people in…
DetailsThe qualification and classification of IVD software determine how and how quickly IVD manufacturers can bring their software to market and what costs arise for “approval.” This article will help you correctly qualify and classify IVD software, thereby avoiding regulatory problems and the resulting costs and delays. 1. Definition of terms 1.1 Qualification Qualification is…
DetailsLaws and standards require medical device manufacturers to compile a Software Bill of Materials, the SBOM. However, standardized SBOM formats are not always sufficient to meet these requirements. In particular, medical device manufacturers who do not supply and use SBOMs for their software are no longer accepted in the market. Here are the reasons. 1.…
DetailsThe Medical Device Regulation (MDR) (like the Medical Device Directive (MDD) and thus the Medical Device Act before it) requires manufacturers to comply with life cycle processes for their software. IEC 62304 and IEC 82304 also refer to software life cycle processes. But what is a software life cycle? The software life cycle includes all…
DetailsGLP (Good Laboratory Practice) defines requirements for a quality assurance system for non-clinical health and environmental safety tests. It also describes the organizational procedure and conditions under which laboratory tests are planned, carried out, and monitored. GLP also covers the record and reporting of. In this article, you can read which requirements medical device manufacturers…
Details