DE102024104157A1 - Technology for configuring a clinical system - Google Patents

Abstract

A technique for configuring a non-linear decision system (102) of a clinical device (100) to support a clinical decision (118) is described. According to one method aspect, a data set (110) with a plurality of data points is acquired (202), wherein at least some of the data points each comprise a value pair (111) with an input value (113) of an input (112) of the decision system (102) indicating patient data (114; 115) of a patient and an output value (117) of an output (116) of the decision system (102) indicating the clinical decision (118) for the patient or dependent thereon. Parameter values (120) of a configuration of the decision system (102) executed by a first server (104) are generated (204) by machine learning, ML, on the basis of a training data set (110-1) which is a subset of the acquired (202) data set (110). A performance value (130) of a performance metric of the decision system (102) configured with the generated (204) parameter values (120) is determined (206), wherein output values (117-K) of the decision system (102) configured with the parameter values (120) are compared in response to the input values (113) of a validation data set (110-2) with the output values (117) of the validation data set (110-2), which is a subset of the acquired (202) data set (110) that is disjoint from the training data set (110-1). The generated (204) parameter values (120) for configuring the decision system (102) executed by a second server (106) in clinical use are sent (208) if the determined (206) performance value (130) meets a predetermined criterion.

Description

Field of the invention

The present disclosure relates to a technique for configuring a clinical decision system. In particular, the disclosure relates to a method for configuring a nonlinear decision system of a clinical decision support device, as well as to a corresponding system and a corresponding computer program product.

Technical background

Artificial intelligence (AI) is a rapidly evolving family of technologies that can bring a wide range of economic and societal benefits across the spectrum of industry, science, and social activities. By improving predictions, optimizing processes and resource allocation, and personalizing services, the use of AI can lead to socially and economically beneficial outcomes. These include machine learning (ML) systems that use prediction models, which have evolved into powerful tools.

However, the very technologies that enable the socio-economic benefits of AI can also bring new risks for individuals or society. In preparation for AI legislation by the European Commission, the document describes WO 2023/014985 A1 Mechanisms for enforcing AI and ML compliance through restrictions and safeguards, controlling the actions of AI systems to prevent faulty or biased predictions from being used by AI systems and potentially causing harm to people or objects. AI enforcement mechanisms aim to ensure that AI systems operate safely, trustworthy, and ethically.

In the medical context, machine learning-based systems are enjoying ever-increasing influence. A physician or assistant can now use these tools largely effortlessly to obtain accurate predictions and recommendations for an upcoming medical task. This is particularly true in ophthalmology, where, for example, a decision regarding the intraocular lens (IOL) to be used must be made. The integration of machine learning-based methods into clinical systems shows great potential, but also entails specific risks, due, among other things, to their underlying "black box" nature. Therefore, any machine learning system used in a clinical device requires approval from regulatory authorities according to medical device principles.

For this purpose, an exchange of data with the authorities for approval is usually necessary. 1 schematically shows a chain of 10 intermediate results that must be transmitted to the authorities for approval. Furthermore, this data exchange must be repeated each time the ML system is modified by retraining. This is described in 1 indicated by the second chain after the second training.

The document US 2023/0081085 A1 Describes the management of changes to machine learning models deployed online in computing systems within a "Software as a Medical Device" (SaMD). These models, implemented in a medical domain, are continuously updated and monitored. All changes to the models are identified and subsequently certified to ensure that they continue to meet performance characteristics and compliance criteria. A distinction is made between "locked" (immutable) and "online" (dynamically learning and adapting) SaMD models. Changes to these systems must be preemptively approved by an approval authority such as the Food and Drug Administration (FDA).

However, this data exchange process is error-prone, requires significant resources, and, in particular, a functioning data connection to the authorities. Furthermore, the interaction can be very time-consuming, which can significantly delay the deployment of the updated ML system. As a result, patients may not be treated with the best available system, as it must first go through the complex exchange process with the authorities.

There is therefore a need for a technology that enables more efficient configuration of clinical systems that use machine learning for prediction in the medical field, especially ophthalmology, without compromising patient safety.

Overview of the invention

This task is achieved by the method described here, the corresponding system and the associated computer program product. The invention is solved according to the independent claims. Further embodiments are described by the respective dependent claims.

A first method aspect relates to a method for configuring a nonlinear decision system of a clinical device to support a clinical decision. The method comprises a step of acquiring a data set with a plurality of data points. At least some of the data points each comprise a pair of values. Each pair of values comprises an input value of an input of the decision system indicating patient data of a patient and an output value of an output of the decision system indicating the clinical decision for the patient or dependent thereon. The method further comprises a step of generating parameter values of a configuration of the decision system executed by a first server through machine learning (ML) based on a training data set that is a subset of the acquired data set. The method further comprises a step of determining a performance value of a performance metric of the decision system configured with the generated parameter values. Output values of the decision system configured with the parameter values in response to the input values of a validation data set are compared with the output values of the validation data set, which is a subset of the acquired data set that is disjoint from the training data set. The method comprises a step of sending (e.g., transmitting or providing) the generated parameter values for configuring the decision system executed by a second server in clinical use if (e.g., only if) the determined performance value meets a predetermined criterion.

Fulfillment of the specified criterion can be causal (e.g., as a necessary or sufficient condition) for the transmission of the parameter values. Furthermore, the transmission can be temporally related to the fulfillment of the specified criterion, for example, by triggering a timer upon fulfillment of the specified criterion. In a first variant, the generated parameter values for configuring the decision-making system executed by the second server in clinical use can be sent immediately and/or automatically upon fulfillment of the specified criterion (e.g., in real time). In a second variant, the parameter values can be sent automatically and/or within a defined period of time (e.g., within one day or one week, and/or outside of the operating hours of the clinical device). In a third variant, the sending of the parameter values may be subject to an additional condition (e.g. a trigger), for example a manual confirmation by an operator (e.g. at the first server or at the second server or at the clinical device accessing the second server) or in the course of a (e.g. regularly scheduled) update (e.g. of a firmware or other software or hardware component) of the clinical device.

The generated parameter values can be sent from the first server and/or to the second server (e.g., directly from the first server to the second server). For example, the generated parameter values can be provided to the second server using the push method. Alternatively or additionally, the first server can provide the parameter values using the pull method (e.g., to a shared memory area of the first and second servers) and/or upon request (technical term: "request").

Embodiments of the method solve the technical problem by first collecting patient data in the form of value pairs, each consisting of an input value (technical term: input) for the decision system and a corresponding output value (technical term: output) for a clinical decision. Based on a portion of this data, the so-called training data set, the decision system executed on a first server learns using machine learning (ML) and thereby generates parameter values for its configuration. The performance of this configured system is then evaluated by comparing generated output values of the system for a further data block separate from the training data set – the validation data set – with the actual clinical decisions. If the system achieves a performance standard determined by the performance value and the criterion, the parameter values are sent to a second server (e.g., transferred to a second server) to configure the decision system for everyday clinical use. The configured decision system, which is executed on the second server, can then be used in everyday clinical use. This enables the timely implementation of a newly adapted decision-making system and reduces the resource requirements and potential errors that could arise from complex and repeated external communications.

A preferred implementation of the method is an automated regulatory performance analysis for the approval of the clinical device or decision system as an ML system in a medical context.

The generation of parameter values by the ML may involve supervised machine learning (ML) using the value pairs.

In a first variant of each embodiment, each data point of the data set can comprise a value pair with an input value and an output value. In a second variant of each embodiment, the portion of the data points that each comprise an input value and an output value (i.e., comprise a value pair) can be a true subset of the data set. In the second variant, the validation data set can be a true subset of the data points with value pairs. Alternatively or additionally, the training data set can comprise both data points with value pairs (i.e., each with an input value and an output value) and data points without an output value. For example, the ML can comprise supervised learning of the parameter values using the data points with value pairs. Alternatively or additionally, the ML can comprise unsupervised learning using the data points without an output value.

For example, ML can determine clusters of input values (preferably using supervised and unsupervised learning or based on the input values of all data points). The input values of data points without an output value can also contribute to determining the clusters. Alternatively or additionally, ML can assign each determined cluster to an output value (e.g., an indication of the clinical decision for the patient). For example, clusters can be determined using unsupervised ML. Alternatively or additionally, supervised ML can assign the determined clusters to output values (e.g., clinical decisions), preferably with the clusters also including input values whose data point does not contain an output value (e.g., no value pair with an output value). The latter can be an example of semi-supervised ML (semi-supervised learning). For example, in the second variant, there may be too few output values available as annotations in the data set compared to the number of input values. In ML, the first server can assign the output values of the non-annotated data points (i.e., the data points without output values) from the subset of annotated data points (i.e., the data points with value pairs) to an existing output value.

The clinical device (e.g., a medical device) may be subject to approval. The specified criteria may include technical (e.g., all technical) requirements for approval of the clinical device. The method may be a manufacturing method for manufacturing the medical device or an updating method for updating the medical device. For example, the parameter values for the function of the medical device may be created and/or updated according to the method.

Embodiments of the method avoid repeated and time-consuming data communication with regulatory authorities, as the performance assessment is automated, integrated, and verifiable. Thus, a deployment process for an updated decision-making system in clinical use can be made more reliable and accelerated by performing a safety check according to the predetermined criterion without intervention. Errors and delays that could occur during (partially manual) data exchange are avoided. Reliable and compliant operation can be ensured through verifiable compliance with specified performance criteria, for example, relating to patient safety and efficacy.

The first server and the second server are preferably different, for example, differently configured. The difference between the first server and the second server can include the configuration of the respective server for different user profiles, a link to different input and output masks, and a different level of access or usage restrictions with respect to the system.

The first server can be a training server. The generation of the parameter values of the configuration can be part of a training phase. The generation of the parameter values of the configuration can take place outside of clinical use. The first server can be located outside the clinical device and/or inaccessible for clinical use (for example, due to an isolated data network). Alternatively or additionally, the second server can be an inference server. The execution of the decision system configured by the parameter values in clinical use can be part of an inference phase. The second server can be located in the clinical device and/or accessible for clinical use (for example, via a data network connection). The configured decision system can be designed to plan a surgical procedure.

The neural network executed by the second server and configured using the parameter values can be a neural network trained for clinical use. Sending (e.g., the Transmission or provision) of the generated parameter values may cause a change (e.g. updating) of the configuration of the decision system in clinical use, for example by the second server loading the received parameter values into a dedicated memory of the neural network of the decision system, e.g. a video shift register or VRAM.

The nonlinear decision system can be configured to output an output value based on an input value and depending on the generated parameter values. A (for example, numerical) relationship between the output value and the input value can be nonlinear, for example, due to activation functions in a neural network of the decision system or due to branches in a decision tree of the decision system.

The decision system may include an AI model for artificial intelligence (AI). The AI model may also be referred to as an ML model. The parameter values may include model parameters of the AI model. Alternatively or additionally, the nonlinear decision system may include a neural network. The parameter values may include weights of the neural network.

The training dataset can be many times more powerful than the validation dataset, i.e., the number of value pairs in the training dataset can be many times larger than the number of value pairs in the validation dataset. The term subset (or disjoint subset) can refer to the value pairs as elements of the dataset.

Generating the parameter values using machine learning can also be referred to as training. Machine learning can involve supervised learning. The input value containing patient data can be a feature, and the output value can be a target or label. The output values of the dataset can be ground-truth data. For example, at least the output values of the validation dataset can be ground-truth data.

Each value pair can comprise an input value with patient data from a single patient. The output value can comprise one or more values or signals to support clinical decision-making for that individual patient.

The decision system may comprise a neural network system, a logistic regression system, a decision tree system, and/or a support vector machine (SVM). Training the decision system using ML may minimize the value of a predetermined loss function step by step (i.e., iteratively). The loss function (also called a cost function or error function) may indicate how well the neural network system is trained. For example, the loss function measures the difference between the ("actual") output values (targets) of the training dataset and the ("predicted") output values (outputs) provided by the decision system. To minimize the loss function, training may involve a gradient descent process. In the gradient descent process, weights of the neural network system can be updated at each step, for example, in the opposite direction of the gradient of the loss function with respect to the weights.

Sending the generated parameter values may include storing the generated parameter values (e.g., in a memory of the first and/or second server) in a memory area containing the decision system released for use (i.e., for clinical use). This may physically manifest a process of releasing the decision system.

The method can iterate the acquisition of a data set, the generation of parameter values, and/or the determination of a performance value. The iteration (e.g., to meet the criterion) can be triggered by an internal event (internal to the first server) and/or if the determined performance value does not meet the specified criterion.

Furthermore, the method, including the iteration, can be repeated by means of an adaptation loop, for example triggered by an external event (external to the first server) and/or if a (preferably sufficiently) changed data set is available.

The first server can execute the method. For example, the first server can document the iteration.

Immediately at the time of terminating the iteration and/or upon sending the generated parameter values, a clinical usage property can be assigned to the generated parameter values, which indicates that the performance value for the generated parameter values has been determined and that the determined performance value meets the specified criterion. This means that the use of the parameter values for clinical use (i.e., for the decision-making system of the clinical device) is technically enabled. This enablement can be implemented by a label in the parameter value memory indicating the enablement or by a memory shared with the second server.

The sending and/or release of the parameter values can be complete, immediate, and sufficient for use by the second server. Optionally, the sent parameter values (e.g., the usage property) can include a checksum and/or encryption for modification-free transmission of the parameters and/or for authentication of the first server as the sender of the parameter values.

The release for use (i.e., for clinical use) of the decision system configured with the generated parameter values may mean that the second server (e.g., as the backend of the clinical device) has a query routine regarding the storage location of the decision system(s) released for use. As soon as a changed configuration of the decision system is detected in memory during a regular query, the query is answered positively and the changed configuration is uploaded to the second server. Such a query and upload routine would be inadmissible for a different storage location, which would correspond to waiting for approval of the clinical device with the changed configuration.

Determining the performance value and selectively sending the results if the performance value meets the specified criteria may involve a compliance review, which is equivalent in content to a traditional external audit for verifying compliance with legal regulations and guidelines. This may include independent reviews of data handling, model training, and/or result quality.

Determining the performance value and/or selectively sending it can be a release procedure. After successful verification and confirmation that the parameter values (i.e., the model) meet the specified criteria according to the determined performance value, the process can include the preparation of detailed reports and documentation for a regulatory authority. The latter can be performed independently or sequentially after the parameter values have been sent.

