Technology for controlling or regulating a medical scanner in a scanner fleet

Abstract

The invention relates to a technique for controlling or regulating a medical imaging device in a fleet of medical imaging devices of a predetermined modality. A computer-implemented method (100) comprises accessing (S102) at least one digital database (304) to receive measurement metadata relating to at least one image acquisition or to the medical imaging device (S104). The image was acquired using the medical imaging device. Using a Large Language Model (LLM) (306), the received (S104) measurement metadata relating to at least one technical parameter of the image acquisition and / or the medical imaging device are analyzed (S106). Based on the analysis (S106) of the at least one technical parameter, program code is determined (S108). The program code is intended for controlling or regulating the medical imaging device.The specific (S108) program code is provided (S112).

Description

[0001] A technology for controlling or regulating a medical imaging device within a fleet of medical imaging devices of a predetermined modality is provided. The technology comprises, in particular, a method, a computing unit, a system, a computer program product, and a computer-readable storage medium.

[0002] As hospital chains consolidate, radiology departments must operate and maintain numerous MRI scanners across distributed locations. At the same time, qualified personnel to operate these scanners are becoming increasingly difficult to find, leading to the implementation of rotating or remotely supervised work models.

[0003] The standardization and homogenization of the MRI fleet of large radiology centers / chains is therefore becoming increasingly important. Detecting deviations, increasing efficiency, and analyzing the various MRI devices, some of which specialize in specific organ systems (e.g., neuro vs. cardio scanners), is a highly complex and iterative process.

[0004] Fleet analysis is currently supported by centrally provided dashboards with graphical visualizations addressing various questions. There are currently two sources for dashboard generation. Firstly, direct analyses are performed using machine log data. Current states and developer debugging information are written to the scanner in log data. A subset of this log information is extracted and analyzed centrally. Secondly, implicit analyses are performed using DICOM tags. By interpreting DICOM tags, scanner-specific implicit inferences about activity, measurement throughput, and other details can be drawn. The images are usually retrieved centrally from a PACS system for analysis, which is naturally limited to the information contained in the available DICOM images (not all are sent to the PACS system) and their tags (the tags contain only specific information).Both methods have in common that textual information must be interpreted and graphically processed.

[0005] The provided method of preparation and the questions are fixed and therefore not always suitable for the questions for the specific fleet and problem analyses of deviations and / or do not ideally reflect the analyst's way of thinking.

[0006] In practice, it's often difficult to find the right chain of dashboards. The insight gained from one visualization often leads to a follow-up question, requiring yet another dashboard to be found, making the process inefficient. Furthermore, newly introduced log information and / or DICOM tags cannot be used directly, and analysis algorithms need to be constantly updated.

[0007] Therefore, an objective of the present invention is to provide a solution for improved control of the scanners in a fleet of scanners of a predetermined modality. Alternatively or additionally, the object is to optimize image quality, energy consumption, and / or scanner utilization within the fleet. Furthermore, alternatively or additionally, the object is to enable further improvements to the control system in the event of future changes to the scanner fleet hardware and / or software.

[0008] This problem is solved by a method for controlling or regulating a medical imaging device in a fleet of medical imaging devices of a predetermined modality, by a computing unit, by a system, by a computer program (and / or a computer program product), and by a computer-readable storage medium according to the attached independent claims. Advantageous aspects, features, and embodiments are described in the dependent claims and in the following description, together with advantages.

[0009] The solution according to the invention is described below with respect to the claimed method and the claimed computing unit. Features, advantages, or alternative embodiments thereof may be assigned to the other claimed subject matter (e.g., the system, the computer program, or a computer program product) and vice versa. In other words, the claims for the computing unit and the system comprising the computing unit may be enhanced by features described or claimed in connection with the method, and vice versa. In this case, the functional features of the method are embodied by structural units of the computing unit or the system, and vice versa.

[0010] According to one procedural aspect, a (particularly computer-implemented) method for controlling or regulating a medical imaging device in a fleet of medical imaging devices of a predetermined modality is provided. The method comprises a step of accessing at least one digital database to receive measurement metadata relating to at least one image acquisition or to the medical imaging device. The image was acquired using the medical imaging device. The method further comprises the step of analyzing, using a Large Language Model (LLM), the received measurement metadata relating to at least one technical parameter of the image acquisition and / or the medical imaging device. The method further comprises the step of determining program code based on the analysis of the at least one technical parameter.The program code is intended to control or regulate the medical imaging device. The procedure further includes the step of providing the specified program code.

[0011] Using the technology according to the invention, image acquisition using medical imaging devices of a predetermined modality in a medical facility or a network of medical facilities can be analyzed and modified interactively, dynamically, iteratively, user-specifically, and / or "on-the-fly" as needed. The analysis and modification as required (e.g., using control or regulation program code) can be performed with high precision and specificity with regard to a medical question. In the context of the technology according to the invention, "on-the-fly" can mean that the permanent or temporary storage of data in a permanent data storage medium is dispensed with. For example, the measurement metadata can be analyzed directly (e.g., without long-term storage on a processing unit executing the process or in a cloud executing the process).Alternatively or additionally, the provided program code does not need to be stored long-term. For example, the result of the analysis of the measurement metadata can be deleted within a predetermined period after being provided as program code.

[0012] The fleet of medical imaging equipment (also: scanner fleet) of a predetermined modality can comprise all scanners of that modality (e.g., all MRI scanners) belonging to a medical facility or a network of medical facilities (also: fleet operator; or simply: operator). For example, the scanner fleet may have a shared scheduling system and / or shared (especially trained) operating personnel.

