Interoperability is the capability of a system (e.g., a medical device or software) to work together with other systems.

Content

On this page, you will find a brief introduction to the topic of interoperability as well as links to further articles on the following topics:

  1. Interoperability levels
  2. Regulatory requirements for interoperability
  3. Support (also for digital health applications (DiGA))

1. Interoperability levels

Interoperability requires common “agreements” at four levels of interoperability:

Level Task Examples of standards
Organizational level Enable cross-system processes, roles, and authorizations IHE
Semantic level Achieve a standardized understanding of the information units Taxonomies, classification systems, nomenclatures such as ICD-10, ICF, LOINC, UCUM, ATC, and the value tables of HL7, FHIR, and DICOM
Syntactic level Identify information units in the data stream Formats such as XML, JSON, HL7*, DICOM*
Structural level Transfer data stream from one system to another Protocols e.g., of the OSI layer model (TCP/IP, FTP, http), RS232, I2C, and many more.

*HL7 and DICOM standardize not only the syntactic level.

Caution!

Make sure you address all four interoperability levels in the system requirements specification and the software requirements specification, not just the lowest level, as is often the case.

2. Regulatory requirements for interoperability

a) MDR and IVDR

Definition

The MDR defines the term interoperability.

Definition: Interoperability

the ability of two or more devices, including software, from the same manufacturer or from different manufacturers, to:

  • exchange information and use the information that has been exchanged for the correct execution of a specified function without changing the content of the data, and/or
  • communicate with each other, and/or
  • work together as intended.

MDR, Article 2.26

General safety and performance requirements

The MDR and IVDR do not explicitly require interoperability. However, they do include it among the general safety and performance requirements:

If the device is intended for use in combination with other devices or equipment the whole combination, including the connection system shall be safe and shall not impair the specified performance of the devices. (MDR, Annex I, Section 14.1)

Also, “risks associated with the possible negative interaction between software and the IT environment within which it operates and interacts” must be eliminated or reduced as far as possible.

Changes to “interoperability channels”

If manufacturers change the “interoperability channels” (i.e., change the specification of an existing interface or add a new interface), this has consequences:

  1. The software (if it is standalone software) must receive a new UDI-DI.
  2. The change counts as a substantial change, which forfeits the “grandfathering” of devices placed on the market under an MDD certificate.

b) Requirements for DiGA

Manufacturers of digital health applications (DiGA) must demonstrate the interoperability of their devices. The BfArM summarizes these requirements well:

Interoperability is, therefore, an essential quality characteristic of DiGA and thus falls under the requirement in Section 139e (2) SGB V. This is further explained in Sections 5 and 6 DiGAV and in Annex 2 to the DiGAV (“Interoperability” section). This specifies which interfaces of a DiGA are to be designed as interoperable and how interoperability must be realized through the use of standards.

c) FDA

The FDA also has requirements for interoperability.

3. Support

Do you still have questions about interoperability? Then, benefit from our free micro-consulting.

In our Medical Device University, you can familiarize yourself with the interoperability levels thanks to numerous video training sessions. You will receive step-by-step instructions on how to use the interoperability levels model when specifying software or systems, enabling you to create lean and “audit-proof” documentation.

Please get in touch with us!