Selective sending may include an automated or semi-automated release mechanism to release the parameter values for clinical use. In response to the sent parameter values, the second server may implement them in the clinical environment, for example, integrating the parameter values (i.e., the approved model) into clinical systems using secure and privacy-compliant interfaces. Alternatively or additionally, the second server may configure notifications or dashboard displays for clinical users to access the decision-making system configured with the parameter values.

In a variant of each embodiment, the method (e.g., determining the performance value of the performance metric) does not include communication with a data server or communication with a server other than the second server.

The method can send a documentation message regarding the configuration of the decision system. The documentation message can be sent to a third server. The third server can be different from the first server. Alternatively or additionally, the third server can also be different from the second server. Furthermore, the first server and/or the second server (and, if present, the third server) can be servers of a server farm. The server farm can comprise a group of networked computers that jointly provide the functionality of one of the servers mentioned here. The multiple computers of a server farm can be connected to form a logical system and distribute the load and computing power among themselves. Alternatively or additionally, the server farm can physically run in a data center, optionally with virtualization technology. Alternatively or additionally, the server farm can comprise a group of networked computers, each providing the functionality of one of the servers mentioned here. For example, the first server and/or the second server (and, if present, the third server) can be different areas, optionally based on virtualization technology, of a server farm or a large server. It is expedient for the first server and/or the second server (and, if present, the third server) to be distinguishable from one another.

The method (for example, generating the parameter values of the configuration of the decision system) can be carried out in response to a (for example quantitative and/or qualitative) change in the data set compared to a previous generation of the parameter values or compared to a previous transmission of the generated parameter values and/or in Paths of an adaptation loop are repeated. The adaptation loop can be superordinate to the iteration, ie, the control loop for fulfilling the criterion, and can include the control loop as an outer loop and the inner loop as the control loop.

The documentation message can specify at least one of the following contents. The documentation message can specify a reason for generating the parameter values of the decision system configuration. Alternatively or additionally, the documentation message can specify a quantitative or qualitative change in the data set compared to a previous generation of the parameter values of the decision system configuration. Alternatively or additionally, the documentation message can specify a quantitative or qualitative change in the data set compared to a previous transmission of the generated parameter values of the decision system configuration. Alternatively or additionally, the documentation message can specify the specific performance value of the performance metric. Alternatively or additionally, the documentation message can specify documentation of the iteration.

The first server can be a training server for the ML (i.e., machine learning) of the decision system. Alternatively or additionally, the second server can be an inference server for the clinical use of the decision system. Alternatively or additionally, the third server can be a data server for audit-proof documentation of the decision system's configuration.

The first server and/or the second server may include or employ graphics processing units (GPUs). The first server may use GPUs to generate the parameter values using ML. The second server may use GPUs to evaluate the decision system configured according to the parameter values, i.e., to determine the output value of the decision system in response to an input value from a patient in clinical use. The third server may not include or employ GPUs, or the third server may exclusively include or employ application processors (Central Processor Units, CPUs) or general-purpose processors (GPPs).

A processor architecture of the first server and/or the second server can comprise highly parallelized hardware designed to process large amounts of data simultaneously. The first server and/or the second server can comprise hundreds or even thousands of cores (compared to the few, but more complex cores of a CPU) that are specialized to perform a large number of similar operations very efficiently. Alternatively or additionally, each core of the GPU can be configured to perform the same operation on different data (technically known as "single instruction, multiple data", SIMD). Alternatively or additionally, the GPUs of the first server and/or the second server can access a local memory (technically known as "shared memory"), which enables data to be shared efficiently between different cores.

The third server can be optimized to store large volumes of documentation messages (for example, with mechanisms for redundancy and data integrity or audit-proof archiving) and make them efficiently available for secure queries. The third server can be part of a database management system (DBMS) and apply functions such as indexing, transactions, caching, and replication to the documentation messages sent to it.

The second server can be specifically configured to run the decision system as an ML model, particularly for the inference process. The inference process can involve applying the decision system configured using the parameter values (i.e., "trained") to input values not contained in the dataset (i.e., "new") in order to support clinical decisions using the resulting output value. The inference can be performed in real-time or near-real-time, for example, through optimization for computationally intensive operations.

The clinical device may include a front-end configured to access the second server as a back-end. In other words, the second server may be configured to receive an input value from the clinical device as a back-end and send the corresponding output value from the decision system executed by the second server to the clinical device.

A second method aspect relates to a method executed by the second server for executing a decision system in clinical use of a clinical device to support a clinical decision based on a data set with a plurality of data points. At least some of the data points each comprise a value pair with an input value of an input of the decision system indicating patient data of a patient and a clinical decision for the patient. specifying or dependent on an output value of an output of the decision system. The method comprises the step of selectively receiving parameter values from a first server at the second server. The parameter values from the first server are generated by machine learning (ML) on the basis of a training data set that is a subset of the data set. The selection of the receipt depends on a performance value of a performance metric of the decision system configured with the generated parameter values meeting a predetermined criterion, wherein the performance metric comprises a comparison of output values of the decision system configured with the parameter values in response to the input values of a validation data set with the output values of the validation data set, which is a subset of the data set that is disjoint from the training data set.

The fact that the parameter values meet the specified criterion can be determined (e.g., partially or completely) by the first server, for example, by configuring the decision system executed by the first server (e.g., a development version of the decision system) with the parameter values (e.g., modified by the ML). Thus, preferably, the second server can only receive parameter values that already meet the specified criterion. Alternatively or additionally, the second server can determine the performance value of the performance metric using the received parameter values, whereby the parameter values are discarded and/or not configured for clinical use if the specified criterion is not met.

• • Erfassen (beispielsweise Empfangen von der klinischen Vorrichtung) des Eingabewertes (beispielsweise eines präoperativen Eingabewertes für den Patienten, beispielsweise für einen ersten Patienten);
• • Erzeugen (beispielsweise mittels des konfigurierten Entscheidungssystems) des Ausgabewertes (beispielsweise für eine Entscheidung oder einen Vorschlag für die Entscheidung) für den Patienten (beispielsweise für den ersten Patienten), vorzugsweise unter Zugriff auf das Entscheidungssystem in einem trainierten Zustand unter Verwendung der Eingabewerte für den ersten Patienten;

• • Ermitteln (beispielsweise Empfangen von der klinischen Vorrichtung) von postoperativen Messdaten eines klinisch real erzielten Ergebnisses (d.h. eines Resultats) des Patienten, vorzugsweise als Teil eines neuen Wertepaares auf Basis des ersten Patienten für weitere Patienten und/oder für einen augmentierten Datensatz;
• • Exportieren (beispielsweise Senden an den ersten Server) des erfassten präoperativen Eingabewertes für den ersten Patienten und/oder des erzeugten Ausgabewertes für den ersten Patienten und/oder der ermittelten postoperativen Messdaten für den ersten Patienten als Teil eines neuen oder augmentierten Datensatzes zum (beispielsweise erstmaligen oder erneuten) Trainieren des Entscheidungssystems gemäß einer Anpassungsschleife (die vorzugsweise der Regelschleife der Iteration übergeordnet ist); und
• • Empfangen der (beispielsweise aktualisierten) Parameterwerte für das Entscheidungssystem, deren bestimmter Leistungswert das vorgegebene Kriterium erfüllt und/oder wobei der zweite Server den Leistungswert der Leistungsmetrik aufgrund der empfangenen Parameterwerte bestimmt bei Erfüllung des Kriteriums abgleicht.

Alternatively or additionally, the second server (for example in clinical use of the decision system) can perform at least one of the following steps:

• • Capturing (e.g., receiving from the clinical device) the input value (e.g., a preoperative input value for the patient, e.g., for a first patient);
• • Generating (for example by means of the configured decision system) the output value (for example for a decision or a proposal for the decision) for the patient (for example for the first patient), preferably by accessing the decision system in a trained state using the input values for the first patient;

• • Determining (e.g., receiving from the clinical device) postoperative measurement data of a clinically real achieved outcome (i.e., a result) of the patient, preferably as part of a new pair of values based on the first patient for further patients and/or for an augmented data set;
• • Exporting (e.g., sending to the first server) the acquired preoperative input value for the first patient and/or the generated output value for the first patient and/or the determined postoperative measurement data for the first patient as part of a new or augmented dataset for training (e.g., for the first time or again) the decision system according to an adaptation loop (preferably overriding the iteration control loop); and
• • Receiving the (e.g. updated) parameter values for the decision system, the determined performance value of which satisfies the specified criterion and/or wherein the second server adjusts the performance value of the performance metric based on the received parameter values when the criterion is met.

The method according to the first and/or second method aspect can further be triggered and/or repeated in an adaptation loop, preferably in response to a predefined external event outside the generation of the parameter values and/or outside the first server. For example, the external event can comprise a predefined quantitative or qualitative change in the data set compared to existing parameter values or a previous generation of the parameter values of the decision system configuration, or compared to a previous transmission of the generated parameter values of the decision system configuration.

The triggering of the procedure or the repetition of the procedure according to the adaptation loop can be decided in an additional step of the procedure. The external event can include reaching a critical number of new data points (e.g., new value pairs) for starting the adaptation loop.

The adaptation loop may include monitoring and/or maintenance of the decision system in clinical use. For example, according to the performance metric, the model's performance in clinical use can be continuously monitored (which is not included in the conventional approval process) and adjusted as needed using the process, for example, to extend the accuracy and relevance of the decision to a wider patient population. Alternatively, or In addition, regular updates of the configuration and/or repetition of the validation and release process according to the procedure for new versions of the configuration can continuously improve the decision system.

This adaptation loop can, in contrast to the control loop for fulfilling the criterion, serve as an outer loop for adapting the decision system to new data points or conditions (e.g., an expanded set of implants).

The additional step of triggering the method and/or repeating the method according to the adaptation loop may comprise at least one of the sub-steps described below: a sub-step for evaluation, for example of the performance of the current configuration with a new data set with new value pairs; a sub-step for decision, for example of determining whether the change in the data set is significant enough to justify an adaptation of the configuration; an adaptation sub-step, for example wherein the decision system is retrained or fine-tuned using new data points in order to better respond to the new patterns or changes in the changed data set; and an integration sub-step, for example wherein the adapted configuration is adopted into the production environment of the second server according to the sending step in order to enable current predictions.

The control loop according to the iteration step and the higher-level adaptation loop can have the synergistic effect of shortening the time between a change in the data set and the adjustment of the decision system's configuration in clinical use, for the benefit of patient care. Alternatively or additionally, the adaptation loop can include monitoring mechanisms to ensure that the configuration is not over-adapted and/or that the new data points in the modified data set do not steer the decision system in the wrong direction.

According to one system aspect, a system for configuring a nonlinear decision system of a clinical device for supporting a clinical decision is provided. The system comprises a first server configured to execute the method according to the first method aspect, and a second server configured to execute the decision system and/or the second method aspect based on the parameter values transmitted by the first server.

According to a system method aspect, the steps of the first and second method aspects are combined.

The input value of each value pair in the dataset may include patient data from the patient before the clinical decision was applied. For example, the input value of each value pair in the dataset may only include patient data from the patient before the clinical decision was applied.

Alternatively or additionally, the method may comprise the output value of each value pair of the data set comprising patient data of the patient after applying the clinical decision. Alternatively or additionally, the output value of each value pair of the data set may comprise the clinical decision for the patient.

Alternatively or additionally, the method may include the input value of each value pair of the data set comprising patient data of the patient before application of the clinical decision and the clinical decision for the patient. In this case, the output value of each value pair of the data set may comprise patient data of the patient after application of the clinical decision.

The decision system may be a decision system for restricting or determining (e.g., for pre-selecting or selecting) an implant. For example, according to the generic term "a decision system of a clinical device for supporting a clinical decision," a decision system of a clinical device may be for determining (e.g., for selecting) an implant.

This means that the decision system can be used, for example, to select or suggest an implant or to make or prepare another clinical decision. The decision of the decision system can be a suggestion that can be followed, but does not have to be. For example, the clinical device can comprise a user interface configured to obtain confirmation or a change (e.g., the decision) from a user (e.g., physician, surgeon, operator) before accepting the parameter values from the first server and/or before accepting an output value (e.g., the decision) from the decision system.

In one variant, if the input value includes the clinical decision for the patient (for example, indicates), a clinically An output value dependent on the clinical decision must be present, e.g. in the sense of the second alternative in the step of capturing claim 1. This allows the decision system to either reinforce the intended clinical decision (e.g., verify) or mark the clinical decision for revision (e.g., falsify).

The clinical decision can comprise a selection of an implant for the patient (for example, from a discrete set of implants) or a pre-selection of a subset of implants for the patient from a discrete set of implants. Alternatively or additionally, the clinical decision can comprise a set of parameters for a patient's implant. Alternatively or additionally, the clinical decision can comprise a control data set for additive and/or subtractive manufacturing of an implant for the patient. Alternatively or additionally, the clinical decision can comprise a control data set for a laser system for refractive surgery, for example for laser-assisted in situ keratomileusis (LASIK) for the patient. Alternatively or additionally, the clinical decision can comprise a control data set for a robot-assisted surgery system for the patient.

The decision system may be a decision system to support clinical decision-making, for example to determine an implant.

The set of parameters can specify material, mechanical and/or optical properties of the implant, for example a refractive power of an intraocular lens (IOL) as the implant to be selected.

In a first variant of each embodiment, the implant can comprise a hip endoprosthesis with a femoral head and/or acetabulum. The patient data can include the patient's biometric data. Based on the configuration with the generated parameter values, the decision system can be configured to optimally adapt a surgery and the prosthesis, for example, to minimize the risk of complications. The patient data can include at least one of the following body measurements: height, weight, hip-specific measurements, leg length, femoral head size (to determine the size of the required prosthetic head), stem diameter, and acetabulum size (size of the acetabulum). The input value of the decision system's input can include results from imaging procedures, for example, X-rays (for example, to determine bone structure, existing wear, and alignment of the hip joints by the decision system) or results from magnetic resonance imaging (MRI) or computed tomography (CT) (for example, to determine soft tissue structure, bone quality, and spatial representation of the hip joint by the decision system).

In a second variant of each embodiment, the implant may comprise an intraocular lens.