[0013] The at least one digital database can comprise a Picture Archiving and Communication System (PACS) and / or an Electronic Health Record (EHR) system (also known as an Electronic Medical Record (EMR) or Electronic Patient Record (ePA)). Alternatively or additionally, the at least one digital database can comprise a local database of the medical imaging device (scanner), for example, a log database.

[0014] The measurement metadata can be metadata relating to image acquisition (also: acquisition and / or measurement) and, in particular, include metadata of acquired image data, for example, as a DICOM header (DICOM stands for Digital Imaging and Communications in Medicine). The DICOM header may, for example, contain a medical question. Alternatively or additionally, the measurement metadata can be metadata relating to the medical imaging device (e.g., the MRI scanner). For example, the measurement metadata may include machine log data and / or measurement metadata of the imaging device. The machine log data and / or measurement metadata may include technical data (e.g., technical parameters) before, during, and / or after image acquisition.For example, machine log data and / or measurement metadata may contain information indicating idle times (also known as dead times) of the scanner and / or times the scanner is in energy-saving mode. Alternatively or additionally, the machine log data and / or measurement metadata may include data on acquired images whose image data was not selected for storage in the PACS. Alternatively or additionally, the measurement metadata may include metadata of the medical imaging device (hereinafter referred to as the device or scanner) relating to the device's power supply, e.g., power supply (such as the number of power interruptions), network connection (e.g., bandwidth fluctuations, etc.). Alternatively or additionally, the measurement metadata from multiple devices in the fleet may be aggregated to enable analysis and / or the calculation of control variables for the fleet.

[0015] Accessing the at least one digital database may involve accessing two or more digital databases, for example, a PACS and the log databases of one or more (especially all) scanners within the fleet.

[0016] The two or more digital databases can contain different types of measurement metadata. For example, the PACS can include selected captured image data with DICOM headers, and the log databases of the scanners used to capture the image data can include machine log data and / or other measurement metadata.

[0017] The LLM (also known as a large language model) can be trained to analyze and / or semantically combine measurement metadata from at least one (especially from different) digital database(s), particularly with regard to at least one technical parameter. This technical parameter may be necessary to answer a question concerning the fleet of medical imaging devices. For example, the technical parameter may include utilization, operating time, downtime, number of examinations, number of protocols used, protocol type, and / or other key performance indicators.

[0018] The LLM can represent a computational linguistic probability model that has learned statistical word and sentence sequence relationships from a variety of text documents (especially including DICOM headers, machine log data and other measurement metadata and / or including an initial program code) through a computationally intensive training process.

[0019] The program code can control or regulate energy consumption (e.g., a transition between recording mode and energy-saving mode) and / or a recording protocol. The program code can be scanner-specific (or device-specific), recording protocol-specific, or universal for multiple (especially all) scanners in the fleet.

[0020] The provision of the program code can include the output of a control signal. Alternatively or additionally, the provision of the program code can include output to a user interface (UI), for example, graphical output on a graphical user interface (GUI). The user interface output can include a graph (also called a dashboard) or other representation of historical and / or statistical data. The output data can relate to a single scanner or a group of scanners (for example, all scanners in the fleet).

[0021] The procedure can be implemented in compliance with data protection requirements. For example, the at least one digital database can be located within a computer system of the medical facility or the network of medical facilities and / or be accessible only within a local network (e.g., a local area network, LAN). Alternatively or additionally, the data in the at least one digital database can be access-protected and / or encrypted.

[0022] The procedure can be executed by a (particularly central) computing unit within the scanner fleet. This (particularly central) computing unit can be an "edge device." The "edge device" can be integrated into an internal computer system of the medical facility and / or provided as a cloud system for the network (fleet of medical imaging devices) via a network connection, e.g., the internet.

[0023] The process can be executed locally, distributed, and / or in a (e.g., local) cloud.

[0024] The predetermined modality may be or include magnetic resonance imaging (MRI), computed tomography (CT), positron emission tomography (PET), single-photon emission computed tomography (SPECT), X-ray and / or a hybrid procedure of the aforementioned modalities, in particular PET / CT or PET / MRI.

[0025] The scanner fleet can, for example, be an MRI scanner fleet. Using the technology according to the invention, the utilization, energy consumption and / or image quality of the MRI scanner fleet (or any other scanner fleet, e.g., a CT scanner fleet) can be optimized.

[0026] The program code may include machine code, in particular to control or regulate energy consumption and / or the use of at least one recording protocol.

[0027] The machine code can be used to modify at least one (e.g., the at least one analyzed) technical parameter of the scanner or of multiple scanners within the fleet (e.g., all scanners). The technical parameter could, for example, be a parameter that distinguishes between a power-saving mode and a recording mode, in particular activating the power-saving mode or configuring its activation (e.g., time-based and / or event-based).

[0028] The machine code allows switching between different scanner states, such as between energy-saving mode and capture mode. Alternatively or additionally, the machine code can be used to distinguish between image capture according to a first capture protocol and image capture according to a second capture protocol, and in particular to control, especially limit, the availability of the capture protocols on the scanner.

[0029] The first and second recording protocols may differ, for example, in the duration of image acquisition, total energy consumption, radiation dose and / or measurement sequence (e.g., in MRI).

[0030] Deployment can include output to a user interface (UI). The procedure can further include a step of receiving user input via the user interface (UI) regarding the deployed program code. The procedure can further include a step of modifying the specific program code based on the received user input. The procedure can further include a step of deploying the modified program code.

[0031] Outputting the provided program code to the user interface (UI) can include a "prompt".

[0032] The term "prompt" can refer, on the one hand, to the output of a request to a user (also: operator) on the UI to provide user input. On the other hand, the term "prompt" can also be understood as the user input itself in response to the prompt.

