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 Health Insurance Portability and Accountability Act (HIPAA) is a US law that establishes requirements for processing protected health data. Institutions that collect or process these data in the USA and their subcontractors must comply with HIPAA if they want to avoid sanctions. For European companies in particular, HIPAA is a regulation that is difficult to understand…
DetailsWe have known how vulnerable IT security is in the healthcare sector since February 2016, when the IT infrastructures of many clinics were brought to a standstill by a simple virus attack. As a result, the authorities are paying closer attention to ensuring that not only clinics but also manufacturers guarantee the IT security of…
DetailsPractical guidance based on the experience of the Johner Institute, Oliver Hilgers, and Stefan Bolleininger The discussion about class I software continues to rage. This article provides guidance regarding the MDR rules for the classification of medical software. 1. Background a) Relevance of the issue Whether or not medical software counts as class I software is…
DetailsDecision Support Systems are also increasingly being used in medicine. If they are medical devices, they must meet the legal requirements (e.g., the general safety and performance requirements). The hype surrounding Artificial Intelligence, in particular Machine Learning, and users such as Watson are raising hopes for the performance of Decision Support Systems. This article presents…
DetailsThe parameterization of software – in this context, we can also talk about customizing or configuring software – often leads to discussion, e.g., regarding responsibilities and the differentiation to in-house production. This article gives manufacturers and their customers important advice on what to look out for when parameterizing software and how to avoid the usual pitfalls.…
DetailsIEC 82304 is now available. This is a good reason to take a closer look at this standard for “health software products.” IEC 82304: Why another standard? Closing the IEC 62304 validation gap IEC 62304 was launched with the claim of being applicable to all medical device software – whether standalone or embedded. However, the…
Details