The patient data may include biometric data of the patient's eye. The clinical decision may include the selection of an intraocular lens (IOL) to be implanted.

The patient data includes biometric data of the patient's eye. The clinical decision involves selecting an intraocular lens to be implanted.

The biometric data of the eye before the application of the decision may include axial length, keratometry, and/or anterior chamber depth. Alternatively or additionally, the biometric data of the eye before the application of the decision may include endothelial cell density and/or intraocular pressure. Alternatively or additionally, the biometric data of the eye before the application of the decision may include a deviation of the eye's refractive power from the norm.

A point in time before the decision is applied may correspond to a preliminary examination. A point in time when the decision is applied may correspond to the implantation of the intraocular lens. A point in time after the decision is applied may correspond to the time when the implantation has healed.

The biometric data of the eye after application of the decision may include a deviation of the refractive power of the eye from the norm or a deviation of the refractive power of the eye from a target value of the implantation.

Capturing the data set may include data cleansing.

Acquiring the dataset may exclude value pairs. The excluded value pairs may concern patient data indicating that a deviation from a norm or target value occurred after the decision was applied. The deviation may be greater than a predetermined threshold. For example, there may be a deviation in the refractive power of the eye from a norm or target value of the implantation.

The threshold can be 1 diopter (D).

Alternatively or additionally, each value pair can be assigned to a clinical person or clinical location. Value pairs of a clinical person or clinical location whose standard deviation between the patient data after applying the decision and the norm or target value exceeds a predetermined threshold can be excluded when capturing the data set.

Alternatively or additionally, the specified criterion (for sending the generated parameter values) can be met if value pairs whose patient data show a deviation from a norm or target value after the application of the decision are output (i.e., predicted) more accurately by the decision system configured with the generated parameter values than by a previous decision system (or the decision system in a previous state).

In a third variant of each embodiment, the clinical decision can relate to surgical planning, for example, the planning of a neurosurgical operation. The patient data available at the input of the decision system can include results from diagnostic imaging, for example, an MRI (for example, for visualizing brain structures, soft tissue, and identifying pathological changes such as tumors or vascular anomalies) or a CT scan (for example, for determining bone structures, bleeding, or, if necessary, emergency diagnostics by the decision system). Alternatively or additionally, the patient data available at the input of the decision system can include physiological parameter values, for example, an intracranial pressure (ICP), a cerebral perfusion pressure (CPP), or a cerebrospinal fluid pressure (CSF). Alternatively or additionally, the patient data available at the input of the decision system can include results from a test of neurological functions, for example, an assessment of the level of consciousness (e.g., according to the Glasgow Coma Scale), motor and sensory functions, reflexes, speech, and coordination skills.

In a fourth variant of each embodiment, the clinical decision may relate to therapy planning. For example, the output value at the output of the decision system may indicate a drug selection, a dosage, and/or a frequency of administration.

A first device aspect relates to a first server configured to execute the first method aspect. For example, the first server comprises units each configured to execute corresponding steps of the first method aspect. Alternatively or additionally, the first server may comprise a memory and a processing unit signal-connected to the memory, which is configured to execute instructions encoded in the memory, wherein the memory comprises instructions according to the steps of the first method aspect.

A second device aspect relates to a second server configured to execute the second method aspect. For example, the second server comprises units each configured to execute corresponding steps of the second method aspect. Alternatively or additionally, the second server may comprise a memory and a processing unit signal-connected to the memory, which processing unit is configured to execute instructions encoded in the memory, wherein the memory comprises instructions according to the steps of the second method aspect.

A third device aspect relates to a system for configuring a nonlinear decision system of a clinical device for supporting a clinical decision, which can be considered associated with the method of the first aspect. This system comprises a processor, a memory operatively cooperating with the processor for storing instructions that, when executed by the processor, cause the processor to execute the method aspect.

Furthermore, embodiments may relate to computer program products accessible from a computer-usable or computer-readable medium comprising program code for use by, or in connection with, a computer or other instruction processing system. These computer program products cause the computer to perform the method aspect. In the context of this description, a computer-usable or computer-readable medium may be any device suitable for storing, communicating, forwarding, or transporting the program code.

Overview of the characters

It should be noted that embodiments of the invention may be described with reference to different implementation categories. In particular, some Embodiments are described with reference to a method, while other embodiments may be described in the context of corresponding devices or systems. Irrespective of this, it is possible for a person skilled in the art to recognize and combine possible combinations of the features of the method, as well as possible combinations of features with the corresponding system, from the above and following descriptions, unless otherwise indicated, even if they belong to different claim categories.

Aspects already described above as well as additional aspects of the present invention result, inter alia, from the described embodiments and from the additional further concrete embodiments described with reference to the figures.

• 1 herkömmliche Entwicklungsketten, die jeweils eine technische Interaktion mit regulatorischen Behörden erfordern, bevor das jeweils resultierende System klinisch einsetzbar ist;
• 2 eine flussdiagrammartige Darstellung eines Ausführungsbeispiels eines Verfahrens zur Konfiguration eines nichtlinearen Entscheidungssystems einer klinischen Vorrichtung zur Unterstützung einer klinischen Entscheidung;
• 3 ein erstes Ausführungsbeispiel eines Systems zur Konfiguration eines nichtlinearen Entscheidungssystems einer klinischen Vorrichtung zur Unterstützung einer klinischen Entscheidung;
• 4 ein zweites Ausführungsbeispiel des Systems zur Konfiguration eines nichtlinearen Entscheidungssystems einer klinischen Vorrichtung zur Unterstützung einer klinischen Entscheidung mit einer detaillierteren Datenstruktur;
• 5 eine Ausgestaltung des Verfahrens mit einer ersten Zuordnung von Wertepaaren zu Ein- und Ausgängen des Entscheidungssystems;
• 6 eine Ausgestaltung des Verfahrens mit einer zweiten Zuordnung von Wertepaaren zu Ein- und Ausgängen des Entscheidungssystems;
• 7 eine Ausgestaltung des Verfahrens mit einer dritten Zuordnung von Wertepaaren zu Ein- und Ausgängen des Entscheidungssystems;
• 8 eine Ausgestaltung des Verfahrens mit einer vierten Zuordnung von Wertepaaren zu Ein- und Ausgängen des Entscheidungssystems;
• 9 eine schematische Schnittansicht eines menschlichen Auges mit exemplarischen biometrischen Patientendaten;
• 10 ein drittes Ausführungsbeispiel des Systems zur Konfiguration eines nichtlinearen Entscheidungssystems einer klinischen Vorrichtung zur Unterstützung einer klinischen Entscheidung mit verketteten funktionalen Modulen, die dazu ausgebildet sind, das Verfahren der 2 auszuführen;
• 11 ein viertes Ausführungsbeispiel des Systems zur Konfiguration eines nichtlinearen Entscheidungssystems einer klinischen Vorrichtung zur Unterstützung einer klinischen Entscheidung mit Busmodulen, die dazu ausgebildet sind, das Verfahren der 2 auszuführen; und
• 12 ein Ausführungsbeispiel eines Computersystems, welches das System entsprechend 3 aufweist.

Preferred embodiments of the present invention are described by way of example and with reference to the following figures.

• 1 traditional development chains, each of which requires technical interaction with regulatory authorities before the resulting system can be used clinically;
• 2 a flowchart representation of an embodiment of a method for configuring a nonlinear decision system of a clinical device for supporting a clinical decision;
• 3 a first embodiment of a system for configuring a non-linear decision system of a clinical device for supporting a clinical decision;
• 4 a second embodiment of the system for configuring a non-linear decision system of a clinical decision support device with a more detailed data structure;
• 5 a design of the procedure with a first assignment of value pairs to inputs and outputs of the decision system;
• 6 a design of the procedure with a second assignment of value pairs to inputs and outputs of the decision system;
• 7 a design of the procedure with a third assignment of value pairs to inputs and outputs of the decision system;
• 8 a design of the procedure with a fourth assignment of value pairs to inputs and outputs of the decision system;
• 9 a schematic cross-sectional view of a human eye with exemplary biometric patient data;
• 10 a third embodiment of the system for configuring a non-linear decision system of a clinical device for supporting a clinical decision with linked functional modules which are designed to implement the method of 2 to carry out;
• 11 a fourth embodiment of the system for configuring a non-linear decision system of a clinical device for supporting a clinical decision with bus modules which are designed to implement the method of 2 to carry out; and
• 12 an embodiment of a computer system which implements the system according to 3 has.

Detailed character description

In the context of this description, conventions, terms and/or expressions should be understood as follows:

The term “intraocular lens” (IOL) describes an artificial lens that is inserted into an eye, for example during cataract surgery, thereby replacing the eye’s natural lens.

The term “patient data,” in particular “ophthalmological patient data” and “biometric patient data,” can here describe patient-specific measurement data, in particular of a patient’s eye, which is preferably available directly or in temporarily stored form—e.g., in a patient measurement data storage device.

The term “clinical decision” can refer to the determination of a technical approach in clinical use or the limitation of alternative technical approaches in clinical use.

The term “application” or “implementation” of a clinical decision may refer to a therapeutic or surgical measure performed outside the procedure (e.g., deferred) that uses a technical resource in accordance with the clinical decision, for example, an implant or a control data set for Control of a surgical robot. Furthermore, the clinical decision can include an instruction or a suggested course of action (e.g., in the form of a workflow).

The term "data set" here specifically describes a set of value pairs, each with input values and output values. A data structure of the input values corresponds to the input of the decision system and can therefore be created there. A data structure of the output values corresponds to the output of the decision system and can therefore be read from there or used to configure the decision system using backpropagation.

The term “post-decision patient data” or “result” or “outcome” may describe, as part of the data set, a measured result of previous clinical decisions, for example in the context of the first server and/or in a training phase, in particular a target refraction value which describes the postoperatively measured refraction value.

Alternatively or additionally, the term “patient data after the decision” or “outcome” or “outcome” can refer to a predetermined or desired result of a clinical decision to be made, for example in the context of the second server and/or in an inference phase in clinical use, in particular a target refraction value which describes the postoperatively desired refraction value.

The term "physical model" or "physical-optical model" can be used to describe, using a formula or relationship, known dependencies of the expected refractive power of an IOL to be inserted, depending on the decision for a specific IOL (or a specific IOL type) and on ophthalmic patient data (as an example: patient data before the decision is applied). Various models are known. A pair of values with patient data and a decision regarding the IOL to be inserted, for which there is a significant deviation between patient data (e.g., refractive power) after the decision is applied and patient data (e.g., refractive power) according to the physical model (e.g., > 1 D), can be described as "surprising" and/or be a criterion for exclusion during data cleansing when capturing the data set.

The decision system can be configurable through machine learning (ML), i.e., a "machine learning system" (ML system). The term ML system can describe a nonlinear and nonprocedural system whose behavior with respect to input values and the resulting output values (e.g., at the respective inputs and outputs of the decision system) is conditioned by a learning process in which pairs of values—i.e., both input values and output values—are used as example data. During the learning process, the parameter values of the decision system are optimized (usually by minimizing a loss function) so that after the completion of the learning (i.e., "training"), the configuration of the decision system is available to predict output values based on new (i.e., unknown in the sense of unlearned) input values (e.g., individual patient data). The optimization process can, for example, be performed via backpropagation of gradients of a loss function for differences between the output values 117-T generated during training and the desired output values 117 according to the training dataset. Various architectures for machine learning systems are known. One example is a neural network, in particular a deep neural network.

The term “ground truth data” generally describes target data or desired prediction results of a machine learning system’s prediction that are used during the training of the machine learning system to condition the machine learning system, i.e., to determine the parameter values.

The term "machine learning model" (ML model) typically describes a set of parameters (e.g., the configuration) that make up the machine learning model. This ML model, i.e., the configuration, is used in the decision-making system as a machine learning system. Optionally, additional configuration parameters of the machine learning itself (i.e., hyperparameters) can also be included in the ML model.

The terms "training dataset" and "validation dataset" here specifically describe disjoint subsets of the dataset. Thanks to data cleaning, "outliers" among the value pairs should not be present in the training dataset or the validation dataset.

The determined "performance value" is a concrete evaluation of the configured decision system (i.e., the decision system configured with the generated parameter values) according to a "performance metric." This evaluation determines whether the specified criterion is met by the configured decision system or not. The performance metric and/or specified criterion can be any or all technical conditions. include conditions that are traditionally part of an approval for an individual clinical device with an ML system, such as safety and effectiveness.

• - Die Standardabweichung ist kleiner (vorzugsweise signifikant kleiner) im Vergleich zu einer IOL-Berechnung nach HAIGIS (d. h. der Haigis-IOL-Kalkulationsformel oder kurz: Haigis-Formel), beispielsweise als Teil eines Heteroskedastizitätstests, fachsprachlich: „Heteroscedastic Test“).
• - Der mittlere absolute Fehler (fachsprachlich: „Mean Absolute Error“) ist kleiner (vorzugsweise signifikant kleiner) als bei der Haigis-Formel.
• - Ein Anteil der Vorhersagen, die in einen Fehlerbereich von +/-0.5 dpt fallen, ist beim konfigurierten Entscheidungssystem 102 größer als bei der Haigis-Formel.
• - Ein Anteil der Vorhersagen, die außerhalb eines Fehlerbereichs von +/-1.0 dpt fallen, ist beim konfigurierten Entscheidungssystem 102 kleiner als bei der Haigis-Formel. Mit anderen Worten, es werden weniger refraktive Überraschungen (definiert als Fehler > 1.0 dpt) erzeugt als bei der Haigis-Formel.

For example, in the case of a clinical decision regarding an IOL, the performance metric and/or the predefined criterion may include one or each of the following conditions:

• - The standard deviation is smaller (preferably significantly smaller) compared to an IOL calculation according to HAIGIS (i.e. the Haigis IOL calculation formula or Haigis formula for short), for example as part of a heteroscedasticity test, technically known as a “heteroscedastic test”).
• - The mean absolute error (technically known as “Mean Absolute Error”) is smaller (preferably significantly smaller) than in the Haigis formula.
• - A proportion of predictions that fall within an error range of +/-0.5 dpt is larger for the configured decision system 102 than for the Haigis formula.
• - The proportion of predictions that fall outside an error range of +/-1.0 D is smaller for the configured decision system 102 than for the Haigis formula. In other words, fewer refractive surprises (defined as errors > 1.0 D) are generated than with the Haigis formula.