[0033] The prompt or user input can be used to control the LLM.

[0034] User input can include feedback (also: feedback and / or evaluation) regarding the provided program code.

[0035] This allows for targeted modification (e.g., optimization) of the program code.

[0036] The procedure may further include a step of checking the specified or modified program code with respect to at least one consistency condition. The step of deploying the program code may be executed if the check results in the satisfaction of at least one consistency condition.

[0037] By verifying at least one consistency condition, it can be ensured that the provided program code is functional, technically correct and / or safe, and / or that the program code meets official requirements (technical term: compliance).

[0038] The minimum consistency requirement can include machine code executability, compiler cross-check, syntax analysis, technical review, safety, compliance with predefined regulations and guidelines, and / or validity.

[0039] In the context of the invention, a compiler (also called a compiler) is a computer program that translates source code of a specific programming language into a form that can be executed (e.g., directly) by a computing device or computer. Passing a compiler cross-check can guarantee that the program code is executable (e.g., more or less directly).

[0040] Syntax analysis can ensure that the program code is functional and meaningful or goal-oriented.

[0041] Adherence to the prescribed regulations and guidelines (also known as compliance) enables conformity with legal, regulatory and / or internal company requirements.

[0042] Technical verification and validation of the program code can each ensure technical executability.

[0043] The process may include a step of receiving user input via a user interface (UI) to determine the program code based on the received user input.

[0044] User input can be received before the step of analyzing the measurement metadata using the LLM (for example, to perform the analysis in a targeted manner for a specific question), before determining the program code (for example, to weight an analysis result), and / or after providing the program code (for example, to modify the program code).

[0045] The procedure may include a step of retraining the LLM using the received measurement metadata and / or the received user input.

[0046] The LLM can be retrained using newly received measurement metadata. In some implementations, the LLM can also be retrained based on one or more user inputs, such as pre-selected criteria and / or feedback on the provided program code. This feedback can be received in the form of user input.

[0047] Receiving user input can include a preselection of criteria (e.g., regarding scanners, acquisition protocols, and / or anatomical regions of a patient group) against which the LLM analyzes the received measurement metadata. For example, the user input can include a medical question for which the image acquisition is to be performed.

[0048] Receiving user input can occur in response to a prompt (also: user request).

[0049] The user interface (UI) can be designed as a graphical user interface (GUI) and / or include a microphone.

[0050] Providing the specific (and / or modified) program code may include a graphical visualization using the GUI.

[0051] The program code can be deployed as one or more dashboards. A dashboard (e.g., in information management) can refer to a graphical user interface used to visualize data. The program code can specify how and when data is displayed on the UI (e.g., the form of the display, the overlaying of displays, and / or the selection and / or combination of data sets, etc.).

[0052] Using the GUI and / or one or more dashboards, the analysis of at least one technical parameter and / or the analysis of measurement metadata of the imaging medical device (for example, one or more MRI scanners) can be intuitively and easily understood.

[0053] Providing the specified or modified program code may include outputting a control signal. Optionally, the control signal may be domain-specific, in particular device type-specific, parameter- and / or software-specific, and / or recording protocol-specific.

[0054] The control signal or regulation signal can be used to change at least one technical parameter for image acquisition by one or more (especially all) scanners in the fleet. For example, idle time can be shortened and / or an acquisition protocol can be modified or replaced.

[0055] The control signal or regulation signal may be intended to activate a power-saving mode, to modify (especially shorten) an idle time until the power-saving mode is activated, to modify or replace an acquisition protocol of at least one medical imaging device and / or to modify the timing of image acquisitions (especially for a predetermined anatomical area of ​​a patient group).

[0056] The control signal for activating the energy-saving mode (also known as standby mode) can specify a predetermined duration for inactivity (also known as idle time) after an image has been captured. After this predetermined period, the energy-saving mode can be activated using the control signal. For example, the control signal can shorten a preset duration to achieve overall energy savings.

[0057] Alternatively or additionally, there can be no preset idle time before the energy saving mode is activated.

[0058] Alternatively or additionally, the energy-saving mode can be activated depending on the time of day and / or day of the week. For example, regularly occurring idle periods can be identified by analyzing the measurement metadata, and the activation of the energy-saving mode can be scheduled for these periods. For instance, a scanner might typically be in regular use during the day from Monday to Friday. At night and on weekends, the scanner might only be used in unplanned emergencies, so overall energy savings can be achieved by activating the scanner's energy-saving mode at night and on weekends, provided there is no unplanned emergency. After an unplanned use, the scanner can then be switched back to energy-saving mode after a short idle period at night and on weekends.

[0059] Modifying or replacing the capture protocol can include, for example, shortening or saving energy. Shortening the capture protocol can enable a greater number of image captures using the scanner. Replacing the capture protocol can involve transferring a capture protocol from one scanner to another. This transfer can be done via the cloud, the (especially central) computing unit, and / or another edge device.

[0060] Modifying the timing of image acquisitions can include optimizing (especially shortening) the intervals between the start of successive image acquisitions for a predetermined type of image data.

[0061] The anatomical area of ​​a patient group may, for example, include image data of a knee area (e.g., in the case of a suspected ligament tear), and / or image data of a thoracic area (e.g., in the case of a suspected heart attack, in the case of another suspected heart and / or vascular disease, and / or in the case of a suspected lung infection), and / or image data of a head area (e.g., in the case of a suspected brain tumor or stroke).

[0062] The patient group may include patients with a similar suspected diagnosis, a similar examination goal and / or a similar treatment goal.

