Autonomous systems are being increasingly used in medicine as well. These autonomous systems can be, on the hand, individual medical devices such as surgical robots or, on the other, combinations of individual (medical) devices.
A lot of medical device manufacturers and hospitals are not fully aware of:
Self-driving cars are one of the most commonly given examples of autonomous systems. These cars are able to safely steer themselves to a destination without human intervention.
A lot of industrial and domestic robots are also autonomous systems.
And autonomous systems are used in medicine as well, for example:
For those of you who want to learn more about these systems, we recommend reading Autonomous Systems in Anesthesia: Where Do We Stand in 2020? A Narrative Review and Robotic anesthesia: not the realm of science fiction any more.
A system is described as autonomous if it can achieve a specified goal independently and in a manner adapted to the situation without human control or detailed programming.
Source: Fachforum Autonome Systeme im Hightech-Forum: Autonome Systeme – Chancen und Risiken für Wirtschaft, Wissenschaft und Gesellschaft. Long version, final report, Berlin, April 2017
There are also other definitions because “autonomous” really only means “independent” or “self-contained.” The definitions always reflect what is important for a particular system, for example:
A fundamental characteristic of autonomous systems is their ability to adapt, i.e. to adapt to different situations by themselves.
In the case of automation, the main aim is replacement, with autonomy it is independence. You “automate something” but are “independent of something.” Automated driving indicates that the “driving” has been automated. Autonomous vehicle indicates that the vehicle is independent of the driver.
However, in general, autonomous systems are able to work independently even in complex and changing environments. This is not the case with standard full automation:
an industrial robot that has been permanently programmed to place a component on a conveyor belt acts completely automatically but is still not an autonomous system according to the above definition.
In contrast, an industrial robot that independently searches for components and assembles them on cars, even if there are different models, the cars are positioned differently or people are in the robot's working area, is an autonomous system.
A lot of autonomous systems include closed loop systems. The popular terms “Sense Understand Decide Act” (SUDA), “Monitor Analyze Plan Act – Knowledge” (MAPE-K) and “Cognitive Loop” are all aimed at the following steps of the control loop:
Unlike in “classical” closed loop systems, in autonomous systems the rules for the prediction and decision-making process are often not so rigidly or explicitly formulated, i.e. programmed. Machine learning methods are regularly used.
In addition, autonomous systems are usually also networked systems, because distributed sensor technology is often an advantage when it comes to gaining a sufficient understanding of the situation. This is not necessarily the case with closed loop systems.
Autonomous systems work independently of, for example, human intervention. This often means that the opportunity for human intervention is lost, which increases the probability that a system error will remain undetected and lead to harm.
These systems are adaptive. They are designed to be able to adapt to different contexts. The contexts will be different in many aspects, including technical aspects, such as the:
The autonomous systems also have to behave safely in different clinical contexts. Attributes of these clinical contexts include the:
A lot of autonomous systems acquire the ability to adapt to different contexts by using adaptive algorithms, e.g., artificial intelligence.
Read more on the challenges and regulatory requirements when using artificial intelligence, particularly with regard to machine learning in medicine.
The more (medical) devices connected to an (autonomous) system, the disproportionately higher the number of interfaces that have to work together is. There are often problems at the semantic interoperability level. That's why the FDA is pushing for the use of international standards.
The strength of autonomous systems – their ability to deal with variable contexts – is also their weakness:
The combinatorial explosion of situations is difficult for manufacturers and operators of autonomous systems to keep track of. Manufacturers do not know all future contexts when developing their systems. Operators do not have all the information required to combine devices into systems.
The most obvious approach to assessing risks and then managing them is assuming the worst case for the different contexts, for example:
Taking this worst-case approach often leads to unacceptable consequences:
Model-based approaches, in particular model-based dynamic risk management, try to avoid these consequences by making a context-dependent assessment of the decision on the acceptance of errors and malfunction. The following examples will illustrate this:
To be able to make these context-dependent decisions, all the necessary information on the individual devices and the context must be available.
This, in turn, requires a standardized exchange of data between devices and manufacturers and, therefore, common data models.
Domain-specific languages (DSL) describe precisely these data models and, as a result, the interfaces.
The individual devices that are part of an autonomous system don’t just communicate their values (e.g., sensor data) and instructions via these interfaces, they also give information about themselves, such as their internal status and the reliability or uncertainty of the values communicated.
The Fraunhofer IESE, for example, has developed DSLs and corresponding tools (including for MagicDraw and Enterprise Architect). The description language used to describe reliability is based on a standard from the Object Management Group (OMG) and has been published as open source.
If all (safety-relevant) information is available from all devices and for the relevant context, a (usually central) decision-making unit is required. This unit:
This decision logic should also be formulated in domain-specific languages. This enables interoperability across devices and manufacturers.
A high degree of domain knowledge is required to describe this “business logic.” Ultimately, this leads to a formalization of medical knowledge.
It is no longer just individual devices that make decisions for themselves, autonomous systems (or their decision-making units) now make decisions on the behavior of the entire system. The system makes these decisions independently and context-specifically.
Domain-specific languages describe both the context and the decision logic and as a result:
Manufacturers can and indeed must define the intended purpose and intended use and, therefore, have to establish the clinical and technical context.
However, they are hardly in a position to assess the risks that could arise with every possible combination of devices and contexts. This applies in particular to situations where users do not use the devices as intended.
As a result, it is difficult to manage these risks and ensure patient safety.
Autonomous systems can (and should) check whether the assumptions made by manufacturers are fulfilled at any given time and then make a context-dependent decision on how safety can also be guaranteed even if the manufacturer’s assumptions are not fulfilled.
A lot of manufacturers try to estimate the risks for the combinatorial range of situations by making worst-case assumptions. But these worst-case assumptions regularly require unnecessarily expensive risk-minimizing measures. These lead to higher costs or even to the device no longer being competitive and therefore no longer being placed on the market.
Autonomous systems should not start from a hypothetical worst-case scenario but make decisions based on actual cases. Systems have more options available to them for reacting to a specific context than individual devices.
As a result, system manufacturers are not just able to implement more economic (more efficient) risk minimizing measures but, using dynamic risk management, they are also able to implement more effective risk minimizing measures. This, in turn, leads to higher patient safety.
Most manufacturers try to meet their customers’ requirements with device variants and device families while limiting development costs.
However, they cannot do this cost-efficiency if they have to create separate technical documentation for each device and each variant and then have to go through a separate authorization process.
These apparent dilemmas are where model-based development comes into its own:
Read more on the advantages of computer-based modeling and simulation here.
Conclusion: Modeling devices and safety strategies in particular can save manufacturers development and documentation time and costs. This advantage increases the more often devices or components are reused in different combinations, e.g., in device families.
This article only looks at autonomous systems in the context of medical devices. But manufacturers can also use autonomous systems to produce medical devices (comparable to the car industry) and in the automation of research (see a press release from the Fraunhofer IESE).
Laws and regulations, such as the Medizinprodukte-Betreiberverordnung, establish special requirements for healthcare facilities that use networked medical devices:
Interconnected medical devices and medical devices connected with accessories including software or with other objects may only be operated and used if they are suitable for use in this combination taking into account the intended purpose and the safety of patients, users, employees or third parties.
MPBetreibV §4 (4)
But how should operators meet these requirements? How can they be able to assess the risks if the only information they have about the devices is what is contained in the accompanying material?
Autonomous systems with device interfaces are described in domain-specific languages help to ensure that the operator can comply with these requirements.
Currently, these requirements are only detailed in the accompanying material (if at all). But these interface descriptions, which can also be evaluated by computer, are a necessary prerequisite for the use of the device.
They allow healthcare institutions to make an informed choice of devices: only devices for which these interface descriptions are available are considered for use in autonomous systems.
Just as DICOM declarations of conformity (with IOD, SCP, SCU) ensure the interoperability of DICOM-capable devices, devices with the interfaces described using DSLs make it possible to select interoperable devices more precisely.
Operators can explicitly specify these interoperability requirements in requests for proposals. It is also easier to select devices and replace them with other devices if they have identical interfaces.
However, the most important advantage for operators is that the interoperability of the devices and the ability of autonomous systems to respond specifically to different contexts will lead to increased patient safety.
Now patient safety doesn’t depend on the timely intervention of medical staff and the specific medical and technical context because autonomous systems are characterized by the fact that they are autonomous and can adapt to different conditions.
The term “system” brings to mind systems consisting of several devices, e.g. in the sense of “systems and procedure packs” according to Article 22 of MDR. But this is not always the case.
Autonomous systems can be:
The MDR and IVDR only establish specific requirements in the first of these cases. The risk management requirements are particularly challenging. This is because manufacturers must assess the combinatorial explosion of devices, the statuses of devices the device is used with and contexts the device is used in.
Standards such as IEC 80001-1 describe the risk management processes that healthcare institutions who combine devices into a “system” should follow.
The intended use of an individual device may include being networked. Therefore, the MDR requires that manufacturers at least guarantee the interoperability of their devices. These requirements can be found, for example, in Annex I.
The risks associated with the possible negative interaction between software and the IT environment within which it operates and interacts;
Devices that are intended to be operated together with other devices or products shall be designed and manufactured in such a way that the interoperability and compatibility are reliable and safe.
Annex I, Section 14.2 and Section 14.5
If a device contains a closed loop control system, manufacturers should study Rule 22 of Annex VIII of the MDR.
Active therapeutic devices with an integrated or incorporated diagnostic function which significantly determines the patient management by the device, such as closed loop systems or automated external defibrillators, are classified as class III.
MDR, Annex VIII, Rule 22.
However, this rule applies to individual devices and the MDR does not contain any specific rules for systems consisting of several (medical) devices.
A lot of regulations, e.g., those in the MDR, do not take networked (autonomous) systems into account. They establish requirements that the individual devices must meet, including the above interoperability requirements.
The MDR does not regulate the responsibility for the functioning of an (autonomous) system consisting of several devices from different manufacturers. This responsibility lies with the operators. However, they are often overwhelmed by this very requirement.
The advantages of autonomous systems are obvious. But so are a lot of the challenges:
In the long run, it is naive to want to treat patients individually, safely and effectively with isolated medical devices and in ignorance of concrete technical and medical contexts.
The increasing shortage of medical personnel requires systems that actually react autonomously, i.e. without human intervention, to contexts such as the failure of system components.
The EU regulations are not suited to the current situation. They focus too much on the individual device and its interoperability. The idea of a system – and not a system as defined by Article 22 – is missing.
Any manufacturers delighted that something has not been regulated may be celebrating too soon because a lack of regulation leads to unnecessarily high levels of uncertainty during the authorization of individual devices. The high demands from authorities and notified bodies and the discussion of unrealistic worst-case scenarios complicate the authorization process.
The belief that operators would effectively analyze and manage the risks of networked systems is no more than a belief.
Manufacturers who already fail to make their medical devices safe by using modular architectures and who do not prepare modular documentation will find it difficult to develop devices for use in autonomous systems.
That's because modular architectures are a prerequisite for
In contrast, manufacturers who have already prepared model-driven modular architectures are well prepared. They will be rewarded with
Even the longest journey starts with the first step. Examples of first steps could be:
As with the use of computer-based modeling and simulation, the hurdles for the development of autonomous systems are high. The development of autonomous system will not be successful without a clear strategy and long-term investment in staff, in strategies and tools.
In contrast, companies that commit to this path will benefit from vital competitive advantages.
Dr. Rasmus Adler from the Fraunhofer IESE and the Johner Institut team are available to answer any questions you may have, e.g., via the free micro-consulting service.