Medical software includes all software used for healthcare, particularly for medical devices or medical devices (embedded software), and software that is itself a medical device (standalone software).
IEC/CD1 82304-1 (Health Software – Part 1: General requirements for product safety) distinguishes between the following terms:
This clarifies that medical software can be a medical device but does not have to be.
Fig. 1: Medical software includes medical device software and software as a medical device (click to enlarge).
The question often arises as to when medical software meets the definition of a medical device. You can find a further discussion on this topic in the article on the classification of software as a medical device and in the article on the qualification and classification of IVD medical device software.
Software that is a medical device or part of a medical device must meet the regulatory requirements:
Read more about legally compliant software development and IEC 62304 here.
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” is a success and that your software or devices are quickly launched on the market.
Threat modeling is a “mandatory” topic for all manufacturers of medical devices that contain or are software. This is because threat modeling is a structured process for the systematic analysis of IT security risks that auditors consider to be the “state of the art.”
More and more manufacturers are using machine learning libraries, such as scikit-learn, Tensorflow, and Keras, in their devices as a way to accelerate their research and development projects. However, not all manufacturers are fully aware of the regulatory requirements that they have to demonstrate compliance with when using machine learning libraries or how best to…
DetailsIn a guidance document, the FDA explains how to implement a software change in a regulatory-compliant manner. It describes when you need a new 510(k) submission (Premarket Notification) and when you “only” need to document the changes.
DetailsWhat a lot of people understand by accessories is different from the definition of the term in the German Medical Device Act (MPG). This article gives you an overview of the definition of the term, the regulatory requirements, and typical questions.
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.
DetailsOn November 21, the Johner Institute, together with TÜV SÜD, TÜV Nord, and with the support of Dr. Heidenreich (Siemens), published a guideline on IT security specifically for medical device manufacturers.
IEC 62304 has introduced the concept of safety classification to allow medical device manufacturers to adapt the effort required for software documentation to the degree of possible harm that a software defect would cause. This article will help you determine the safety classes and document compliant with IEC 62304. Update: No more presumption of conformity…
DetailsIEC 82304 is now available. This is a good reason to take a closer look at this standard for “health software products.”
The Health Breach Notification Rule defines when health records providers have to report which security issues to whom, within what time frame and in what form. This article provides a brief overview of the requirements of the US Federal Trace Commission (FTC).
The Federal Trade Commission (FTC) is an US agency that aims to ensure compliance with competition law and consumer protection. This article explains the circumstances that require you (e.g., as a medical device manufacturer) to comply with the FTC requirements and the specifics of these requirements. The case of Lumosity shows how radically the FTC…
Details