System Architecture for Medical Devices

The System Architecture describes how a (medical) product is composed of components and how the components are related to each other via interfaces. In stand-alone software systems architecture and software architecture fall together.

Documentation of the system architecture

The documentation should reveal the individual components and their interaction. We recommend that you use standard notations like UML or SysML and not to work in PowerPoint with undefined notation elements.

In addition to the charts with the different views, the interfaces of the individual components is to be specified. Here you will find instructions on how to fully describe the specific requirements of interoperability.

Regulatory requirements for the system architecture

There are some regulatory requirements for documentation of system architectures. On the one hand calls for the Medical Device Directive MDD that manufacturers have to document design drawings [...] as well as diagrams of components, sub-assemblies and circuits in the product file. Without an explicitly documented system architecture this legal requirement would not be met.

The IEC 60601-1 requires that the medical device manufacturer identifies the programmable electrical subsystems PESS, formulates requirements and verifies their fulfillment. Without a documented system architecture the demand can not be fulfilled.

A documented system architecture is also a necessary condition for a more accurate risk analysis for an FMEA. A suitable system architecture doubles the risk control. In the Audit Guarantor you will find video training on safety-critical system architectures.

Analysis of systems in components

Risk in relation to dismantling systems in layers

In the dismantlement of systems into components, some manufacturers tend to dismantle them in different ‘subsections’, for example, in mechanics, electro-mechanics, electronics and software. We would advise against this because on the one hand this layered system architecture (hopefully) does not reflect reality and on the other you can not consistently think in components.

Only a component-based system architecture is a maintainable, testable, reusable architecture.

System Architecture and Software Architecture

In particular, it can and should not be, that software components are modeled on the first level of the system architecture. Whether that's the case for you also depends on what you define as software architecture.

Option 1: A software system is part of a PESS

If you define a software system as the totality of all software that runs in a memory / processor (and thus in a ) PESS, no software should be seen in the system architecture. Unless the system is a stand-alone software. Otherwise, you would only recognise in the system architecture, the components which are a subset of PESS. And in each PESS there is software (ie, a software system), for which there is a software architecture and software requirements so that again and again software components are identified. But the latter is not visible in the system architecture.

Option 2: A software system is the totality of all software

If you, however, understand the totality of all software in the medical device under a software system (I do not recommend this definition), then you would get a "lasagna-subdivision". They would then have no right system architecture, but a software architecture, an electronic architecture and a "mechanical architecture".

The standard gives no specification as to which variant you have to choose.

Assistance in the creation and testing of system architectures

The team of Johner Institute specialises in using, creating and testing system architectures with and for medical device manufacturers and thus:

  • Identify and dominate risks posed by the medical device,
  • Avoid difficulties during the audit and in the approval,
  • Keep system architectures condensed, precise, meaningful and in compliance with standards as well as
  • Find mistakes early and fix them and thus avoiding costly rework and project delays.

Wha not get in touch now with our experts?

Author:

Prof. Dr. Christian Johner

Starter-Kit_rot_dunkel

A quick overview: Our

Starter-Kit

Learn More Pfeil_weiß
blog_rot_dunkel

Always up to date: Our

Institutejournal

Learn More Pfeil_grau