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.
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.
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.
Software architecture is the decomposition of a software system into components and the specification of the interfaces between these components.
An illustrative definition comes from Martin Fowler:
The set of all important decisions that are both important and hard to change
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.
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.
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.
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.
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.
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).
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.
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.”
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.
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.
Some developers document the software architecture using boxes and arrows in PowerPoint. However, what an arrow indicates must be clear. A
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.
The article on documenting software architecture presents a proven chapter structure.
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.
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.
Benefit from the support of the Johner Institute:
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.
DetailsThe 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.
DetailsThe 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…
DetailsThe 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…
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.
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.
DetailsBoth IEC 62304 and the FDA require integration tests.
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!