[0063] Modifying or replacing the acquisition protocol and / or imaging the predetermined anatomical region of the patient group may involve the administration of contrast agent (particularly omitting a contrast agent administration to optimize time) and / or the inclusion (and / or omission and / or replacement) of equipment (for example, anatomically specific measuring coils such as knee coils). For instance, an acquisition protocol can be simplified and / or shortened by acquiring only one image instead of two images with and without contrast for comparison. Alternatively or additionally, an acquisition protocol can be simplified and / or shortened by, for example, omitting a multi-channel coil of an MRI scanner.

[0064] The at least one digital database can include at least one vector database and / or an embedded database system.

[0065] A vector database can be a database system used for storing and searching vectors. The database system can be optimized for efficient searches for similar vectors within the database. The vectors can be high-dimensional representations of unstructured data, such as images and / or descriptive text. A cosine similarity and / or a Euclidean distance can be used as measures of similarity for the vectors. The most similar vectors can be identified, for example, using predefined thresholds (e.g., encompassing a maximum of N similar vectors for a natural number N) and / or by weighting the N best vectors. Alternatively or additionally, an approximate nearest-neighbor search can be used.

[0066] An embedded database system is a database system embedded within application software, but it is not visible from the outside. An embedded database system does not need to be recognizable as such from the outside and / or cannot be used by third-party systems for data storage. The advantages of embedded database systems arise from the fact that the manufacturer can implement a customized solution tailored to the specific application (especially medical imaging of the predetermined modality), which goes beyond the capabilities of standard administration and acceleration. At the same time, data protection regulations can be observed.

[0067] Another advantage is the simpler installation and licensing of a product (especially a scanner and / or its software) that uses an embedded database system. The product manufacturer can deliver their product as a whole to their customers. Licenses for their product can be negotiated directly between the product manufacturer and their customer without the involvement of the database manufacturer. The product manufacturer can reach a license agreement with the database manufacturer without involving their customers.

[0068] The at least one digital database and / or the LLM can use one or more predefined database languages. For example, SQL (also known as Structured Query Language) can be a database language for defining data structures in relational databases, as well as for manipulating (e.g., inserting, modifying, and / or deleting) and querying the data sets based on them.

[0069] Using vector databases, the embedded database system and / or the predefined database languages, semantic search and / or semantic analysis of the received measurement metadata is enabled.

[0070] The analysis can include semantic mapping and / or structured summarization of the measurement metadata.

[0071] The at least one technical parameter may include the energy consumption of a medical imaging device per unit of time, the number of images taken by a medical imaging device per unit of time, the number of images taken per unit of time depending on an acquisition protocol and / or the number of images taken per unit of time depending on an anatomical area of ​​a patient group captured.

[0072] In one implementation example, the energy efficiency of one or more scanners within the fleet is analyzed using LLM. Based on the received measurement metadata, energy consumption is determined over a predetermined period (also: per unit of time). An average energy consumption (for example, for a predetermined acquisition protocol and / or a predetermined medical question) of all scanners within the fleet can be determined, as well as deviations of one or more scanners. It can be determined whether and / or when an energy-saving mode is active on the scanner or should be active. The length of the idle time before switching to energy-saving mode can be checked and optimized (e.g., shortened).

[0073] In another embodiment, scan efficiency can be analyzed. For example, the number of image acquisitions, the number of patients, and / or the number of measurements over a predetermined period (also: per unit of time) can be determined. An average value can be calculated, for example, depending on the anatomical area (also: per body region), and deviations of individual scanners can be determined. An acquisition protocol and / or the number of measurement steps can be optimized. For example, an acquisition protocol measurement time can be reduced by reducing the number of measurement steps (e.g., no separate measurements with and without contrast agent) and / or by changing the parameterization of the measurement steps.

[0074] In another embodiment, scanner utilization can be analyzed. For example, a schedule and / or temporal trends can be analyzed when the scanner is underutilized. In particular, the analysis can consider the anatomical areas (also: measured body regions) captured.

[0075] The implementation examples can be combined to optimize the utilization of the scanner fleet and / or the overall energy efficiency of the scanner fleet and / or to reduce the time delay of image acquisition.

[0076] The analysis of at least one technical parameter can be scanner-specific, specific to a type of activity (e.g., which anatomical areas are typically recorded using a scanner), specific to a recording protocol, and / or specific to a type of measurement (also: image acquisition).

[0077] By analyzing at least one technical parameter, program code can be determined to, for example, activate an energy-saving mode. This can be done, for instance, via an application programming interface (API). A Boolean flag can be set in a service software layer of the scanner. Alternatively or additionally, an idle time before switching to energy-saving mode can be adjusted, particularly for the entire scanner fleet. For example, an integer value in the control software (e.g., as an idle time in milliseconds) can be set and / or modified to, for instance, put a gradient amplifier (GPA) into energy-saving mode (also known as standby mode) after the idle time has elapsed, such as in an MRI scanner.

[0078] Modifying or replacing the acquisition protocol can involve replacing one measurement program with the measurement program of a different scanner. In one embodiment, the measurement program can be transferred from Scanner B (or the other scanner) to Scanner A (the scanner) via the (e.g., central) processing unit, the edge device, the cloud, and / or a network drive. Alternatively or additionally, a push update can be performed on the scanner from a central protocol management server. Modifying or replacing the acquisition protocol or measurement program can be done via an HTTP REST interface of the scanner.

[0079] In a recorded anatomical area (also: body area) with many idle times (also: dead times), utilization can be optimized by changing the time schedule.

[0080] The process can be executed on a central computing unit, on an edge device and / or in a cloud.