Alternatively or additionally, the performance metric and/or the specified criterion may demonstrate clinical safety and efficacy according to a performance comparison (technically known as “benchmarking”) with other closed-form formulas and/or procedural predictions, which are used in aggregate to decide in step 206, 208 and/or 210 whether the configuration generated in step 204 (i.e., the parameter set) should actually be released according to step 208.

Safety can be defined by the risk of the procedure 200, for example the standard deviation, the number of outliers, and/or the number of data in a certain error range.

The effectiveness (technical term: "effectiveness") can be defined by a benefit of the method 200 compared to a conventional prediction (for example, based on a closed formula or a procedural prediction). These can be similar or identical conditions and variables as in the aspect of safety. The focus of the effectiveness can be on highlighting features or cases in which the decision system 102 resulting from the method 200 is more accurate than the conventional prediction. An example would be greater accuracy (for example, a significantly smaller error) in a sub-area of the data set 110 (for example, a sub-area of the validation data set 110-2), for example, with "short" eyes 900.

A detailed description of the figures is provided below. It is understood that all details and instructions in the figures are shown schematically. According to a prior art, a flowchart-like representation of an embodiment of the computer-implemented method aspect of the invention is first presented. Further embodiments of the corresponding system are described below.

1 schematically shows two chains 10 of intermediate results in the conventional configuration creation process, which must be submitted to the authorities for approval and each must await a release response before clinical use. This bidirectional data exchange must be repeated whenever the behavior of the clinical device changes, especially if the ML system has been modified by retraining.

2 depicts a flowchart representation of a preferred embodiment of the computer-implemented method 200 for configuring a nonlinear decision system. The configured nonlinear decision system serves a clinical device for supporting a clinical decision.

The method 200 may begin with the step of acquiring 202 a data set containing patient data. This data set contains a plurality of data points, in particular value pairs, where each pair comprises an input value (e.g., relating to a patient) and a corresponding output value (e.g., indicating the clinical decision for that patient). Acquiring the data set may optionally include data cleansing; for example, conspicuous data points (preferably conspicuous value pairs) may be excluded.

A pair of values can be a data point, or a data point can comprise a pair of values. The data set can be referred to as data points. Each input value can comprise one or more numerical values, i.e., the input value can be a It can be an input scalar (e.g., a single numerical value or a geometric invariant), an input vector (e.g., a list of numerical values or a geometric object), or a tensor (e.g., of level two or higher). The input value can belong (e.g., in terms of its format) to an input of the decision system. The same applies to the single- or multi-valued output value of an output of the decision system.

For each pair of values, the input value (e.g., vector-valued) can specify patient data (e.g., biometric data) before implementation of the clinical decision (e.g., in the form of the biometrics of an eye) and, optionally, the decision itself (e.g., the refractive power of an IOL to be implemented). The output value can include patient data after implementation of the clinical decision, which, for example, indicate the outcome of the implementation of the clinical decision (in technical terms, the outcome, e.g., in the form of a refractive result).

A pair of values alone does not constitute an assessment of the refractive outcome. For example, a so-called "refractive surprise" exists in the data set if a prediction method (e.g., one not based on ML) produces a prediction of the refractive outcome that deviates from the actual refractive outcome by more than 1 D. The prediction method can be defined by a closed formula. Thus, for one formula, a pair of values can be a refractive surprise, but for another, it is not. Generally speaking, an underlying model is required that can be used to calculate the expected patient data after the clinical decision (e.g., the refractive outcome) has been implemented in order to assess a pair of values as "surprising." Optionally, "surprising" pairs of values can be excluded during data cleansing.

In the next step, generation 204, parameter values for a configuration of the decision system are generated using machine learning (ML). This is based on a portion of the initially acquired data set, the so-called training data set.

Subsequently, and independently of the ML, a performance value is determined in step 206 based on a performance metric. This checks how well the configured decision system functions with the previously generated parameter values by comparing the output values of the decision system, which it provides in response to the input values of a validation dataset, with the actual output values of the validation dataset.

A first server carries out at least the generation 204 of the parameter values of the configuration of the decision system. Preferably, the same first server also determines the performance value for the corresponding configuration.

If the performance value determined in step 206 meets a predefined criterion (e.g., exceeds a threshold), these generated parameter values are sent 208 immediately, i.e., without conditional communication with a regulatory authority or its approval, to configure the decision system on a second server for clinical use. Immediate approval can therefore be an automated approval on the part of the first server without additional approval communication, for example, without any communication at all, or without bidirectional communication, or without an approval response (e.g., with the third server or an regulatory server). For example, unidirectional communication may be acceptable for documentation purposes, as it does not cause a pause in the process. Alternatively or additionally, bidirectional communication with the clinical device 100 may be acceptable to confirm the configuration of the decision system changed according to the parameter values (e.g., by a physician), since the time of the update is then at the discretion of the clinic.

To physically manifest the release of the decision system, the method 200 may use a label in the memory of the parameter values indicating the release. Alternatively or additionally, the method 200 may utilize memory areas released (e.g., dedicated or exclusive) for the second server. Thus, the method 200 may include transferring the parameter values to the released memory area for physically manifesting the release of the decision system.

Optionally, for example, as an alternative to sending 208, the method 200 may also include iterating 210 steps to repeat the collection 202 of data sets, the generation 204 of parameter values, and/or the determination 206 of performance values if the specified predefined criterion is not met or if another predefined criterion is met. In this case, the first server, which acts as a training server, may document the iteration.

It is also possible that the method 200 for configuring the decision system in response to qualitative and/or quantitative tative changes to the data set are carried out.

Additionally, the flowchart shows two optional iteration loops (shown as dashed lines), which can be implemented alternatively or together. During iteration 210 or the event-driven execution of the method 200, hyperparameters of the machine learning (ML) can be changed in step 204. Alternatively or additionally, other data values, for example, an amended or updated data set, can be used as the basis for generating 204 the configuration. Optionally, both the data set and the hyperparameters of the learning process can be adjusted, for example, by making a learning rate of the ML in step 204 dependent on the homogeneity of the data set. For example, a more inhomogeneous data set may require a smaller learning rate.

Here, the learning rate can be a hyperparameter that refers to the generation of parameter values by ML (i.e., training) of models (e.g., neural networks). It defines a step size from one epoch to the next, i.e., how quickly training progresses. A higher value can potentially accelerate convergence within the step. However, the higher the learning rate, the greater the risk of missing details in the dataset.

It is noteworthy that iteration 210 and the specified criterion do not relate to the ML. An inner iteration based on the hyperparameters (e.g., based on the learning rate) takes place within step 204 in the ML. Step 206 for deciding whether the approval criterion is met or not is a step superior to the ML within step 204. Accordingly, the selective iteration 210 is an outer iteration loop relative to the inner iteration within step 204, which is essential for generating 204 the parameter values of the configuration.

Optionally, the method includes sending 212 a documentation message containing information about the configuration of the decision system. The documentation message is sent to a third server that is different from the first server and the second server. The documentation message may specify a reason for generating the parameter values, describe the change in the data set, describe the change in the hyperparameters, contain the determined performance value (e.g., the last determined performance value that led to the release, i.e., the sending 208), and/or the documentation of the iteration (e.g., the determined performance value(s) that were insufficient for release in step 208).

The decision system itself can consist of various systems such as a neural network, a logistic regression system, a decision tree system, or a support vector machine. Based on the method 200, it can be configured for specific medical tasks, such as the (pre-)selection of implants or support during surgical procedures.

All steps of the procedure can be carried out temporally (especially causally) before the implementation of a clinical decision, supported by the configured decision system.

For illustrative purposes, and without being limited to this, reference symbols 1XY are occasionally referenced below, which appear in the figures from 3 are shown.

With respect to biometric patient data, the method 200 may, for example, prepare for the use of the decision system 102 in ophthalmology, where the restrictive preselection or selection of an intraocular lens (IOL) to be implanted, as an example of the clinical decision, is made based on the biometric data of the patient's eye as input value 113. In this case, the patient data 114 and/or 115 may include, among other things, the axial length, keratometry (i.e., the measurement of the cornea), and the anterior chamber depth of the eye. Further examples of the biometric patient data 114 and/or 115 are described above for neurosurgical procedures and hip prostheses and below for ophthalmology.

Embodiments of this method 200 solve the problem of delayed updating of the decision system 102 mentioned at the outset by integrating the security check of the decision system 102 as an ML system into the creation process 204 of the decision system 102 in step 206 - and the associated selectivity of step 208 (and optionally the complementary step 210) - so that after training 204 has taken place, the configuration 120 can be classified as secure and reliable without further data exchange with (in particular without feedback from) a third server 108 and independent of time, i.e., the sending 208 takes place and the decision system 102 is immediately ready for use without a separate approval process.

• • den Datensatz 110, insbesondere dessen Filterung (beispielsweise Datenbereinigung), beim Erfassen 202; und/oder
• • die Wertepaare 111 aus Eingabewert 113 und Ausgabewert 117 beim Erzeugen 204 der Parameterwerte 120 der Konfiguration; und/oder
• • Hyperparameter des Erzeugens 204

als eine oder mehrere Stellgrößen der Regelung. Die Stellgrößen können von einem zum nächsten Schritt der Iteration 210 angepasst werden, beispielsweise so lange bis ein dem Kriterium (z.B. regulatorischen Kriterien) entsprechend ausreichender Leistungswert als Regelgröße im Schritt 206 bestimmt worden ist.Here, a control loop can be implemented in the method 200 (for example, as a higher-level verification 206 of the training process 204) through the selective iteration 210. The iteration 210 can include a control, for example, with respect to:

• • the data set 110, in particular its filtering (e.g. data cleansing), during recording 202; and/or
• • the value pairs 111 from input value 113 and output value 117 when generating 204 the parameter values 120 of the configuration; and/or
• • Hyperparameters of generation 204

as one or more control variables. The control variables can be adjusted from one step to the next in iteration 210, for example, until a sufficient power value according to the criterion (e.g., regulatory criteria) has been determined as the controlled variable in step 206.

The method 200 or the control loop can be automatically terminated by the failure of the specified criterion in step 210. Instead of a constantly repeated review of the performance metrics of concrete AI models (as in the case of 1 ) Only a one-time validation of the procedure 200, i.e., the process it creates, is performed, particularly based on the criterion in step 208 for sending it to clinical use. Preferably, the specified criterion includes or exceeds all technical requirements of a conventional medical device approval.

The method 200 can be triggered and/or repeated (in an adaptation loop higher than the control loop of iteration 210). The condition for executing and/or repeating the method 200 can be an event (technically termed a "trigger"), preferably an external event that lies outside the ML when the parameter values are generated 204. An example of the triggering event is a critical new data set in the data set 110 or the elapse of a predetermined time period since the last generation 204 of parameter values. Alternatively or additionally, the method 200 can be executed and/or repeated to update the decision system 102, for example, to retrain it. The repetition can be (for example, event-driven) retraining or periodic (for example, continuous) training. This allows for continuous improvement and/or progressive generalization to be achieved due to an increase in the data basis (e.g., a larger number of data points and/or more heterogeneous composition in the data set for the subsequent execution of the method 200).

The method 200 is also referred to as a pipeline due to the sequence of steps 202 to 208. The regulatory processing, i.e., the determination 206 and the associated selectivity of sending 208 the configuration 120 to the second server 106, within the pipeline 200 is particularly advantageous when unexpectedly new data sets 110 arrive, the analysis of which reveals that a new ML model (i.e., a new configuration 120) is required, but conventional external certification is not possible (in terms of time). For the patient, the improved configuration 120 becomes available significantly faster through this method 200, since the long delay resulting from conventional interaction with the authorities is avoided. It is precisely the iteration 210 as a control loop as well as the integration of automated or predefined triggers (such as a critical mass of additional or changed or exchanged value pairs 111 in the data set 110) that distinguishes embodiments of the method 200 from the prior art.

The method 200 can be implemented as an end-to-end processing pipeline for AI-based predictions, i.e., a pipeline 200 for creating 204 the configuration 120 and evaluating it in step 206 in a medical context. Embodiments of the method 200 combine the acquisition 202 (e.g., creation) of the data set 110, the evaluation by the performance metric in step 206, and the verification of the release criterion (e.g., equivalent to an approval criterion) before sending 208 to the configured decision system 102 (i.e., the trained ML model). This pipeline 200 includes a verification in steps 206 and 208 of the configured decision system 102, thus avoiding the conventional exchange with the authorities and the described technical requirements and problems. The pipeline 200 itself can consist of several modules that allow successive processing and create a test dataset as an example of documentation of the test 206-208. The test dataset can optionally be sent in the documentation message in step 212. The pipeline 200 can be integrated into a control loop that performs automated or manual adjustments of the training process 202-204 (for example, with regard to dataset 110 and/or hyperparameters) until a regulatory-sufficient performance value is achieved.

From the perspective of the second server 106, the present technique for configuring a clinical device 100 by a method 400, which includes the step 408 of selectively receiving parameter values. In a first variant of the method 400, the reception triggers a user-side query (for example, via the clinical device 100). If this query is answered positively, the received parameter values 120 are transferred to the inference memory of the second server 106 for execution of the decision system 102. In a second variant, the receipt of the parameter values leads directly (for example, without further communication or interaction) to the transfer of the parameter values 120 for execution of the decision system 102 in clinical use. In a third variant, the second server 106, alternatively or additionally to step 206 of the first server 104, carries out the determination of the performance value of the performance metric using the received parameter values and adopts the received parameter values 120 for inference in clinical use (ie, for configuring the decision system 102 for clinical use) if the determined performance value meets a predetermined criterion (for example, any criterion mentioned herein in the context of step 206).

The clinical use 414 mentioned herein can be characterized in any embodiment of the method 200 executed by the first server 104 and/or the method 400 executed by the second server 106 in that an input value 113 is received from the clinical device 100, that the input value 113 is optionally preprocessed, that an output value 117-K is determined by means of the decision system 102 configured with the received parameter values 120 in response to the input value 113 present at the input 112, and that the output value 117-K is sent to the clinical device 100 (optionally after post-processing).

