Entries tagged with "Software architecture (compliant with IEC-62304)"
Software architecture (compliant with IEC-62304)
Manufacturers almost always have to design and verify a software architecture for medical device software.
Content
This page provides you with a quick overview and links to further articles.
Basics
Software architecture in the product life cycle
Regulatory requirements
Five practical tips
Support
1. Basics
a) Objective
The software architecture serves as input for the software development team to develop the software as planned (time, money, quality). It is intended to minimize development risks and ensure that the software meets the software requirements.
b) Definition
Software architecture is understood to be both a phase with a set of activities as well as the output of these activities. Most definitions are aimed at the latter.
Definition: Software architecture
Software architecture is the decomposition of a software system into components and the specification of the interfaces between these components.
Source: Johner Institute, based on IEEE
An illustrative definition comes from Martin Fowler:
Definition: Software architecture
The set of all important decisions that are both important and hard to change
2. Software architecture in the development life cycle
a) Standalone software (Software as a medical device)
For standalone software, the software architecture is the “blueprint” that specifies how the software requirements (the input) are to be implemented in software (see Fig. 1). The output of this phase is the documented software architecture. This includes the software items and their requirements.
Fig. 1: The “software architecture” phase has the software requirements as input and the documented software architecture as output.
Fig. 1 is reminiscent of a V-model. However, in this context it is to be understood more as a software development documentation model than a process model.
b) Software as part of a device (software in a medical device)
For the software part of a device, the software requirements also serve as input for the software architecture. However, they do not correspond to the system or product requirements (see Fig. 2 and Tip 1).
Fig. 2: For the software part of a device, the “software architecture” phase also has the software requirements as input and the documented software architecture as output.
The output here is also the documented software architecture, including the requirements for the software items.
Note
IEC 62304 requires that the development planning should specify the tools, methods, and coding guidelines. However, these specifications are often only meaningful once the software architecture has been established.
c) Interaction with risk management
For medical devices, software architecture and software risk management must work hand in hand. This applies in particular to software risk analysis, for example, with the help of a software FMEA or threat modeling.
Risk-minimizing measures, such as the segregation of components, should also be defined in this phase.
d) Demarcation (abdominal architecture)
In contrast to software architects, building architects not only create the construction plan. They also determine the stakeholder requirements (together with the client).
Software architects should only create the blueprint (the software architecture). Eliciting the requirements is the task of requirements engineering.
Regulatory requirements
Europe
MDR, IVDR
The MDR and IVDR require software life-cycle processes according to the state of the art (see MDR, Annex I, Section 17.2) and the “description of the software design” (see Annex II, Section 6.1.b).
IEC 62304
The harmonized standard IEC 62304 for these EU regulations specifies a software architecture and a detailed software design in chapters 5.3 and 5.4. To this end, manufacturers must identify the software items and software units and specify the corresponding interfaces.
If manufacturers use off-the-shelf software (SOUP), they must also specify the requirements for this and document and guarantee the prerequisites for its use.
The standard obliges manufacturers to verify the software architecture, for example, whether all requirements have been taken into account and risk control measures have been implemented.
USA
The FDA acknowledges IEC 62304 as a “recognized standard”. However, the authority formulates the most relevant requirements for software architecture in its General Principles of Software Validation guideline.
In addition, the guideline Content of the premarket submission specifies which documents manufacturers must submit. In this document, the FDA also sets out requirements for the “software architecture” and the “software detailed design.”
Practical tips
Tip 1: Do not necessarily define the software system as the entirety of the software
Medical electrical equipment can contain more than one CPU and, therefore, more than one “software” (see Fig. 3). Manufacturers should not define the entirety of all software as the software system. Instead, the software for each processor unit (which may contain multiple cores) should count as a separate software system.
Fig. 3: A medical device consists of components. These, in turn, contain software.
Manufacturers thus avoid layered architectures and devices mentally divided into mechanical, electronic, and software layers. They should divide devices according to functional considerations.
Tip 2: Choose the right timing
It is neither sensible nor legally compliant to specify and document the software architecture only after the software has been developed.
In agile software development, continuous refactoring is possible and common. However, experience shows that most manufacturers are challenged with a precise and viable upfront architecture. Maintaining the conceptual integrity of an architecture in agile development requires high skills.
It is, therefore, helpful to make the key design decisions early on and based on stable requirements.
Tip 3: Use defined notation
Some developers document the software architecture using boxes and arrows in PowerPoint. However, what an arrow indicates must be clear. A
dependency relationship?
association? Composition, or aggregation?
inheritance relationship?
direction of data flow?
direction of method calls?
implementation?
A model is only meaningful if the notation elements (shapes, colors, etc.) are clearly defined. Therefore, do not invent your notation language; use standardized languages such as UML.
Tip 4: Define integration strategy at an early stage
An essential characteristic of a good software architecture are components that are characterized by “weak coupling and strong cohesion” in the software system. This weak coupling is the prerequisite for later assembling and integrating the software piece by piece from the components.
Manufacturers should determine the integration strategy very early because this forces them to think about the strength of the coupling from the outset. The integration strategy also influences the integration tests.
Tip 5: Verification with checklists
The architecture must be verified before development begins. A change to the software architecture requires renewed verification (at least of the changes).
Conformity and completeness of the software architecture can be checked in an understandable manner using checklists such as those found in the medical device university. This helps manufacturers to avoid forgetting aspects.
Support
Benefit from the support of the Johner Institute:
Do you still have questions about software architecture or regulatory requirements? Then, benefit from our free micro-consulting.
In the compact seminar on medical software, you will learn about the legal requirements for software development and how to comply with them.
The Medical Device University uses video training to show you how to create a lean and IEC 62304-compliant “software file.” A complete set of templates takes a lot of work off your hands.
Contact us right away so that we can discuss the next steps. This way, you can ensure that the “approval” is safe and that your devices are quickly launched on the market.
FMEA, or Failure Mode and Effect Analysis, is a procedure for investigating the unknown effects of known causes. In the case of medical devices, for example, FMEA is used in risk analysis to analyze the consequences of a faulty component, in particular, the resulting hazards.
The system architecture describes the components of a (medical) device and how these components interact with each other via interfaces. For standalone software, the system architecture and software architecture coincide.
Both the FDA and IEC 62304 recognize software developed by third parties. They refer to Off-the-Shelf Software (OTS) and Software Of Unknown Provenance (SOUP). What is the difference between OTS and SOUP? What do they have in common? What legal requirements do they have to meet? This article provides answers.
The TIR45 (“Guidance on the use of AGILE practices in the development of medical device software”) is a Technical Information Report (hence TIR) of AAMI, the Association for the Advancement of Medical Instrumentation. First published in 2012, TIR45 has one primary objective: To guide medical device manufacturers on developing software compliant with FDA requirements while…
The V-model is a development process model that was originally used for government projects (e.g., armaments). To this day, it is still anchored in many people’s minds and in standards for projects in regulated environments (e.g., medical technology, banks). This leads to disputes in teams that prefer agile development processes. This article helps to resolve…
Laws 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.
Medical 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.
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.”
Software risk analysis depends on the following: Software itself cannot cause harm. It always happens via hardware or people. However, this does not mean there is no need for risk analysis in software. The opposite is the case!
We need your consent before you can continue on our website.If you are under 16 and wish to give consent to optional services, you must ask your legal guardians for permission.We use cookies and other technologies on our website. Some of them are essential, while others help us to improve this website and your experience.Personal data may be processed (e.g. IP addresses), for example for personalized ads and content or ad and content measurement.You can find more information about the use of your data in our privacy policy.You can revoke or adjust your selection at any time under Settings.
If you are under 16 and wish to give consent to optional services, you must ask your legal guardians for permission.We use cookies and other technologies on our website. Some of them are essential, while others help us to improve this website and your experience.Personal data may be processed (e.g. IP addresses), for example for personalized ads and content or ad and content measurement.You can find more information about the use of your data in our privacy policy.Here you will find an overview of all cookies used. You can give your consent to whole categories or display further information and select certain cookies.