[0081] In one embodiment, the method can be executed on an edge device or other central computing unit of the medical facility or network of medical facilities. In another embodiment, the method can be executed distributed across multiple hardware units, for example, in a local cloud of the medical facility or network of medical facilities. The edge device can alternatively or additionally be configured as hardware that connects the local network to the external internet.

[0082] According to one aspect of the device, a computing unit is provided for controlling or regulating a medical imaging device within a fleet of medical imaging devices of a predetermined modality. The computing unit includes a database interface configured to access at least one digital database in order to receive measurement metadata relating to at least one image acquisition or to the medical imaging device itself. The image acquisition was performed using the medical imaging device. The computing unit further includes an analysis module configured to analyze, using a linear function module (LLM), the received measurement metadata relating to at least one technical parameter of the image acquisition and / or the medical imaging device.The processing unit further comprises a program code determination module, which is configured to determine a program code based on the analysis of at least one technical parameter. The program code is intended for controlling or regulating the medical imaging device or for analyzing measurement metadata of the medical imaging device. The processing unit further comprises a program code interface or a program code deployment module, which is configured to provide the determined program code.

[0083] The computing unit can be a central computing unit and / or an edge device. The computing unit can be configured to execute the procedure according to the procedure aspect. Alternatively or additionally, the computing unit can comprise any feature disclosed in the context of the procedure according to the procedure aspect.

[0084] According to one system aspect, a system for controlling or regulating a medical imaging device or for analyzing measurement metadata of a medical imaging device is provided in a fleet of medical imaging devices of a predetermined modality. The system comprises a computing unit according to the immediately preceding claim. The system further comprises at least one digital database in which measurement metadata, in particular relating to at least one image acquired by the medical imaging device, is stored.

[0085] The system can be configured to execute the procedure according to the procedure aspect. Alternatively or additionally, the system can include any feature disclosed in the context of the procedure according to the procedure aspect.

[0086] According to another aspect, a computer program product is provided with program elements that cause a computing unit to execute the steps of the procedure for controlling or regulating a medical imaging device in a fleet of medical imaging devices of a predetermined modality according to the procedure aspect when the program elements are loaded into a memory of the computing unit.

[0087] According to yet another aspect, a computer-readable medium is provided on which program elements are stored that can be read and executed by a computing unit to carry out steps of the procedure for controlling or regulating a medical imaging device in a fleet of medical imaging devices of a predetermined modality according to the procedure aspect when the program elements are executed by the computing unit.

[0088] The properties, features, and advantages of the present invention described above, as well as the manner in which they are achieved, will become clearer and more understandable in light of the following description and the exemplary embodiments, which are explained in more detail in connection with the drawings. This following description does not limit the invention to the embodiments contained therein. Identical components or parts may be designated with the same reference numerals in different figures. In general, the illustrations are not to scale.

[0089] It is understood that a preferred embodiment of the present invention may also be any combination of the dependent claims or of the above embodiments with the respective independent claim.

[0090] These and other aspects of the invention will become apparent from the embodiments described below and will be explained by reference to them. Fig. Figure 1 is a flowchart of a method for controlling or regulating one medical imaging device in a fleet of medical imaging devices of a predetermined modality according to a preferred embodiment of the present invention; Fig. Figure 2 is an overview of the structure and design of a computing unit for controlling or regulating a medical imaging device in a fleet of medical imaging devices of a predetermined modality according to a preferred embodiment of the present invention; and Fig. Figure 3 shows a schematic embodiment of the method of Fig. 1. Including a check of consistency conditions or “reasoning” as well as visualizations of the program code.

[0091] Any reference numerals in the claims are not to be understood as limiting the scope of application.

[0092] Fig. Figure 1 schematically shows an exemplary flowchart of a computer-implemented procedure 100 for controlling or regulating a medical imaging device in a fleet of medical imaging devices of a predetermined modality.

[0093] Procedure 100 comprises step S102 of accessing at least one digital database to receive measurement metadata relating to at least one image acquisition or to the medical imaging device S104. The image acquisition was carried out using the medical imaging device.

[0094] The procedure 100 further includes a step S106 of analyzing, using a Large Language Model (LLM), the received S104 measurement metadata with respect to at least one technical parameter of the image acquisition and / or the imaging medical device.

[0095] Procedure 100 further comprises step S108 of determining a program code based on the analysis S106 of at least one technical parameter. The program code is intended for controlling or regulating the medical imaging device.

[0096] Procedure 100 further includes a step S112 of providing the specified S108 program code.

[0097] Procedure 100 can include step S105 of retraining the LLM using the received S104 measurement metadata and / or using a received (e.g. in steps S107 and / or S114) user input.

[0098] Procedure 100 can include a step S107 of receiving user input via a user interface (UI) to determine the program code based on the received S107 user input S108. The user input can be received not only at the in Fig. not only at the point shown in the process flow, but also, for example, before step S105 of retraining the LLM and / or before step S106 of analyzing the measurement metadata using the LLM.

[0099] Procedure 100 may include a step S110; S110' of checking the specified S108 or a modified (e.g. in step S116) program code with respect to at least one consistency condition.

[0100] Procedure 100 can include a step S114 of receiving user input via a user interface (UI) regarding the provided S112 program code. In a step S116, the specified S108 program code can be modified based on the received S114 user input. The modified S116 program code can be provided in a step S118.

[0101] Fig. Figure 2 schematically shows an embodiment of a computing unit 200 for controlling or regulating a medical imaging device in a fleet of medical imaging devices of a predetermined modality.

[0102] The computing unit 200 includes a database interface 202, which is configured to access at least one digital database in order to receive measurement metadata relating to at least one image acquisition or to the medical imaging device. The image acquisition was carried out using the medical imaging device.