Depending on the choice of reference symbols, steps 208 and 408 can correspond to one another, for example, they can be executed essentially simultaneously (preferably except for a runtime for the data transfer from the first server 104 to the second server 106). Clinical use 414 can follow method 200. Alternatively or additionally, documentation 212 can be performed in parallel with the ongoing clinical use 414, which can further shorten the time delay between data acquisition 202 and clinical use 414.

3 shows a first embodiment of a system, generally designated by reference numeral 300, for configuring a non-linear decision system 102 of a clinical device 100 for supporting a clinical decision.

The output values in data set 110 as part of value pairs 111, for example, measured and/or recorded output values, are designated herein by reference numeral 117. For differentiation, the output values output by decision system 102 are designated with a suffix "117-...". A distinction must be made between the output values 117-T output by the decision system 102, which is yet to be configured (at the first server 104), and the output values 117-K output by the decision system 102, which is configured for use (at the second server 106).

Thus, the output values 117-T can be the still unfinished states at the output 116 of the decision system 102 when the decision system 102 is being trained. The output value 117-T can be generated within the framework of the ML (i.e. from the first server 104 or from the decision system 102 that is still to be configured, for example on the left in the “product development” in 3 ) are output. This is an internal value of the server 104 and therefore in the 3 not shown.

This must be distinguished from the clinical application (i.e. from the second server 106 or from the configured decision system 102, for example on the right in the “Product Development” in 3 ) output value 117-K.

In 3 , a system 300 is shown that is used to configure a nonlinear decision system 102 used in clinical devices 100 to support clinical decisions 118. The system 300 includes a first server 104 and a second server 106, both of which represent operational components that play a role in the development and clinical deployment of the decision system 102.

The first server 104 is responsible for the product development of the decision system 102 and, in particular, for training, i.e., step 204. The first server 104 uses a data set 110 containing value pairs 111 from historical patient data 114 before a clinical decision 118 (and optionally also the result, i.e., patient data 115 after the implementation of the clinical decision 118) and the associated historical decision 118 as output values 117 to develop a suitable configuration of the decision system 102 in the form of trained parameter values 120 through machine learning (ML).

To evaluate the quality and reliability of the trained parameter values 120, a comparison takes place in step 206, in which the predictions of the decision system 102 (represented by the trained parameter values 120) are compared against further historical clinical results—the validation dataset 110-2. This serves to determine a performance value 130 according to a performance metric that indicates how accurate the decision system 102 is in supporting clinical decisions.

Once the first server 104 has generated a configuration that meets the specified criteria for accuracy and reliability according to the performance metric, these parameter values 120 are transmitted to the second server 106. The second server 106 is then used in clinical use to operate the decision system 102 with the new configuration.

The system 300 optionally includes a third server 108 (e.g., a data server without AI support) that acts as a repository for approval documentation. All relevant information about the configuration and release processes performed, as well as the resulting performance values 130, are stored there. This third server 108 is separate from the other two servers and serves as a secure and reliable documentation source for approval and verification purposes.

For practical use of the System 300 in a clinical environment, the 3 the use of clinical devices 100 based on the decision system 102 to support and improve clinical decisions 118. These devices 100 may, for example, be computer-assisted systems for surgical interventions or diagnostic instruments that can make precise clinical decisions 118 based on the configuration 120 developed (i.e., trained) by the first server 104 and in communication with the second server 106.

In summary, 3 an interlocking system 300 comprising the first server 104 for capturing 202 the data set 110 and for self-verified generation 204 of the configuration 120 (i.e. for training), the second server 106 for practical application, and optionally the third server 108 for documentation without approval release, which together aim to improve the accuracy and efficiency of clinical decision-making processes by using the configuration 120 verified solely on the first server 104, without bidirectional approval communication.

The 4 illustrates a second embodiment of the system 300 for configuring 120 a nonlinear decision system 102 of a clinical device 100 to support a clinical decision 118. Within this system 300, various components and data structures are networked to enable the development, verified evaluation, and application of machine learning models in the clinical context.

The second embodiment of the 4 can be used on its own or as a further development of the first embodiment of the 3 be realized. The data set 110 contains value pairs 111, each containing individual information on individual patient cases. Each value pair 111 comprises patient data 114 and 115, which encompasses both the state before and after a clinical decision. In one embodiment of the decision system 102, this data serves as input values 113 and for training 204 and validating 206 the decision system. For this purpose, the data set 110 is divided so that the data structure (not the data) in the training data set 110-1 and the validation data set 110-2 is the same.

The function of the individual value pairs 111 is to provide the machine learning model in the first server 104 with context information, which it uses to learn to map input values 113 to correct output values 117-K using trained parameters 120. This enables the system 300 to support clinical decisions.

For the patient data 114 prior to the application of the clinical decision, various biometric or diagnostic attributes of a patient can be measured and documented, which then serves as input value 113 during training 204 of the decision system 102. After the application of the clinical decision 118, new patient data 115 (the so-called "result") results, which describe the state after the application of the decision. For the purpose of generating 204 the configuration 120 (i.e., during training), the result 115 and/or the decision 118 itself can be either part of the input value 113 or part of the output value 117, depending on the design of the decision system 102.

Four exemplary embodiments of the decision system 102 are described below with reference to the 5 to 8 described. In any embodiment of the decision system 102, the patient data 115, if contained in the value pairs 111 of the data set 110 at all, can be used for data cleansing after the implementation of the clinical decision.

As in the 5 to 7 Shown schematically, the output values 117 of the data set 110 (and thus also the resulting output values 117-T or 117-K of the decision system 102) can directly indicate a clinical decision 118. In the case of the data set 110, these can be the decisions 118 captured (e.g., recorded) in step 202 as part of the value pairs 111 of the data set 110. In the case of the output values 117-T or 117-K output by the decision system 102 at the output 116, these can be output values 117-T during ML in step 204 or decisions 118 output by the configured and released decision system 102 in clinical use after step 208 in the output value 117-K. Input values 113 are present at the input 112 of the decision system 102. For example, in training step 204, the decision system 102 can be trained on the input side with the patient data 114 (i.e., the measured patient data before the implementation of the clinical decision, e.g., measured pre-operatively) and optionally further with the patient data 115 on the result (e.g., the post-operative measured result) and on the output side with the respective clinical decision 118 made.

Input 112 of decision system 102 may correspond to a first layer of a neural network. Alternatively, input 112 may be the input of an encoder located upstream of the neural network. Output 116 of decision system 102 may correspond to a final layer of the neural network. Alternatively, output 116 may be the output of a decoder located downstream of the neural network.

In a variant of each embodiment, the neural network may comprise multiple layers of neural connections. To capture the abstract relationships between the patient's pre-treatment status, post-treatment goals, and the resulting clinical decisions, backpropagation using the loss function between input 117 and output 117-T may be used in each embodiment to adjust the network weights 120 so that the network 102 more reliably represents the input (e.g., decisions 118).

In 5 During acquisition 202, a data cleansing procedure optionally takes place based on the acquired patient data 115 after applying the decision 118 (i.e., the result 115). A data cleansing criterion is applied to the value pair 111 of the data set 110, which checks the validity of the contained value pairs 111. The value pairs 111 indicate patient data 114 before the clinical treatment and corresponding decisions 118 that are relevant to the treatment. The value pair 111 indicates not only the preclinical state 114 of the patient but also the achieved state 115.

In the first design according to 5 Both patient data 114 and 115 are in the input value 113, so that the AI-supported decision system 102 uses the value pairs 111 of the training data set 110 to learn which decisions 118, based on the patient data 114, lead to the desired treatment goal 115. During generation 204, the (possibly adjusted) patient data 114 before the treatment and the actually achieved goal 115 after the treatment serve as the input value 113, which is fed into the neural network of the decision system 102.

Thus, in clinical use, after step 208, the treatment goal (i.e., outcome 115) is a specification for the proposed decision 118 in the output value 117-K. In other words, "What is the patient's status?" (i.e., patient data 114) and the objective (i.e., patient data 115) are in the input value 113. The decision system 102 supports how the goal is to be achieved with the proposed decision 118 in the output value 117-K.

In 6 A second embodiment of the decision system 102 is shown schematically. In the second embodiment, the input value 113 of each value pair 111 of the data set 110 comprises exclusively patient data 114, which reflects the patient's condition prior to the application of a clinical decision 118. In this specific scenario, the data set 110 contains value pairs 111 whose input values 113 are used for machine learning to train the decision system 102. This serves the purpose of being able to make predictions of the clinical decisions 118 in subsequent clinical applications based on new patient data 114 (and not on the outcome 115). The treatment goal 115 is learned implicitly in the second embodiment.

In this configuration, the decision system 102 is a learning model that processes input data 113 during the training phase without requiring information about the results 115 of the clinical decisions 118 (i.e., without patient data 115 after the decision 118). Instead, the system 102 learns based on historical data which clinical decisions led to which results and uses this information to make predictions for future cases.

To evaluate the performance of the trained decision system 102, i.e., to determine the performance value 130 206, it is tested with a validation dataset 110-2. This validation dataset is separate from the training dataset and contains the actual results, also known as ground truth data, which are used to assess the precision and accuracy of the decision system 102 with regard to predicting clinical decisions 118.

If the determined performance value 130 exceeds the predefined criteria, indicating a successful training and validation phase, the developed parameter values 120 are transmitted 208. These parameter values 120 are then used to immediately configure the decision system 102 operating on a second server 106 for clinical use and make it available. The second server 106 can thus be used in everyday medical practice to make appropriate decisions 118 based on patient data 114 collected immediately before the clinical decision, thereby improving the quality of treatment.

In the third embodiment of the method and decision system 102, which is shown schematically in 7 As shown, each value pair 111 of the data set 110 includes the patient data before the application of the clinical decision as input values 113. This includes information about the patient's condition that is captured before a medical procedure or treatment is carried out. In addition, in this embodiment, each value pair 111 contains output values 117, namely the patient data 115 after the application of the clinical decision 118 and the indication of the decision 118. These reflect the patient's condition 115 after the treatment has been carried out according to the decision 118. This means that both information about the original condition 114 and about the result 115 of the treatment 118 are used for machine learning.

In clinical use, the decision system 102 therefore provides a basis for the decision 118 and the goal 115 pursued thereby.

It should be noted that in the second and third embodiments, the patient's initial state is the sole input value 113. The treatment goal 115 is implicitly trained in these embodiments and is additionally output in the third embodiment as output value 117-K.

The fourth design, shown in 8 , illustrates a method 200 and decision system 102 in which the input value 113 of each value pair 111 of the data set 110 includes both the patient data 114 before the application of the clinical decision 118 and the respective clinical decision 118 itself. The output value 117 of the value pair 111 includes the patient data 115 after the application of the clinical decision, which provides information about the outcome of the decision 118.

The use of the patient data 114 before applying the decision 118, including the made clinical decision 118 in the input value 113, makes it possible to provide predictions and support for the clinical decisions 118 based on broad historical knowledge and results.

The fourth embodiment allows for a more conservative working mode, in which, for example, physicians, rather than the decision system 102, first present the explicit suggested action 118. Instead, the physician can review his or her proposed decision 118 (e.g., an implant selection) with respect to the expected treatment goal. This also provides decision support because, by entering multiple alternative options (as input values 113) (i.e., candidates for the decision 118), the final decision 118 (e.g., which implant to use) can be aligned with the most appropriate result 115 (e.g., a target refractive power).

A further advantage of the fourth embodiment is that, if the outcome 115 of different treatment options 118 is equivalent, the physician has an additional degree of freedom for secondary decision criteria. For example, the primary decision can be based on treatment success 115, while the secondary decision can be based on the implant's service life and the patient's age (for example, when selecting the material for a hip joint prosthesis).

9 represents an eye 900 with various biometric sizes of the eye 900. In particular, the following sizes are shown: axial length 902 (technical term: "axial length", AL), anterior chamber thickness 904 (technical term: "anterior chamber depth", ACD), keratometry value 906 (K or radius), refractive power of the lens, lens thickness 908 (technical term: "lens thickness", LT), central cornea thickness 910 (technical term: "central cornea thickness", CCT), white-to-white distance 912 (technical term: "white-to-white distance", WTW), pupil size 914 (technical term: "pupil size", PS), posterior chamber depth 916 (technical term: "posterior chamber depth", PCD), retinal thickness 918 (fold linguistically: "retina thickness", RT). At least one of these ophthalmological variables can serve as input value 113 or output value 117 in step 204 in the biometric patient data 114 before or 115 after the implementation of the decision - and accordingly be contained in the ophthalmological individual patient data 114 (and optionally 115) of a patient in clinical use as input value 113.

10 shows a third embodiment of the system 300. The system 300 is designed for the automated detection of value pairs 111 in step 202 and evaluation of a performance metric (ie the determination of a performance value 130) in step 206 (preferably based on statistics of the predictions 117-K after completion of the generation 204 of the configuration 120 by means of ML) in the regulatory context.

Optionally, regulatory and/or clinical reports from the ML can be documented in step 204, and the determined performance values 130 for medical applications can be documented in step 212. This allows the automated safety check in step 206 of the decision system 102 made available in step 208 to be verifiably audited, eliminates the need for conventional bidirectional communication with regulatory authorities, avoids documentation errors and non-standardization, and improves the time efficiency of making available. Instead of performing the AI training process in step 204 on a separate server that outputs fixed weights of the neural network, which then must be further analyzed for their safety, the training process 204 and the testing process 206 are integrated into a processing pipeline 200 in the system 300.

The third embodiment of the system 300 comprises the following modules: a module for data filtering, for example, according to step 202; a module for data preparation (also: data processing), for example, for forming the value pairs 111 in step 202 or 204; a training module for generating (for example, determining or adapting) the parameter values 120 of the decision system 102 (i.e., an ML system for clinical decision-making), e.g., for determining the weights of the neural network according to step 204; a module for evaluating the generated parameter values 120 of the decision system 102, i.e., for verifying inference (and not clinical inference) with respect to the validation data set (also: test data set) in step 206; a module for evaluating a performance metric for determining performance values 130 in step 206. and an optional module for creating documents (e.g., reports) according to step 212, for example, about the determined performance values 130 and a cause of the iteration 210.

Alternatively or additionally, the modules can perform the following functions.

Data filtering

In a first sub-step 202-1 of step 202, the data points used for the training process 204 (e.g., value pairs 111) are filtered in the data filtering module. Here, all data points are removed from the data set 110 that are considered incorrect, unrepresentative of the task of specifying a decision 118, or outside the scope of the prediction task under consideration. Additionally, it can be checked whether the data points as a whole are statistically representative of the prediction task. The data points remaining in the data set 110 are free of measurement errors and meaningful with regard to the training requirements of step 204.

Data preparation

In the next substep 202-2 of step 202, a data preparation module prepares the data set 110 for the training process 204. This preprocessing may include the (preferably disjoint) division of the data set 110 into the training data set 110-1, a training-internal evaluation data set 110-1', and the independent validation data set 110-2 (also: test data set).

Alternatively or additionally, sub-step 202-2 may include the preparation of a cross-validation (technical term: "cross validation") or a bootstrapping procedure in step 206. Cross-validation and bootstrapping are statistical methods that can be used to create 204 and validate 206 the decision system 102 as an ML model. Cross-validation and bootstrapping are conventionally known as techniques for measuring the training setup and, in contrast to measuring model performance, are used here as examples for the performance values 130 related to safety and efficacy. Cross-validation is a procedure in which the data set 110 is divided into smaller groups (technical term: "folds"). The configured but not yet released decision system 102 is then trained several times in step 204, wherein in each run a different combination of 'folds' is used for training 204 as the training data set 110-1 and the remaining unused 'fold' is used for validation as the validation data set 110-2 in step 206. This embodiment of the method 200 is able to determine in step 206 how well the Ent decision system 102 is generalized to unknown data (ie unknown input values 113).

The bootstrapping procedure, on the other hand, creates so-called resamples of the data set 110, i.e., multiple samples with replacement drawn from a single random sample. Following the ML in step 204, the bootstrapping procedure can be used to estimate the performance in terms of safety and effectiveness of the decision system 102 in step 206, for example, to detect overfitting relevant to safety.

The choice between cross-validation and bootstrapping procedures when implementing the integral steps 204 and 206 may depend on the size and/or distribution of the data set 110.

training

The training module performs the actual training, i.e., the generation step 204, of the decision system 102 as an ML system using the prepared training data set 110-1 and the optional evaluation data set 110-1' (also: evaluation data). For example, a neural network is defined for a loss function (technically known as a "loss function") that mathematically describes the optimization task in a medical context. This task can be a medical diagnosis, the detection of disease-related information, or the prediction of a treatment-relevant variable such as the refractive power of an intraocular lens (IOL) for cataract surgery. The training process 204 is performed by optimizing the decision system 102 as an ML system for strong performance on the given value pairs 111. In a neural network as an example of the decision system 102, the output values 117-T (technically: the predictions) of the neural network are processed with the loss function during training 204, and the mathematical gradient on the deviation of the predetermined output values 117 of the training data set 110-1 is propagated through the neural network by means of gradient descent in order to optimize the corresponding weights 120 with a view to better performance for the value pairs 113 and 117 of the training data set 110-1.

Here, the reference symbol variants 110-1, 110-1' and 110-2 are used to emphasize the differentiation of the data set 110 into training data, evaluation data and validation data (also: test data) and not to identify features of the drawings.

Optionally, during the creation 204 of the configuration 120, the performance development of the decision system 102 is tracked using evaluation data 102-1'. Training 204 can be completed when the measured performance development has reached a predetermined absolute first training threshold and/or a rate of performance development per epoch is less than a predetermined second training threshold (which, for example, indicates that the training 204 has converged). After completion of training 204, the fully trained AI model is forwarded to the evaluation module.

Inference evaluation and performance metric evaluation

The first evaluation module for evaluating the generated parameter values 120 uses the provided trained AI model (preferably on the same first server 104 without copying the training parameters) as a configured and not yet released decision system 102 to evaluate, by means of the second evaluation module, its performance in terms of effectiveness and safety according to the performance metric in step 206 using the validation data set (ie, the test data) that was provided in the data preparation module. The first evaluation module and the second evaluation module are in 10 referred to as "predictions" or "metrics," which are collectively also referred to as the evaluation module and which functionally correspond to step 206. The use of the trained decision system 102 means that it is executed with input values 113 from the validation data set 110-2, whose value pairs 111 contain an output value 117 in addition to the input value 113. The resulting output values 117-K (technically known as predictions or forecasts) of the configured and not yet released decision system 102 are compared with the specified output values 117 of the validation data set 110-2. Optionally, the evaluation module saves the corresponding prediction results.

The independent testing of the configured and not yet released decision system 102 as an AI model ensures that the evaluation is not influenced by the training data 110-1. At the same time, the evaluation module can perform predictions based on the same evaluation data using other methods suitable for the prediction task, if, for example, a comparison with the state of the art is required. For the area of IOL refractive power calculation, for example, the trained AI model as well as other IOL calculation formulas (such as the IOL calculation according to HAIGIS mentioned herein) can be used to to perform a prediction of the required IOL power for each data point. The evaluation results are then sent to the performance metrics module (e.g., at reference numeral 130 for the power values in 10 ). The performance metrics module may functionally correspond to step 206.

Within the second evaluation module, i.e., the performance metric module, all evaluations of the multidimensional or multivariate performance metrics relevant for assessing the safety and effectiveness (i.e., efficacy) of the trained AI model as a decision system 102 are calculated based on the evaluation results provided by the first evaluation module. The second evaluation module can therefore also be referred to as the assessment module.

The performance metric may include, for example, for a decision system 102 for predicting IOL power for cataract surgery, at least one of the following metrics: mean error (ME); mean absolute error (MAE); standard deviation (SD); proportion of predictions with a prediction error within +/-0.5 D; and proportion of predictions with a prediction error outside +/-1.0 D. Furthermore, the second evaluation module for the performance metric may perform a comparison with the metrics of other methods if these were calculated in the evaluation module. This comparison may include calculating a statistically significant difference between the evaluation results of the different approaches. In addition, the dependence of the trained AI model, e.g., the parameter values 120, on the given input values 113 may be evaluated. A further analysis performed in the evaluation module can be the general comparison of the predictive behavior of the different approaches on the given data set 110.

documentation

Finally, according to the (e.g., multidimensional) performance metric, all performance values, statistics, and further analyses are forwarded to the document generation module (e.g., reports). In this respect, the document generation module can functionally correspond to step 212.

In the document creation module, one or more reports are created based on the provided performance values, statistics, and analyses. These reports summarize the overall performance analysis of the configured decision system 102 as an AI model with regard to its safety and effectiveness. The report is designed to contain all the information necessary to evaluate these requirements. The report can be forwarded to the third server 108 (for example, for later manual review) in step 212.

• - unabhängig von dem Vorhandensein einer Datenverbindung zu den Behörden bzw. zu einer „benannten Stelle“,
• - vollständig standardisiert und reproduzierbar,
• - wesentlich weniger fehleranfällig als ein manueller Prozess, und
• - wesentlich schneller im Vergleich zu einem manuellen Prozess.

The described pipeline, i.e., the method 200, ensures a reproducible, rapid, and fully documented process that leads to a decision system 102 validated for safety and efficacy, thus avoiding bidirectional communication with regulatory authorities. The proposed pipeline 200 is therefore preferable or advantageous:

• - regardless of the existence of a data connection to the authorities or to a “notified body”,
• - fully standardized and reproducible,
• - significantly less error-prone than a manual process, and
• - much faster compared to a manual process.

The above-described embodiments of the method 200 (for example, as a pipeline) and the system 300 can be supplemented by any of the following features (or steps).

According to one embodiment, method 200 can be implemented as a pipeline for the implicit approval of AI-based models in a medical context. Method 200 is characterized in that the achieved approval of decision system 102 as a single trained ML model can be achieved independently of regulatory authorities.

An analysis module, i.e., step 206, is integrated into the method 200, which generates a validation data set (also: test or inspection data set) (if this does not already occur during the acquisition 202) and verifies at least all technical conditions of an aspect conventionally checked by the approval authorities using the validation data set.

Within the method 200, a validation data set may be created and/or used that enables qualitative and quantitative analysis of the configuration 120 with regard to safety and effectiveness.

The method 200 may include or combine the regulatory requirements (ie, the technical conditions) of several regulatory authorities in step 206 in order to test (and optionally certify) the decision system 102 for all regulatory authorities in parallel or with overlapping time.

The method 200 may integrate and include conventional testing methods, such as procedural predictions, as competitor methods against which the configured decision system 102 is compared. This process in step 206 supports the integrated approval in step 208.

The competitor methods can be dynamically adapted as soon as the state of knowledge regarding procedural predictions (e.g. empirical formulas) changes.

The method 200 can continuously or intermittently introduce, collect, and check input values 113 or value pairs 111 that are suitable for executing or repeating the method 200 or 400 (e.g., retraining the AI model, i.e., repeating at least step 204) by way of the adaptation loop. For this purpose, an additional step of the method 200 or 400 can include evaluating the modified and/or augmented data set 110 (e.g., data on input values). For example, the external event for executing or repeating the method 200 or 400 can occur if the data on input values lie outside a convex hull of the input values in the data set from the last execution of the method.

Upon reaching a predetermined absolute or relative amount (e.g., a "critical mass") of changes or additions in the data set 110, for example, with regard to quantity and/or quality, an output of a signal to a user or an automatic "re-training" of the decision model 102 according to the adaptation loop can take place in an additional step (which, for example, is different from, in particular chronologically after, step 210 or 212).

The iteration 210 can be implemented as a control loop, for example, with the configuration 120 as the manipulated variable and the power value 130 as the controlled variable. In this case, the method 200 (i.e., the process) can include the use of a control loop that, if the created AI model fails, causes the process 200 to be repeated until a satisfactory result according to the predetermined criterion is achieved.

The control loop, i.e., iteration 210, can be part of the automated process 200 or can be requested via a user interface and initiated manually.

The control loop 210 can contain, among other things, one of the following components. A first component is the expansion of the data basis in the data set 110. A second component is the change in the analysis method, i.e., a change in the data cleansing during acquisition 202, e.g., through an analysis broken down by source of the individual value pairs 111. For this purpose, the data set can be sorted by source, or each value pair can further include an identifier (technical term: "identifier" or ID) of the source. An example of source decoding can be the person of the surgeon (technical term: "surgeon ID"). For example, during acquisition 202, deviating value pairs 111 can be recognized as outliers (technical term: "outliers") and assigned to one of the sources. A source with a disproportionate share of outliers can be completely excluded from the data set 110. A third component comprises a change in the hyperparameters, i.e., those parameters that control the training 204.

When deciding whether to perform iteration 210 or transmission 208, the type, number, and order of the criteria used can be varied. For example, the control loop can perform a qualitative or quantitative check of the results (e.g., the performance value 130) of the last calculation process (e.g., the last procedure) and adjust the type, number, and order of the control loop criteria to be used accordingly.

• - ohne eine externe Kommunikation,
• - ohne eine bidirektionale Kommunikation mit dem dritten Server 108,
• - ausschließlich auf dem ersten Server 104; und/oder
• - vollständig automatisiert.

In a variant of each embodiment, the control loop (i.e., iteration 210) can be executed without creating documentation (e.g., without step 212). Alternatively or additionally, the method 200 can execute a change in the data set 110 and/or the hyperparameters and/or one of the aforementioned components for generating 204 the updated configuration 120, preferably:

• - without external communication,
• - without bidirectional communication with the third server 108,
• - exclusively on the first server 104; and/or
• - fully automated.

The method 200 and the system 300 are thus distinguished from the prior art, in which In which a bidirectional data transfer (i.e., with feedback) of the evaluation of each trained AI model is performed to a third-party server for the purpose of technical approval. This feedback verifies that the evaluation of the AI model allows for use in a medical context and releases the AI model. This process repeatedly requires a data connection for data exchange, is time-consuming, and error-prone.

In contrast, in embodiments of the method 200 and the system 300, bidirectional data transmission is omitted (i.e., eliminated). The method 200, with steps 206 and 208 (and optionally steps 210 and 212), comprises an automated, fast, and standardized process by creating a validation dataset 110-2 (i.e., a test or verification dataset) and integrating an analysis model with regulatory criteria into the process 200. Furthermore, a control loop 210 can be integrated into the method 200 for successively improving the performance value 130 of the decision system 102 until these criteria are met, in order to ensure compliance with the necessary technical requirements.

The control of the entire process 200 (i.e., the execution of the method 200 or its iteration 210) can, for example, be carried out via a critical data set.

Thus, embodiments of method 200 and system 300 solve the described technical problem of frequent data exchange in the context of an approval. This technical problem in the prior art relates to the high technical requirements and the error-prone nature of frequent data exchange. The described embodiments solve this technical problem by technically implementing the performance value determination within method 200 and system 300, respectively.

The system 300 is preferably implemented exclusively by the first server 104. The first server 104 has computing resources (technically known as "computing resources") that allow effective training 204 of the ML system 102 (e.g., GPUs, etc.). Furthermore, the first server 104 is configured to process the patient data 114 and/or 115 in a security-related manner (e.g., with encryption, etc.). Since the control loop 210 exerts a direct influence on the subsequent training 204 within the first server 104, it is technically advantageous if the control loop 210 is executed by the same first server 104. However, this is not technically necessary.

The third server 108 can be configured to provide a function for uploading the documentation message via a public and password-protected interface (e.g., an upload portal). The omitted step can relate to the transfer of the decision system 102 (or its configuration 120) and/or the determined performance values 130 to the upload portal. The upload portal is not configured to execute or train the decision system 102. The decision system 102 configured in step 204 is thus enabled from the time the predetermined criterion is reached in step 208, without the detour or delay via the external upload portal, and/or can be fed directly into a (preferably non-public) cloud platform-based computer application that includes a front end operable by the clinical device 100 (e.g., by a physician).

Embodiments of method 200, method 400, and system 300 may include the negative feature of no communication (or at least no bidirectional communication) with a regulatory authority. Alternatively or additionally, communication with a regulatory authority server 108 may be limited to uploading the documentation message.

Alternatively or additionally, embodiments of the method 200 and the system 300 may be characterized in step 208 by the immediacy of the release of the configured decision system 102. For example, fulfilling the predetermined criterion in step 208 may trigger sending to a storage location that enables use in clinical applications (e.g., through direct access from the clinical device 100).