[0103] The computing unit 200 also includes an analysis module 206, which is designed to analyze, by means of an LLM, the received measurement metadata with regard to at least one technical parameter of the image acquisition and / or the imaging medical device.

[0104] The computing unit 200 also includes a program code determination module 208, which is designed to determine a program code based on the analysis of at least one technical parameter. The program code is intended for controlling or regulating the medical imaging device or for analyzing measurement metadata of the medical imaging device.

[0105] The computing unit 200 also includes a program code interface 212 or a program code deployment module 212, which is designed to deploy the specific program code.

[0106] The computing unit 200 can include a retraining module 205, which is designed to retrain the LLM using the received (measurement metadata and / or the received user input).

[0107] The computing unit 200 can include a user input receiving interface 207, which is configured to receive user input via a user interface (UI) in order to determine the program code based on the received user input.

[0108] The user input receiving interface 207 can alternatively or additionally be configured to receive user input via the user interface (UI) regarding the provided program code.

[0109] The computing unit 200 can include a verification module 210, which is designed to check the specified or modified program code with respect to at least one consistency condition.

[0110] The computing unit 200 can include a program code modification module 216, which is trained to modify the specific program code based on the user input received.

[0111] The program code interface 212 can also be configured to provide the modified program code.

[0112] The computing unit 200 can include an input / output interface 220. The database interface 202, the optional user input / receiving interface 207, and / or the program code interface 212 can be embodied by the input / output interface 220.

[0113] The computing unit 200 can comprise a processor 222. The optional retraining module 205, the analysis module 206, the program code determination module 208, the optional verification module 210 and / or the optional program code modification module 216 can be embodied by the processor 222.

[0114] The computing unit 200 can include a memory 224. Program elements for executing the procedure 100 can be stored in this memory. Alternatively or additionally, intermediate or final results of the steps of the procedure 100, or outputs from the individual modules or interfaces of the computing unit 200, can be temporarily stored or saved.

[0115] The computing unit 200 can be configured to execute procedure 100.

[0116] A system (not shown) for controlling or regulating a medical imaging device or for analyzing measurement metadata of a medical imaging device in a fleet of medical imaging devices of a predetermined modality comprises a computing unit 200 and at least one digital database in which measurement metadata, in particular relating to at least one image acquired by means of the medical imaging device, is stored.

[0117] The system can be trained to execute procedure 100.

[0118] The technology according to the invention (for example comprising the method 100, the computing unit 200 and / or a system comprising the computing unit 200) can also be referred to as “Generative MR Fleet Analysis with LLMs”.

[0119] The technology according to the invention can significantly simplify fleet analysis. Fleet analysis can be interactive, dynamic, iterative, user-specific, and / or graphical.

[0120] Using a Large Language Model (LLM), all data sources (e.g., logs, DICOM tags, etc.) can be efficiently analyzed with regard to a question, and the LLM can create associated program code, for example, for graphical visualization.