Optionally, steps 202 to 212 of method 200 can be performed by the same server 104 and/or in the same network (particularly for training 204 and determination 206 of performance value 130 as the control loop termination condition of steps 208 or 210). The same server 104 and/or the same network can be determined by using identical GPUs.

As stated above, the decision system 102 may encompass any application in which the clinical device 100, which is functionally dependent on the decision system 102 and in data exchange with it, is a medical device subject to approval. Alternatively or additionally, the decision 118 of the decision system 102 may relate to surgical planning (surgical planning), a choice of an implant (for example, by restricting or preselecting specific areas), or concern the planning of a neurosurgical operation (for example, by generating control data for a surgical robot). Alternatively or additionally, the decision 118 of the decision system 102 can concern therapy planning (for example, with regard to the choice of medication, dosage of a medication, or frequency of medication administration).

In each embodiment, a physician can use the clinical device 100 as a front-end system (e.g., a medical application, or "app" for short) that accesses the decision-making system 102 executed by the second server 106 in the backend via an application programming interface (API). For example, the first server 104 can be a decentralized cloud server. Alternatively or additionally, the second server can be spatially associated with a plurality of clinical devices 100, for example, as an edge computing server.

In each embodiment, the output value 117-K of the configured decision system 102 (technically known as prediction) may be a recommendation for a physician.

While method 200 is generally disclosed as a configuration method for decision system 102, method 200 may be a manufacturing method for manufacturing decision system 102 as an ML model. For example, generation 204 may include initializing the ML model or an initial configuration 120. Alternatively or additionally, generation 204 may adjust all or individual parameter values based on a previous version of the configuration to create the configuration.

Creating the configuration 120 for the decision system 102 may include initializing the ML model. The creation method 200 may include creating the ML model for the first time or creating it anew. For example, the training 204 may include redetermining all parameter values 120 of the ML model. Alternatively, the creation method 200 may be an adaptation method for adapting the decision system 102. For example, the training 204 may include adapting parameter values 120 of the ML model based on a previous version of the ML model or a base version of the ML model.

Preferably, iteration 210 (i.e., the control loop) is neither part of the ML in step 204 nor part of the adaptation loop (i.e., retraining) for adapting to an updated data set. If a training iteration is performed in the context of ML until certain conditions are reached in step 204, these can be learning cycles or epochs within the training phase 204. The generation 204 of the parameter values 120 can comprise an inner loop (first loop) (e.g., through epochs). The iteration 210 can form a control loop (second loop) superior to the generation. The adaptation loop can form an outer loop (third loop) superior to the iteration 210 (preferably aperiodic).

The acquisition 202 or iteration 210 for the control loop can, for example, detect the presence of data points in the data set 110 that lead to systematic deviations in certain areas of the prediction 117-K and remove them for training 204. This deviation can relate to individual data points or a data group, such as the data points of a specific physician. Preferably, this filtering or data cleansing affects the training data set 110-1 and not the validation data set 110-2, so that the testing according to steps 206 and 208 is not affected. This means that the conspicuous data points continue to be used in the validation of the decision system 102. This can prevent an artificial improvement or apparent improvement of the performance value 130 by excluding difficult cases.

Alternatively or additionally, during acquisition 202 and/or iteration 210, areas of the data points (for example, areas of the input values 113) can be detected in which there is currently little data and which therefore exhibit a weakness in the prediction 117-K. In the detected areas, new data points can be generated by targeted augmentation or included in the data set 110. Here, too, the augmented data points are preferably added only to the training data set 110-1 and not to the validation data set 110-2, so that the augmented data points are used only for training.

In each embodiment, data cleansing (e.g., data filtering) can statistically evaluate the data set 110 and, based on this, filter out distorting outliers among the data points (e.g., value pairs 111) and/or add data points (e.g., value pairs 111) in a relatively low-density area, at least in the training data set 110-1. Filtering out results in a saving of computing resources for training 204 as well as time. Data filtering can include data cleansing (technical term: "data cleansing").

Acquiring 202 the data set 110 may include eliminating a value pair 111 from the data set 110, optionally from the training data set 110-1 or the validation data set 110-2, for example, if a loss function or deviation between the output value 117-K of the ML model in response to one of the input values 113 of the validation data set 110-2 and the corresponding output value 117 of the validation data set 110-2 exceeds a predetermined threshold. For example, the value pairs 111 of the data set 110 may each include an identifier of a surgeon, a physician, or a clinic, wherein furthermore, all value pairs 111 with the same identifier are eliminated.

In response to the performance value 130 of the performance metric failing to meet the predetermined criterion, a value pair 111 may be eliminated from the validation data set 110-2 or transferred to the training data set if a loss function or deviation between the output value 117-K of the ML model in response to the input value 113 of the value pair 111 and the output value 117 of the value pair 111 exceeds a predetermined threshold.

In a variant of each embodiment, iterating 210 of method 200 may comprise iterating the generation 204, for example, with a change in one or more hyperparameter values of the generation 204 of the parameter values 120 of the decision system 102. The hyperparameters may comprise external configuration variables used for training 204 of the decision system 102, i.e., for producing the ML model using ML. For example, the hyperparameters may comprise a learning rate and/or number of epochs (e.g., how often the training dataset is applied). Alternatively or additionally, the hyperparameters (e.g., in a neural network system as the decision system) may comprise a number of layers of a neural network system, a number of nodes per layer, and/or an activation function (e.g., a shape and/or a threshold of the activation function). Alternatively or additionally, the hyperparameters (e.g., in a decision tree as the decision system) may comprise a number of branches in the decision tree. Alternatively or additionally, one or more of the following hyperparameters can be changed: a learning rate, an activation function of the neural network, a change in the epochs and patience, a number of layers and/or a size of the neural network, and the loss function or a weighting of the loss function.

Alternatively or additionally, the change in a generation 204 triggered by an external event or an internal iteration may include: a change in the augmented value pairs 111 or a change in the detected areas for augmentation (for example, an axial length 902 of the eye 900, which is often underrepresented for "long" eyes 900); a change in configurable constants for optical loss constraint (technically: in the optical "loss constraint"), for example, to better adapt the generation 204 to an IOL type; or a change in the parameters of the IOL position prediction.

Determining 206 the performance value 130 of the performance metric and the criterion for this can be equivalent to a performance analysis within the meaning of a Medical Device Regulation (MDR) without any regulatory interaction. Alternatively or additionally, the performance metric and the criterion can correspond to a regulatory requirement for the approval of the system.

Each embodiment may include, before iteration 210 or before transmission 208, a significance value for the difference between the previous version of the configuration and the configuration 120 generated or to be generated in step 204 (i.e., the parameter values 120). If the significance value falls below a minimum value, iteration 210 or transmission 208 may be omitted. Alternatively or additionally, in the case of a decision 118 regarding the selection of an IOL, a decision 118 for nearsightedness may be preferred over a decision for farsightedness.

The output values 117 of the validation data set 110-2 may comprise output values 117 of a reference system to the input values 113 of the validation data set 110-2, optionally wherein the reference system is a previous version of the decision system 102, an algorithmic or procedural system for predicting the decision, a tabular interpolation for predicting the decision, or a calculation formula for predicting the decision.

While the training data set 110-1 may be based on new measurements, the validation data set 110-2 may not include any results of the new measurements. For example, the training data set 110-1 may be updated with a periodicity (or frequency) that is shorter (or greater) than the periodicity (or frequency) with which the validation data set 110-2 is updated. Alternatively or additionally, the validation data set 110-2 may have a first time rank and the training data set 110-1 a second have a seniority that is younger than the first seniority.

In any embodiment, the decision system 102 configured in step 204 can be configured to determine or preselect an implant based on the patient data 114 and/or 115. A loss function of the training 204 can include a categorical cross-entropy for determining a class of implants. Alternatively or additionally, a loss function of the training 204 for determining implant parameter values of an implant can include a mean square error between an output value 117-K of the decision system 102 in response to one of the input values 113 of the training data set 110-2 and the corresponding output value 117 of the training data set 110-1.

The type or class of the implant can determine one implant from a set of alternative implants. Alternatively or additionally, the (e.g., vector-valued) output value 117 can comprise parameter values of an implant. The parameter values can determine the geometry of the implant, for example, size and/or surface curvatures. In the case of an IOL as an implant, the implant parameters can include a refractive power and/or a diameter of the IOL.

The method 200 or a repetition of the method 200 via the adaptation loop can be triggered by an external event. The method 200 can be executed or repeated if the data set 110 includes a predetermined number of newly measured value pairs 111 (for example, compared to the data set underlying the current configuration 120) and/or if a predetermined time has passed since the last generation 204 of the configuration 120.

The method 200 may further comprise: sending (for example, in step 212) initial documentation regarding the implementation of the method 200, the processes used for validation 206, and the results (for example, the performance values 130) of this validation 206 on sample data to a third server, for example, the aforementioned third server 108. This initial documentation may be sent once to designated bodies (approval authorities). Preferably, no sets (configurations) with parameter values 120 are sent to the authorities for approval. Optionally, the method 200 (for example, before an iteration 210) includes receiving an approval in response to the initial documentation.

11 shows a diagram of a third embodiment of the system 300 for configuring 120 a non-linear decision system 102 of a clinical device 100 for supporting a clinical decision 118. The third embodiment comprises units 1102 to 1112, each of which is configured to carry out steps 202 to 212 of the method 200.

To this end, the system 300 further comprises a processor 1126 and a memory 1124 operatively interacting with the processor 1126 for storing instructions that, when executed by the processor 1126, cause the processor 1126 to: measure—in particular by means of the data acquisition unit 1102—biometric patient data 114 and/or 115 (e.g., ophthalmic patient data) and to receive—for example, by means of an acquisition unit 1102—an input value 113 (e.g., a target refraction value). Either the target refraction value or the target refractive power value can be entered here.

In addition, the processor 1126 is caused to generate 204 the parameter values 120 by means of the unit 1104 and to determine 206 a power value by means of the unit 1106.

It should be expressly pointed out that the units (e.g., modules) 1102 to 1112, the processor 1126, and the memory 1124 may be connected by electrical signal lines or via a system-internal bus system 1122 for the purpose of signal or data exchange.

12 illustrates a fourth embodiment of the system 300 as part of a computer system 1200, which is implemented according to one of the preceding embodiments (e.g. 3 , 4 or 10 ). The computer system 1200 has a plurality of general purpose functions. The computer system can be a tablet computer, a laptop/notebook computer, another portable or mobile electronic device, a microprocessor system, a microprocessor-based system, a smartphone, a computer system with specially configured special functions, or even a component of a microscope system. The computer system 1200 can be configured to execute instructions executable by the computer system - such as program modules - that can be executed to implement functions of the concepts proposed here. For this purpose, the program modules can have routines, programs, objects, components, logic, data structures, etc. to implement specific tasks or specific abstract data types.

The computer system 1200 may be an embodiment of the first server 104.

The components of the computer system may include one or more processors or processing units 1202, a memory system 1204, and a bus system 1206 that connects various system components, including the memory system 1204, to the processor 1202. Typically, the computer system 1200 includes a plurality of volatile or non-volatile storage media accessible by the computer system 1200. The data and/or instructions (commands) of the storage media may be stored in the memory system 1204 in volatile form—such as in a RAM (in technical terms: "random access memory") 1208—for execution by the processor 1202. These data and instructions implement one or more functions or steps of the concept presented here. Further components of the storage system 1204 may be a permanent memory (ROM) 1210 and a long-term memory 1212 in which the program modules and data (reference numeral 1216), as well as workflows, may be stored, for example the units 1102 to 1112 of the 11 .

The computer system has a number of dedicated devices for communication (keyboard 1218, mouse or other pointing device, screen 1220, etc.). These dedicated devices can also be combined in a touch-sensitive display. A separately provided I/O controller 1214 ensures smooth data exchange with external devices. A network adapter 1222 is available for communication via a local or global network (LAN, WAN, e.g., via the Internet). The network adapter can be accessed by other components of the computer system 1200 via the bus system 1206. It is understood that—although not shown—other devices can also be connected to the computer system 1200.

The description of the various embodiments of the present invention has been presented for clarity, but does not serve to directly limit the inventive concept to these embodiments. Further modifications and variations will become apparent to those skilled in the art. The terminology used herein has been chosen to best describe the basic principles of the embodiments and to make them readily accessible to those skilled in the art.

The principle presented here can be embodied as a system, a method, combinations thereof, and/or as a computer program product. The computer program product can comprise one or more computer-readable storage media containing computer-readable program instructions for causing a processor or control system to execute various aspects of the present invention.

Electronic, magnetic, optical, electromagnetic, infrared media, or semiconductor systems can be used as the transmission medium; for example, SSDs (solid-state devices/drives), RAM (random access memory) and/or ROM (read-only memory), EEPROM (electrically erasable ROM), or any combination thereof. Other transmission media can include propagating electromagnetic waves, electromagnetic waves in waveguides or other transmission media (e.g., light pulses in optical cables), or electrical signals transmitted in wires.

The computer-readable storage medium may be an embodied device that holds or stores instructions for use by an instruction execution device. The computer-readable program instructions described herein may also be downloaded to a corresponding computer system, for example, as an application (e.g., a mobile "app") from a service provider via a wired connection or a cellular network.

The computer-readable program instructions for performing operations of the invention described herein may be machine-dependent or machine-independent instructions, microcode, firmware, state-defining data, or any source code or object code written, for example, in C++, Java, or similar, or in conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer-readable program instructions may be executed entirely by a computer system. In some embodiments, electronic circuits, such as programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may also execute the computer-readable program instructions by utilizing status information from the computer-readable program instructions to configure or customize the electronic circuits according to aspects of the present invention.

Furthermore, the invention presented herein is illustrated with reference to flowcharts and/or block diagrams of methods, devices (systems), and computer program products according to embodiments of the invention. It should be noted that virtually every block of the flowcharts and/or block diagrams may be embodied as computer-readable program instructions.

The computer-readable program instructions may be provided to a general-purpose computer, a special-purpose computer, or another programmable data processing system to produce a machine, such that the instructions, executed by the processor or computer or other programmable data processing device, generate means for implementing the functions or operations depicted in the flowchart and/or block diagrams. These computer-readable program instructions may also be stored on a computer-readable storage medium.