[0121] To ensure the program code (or simply code) is valid, one implementation example includes programming language-specific and / or program-specific reasoning elements (also known as verifiable consistency conditions, for example, in steps S110 and S110' of procedure 100). These elements filter out invalid results during inference (e.g., via compiler cross-check). For instance, based on the interpretation of the current graph, the user can initiate a follow-up question, which in turn extends and / or modifies the existing code, thereby improving, among other things, the graphical visualization. Thus, based on their newly acquired insights, the user can refine the graphical evaluation to better analyze the fleet of medical imaging devices (e.g., an MRI fleet).

[0122] According to the inventive technique, the LLM can also modify existing dashboards, which are either provided by default or created from a previous (or recent) analysis. For example, the prompt is supplemented with the existing code and adapted to include an extension relevant to the specific question.

[0123] The user can enter their question either in a provided input window (as an example of a UL, especially a GUI) and / or via voice input (as an alternative example of a UI).

[0124] Optionally, the user can pre-select a specific area of ​​existing graphical representations to narrow their question to that specific area, e.g. by marking a particular scanner, body area, or subplots.

[0125] Fig. Figure 3 shows an embodiment of the technology according to the invention. At reference numerals S107 and S114, user input is received from user 302. The user input can be, for example: "Output of the fleet operators or scanners that performed more than 3 neurological examinations in the past month"; "Display of the MRI scanner with the lowest patient throughput in the past month" and / or "Determine which clinical program requires the most time on average".

[0126] The LLM 306 performs step S106 of analyzing measurement metadata. As shown at references S102 and S104, the measurement metadata is received from one or more digital databases. For example, the measurement metadata may include MRI scanner logs (or machine logs, also known as machine log data), DICOM tags, and / or transponder (TP) receiver logs.

[0127] At reference S108, program code is determined and at reference S110, it is checked in a sketched "reasoning" element with respect to one or more consistency conditions. For example, a compiler cross-check and / or a syntax check is performed.

[0128] The program code provided at reference S112 may include a database language, such as SQL (e.g., SQL for Structured Query Language), and / or a visual source code.

[0129] Reference numeral 308 outlines two types of graphical representations or visualizations as examples. These graphical representations or visualizations can, for example, utilize a program such as QLikeSense, HTML5 Plots, and / or Power BI for data analysis.

[0130] Reference numeral 310 in Fig. Figure 3 shows an embodiment in which an initial source code for an existing visualization and / or prior information of elements that have been selected by the user is provided.

[0131] Reference 312 in Fig. Figure 3 further outlines an embodiment in which the user visually interprets the graphical representations or visualizations 308. This may give rise to follow-up questions and / or a need for further analysis. For example, the user may receive a prompt or a request for user input.

[0132] Existing LLMs can be adapted and / or extended in different, combinable ways for the application according to the invention.

[0133] In one embodiment, the LLM can be fine-tuned. To optimize the LLM specifically, it can be further trained with a dataset (in particular, a measurement metadata set) that includes user (or operator) queries, fleet databases (e.g., comprising DICOM tags and / or log data, such as machine log data), and associated dashboard and / or visualization source code. The data can be derived from real-world datasets, allowing the LLM to gain a better understanding of which procedures (e.g., regulations or controls) are best suited in which contexts.

[0134] In a further embodiment, the technology according to the invention includes prompting. The LLM can be controlled by specific input prompts, among other things to provide relevant and concrete dashboard suggestions. Over time and with feedback, the structure and wording of the prompt can be refined and improved via metaprompting, which optimizes the configuration of the LLM for this embodiment (or use case). For example, high precision and / or high specificity of the response can be required.

[0135] In another embodiment, the at least one digital database comprises semantic databases. The LLM can be used in combination with a so-called embedded database and / or vector database containing user data, operator-specific data (e.g., specific to a clinic or medical facility, and / or a network of clinics or medical facilities, particularly with a distributed system), DICOM tags, and / or dashboard or visualization source code. Such a database can enable the LLM to semantically access an extensive history of cases and thus process large amounts of data in one or more prompts.

[0136] In another embodiment, continuous learning and feedback loops can be incorporated. Users can provide feedback (also called user input) on the LLM's suggestions. This feedback can be used to regularly update and improve the LLM. For example, a system can be implemented where users rate how useful or accurate a suggested visualization was. These ratings can then be used to fine-tune the model.

[0137] In a further embodiment, the technology according to the invention is integrated into existing imaging (e.g., MRI) software. The LLM can be centrally hosted directly in the Teamplay Cloud and communicate with the fleet's image (e.g., MRI) database and the Teamplay frontend. The Teamplay Cloud can include a (e.g., manufacturer-specific) solution for fleet analysis and data management.

[0138] The technology according to the invention allows for user-specific, interactive, dynamically expandable, and / or "on-the-fly" analysis of various data sources for interpreting the activity of (e.g., MRI) scanner fleets. Various information sources can be structured and aggregated, and information can be efficiently summarized and / or extracted for graphical representation. The technology according to the invention enables an iterative, investigative approach to analyzing fleet deviations, statistics, trends, and / or visualization methods.

[0139] A general challenge is unstructured data, from which it is difficult to derive a control loop for (e.g., MRI) scanner fleet optimization.

[0140] Hosting or implementation of the technology according to the invention can preferably take place on an edge device (EDGE, e.g., the computing unit 200), which provides a bidirectional connection and / or a data node to the respective imaging systems or scanners. For example, edge hosting may be preferred for data protection reasons (especially with regard to patient data). Alternatively, hosting or implementation of the technology according to the invention can take place in a cloud.

[0141] Control loop scenarios can affect the energy efficiency of the imaging systems or scanners, the scan efficiency of the imaging systems or scanners (especially during a measurement or image acquisition) and / or the scan utilization of the imaging systems or scanners.

[0142] One example of a control loop regarding the energy efficiency of imaging systems or scanners might include the requirement to determine (and / or output) the average energy consumption of the MRI systems over the past month and to identify (and / or output) which systems or scanners deviate significantly from the average in terms of energy consumption, particularly those exceeding it. Another requirement might be to check whether an energy-saving mode (also known as Eco Power Mode) is active on the systems or scanners. If the energy-saving mode is not active, it can be activated via a system programming interface (API). The LLM can generate program code to activate the energy-saving mode for some or all (e.g., N) of the imaging systems or scanners. This can involve setting a Boolean flag in a service software layer of the respective scanner.

[0143] Alternatively or additionally, a predetermined "idle time" (also known as idle time or dead time) can be monitored, after which the imaging system or scanner switches to energy-saving mode (also known as Eco mode). The "idle time" can be reduced across the entire fleet so that it enters standby mode (also known as energy-saving mode) sooner. An integer value can be set in the control software to define the "idle time" in milliseconds (ms). For example, the gradient amplifier (GPA) of an MRI scanner switches to standby mode based on this integer value.

[0144] In another embodiment, a control loop regarding the scan efficiency of imaging systems or scanners, particularly during a measurement or image acquisition, includes determining (and / or outputting) the average number of patients measured per (e.g., MRI) scanner over the past month. For example, for two imaging systems or scanners that deviate (especially from the average), the average scan time per body region can be determined (and / or output), and it can be determined (and / or output) which body region deviates on average from the other imaging systems or scanners. The acquisition protocol (and / or individual measurement steps) for the deviating body regions and their individual protocol measurement times can be determined (and / or output). Deviations can consist of a number of measurement steps and / or parameterization of the individual measurement steps.As a corrective measure, a deviating measurement program or image acquisition program can be replaced by the corresponding program of another system.

[0145] According to option A, the protocol from system A is exported as a protocol structure to a network drive, an EDGE, and / or the cloud, and then programmatically imported by system B. According to option B, a protocol update is triggered as a 'push' from a central protocol management server (Teamplay MR Protocol Module) to the system. Communication with the central server can be initiated via an HTTP REST interface.

[0146] In another embodiment, a control loop regarding system scan utilization includes determining (and / or outputting) a 'table time' share of the scanner fleet, e.g., the percentage of scanner 'operating time' during which a patient is lying on the table (or patient bed). For scanners with low 'table time,' a timeline of the past week is determined (and / or output), and 'table time' ranges are marked. A percentage breakdown of the measured body regions with the most 'table time' gaps (and / or scanner downtime) is determined (and / or output). For example, one result might be that head scans consistently have many downtimes. As a corrective measure, the slot duration for brain scans can be reduced from 40 to 25 minutes via the scheduling API.

[0147] Regardless of the grammatical gender of a particular term, persons (e.g. users) with male, female or other gender identities are included.

[0148] Unless explicitly described already, individual embodiments or their individual aspects and features described with reference to the drawings may be combined or interchanged without limiting or extending the scope of the described invention, provided such combination or interchange is meaningful and in line with the present invention. Advantages described with respect to a particular embodiment of the present invention or with respect to a particular figure are, wherever applicable, also advantages of other embodiments of the present invention.

Claims

[1] Computer-implemented method (100) for controlling or regulating one medical imaging device in a fleet of medical imaging devices of a predetermined modality, comprising the steps: - Accessing (S102) at least one digital database to receive measurement metadata relating to at least one image acquisition or to the medical imaging device (S104), wherein the image acquisition was carried out using the medical imaging device; - Analyze (S106), using a Large Language Model, LLM, the received (S104) measurement metadata with respect to at least one technical parameter of the image acquisition and / or the medical imaging device; - Determining (S108) a program code based on the analysis (S106) of the at least one technical parameter, wherein the program code is intended for controlling or regulating the medical imaging device; and - Providing (S112) the specified (S108) program code. [2] Method (100) according to claim 1, wherein the predetermined modality is selected from the group comprising: - Magnetic resonance imaging (MRI); - Computed tomography, CT scan; - Positron emission tomography, PET; - Single-photon emission computed tomography, SPECT; - X-rays; and - Hybrid procedures of the above modalities, in particular PET / CT or PET / MRI. [3] Method (100) according to any one of the preceding claims, wherein the program code comprises machine code. [4] Method (100) according to one of the preceding claims, wherein the provisioning (S112) comprises outputting to a user interface, Ul, and wherein the method (100) further comprises the steps: - Receiving (S114) user input via the user interface, UI, with respect to the provided (S112) program code; - Modifying (S116) the specified (S108) program code based on the received (S114) user input; and - Providing (S118) the modified (S116) program code. [5] Method (100) according to any one of the preceding claims, further comprising the step: - Checking (S110; S110') the specified (S108) or modified (S116) program code with respect to at least one consistency condition, wherein the step of deploying (S112; S118) the program code is performed if a result of the checking (S110; S110') shows that the at least one consistency condition is satisfied. [6] Method (100) according to the immediately preceding claim, wherein the method comprises at least one consistency condition: - The executability of machine code; - A compiler cross-check; - A syntax analysis; - A technical inspection; - A safety; - Compliance with prescribed regulations and guidelines; and / or - a validity. [7] Method (100) according to any one of the preceding claims, further comprising at least one of the steps: - Receiving (S107) user input via a user interface, UL, to determine (S108) the program code based on the received (S107) user input; and / or - Retraining (S105) the LLM using the received (S104) measurement metadata and / or using the received user input. [8] Method (100) according to claim 4 or 7 in combination with any other preceding claim, wherein the user interface, Ul, comprises a graphical user interface, GUI, and / or a microphone. [9] Method (100) according to one of the preceding claims, wherein providing (S112; S118) the specified (S108) or modified (S116) program code comprises outputting a control signal or regulating signal, optionally wherein the control signal or regulating signal is domain-specific, in particular device type-specific, parameter and / or software-specific and / or recording protocol-specific. [10] Method (100) according to the immediately preceding claim, wherein the control signal or regulating signal is intended to: - Activating a power saving mode; - Modifying, in particular shortening, the idle time until the energy-saving mode is activated; - Modifying or replacing an acquisition protocol of at least one medical imaging device; and / or - Modifying the timing of imaging procedures, especially for a predetermined anatomical area of ​​a patient group. [11] Method (100) according to any of the preceding claims, wherein the at least one digital database comprises at least one vector database and / or an embedded database system. [12] Method (100) according to one of the preceding claims, wherein the analysis (S106) comprises a semantic mapping and / or structured summarization of the measurement metadata. [13] Method (100) according to any one of the preceding claims, wherein the method comprises at least one technical parameter: - the energy consumption of a medical imaging device per unit of time; - a number of images taken by a medical imaging device per unit of time; - a number of image captures per unit of time depending on a capture protocol; and / or - a number of image acquisitions per unit of time depending on a recorded anatomical area of ​​a patient group. [14] Method (100) according to any of the preceding claims, wherein the method is executed on a central computing unit, on an edge device and / or in a cloud. [15] Computing unit (200) for controlling or regulating one medical imaging device in a fleet of medical imaging devices of a predetermined modality, the computing unit comprising: - A database interface (202) configured to access at least one digital database in order to receive measurement metadata relating to at least one image acquisition or to the medical imaging device, wherein the image acquisition was carried out using the medical imaging device; - An analysis module (206) designed to analyze, using a Large Language Model (LLM), the received measurement metadata with respect to at least one technical parameter of the image acquisition and / or the medical imaging device; - A program code determination module (208) configured to determine a program code based on the analysis of at least one technical parameter, wherein the program code is intended for controlling or regulating the medical imaging device or for analyzing measurement metadata of the medical imaging device; and - A program code interface (212) or a program code deployment module (212) that is configured to deploy the specified program code. [16] System for controlling or regulating a medical imaging device or for analyzing measurement metadata of a medical imaging device in a fleet of medical imaging devices of a predetermined modality, the system comprising: - A computing unit (200) according to the immediately preceding claim; and - At least one digital database containing measurement metadata, in particular regarding at least one image taken using the medical imaging device.

Images