In this sense, each block in the illustrated flowchart or block diagrams may represent a module, segment, or portion of instructions that represent multiple executable instructions for implementing the specific logic function. In some embodiments, the functions represented in the individual blocks may be executed in a different order—possibly even in parallel.

The illustrated structures, materials, processes, and equivalents of all means and/or steps with associated functions in the claims below are intended to employ all structures, materials, or processes as expressed by the claims.

10

Bidirektionaler Datenaustausch im Stand der Technik

100

Klinische Vorrichtung

102

Entscheidungssystem, von erstem Server trainiert oder zweiten Server ausgeführt, beispielsweise neuronales Netzwerk, logistisches Regressionssystem, Entscheidungsbaumsystem, Support-Vektor-Maschine

104

Erster Server, beispielsweise zum Erzeugen der Parameterwerte der Konfiguration und/oder Bestimmung des Leistungswertes

106

Zweiter Server, beispielsweise zum Ausführen des konfigurierten Entscheidungssystems im klinischen Einsatz

108

Dritter Server, beispielsweise zur revisionssicheren Dokumentation

110

Datensatz mit einer Vielzahl von Datenpunkten

110-1

Trainingsdatensatz

110-2

Validierungsdatensatz

111

Wertepaar als Beispiel eines Datenpunkts

112

Eingang des Entscheidungssystems

113

Eingabewert für Eingang des Entscheidungssystems, beispielsweise Skalar, Vektor oder Tensor

114

Patientendaten eines Patienten vor einer Anwendung, beispielsweise vor Umsetzung der Entscheidung

115

Patientendaten des Patienten nach der Anwendung, beispielsweise nach Umsetzung der Entscheidung

116

Ausgang des Entscheidungssystems

117

Ausgabewert für Ausgang des Entscheidungssystems, beispielsweise Skalar, Vektor oder Tensor

117-T

Ausgabewerte beim Training

117-K

Ausgabewerte im klinischen Einsatz

118

Klinische Entscheidung

120

Parameterwerte einer Konfiguration des Entscheidungssystems

130

Leistungswert einer Leistungsmetrik

200

Verfahren zur Konfiguration eines nichtlinearen Entscheidungssystems, beispielsweise seitens des trainierenden Servers

202

Schritt des Erfassens eines Datensatzes

204

Schritt des Erzeugens von Parameterwerten einer Konfiguration des Entscheidungssystems

206

Schritt des Bestimmens eines Leistungswertes

208

Schritt des Sendens (beispielsweise des Übertragens oder Bereitstellens)

210

Schritt des Iterierens, beispielsweise Iteration des Erfassens von Datensätzen, Erzeugens von Parameterwerten und des Bestimmens von Leistungswerten

212

Schritt des Sendens einer Dokumentationsnachricht

300

System zur Konfiguration eines nichtlinearen Entscheidungssystems

400

Verfahren zur Konfiguration eines nichtlinearen Entscheidungssystems, beispielsweise seitens des ausführenden Servers

408

Schritt des Selektives Empfangen

900

(beispielsweise „kurzes“ oder „langes“) Auge des Patienten

902

Axiale Länge

904

Vordere Kammerdicke

906

Keratometriewert

908

Linsendicke

910

Zentrale Korneadicke

912

Weiß-zu-Weiß-Abstand

914

Pupillengröße

916

Hintere Kammertiefe

918

Retinadicke

1102

Datensatz-Erfassungseinheit

1104

Parameterwert-Erzeugungseinheit

1106

Leistungswert-Bestimmungseinheit

1108

Parameterwert-Sendeeinheit

1200

Computersystem

Unless otherwise specified in the context of the figure description, the reference symbols may have the following meaning:

10

Bidirectional data exchange in the state of the art

100

Clinical device

102

Decision system, trained by a first server or executed by a second server, e.g. neural network, logistic regression system, decision tree system, support vector machine

104

First server, for example to generate the parameter values of the configuration and/or determine the performance value

106

Second server, for example, to run the configured decision system in clinical use

108

Third-party server, for example for audit-proof documentation

110

Data set with a large number of data points

110-1

Training dataset

110-2

Validation dataset

111

Pair of values as an example of a data point

112

Entrance of the decision system

113

Input value for the input of the decision system, for example scalar, vector or tensor

114

Patient data of a patient before an application, for example before implementation of the decision

115

Patient data of the patient after the application, for example after implementation of the decision

116

Output of the decision system

117

Output value for the output of the decision system, for example scalar, vector or tensor

117-T

Output values during training

117-K

Output values in clinical use

118

Clinical decision

120

Parameter values of a decision system configuration

130

Performance value of a performance metric

200

Method for configuring a nonlinear decision system, for example by the training server

202

Step of capturing a data record

204

Step of generating parameter values of a configuration of the decision system

206

Step of determining a performance value

208

Sending step (e.g., transmitting or providing)

210

Step of iterating, for example, iteration of collecting data sets, generating parameter values and determining performance values

212

Step of sending a documentation message

300

System for configuring a nonlinear decision system

400

Method for configuring a non-linear decision system, for example by the executing server

408

Selective receiving step

900

(e.g. “short” or “long”) eye of the patient

902

Axial length

904

Anterior chamber thickness

906

Keratometry value

908

Lens thickness

910

Central corneal thickness

912

White-to-white distance

914

Pupil size

916

Posterior chamber depth

918

Retinal thickness

1102

Data record acquisition unit

1104

Parameter value generation unit

1106

Performance value determination unit

1108

Parameter value sending unit

1200

computer system

QUOTES CONTAINED IN THE DESCRIPTION

This list of documents submitted by the applicant was generated automatically and is included solely for the convenience of the reader. This list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited patent literature

• WO 2023/014985 A1 [0003]
• US 2023/0081085 A1 [0006]

Claims (15)

A method (200) for configuring a nonlinear decision system (102) of a clinical device (100) to support a clinical decision (118), the method (200) comprising: acquiring (202) a data set (110) having a plurality of data points, wherein at least some of the data points each comprise a value pair (111) with an input value (113) of an input (112) of the decision system (102) indicating patient data (114; 115) of a patient and an output value (117) of an output (116) of the decision system (102) indicating the clinical decision (118) for the patient or dependent thereon; Generating (204) parameter values (120) of a configuration of the decision system (102) executed by a first server (104) by machine learning (ML) based on a training data set (110-1) that is a subset of the acquired (202) data set (110); Determining (206) a performance value (130) of a performance metric of the decision system (102) configured with the generated (204) parameter values (120), wherein output values (117-K) of the decision system (102) configured with the parameter values (120) are compared in response to the input values (113) of a validation data set (110-2) with the output values (117) of the validation data set (110-2), which is a subset of the acquired (202) data set (110) that is disjoint from the training data set (110-1); and sending (208) the generated (204) parameter values (120) for configuring the decision system (102) executed by a second server (106) in clinical use if the determined (206) performance value (130) meets a predetermined criterion. Procedure (200) according to Claim 1 , wherein the method (200) iterates (210) the acquisition (202) of a data set (110), the generation (204) of parameter values (120) and the determination (206) of a performance value (130) if the determined (206) performance value (130) does not meet the predetermined criterion. Procedure (200) according to Claim 1 or 2 , wherein the first server (104) executes the method (200), optionally after Claim 2 wherein the first server (104) documents the iteration (210). Method (200) according to one of the Claims 1 until 3 , further comprising: sending (212) a documentation message regarding the configuration of the decision system (102) to a third server (108) that is different from the first server (104) and the second server (106). Procedure (200) according to Claim 4 , wherein the documentation message specifies at least one of the following contents: a reason for generating (204) the parameter values (120) of the configuration of the decision system (102); a quantitative or qualitative change in the data set (110) compared to a previous generation (204) of the parameter values (120) of the configuration of the decision system (102) or compared to a previous transmission (208) of the generated (204) parameter values (120) of the configuration of the decision system (102); the determined (206) performance value (130) of the performance metric; and documentation of the iteration (210). Method (200) according to one of the Claims 1 until 5 , wherein the first server (104) is a training server for the ML of the decision system (102); and/or wherein the second server (106) is an inference server for the clinical use of the decision system (102); and/or wherein with reference to the Claim 5 or 6 the third server (108) is a data server for audit-proof documentation of the configuration of the decision system (102). Method (200) according to one of the Claims 1 until 6 , wherein the input value (113) of each value pair (111) of the data set (110) comprises patient data (114) of the patient before an application of the clinical decision (118) and patient data (115) of the patient after an application of the clinical decision (118); or wherein the input value (113) of each value pair (111) of the data set (110) comprises only patient data (114) of the patient before an application of the clinical decision (118); or wherein the input value (113) of each value pair (111) of the data set (110) comprises patient data (114) of the patient before an application of the clinical decision (118) and the output value (117) of each value pair (111) of the data set (110) comprises patient data (114) of the patient after an application of the clinical decision (118); or wherein the input value (113) of each value pair (111) of the data set (110) comprises patient data (114) of the patient before an application of the clinical decision (118) and the clinical decision (118) for the patient and the output value (117) of each value pair (111) of the data set (110) comprises patient data (114) of the patient after an application of clinical decision (118). Method (200) according to one of the Claims 1 until 7 , wherein the clinical decision (118) comprises: a selection of an implant for the patient from a discrete set of implants or a preselection of a subset of implants for the patient from a discrete set of implants; a set of characteristics for an implant of the patient; or a control data set of an additive and/or subtractive manufacturing of an implant for the patient; a control data set of a laser system for refractive surgery, optionally for laser-assisted in situ keratomileusis, LASIK, of the patient; or a control data set of a robot-assisted surgery system for the patient. Method (200) according to one of the Claims 1 until 8 , wherein the patient data (114; 115) comprise biometric data of the patient's eye (900), and wherein the clinical decision (118) comprises a selection of an intraocular lens to be implanted. Method (200) according to one of the Claims 1 until 9 , wherein the acquisition (202) of the data set (110) excludes value pairs (111) whose patient data (115) of the patient, after the application of the decision (118), have a deviation from a standard or target value that is greater than a predetermined threshold value, optionally a deviation of the refractive power of the eye (900) from a standard or target value of the implantation. Method (400) for executing a decision system (102) in clinical use of a clinical device (100) to support a clinical decision (118) based on a data set (110) with a plurality of data points, wherein at least some of the data points each comprise a value pair (111) with an input value (113) of an input (112) of the decision system (102) indicating patient data (114; 115) of a patient and an output value (117) of an output (116) of the decision system (102) indicating the clinical decision (118) for the patient or dependent thereon, wherein the method (400) comprises: Selectively receiving and/or applying (408) parameter values (120) from a first server (104) to a second server (106), wherein the parameter values (120) from the first server (104) are determined by machine learning, ML, based on a training data set (110-1) which is a subset of the data set (110), and wherein the selection of receiving and/or applying (408) depends on a performance value (130) of a performance metric of the decision system (102) configured with the generated parameter values (120) satisfying a predetermined criterion, wherein the performance metric comprises a comparison of output values (117-K) of the decision system (102) configured with the parameter values (120) in response to the input values (113) of a validation data set (110-2) with the output values (117) of the validation data set (110-2), which is a subset of the data set (110) that is disjoint from the training data set (110-1). Method (200; 400) according to one of the Claims 1 until 11 , wherein the method (200; 400) is triggered and/or repeated in an adaptation loop in response to a predefined external event outside the generation (204) of the parameter values (120) and/or outside the first server (104), optionally wherein the external event comprises a predefined quantitative or qualitative change in the data set (110) compared to existing parameter values (120) or a previous generation (204) of the parameter values (120) of the configuration of the decision system (102) or compared to a previous transmission (208) of the generated (204) parameter values (120) of the configuration of the decision system (102). A first server (104) for configuring a non-linear decision system (102) of a clinical device (100) for supporting a clinical decision (118), comprising: a data set acquisition unit (1102) designed to acquire (202) a data set (110) having a plurality of data points, wherein at least some of the data points each comprise a value pair (111) with an input value (113) of an input of the decision system (102) indicating patient data (114; 115) of a patient and an output value (117) of an output of the decision system (102) indicating the clinical decision (118) for the patient or dependent thereon; a parameter value generation unit (1104) designed to generate (204) parameter values (120) of a configuration of the decision system (102) executed by the first server (104) by machine learning, ML, on the basis of a training data set (110-1) which is a subset of the acquired (202) data set (110); a performance value determination unit (1106) designed to determine (206) a performance value (130) of a performance metric of the decision system (102) configured with the generated (204) parameter values (120), wherein output values (117-K) of the decision system (102) configured with the parameter values (120) are compared in response to the input values (113) of a validation data set (110-2) with the output values (117) of the validation data set (110-2), which is a subset of the acquired (202) data set (110) that is disjoint from the training data set (110-1); and a parameter value transmission unit (1108) designed to transmit (208) the generated (204) parameter values (120) for configuring the decision system (102) executed by a second server (106) in clinical use, if the determined (206) performance value (130) meets a predetermined criterion. A second server (106) for executing a decision system (102) in clinical use of a clinical device (100) for supporting a clinical decision (118) based on a data set (110) with a plurality of data points, wherein at least some of the data points each comprise a value pair (111) with an input value (113) of an input (112) of the decision system (102) indicating patient data (114; 115) of a patient and an output value (117) of an output (116) of the decision system (102) indicating the clinical decision (118) for the patient or dependent thereon, wherein the second server (106) comprises: a parameter value receiving unit configured to selectively receive and/or apply (408) parameter values (120) from a first server (104) to the second server (106), wherein the parameter values (120) from the first server (104) are machine learning, ML, are generated on the basis of a training data set (110-1) which is a subset of the data set (110), and wherein the selection of receiving and/or applying (408) depends on a performance value (130) of a performance metric of the decision system (102) configured with the generated (204) parameter values (120) meeting a predetermined criterion, wherein the performance metric comprises a comparison of output values (117-K) of the decision system (102) configured with the parameter values (120) in response to the input values (113) of a validation data set (110-2) with the output values (117) of the validation data set (110-2), which is a subset of the data set (110) that is disjoint from the training data set (110-1). A computer program product for configuring a non-linear decision system (102) of a clinical device (100) for supporting a clinical decision (118), the computer program product comprising a computer-readable storage medium having program instructions stored thereon, the program instructions being executable by one or more computers or control units and causing the one or more computers or control units to perform the method according to one of the Claims 1 until 12 to execute.