Automated configuration of a magnetic resonance imaging system

Abstract

Disclosed herein is a medical system (100, 300, 500) comprising a memory (116) storing machine executable instructions (120) and a graph database (122). The graph database is configured to output magnetic resonance imaging pulse sequence configuration data (126) in response to receiving object data. The medical system further comprises a computing system (110). Execution of the machine executable instructions causes the computing system to: receive (200) object data; and receive (202) magnetic resonance imaging pulse sequence configuration data in response to inputting the object data into the graph database.

Description

Technical Field

[0001] The present invention relates to magnetic resonance imaging, and in particular to the configuration of a magnetic resonance imaging system. Background Art

[0002] As part of the process of producing images inside a patient's body, a magnetic resonance imaging (MRI) scanner uses a large static magnetic field to align the nuclear spins of atoms. This large static magnetic field is called the B0 field. Configuring an MRI system can be complex and may require years of training.

[0003] Publication article: Deneck et al., "Automated Protocoling for MRI Exams - Challenge and Solutions," Journal of Digital Imaging (2022) 35: 1293-1302, https: / / doi.org / 10.1007 / s10278-022-00610-1, discloses that automated protocol development for MRI examinations is a modifiable goal for workflow automation using artificial intelligence. However, challenges remain to be overcome for a successful and robust approach. A literature review was conducted that analyzed the limitations of currently published methods for automated protocol development. These limitations were quantitatively assessed based on data from a private radiology practice. To this end, the information content provided by clinical indications was further assessed by calculating overlap coefficients for the set of ICD-10 coded permitted diagnoses for different MRI protocols. In addition, the heterogeneity of protocol trees from three different MRI scanners was assessed based on the overlap coefficients, MRI protocol, and sequence level. In addition, sequence name standardization was applied to demonstrate its effect on the heterogeneity assessment (i.e., overlap coefficient) of different protocol trees. The overlap coefficients of the sets of ICD-10 coded allowed diagnoses for different protocols ranged from 0.14 to 0.56 for brain / head MRI examinations to 0.04 to 0.57 for spine examinations. The overlap coefficients between the sequence sets used at two different scanners increased when sequence name standardization was applied (from 0.81 / 0.86 to 0.93). Automated protocol development for MRI examinations has the potential to reduce the workload of radiologists.

[0004] U.S. patent application publication US2022 / 0068472 A1 discloses a system for standardized MRI examinations with patient-centric scan workflow adaptation, comprising: a protocol management system for centrally setting up and / or maintaining scan procedures and / or scan protocols; a scan queue designed to provide a representation of past and planned scan workflow steps; and a scan workflow guidance system configured to use preconfigured scan protocols and / or scan procedures with patient-specific adaptation. Summary of the Invention

[0005] The invention provides a medical system, a computer program and a method as claimed in the independent claims.

[0006] In one aspect, the present invention provides a medical system comprising a memory storing machine-executable instructions and a graph database. The graph database is configured to output magnetic resonance imaging pulse sequence configuration data in response to receiving subject data. The medical system also includes a computing system. Execution of the machine-executable instructions causes the computing system to receive the subject data. Execution of the machine-executable instructions also causes the computing system to receive the magnetic resonance imaging pulse sequence configuration data in response to inputting the subject data into the graph database. This embodiment can be beneficial because it can provide a means for automatically configuring a magnetic resonance imaging system.

[0007] As used herein, a graph database encompasses databases that use graph structures and encode “data” and “relationships” using “nodes” and “edges.” Nodes can encode data, and edges can encode relationships between those nodes.

[0008] The object data may be magnetic resonance imaging object data. The object data may be data used to describe the subject, describe the magnetic resonance imaging system, provide information about a medical problem or suspected health problem with the subject, or provide measurement data or control data from the magnetic resonance imaging system. For example, the object data may be data measured during a previous magnetic resonance imaging system procedure or a previous setup of the magnetic resonance imaging system. In this case, the graph database may be used as part of a closed-loop control loop for controlling the magnetic resonance imaging system.

[0009] In another embodiment, the graph database includes an object data hypergraph and a pulse sequence configuration hypergraph. The object data hypergraph includes object nodes that encode object data. For example, each value of object data or type or item of object data can be represented by a node in the object data hypergraph. The object data hypergraph also includes object hyperedges, which connect object nodes and encode joint occurrences of object data. For example, if certain items of object data exist or occur in conjunction, they can be connected together to form a "relationship". For example, the graph database can have a table that lists various object hyperedges and contains a list of various object nodes connected by each hyperedge.

[0010] One thing to note is that, at a formal level, object hyperedges can be decomposed into sub-object hyperedges. For example, object data can contain various types of data, such as data describing the physical condition, dimensions, or medical history of the object. In other cases, object data can also include data measured using sensors or from previous magnetic resonance imaging scans and grouped together as another set of data. In other cases, data describing the type of magnetic resonance imaging system used and its capabilities and / or available accessories or equipment can include another set of data. Each subgroup of data can have its own hyperedge. In this case, several hyperedges can be specified for each instance of object data. These results are formally equivalent regardless of whether there is a single object data hypergraph or whether it is decomposed into multiple object data hypergraphs.

[0011] The pulse sequence configuration hypergraph includes configuration nodes that encode individual configuration data for individual magnetic resonance imaging pulse sequences. The pulse sequence configuration hypergraph also includes configuration hyperedges that connect configuration nodes to pulse sequence combinations that form magnetic resonance imaging pulse sequence configuration data. Configuration hyperedges connect individual magnetic resonance imaging pulse sequences together. In some cases, configuration hyperedges can then be considered to form a magnetic resonance imaging protocol or a set of magnetic resonance imaging pulse sequences to be performed on a particular subject.

[0012] The database also includes a master graph data frame that lists each object hyperedge and its connection to a configuration hyperedge. The master graph data frame list can be, for example, a table containing this information. Where a specific object hyperedge or combination of hyperedges can be listed (if the hyperedge is formally decomposed into smaller hyperedges), these links to various configuration hyperedges are provided.

[0013] The master image data frame list comprises a bridge between one (or more) object data hypergraphs and a pulse sequence configuration hypergraph. The object data can be used to select a specific object data hyperedge, which can then be mapped to one or more configuration hyperedges. Each of these hyperedges provides a different magnetic resonance imaging protocol, which includes one or more pulse sequences to be executed by the magnetic resonance imaging system. Thus, the system can provide a means for acquiring object data and then automatically providing the configuration data required to execute a complete magnetic resonance imaging protocol.

[0014] In another embodiment, the connection to the configuration hyperedge includes a weighting factor. The graph database is configured to select magnetic resonance imaging pulse sequence configuration data using the object data, including: using the object data to identify the closest matching object hyperedge in the object data hypergraph. In this case, various methods can be used to find the closest matching object hyperedge. In one case, the object data can be used to find an object hyperedge that contains all elements of the object data. This can then be considered a matching object hyperedge. However, it may not be possible to find the same match for a particular object hyperedge. In this case, a search can be used to find the closest matching object hyperedge. For example, various elements of the object data can be selectively excluded. After excluding an element, segment, or data from the object data, a search for matching object hyperedges can be performed again. For example, the closest matching object hyperedge can be the object hyperedge that matches when excluding the least number of object data elements. In some cases, when searching for the closest matching object hyperedge, there may be a list, ranking, or specific order for excluding various elements of the object data.

[0015] The graph database is further configured to select magnetic resonance imaging pulse sequence configuration data using the object data, including the steps of returning configuration hyperedges and weighting data associated with the most closely matching object hyperedge in the main graph data frame. Selecting the magnetic resonance imaging pulse sequence configuration data using the object data further includes selecting the magnetic resonance imaging pulse sequence configuration data from the returned configuration hyperedges using, at least in part, the weighting data.

[0016] For example, within the master graph data frame list for a particular object hyperedge, there may be links to multiple configuration hyperedges. The weighting data may provide a rating or ranking of each of these configuration hyperedges in the master graph data frame list. As the simplest means of selecting the closest matching object hyperedge, one may simply select the object hyperedge with the highest weighting factor.

[0017] In other examples, other considerations may also be taken into account when selecting configuration hyperedges. For example, the weighting values ​​for configuration hyperedges must not only be at the "this-protocol-for-those-symptoms" level (derived from the main graph data frame, as described above), but the weights may also be derived from additional values ​​(node ​​"size" and merits) such as usage counters and thumbs-up counters (user ratings) for each individual sequence (independent of the symptoms), which may also be used when selecting or constructing MRI protocols.

[0018] In another embodiment, each object data hyperedge is identified by a unique hash number. For example, for each specific classification that may be in the object data, a hash value can be assigned. This means that a specific combination of values ​​for the object data can have a unique hash number. This enables each object data hyperedge to be identified by a unique hash number or hash value. Execution of the machine-executable instructions also includes converting the object data into an object hash number and then using the object hash number to search the main graph data frame for the closest matching object hyperedge. For example, the main graph data frame can be a table that lists the various hash values ​​and then lists the matching configuration hyperedges in other columns.

[0019] If a particular object hash number does not match an existing object hyperedge in the main graph data frame, various elements can be selectively excluded from the object data to see if a match can be obtained by reducing the amount of data to match. In some cases, there may be a list so that specific elements of the object data are selected in a specific order.

[0020] In another embodiment, the encoding of the magnetic resonance imaging pulse sequence configuration data for individual pulse sequences is numerical. Typically, there are different values ​​within a pulse sequence, and these different values ​​are numerical. These can be, for example, various time elements within the pulse sequence, as well as various values ​​such as the gradient strength or the intensity of the generated RF pulses. There are also other values ​​that can be considered non-numerical. To encode them digitally, it is simple to assign digital values ​​to these non-numerical values ​​and provide a mapping, which is then digital. This can have the advantage that various digital analysis techniques can be applied to the nodes of the pulse sequence configuration hypergraph.

[0021] In another embodiment, the graph database is configured to add new configuration nodes to the configuration hypergraph by binning the pulse sequence parameters. This can be beneficial because it can provide a means for grouping functionally equivalent pulse sequences together or by reducing the number of pulse sequences.

[0022] In another embodiment, the method further comprises calculating distances within the magnetic resonance imaging pulse sequence configuration data for configuration nodes connected by configuration hyperedges associated with the closest object hyperedge in the main image data frame. The method further comprises selecting magnetic resonance imaging pulse sequence configuration data or at least partially combining magnetic resonance imaging pulse sequence configuration data from the returned configuration hyperedges by using a combination of the weighted data and the calculated distances within the magnetic resonance imaging pulse sequence configuration data.

[0023] This embodiment can be beneficial because it can provide a means for providing MRI protocols that can provide more diverse results. In some cases, the distance within the MRI pulse sequence configuration data can be considered a metric. Since the configuration nodes are digitally encoded, the distance can be calculated using this purely digital configuration data. As previously described, this can be, for example, a simple Euclidean distance, or it can be a more complex metric capable of measuring digital distances.

[0024] In another embodiment, the configuration node is encoded in a reduced-dimensionality state. The memory further comprises: a mapping between the reduced-dimensionality state and magnetic resonance imaging pulse sequence configuration parameters. Providing magnetic resonance imaging pulse sequence configuration data comprises: converting between the reduced-dimensionality state and the magnetic resonance imaging pulse sequence configuration parameters.

[0025] This can be beneficial because not all values ​​within a pulse sequence are independent of each other. For example, principal component analysis can be used to achieve this dimensionality reduction. This can reduce the number of variables required to represent a particular pulse sequence. Calculating distances within the MRI pulse sequence configuration data can be more meaningful in this dimensionality reduction. For example, this can help select MRI protocols with a greater diversity of MRI settings. This can provide a wider variety of MRI images with a minimum of measurement time.

[0026] In another embodiment, execution of the machine-executable instructions further causes the computing system to receive magnetic resonance imaging survey scan data describing the object. Execution of the machine-executable instructions further causes the computing system to derive at least a portion of the object data from the survey scan data.

[0027] As used herein, an MRI exploratory scan includes an MRI scan that is performed before other MRI scans in an MRI protocol. The MRI exploratory scan is typically performed at a lower resolution so that it can be performed quickly and provides a preview of a larger area of ​​the object. This can, for example, be used to perform alignment of the imaging volume and provide a preview to a clinician or technician to determine what further MRI scans are to be performed and what the geometrical settings of the imaging scans may be (field of view, angulation, shimming). Typically, if an automated system for configuring and performing an MRI system is to be established, it will be beneficial to first perform a standardized MRI exploratory scan using a large imaging field of view. In this embodiment, the preliminary scan or exploratory scan is then used to provide at least a portion of object data.

[0028] In another embodiment, deriving at least a portion of the object data from the scout scan data includes determining image segmentation of the scout scan using an automatic segmentation module. For example, various image segmentation modules are available, including shape deformation or even segmentation algorithms for specific regions of the body, such as locating the position of a diaphragm or using edge detection. Derivation of at least a portion of the object data from the scout scan data also includes calculating at least a portion of the object data using image segmentation. This can be useful, for example, when aligning or configuring the size or orientation of a field of view or imaging volume in an MRI system.

[0029] In another embodiment, deriving at least a portion of the object data from the scout scan further comprises calculating at least a portion of the configuration data using the image segmentation and the pre-scan or scout data. Deriving at least a portion of the object data from the scout scan further comprises providing a recommendation to an operator on how to adjust imaging configuration settings to achieve better desired image quality. For example, this may provide a list of settings or suggested settings or various protocols that may be selected by the operator.

[0030] In another embodiment, the memory further comprises an image classification machine learning module. Exporting at least a portion of the object data comprises receiving an image classification in response to inputting the probe image data into the image classification machine learning module, and then providing the image classification as at least a portion of the object data.

[0031] For example, an image classification machine learning module can be implemented as a convolutional neural network, random forest, or support vector machine. These are essentially various technologies that can be used to receive images or 3D data and output a classification. For example, if a convolutional neural network is used, it can be trained using various labeled exploration scans with various classifications. Various types of neural network architectures can be used to implement the image classification learning module. In some cases, a U-net, ResNet, or other types of convolutional neural networks commonly used to perform classification on images can be used.

[0032] In another embodiment, deriving at least a portion of the object and / or configuration data further includes determining whether the signal quality is sufficient for the planned acquisition and whether the sequence settings may be adjusted. This can also be performed, for example, using an image classification learning module. The scout scan can be input into the image classification learning module, which can output one or more signal values, such as signal-to-noise ratio or image contrast, which can be used to provide an estimate of the signal quality. This can be used to adjust pulse sequence parameters before executing the pulse sequence.

[0033] In another embodiment, sequence configuration parameters or instances for which the proposed algorithm has high uncertainty (e.g., sensitive fat suppression settings or very unusual geometries) can be presented to the operator in a prominent manner. In a non-expert user interface mode, sequence parameters that are not recommended for change or determined with high fidelity can be hidden from the user, thereby exposing a smaller set of "modifiable" parameters to achieve an easier magnetic resonance imaging user interface. These modifiable parameters do not have to be the classic user interface settings found on magnetic resonance scanners today, but can also be alternative contrast control parameters defined using functional mapping, dimensionality reduction, or machine learning techniques. This can provide a simplified user experience and enable "non-expert" operators to easily adjust typical parameter combinations to alleviate certain observed image quality issues.

[0034] In another embodiment, execution of the machine-executable instructions further causes the computing system to receive a selection of a magnetic resonance imaging system. Execution of the machine-executable instructions further causes the computing system to convert the received magnetic resonance imaging pulse sequence configuration data into one or more pulse sequences configured to control the magnetic resonance imaging system to acquire k-space data of the subject. This embodiment may be beneficial because it may provide a device-agnostic means for providing magnetic resonance imaging protocols to magnetic resonance imaging systems and enable one database to host information for all scanners, without requiring separate hardware- or vendor-specific databases.

[0035] For example, if the magnetic resonance imaging pulse sequence configuration data has been digitally encoded, the conversion may involve the step of converting the digital code back into the pulse sequence settings. For example, the digital encoding may enable conversion from a generic or purely digital representation to pulse sequence commands and protocols specific to the device or magnetic resonance imaging.

[0036] In another embodiment, the medical system further comprises one or more magnetic resonance imaging systems. Execution of the machine executable instructions further causes the computing system to acquire k-space data of the object by controlling the one or more magnetic resonance imaging systems using one or more pulse sequences. In most cases, the medical system will include the computing system and a graph database in communication with the one or more magnetic resonance imaging systems. For a specific object located at a specific magnetic resonance imaging system, object data will be sent, and in response, the one or more pulse sequences will be provided to execute a specific magnetic resonance imaging protocol. This embodiment can be beneficial because it can provide a means for automating or semi-automating the acquisition of k-space data from an object at one or more locations.

[0037] In another embodiment, execution of the machine-executable instructions further causes the computing system to reconstruct one or more magnetic resonance images from the k-space data. For example, this may be performed by a magnetic resonance imaging system that acquired the k-space data. In other cases, the k-space data may be sent to a cloud-based or internet-based service for image reconstruction. The service may or may not be co-located with the graph database.

[0038] In another embodiment, when the magnetic resonance images are acquired, they are subsequently processed, for example using a segmentation module and / or a pattern recognition module, and are subsequently used to generate further object data, which can be used to select a further magnetic resonance imaging protocol or to modify an already partially executed magnetic resonance imaging protocol. This can result in a closed-loop control circuit when operating the magnetic resonance imaging system in conjunction with the use of the map database.

[0039] In another aspect, the present invention provides a method for operating a medical system. The medical system includes a computing system. The medical system also includes a memory storing machine-executable instructions and a graph database. The graph database is configured to output magnetic resonance imaging pulse sequence configuration data in response to receiving subject data. The method includes: receiving the subject data by the computing system. The method also includes: receiving the magnetic resonance imaging pulse sequence configuration data in response to inputting the subject data into the graph database. Inputting the subject data into the graph database can also be interpreted as querying the graph database using the subject data.

[0040] In another aspect, the present invention provides a computer program comprising machine-executable instructions for execution by a computing system. Execution of the machine-executable instructions causes the computing system to receive subject data. Execution of the machine-executable instructions further causes the computing system to receive magnetic resonance imaging pulse sequence configuration data in response to inputting the subject data into a graph database. The graph database is configured to output the magnetic resonance imaging pulse sequence configuration data in response to receiving the subject data.

[0041] It should be understood that one or more of the aforementioned embodiments of the present invention may be combined as long as the combined embodiments are not mutually exclusive.

[0042] Those skilled in the art will recognize that aspects of the present invention may be implemented as apparatus, methods, or computer program products. Thus, aspects of the present invention may take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects, all of which may generally be referred to herein as "circuits," "modules," or "systems." Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer-readable media having computer-executable code embodied thereon.

[0043] Any combination of one or more computer-readable media can be used. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. As used herein, "computer-readable storage medium" encompasses any tangible storage medium that can store instructions that can be executed by a processor or computing system of a computing device. The computer-readable storage medium can be referred to as a computer-readable non-transitory storage medium. The computer-readable storage medium can also be referred to as a tangible computer-readable medium. In some embodiments, the computer-readable storage medium can also store data that can be accessed by the computing system of the computing device. Examples of computer-readable storage media include, but are not limited to: a floppy disk, a magnetic hard drive, a solid-state drive, a flash memory, a USB thumb drive, a random access memory (RAM), a read-only memory (ROM), an optical disk, a magneto-optical disk, and a register file of a computing system. Examples of optical disks include compact discs (CDs) and digital versatile discs (DVDs), such as CD-ROMs, CD-RWs, CD-Rs, DVD-ROMs, DVD-RWs, or DVD-R discs. The term computer-readable storage medium also refers to various types of recording media that can be accessed by a computing device via a network or communication link. For example, data can be retrieved via a modem, via the Internet, or via a local area network. Computer executable code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0044] A computer-readable signal medium may include a propagated data signal having computer-executable code embodied therein, for example, in baseband or as part of a carrier waveform. The propagated signal may take any of a variety of forms, including, but not limited to, electromagnetic, optical, or any suitable combination thereof. A computer-readable signal medium may be any computer-readable medium that is not a computer-readable storage medium and that is capable of communicating, propagating, or transporting a program for use by or in connection with an instruction execution system, apparatus, or device.

[0045] "Computer memory" or "memory" is an example of a computer-readable storage medium. Computer memory is any memory directly accessible to a computing system. "Computer storage" or "storage" is another example of a computer-readable storage medium. Computer storage is any non-volatile computer-readable storage medium. In some embodiments, computer storage may also be computer memory, and vice versa.

[0046] As used herein, a "computing system" encompasses an electronic component capable of executing a program or machine-executable instructions or computer-executable code. References to computing systems including examples of a "computing system" should be interpreted as potentially including more than one computing system or processing core. A computing system may, for example, be a multi-core processor. A computing system may also refer to a collection of computing systems within a single computer system or distributed across multiple computer systems. The term computing system should also be interpreted as potentially referring to a collection or network of computing devices, each of which includes a processor or computing system. Machine-executable code or instructions may be executed by multiple computing systems or processors, which may be within the same computing device or even distributed across multiple computing devices.

[0047] Machine executable instructions or computer executable code can include instructions or programs that enable a processor or other computing system to perform an aspect of the present invention. The computer executable code for performing the operations of various aspects of the present invention can be written in any combination of one or more programming languages ​​and compiled into machine executable instructions. These programming languages ​​include object-oriented programming languages ​​(such as Java, Smalltalk, C++, etc.) and conventional procedural programming languages ​​(such as "C" programming language or similar programming languages). In some cases, the computer executable code can be in the form of a high-level language or in a precompiled form and is used in conjunction with an interpreter that generates machine executable instructions on the fly. In other cases, the machine executable instructions or computer executable code can be in the form of programming for a programmable logic gate array.

[0048] The computer executable code may be executed entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or a connection may be formed to an external computer (e.g., over the Internet using an Internet service provider).

[0049] Aspects of the present invention are described with reference to the flow charts and / or block diagrams of the methods, devices (systems) and computer program products according to the embodiments of the present disclosure. It should be understood that each frame of the flow chart, diagram and / or block diagram or a part of these frames can be implemented by computer program instructions in the form of computer executable code when applicable. It should also be understood that, when not mutually exclusive, the combination of frames in different flow charts, diagrams and / or block diagrams can be combined. These computer program instructions can be provided to the computing system of a general-purpose computer, a special-purpose computer or other programmable data processing device to produce a machine so that the instruction, when executed via the computing system of a computer or other programmable data processing device, generates a means for realizing the function / action specified in the frame of the flow chart and / or block diagram.

[0050] These machine-executable instructions or computer program instructions may also be stored in a computer-readable medium, which can instruct a computer, other programmable data processing apparatus or other device to work in a specific manner, so that the instructions stored in the computer-readable medium produce an article of manufacture, which includes instructions for implementing the functions / actions specified in the blocks of the flowchart and / or block diagram.

[0051] In addition, machine-executable instructions or computer program instructions can also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operable steps to be performed on the computer, other programmable apparatus or other device to generate a computer-implemented process, so that the instructions executed on the computer or other programmable apparatus provide a process for implementing the functions / actions specified in the blocks of the flowchart and / or block diagram.

[0052] As used herein, a "user interface" is an interface that allows a user or operator to interact with a computer or computer system. A 'user interface' may also be referred to as a 'human interface device'. A user interface can provide information or data to an operator and / or receive information or data from an operator. A user interface can enable input from an operator to be received by the computer and can provide output from the computer to the user. In other words, a user interface can allow an operator to control or manipulate the computer, and the interface can allow the computer to indicate the effects of the operator's controls or manipulations. Displaying data or information on a display or graphical user interface is an example of providing information to an operator. Receiving data via a keyboard, mouse, trackball, touchpad, pointing stick, graphic tablet, joystick, game controller, webcam, head-mounted device, pedals, wired gloves, remote controls, and accelerometers are all examples of user interface components that can receive information or data from an operator.

[0053] As used herein, a "hardware interface" encompasses an interface that enables a computing system of a computer system to interact with and / or control an external computing device and / or apparatus. A hardware interface can allow a computing system to send control signals or instructions to an external computing device and / or apparatus. A hardware interface can also enable a computing system to exchange data with an external computing device and / or apparatus. Examples of hardware interfaces include, but are not limited to, a universal serial bus, an IEEE 1394 port, a parallel port, an IEEE 1284 port, a serial port, an RS-232 port, an IEEE-488 port, a Bluetooth connection, a wireless LAN connection, a TCP / IP connection, an Ethernet connection, a control voltage interface, a MIDI interface, an analog input interface, and a digital input interface.

[0054] As used herein, a "display" or "display device" encompasses an output device or user interface suitable for displaying images or data. A display may output visual, audio, and / or tactile data. Examples of displays include, but are not limited to: computer monitors, television screens, touch screens, tactile electronic displays, Braille screens,

[0055] Cathode ray tubes (CRTs), memory tubes, bi-stable displays, electronic paper, vectorscope displays, flat panel displays, vacuum fluorescent displays (VFs), light-emitting diode (LED) displays, electroluminescent displays (ELDs), plasma display panels (PDPs), liquid crystal displays (LCDs), organic light-emitting diode displays (OLEDs), projectors, and head-mounted displays.

[0056] K-space data is defined herein as the recorded measurement data of radio frequency signals emitted by atomic spins using the antenna of a magnetic resonance apparatus during a magnetic resonance imaging scan.

[0057] A magnetic resonance imaging (MRI) image or MR image is defined herein as a reconstructed two- or three-dimensional visualization of anatomical data contained within magnetic resonance imaging data. The visualization may be performed using a computer. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] The following preferred embodiments of the present invention will be described, by way of example only, with reference to the accompanying drawings, in which:

[0059] Figure 1 An example of a medical system is shown;

[0060] Figure 2 Shows instructions for use Figure 1 A flowchart of a method for a medical system;

[0061] Figure 3 Another example of a medical system is shown;

[0062] Figure 4 Shows instructions for use Figure 3 A flowchart of a method for a medical system;

[0063] Figure 5 Another example of a medical system is shown;

[0064] Figure 6 is an exemplary graph database displayed in a tabular form;

[0065] Figure 7 Several examples of magnetic resonance imaging scan setup tables that maintain node information for a configuration hypergraph are shown; and

[0066] Figure 8 It is a graphical representation of a graph database.

[0067] Figure 9 Additional views of the graph database are shown. DETAILED DESCRIPTION

[0068] Elements with the same number in these figures are equivalent elements or perform the same function. If the function is equivalent, an element that has been discussed previously will not need to be discussed in the following figures.

[0069] Figure 1An example of a medical system 100 is shown. The medical system 100 is shown to include a computer 102 and an optional magnetic resonance imaging system 104, an optional magnetic resonance imaging system 106, and an optional magnetic resonance imaging system 108. The optional magnetic resonance imaging systems 104, 106, and 108 are intended to illustrate that the medical system 100 can form the core of a system that integrates multiple magnetic resonance imaging systems 104, 106, and 108. The computer 102 is shown to include a computing system 110. The computer 102 is intended to represent one or more computers that can be located at one or more locations. Similarly, the computing system 110 can also represent multiple computing systems, processors, or cores located at one or more locations.

[0070] The computing system 110 is shown connected to an optional user interface 112. The user interface 112 enables an operator or controller to control and interact with the medical system 100. The computing system 110 is further shown connected to a network interface or hardware interface 114. The network interface can be used to communicate with other devices or components of the medical system 100. For example, the network interface 114 is shown forming a network connection with the magnetic resonance imaging systems 104, 106, and 108.

[0071] Computing system 110 is further shown in communication with memory 116. Memory 116 is intended to represent various types of memory accessible by computing system 110. In one example, memory 116 may be a non-transitory storage medium.

[0072] Memory 116 is shown as containing machine-executable instructions 120. Machine-executable instructions 120 may include instructions that enable computing system 110 to perform basic image and digital tasks. In some examples, machine-executable instructions 120 may enable computing system 110 to control other components of medical system 100, such as magnetic resonance imaging systems 104, 106, and 108. Memory 116 is further shown as containing a graph database 122. Memory 116 is further shown as containing object data 124, which may be used as input or to query graph database 122. Memory 116 is further shown as containing magnetic resonance imaging pulse sequence configuration data 126.

[0073] The computer 102 may be, for example, a remote server or cloud-based system that hosts or provides access to the graph database 122 .

[0074] The magnetic resonance imaging pulse sequence configuration data 126 is received in response to querying the graph database 122 using the object data 124. In some examples, the magnetic resonance imaging pulse sequence configuration data 126 is in the form of a plurality of pulse sequences that may be used to control one or more of the magnetic resonance imaging systems 104, 106, and 108. In other examples, the magnetic resonance imaging pulse sequence configuration data 126 may have to undergo a conversion process to convert it into one or more pulse sequences that may then be used to control the magnetic resonance imaging systems 104, 106, and / or 108.

[0075] Figure 2 Shows the instructions for operation Figure 1 FIG2 is a flow chart of a method of the medical system 100 of FIG2. In step 200, subject data is received. In step 202, magnetic resonance imaging pulse sequence configuration data 126 is received in response to inputting or querying the map database 122 using the subject data 124.

[0076] Figure 3 Another example of a medical system 300 is shown. This is shown to include Figure 1 1 and 106. Components of the magnetic resonance imaging system 104 are shown in detail.

[0077] Magnetic resonance imaging system 104 includes magnet 304. Magnet 304 is a superconducting cylindrical magnet with a hole 306 passing through it. Separated cylindrical magnets and so-called open magnets can also be used. Except that the cryostat has been divided into two parts to allow access to the iso-plane of the magnet, the separated cylindrical magnet is similar to a standard cylindrical magnet, and such a magnet can be used in combination with charged particle beam therapy, for example. The open magnet has two magnet parts, one magnet part above the other magnet part, with a space large enough to receive the object between them. The arrangement of these two partial areas is similar to that of a Helmholtz coil. Open magnets are popular because there are fewer restrictions on the object. Inside the cryostat of the cylindrical magnet, there is a collection of superconducting coils.

[0078] Within the bore 306 of the cylindrical magnet 304 lies an imaging zone 308 in which the magnetic field is sufficiently strong and uniform to perform magnetic resonance imaging. A field of view 309 is shown within the imaging zone 308. K-space data is acquired for the field of view 309. A region of interest may be the same as the field of view 309, or it may be a subvolume of the field of view 309. An object 318 is shown supported by an object support 320 such that at least a portion of the object 318 is within the imaging zone 308 and the field of view 309.

[0079] Also within the bore 306 of the magnet is a set of magnetic field gradient coils 310 for acquiring measured k-space data to spatially encode magnetic spins within the imaging region 308 of the magnet 304. The magnetic field gradient coils 310 are connected to a magnetic field gradient coil power supply 312. The magnetic field gradient coils 310 are intended to be representative. Typically, the magnetic field gradient coils 310 include three separate sets of coils for spatial encoding in three orthogonal spatial directions. The magnetic field gradient power supply supplies current to the magnetic field gradient coils. The current supplied to the magnetic field gradient coils 310 is controlled as a function of time and can be ramped or pulsed.

[0080] Adjacent to the imaging zone 308 is a radio frequency coil 314, which is used to manipulate the orientation of magnetic spins within the imaging zone 308 and to receive radio transmissions from spins also within the imaging zone 308. The radio frequency antenna may include multiple coil elements. An radio frequency antenna may also be referred to as a channel or antenna. The radio frequency coil 314 is connected to a radio frequency transceiver 316. The radio frequency coil 314 and the radio frequency transceiver 316 may be replaced by separate transmit and receive coils, or separate transmitters and receivers. It should be understood that the radio frequency coil 314 and the radio frequency transceiver 316 are representative. The radio frequency coil 314 is also intended to represent a dedicated transmit antenna and a dedicated receive antenna. Similarly, the transceiver 316 may also represent a separate transmitter and receiver. The radio frequency coil 314 may also have multiple receive elements / transmit elements, and the radio frequency transceiver 316 may have multiple receive channels / transmit channels.

[0081] The magnetic resonance imaging system 104 is shown as including a computer 102' that also includes a computing system 110', a hardware interface 114', an optional user interface 112', and a memory 116'. In other examples, features and components of the computers 102' and 102' may be combined. Figure 3 While shown with a central computer 102 serving several magnetic resonance imaging systems 104 , 106 , the functionality of the computer system 102 may be integrated into a computer 102 ′ that locally controls the magnetic resonance imaging system 104 .

[0082] The memory 116 ′ of the computer 102 ′ is shown as including machine-executable instructions 120 ′. The machine-executable instructions 120 ′ comprise instructions that may enable the computing system 110 ′ to perform tasks such as image reconstruction, data manipulation, and control of other components of the magnetic resonance imaging system 104 .

[0083] Memory 116' is shown as containing scoping scan pulse sequence commands 330. In an automated system, scoping scan pulse sequence commands 330 may be, for example, pulse sequence commands that are automatically executed when subject 318 is inserted into magnetic resonance imaging system 304 and reaches imaging zone 308. Memory 116' is further shown as containing scoping scan k-space data 332. This is acquired k-space data acquired by controlling magnetic resonance imaging system 104 using scoping scan pulse sequence commands 330. Memory 116' is further shown as containing scoping scan data 334, which may be a scoping scan image reconstructed from scoping scan k-space data 332. Memory 116' is further shown as containing local subject data 336. This may include things such as a selection of the region of subject 318 to be imaged, details about subject 318 such as weight, age, or other metadata describing subject 318.

[0084] The memory 116 in the computer 102 is shown as also containing the scoping scan data 334 and local object data 336. The local object data 336 may also contain information describing the particular magnetic resonance imaging system 104 and its capabilities, such as what hardware is or is not available.

[0085] The memory 116 is further shown as containing an image classification machine learning module 338. The memory 116 is further shown as containing an image classification 340, which is received from the image classification machine learning module 338 in response to receiving the exploratory scan data 334 as input. For example, a standard convolutional neural network can be used to classify images. The image classification 340 can be concatenated with the local object data 336 to produce the object data 124. This can then be input into the graph database 122 to produce the magnetic resonance imaging pulse sequence configuration data 126. The magnetic resonance imaging pulse sequence configuration data 126 can then be converted into one or more pulse sequences 342 specifically customized or modified for the magnetic resonance imaging system 104.

[0086] It can also be seen that one or more pulse sequences 342 have been transferred to the memory 116. The memory 116′ is further shown as containing k-space data 344 that has been acquired by controlling the magnetic resonance imaging system 104 using the one or more pulse sequences 342. The memory 116′ is further shown as containing one or more magnetic resonance images 346 that have been reconstructed from the k-space data 344.

[0087] In other examples, the one or more magnetic resonance images 346 may be further processed, for example by an image classification machine learning module 338 or the like, and used to further refine or control the magnetic resonance imaging system 104 for further examination of the subject 318. In this way, a closed control loop may be formed.

[0088] Figure 4 Shows the instructions for operation Figure 3 Flowchart of a method of a medical system 300 of the present invention. In step 400, magnetic resonance imaging detection scan data 334 is received. In step 402, at least a portion of the object data 324 is derived from the detection scan data 334. In step 404, a selection of the magnetic resonance imaging system 104 is received. Steps 200 and 202 are performed, as shown in FIG. Figure 2 As shown. In step 406, the magnetic resonance imaging pulse sequence configuration data 326 is converted into one or more pulse sequences 342, which are configured to control the magnetic resonance imaging system 104 to acquire k-space data 344. In step 408, the k-space data 344 is acquired by controlling the magnetic resonance imaging system 104 using the one or more pulse sequences 342. Then, in step 410, one or more magnetic resonance images 346 are reconstructed from the k-space data 344.

[0089] The example can provide an MRI protocol development automation tool and underlying system. The backend includes a graph database (122) that implements a scalable and well-maintained way to automate MRI protocol development based on patient indications and other variables or data. The proposed system can be well-interoperable across different scanners, sites and vendors, which potentially solves many open problems in MRI protocol development automation. The envisioned database will connect the object data (124) (magnetic resonance imaging pulse sequence configuration data 126) of the MRI sequence with the appropriate MRI protocol and possibly other relevant patient information. The database can be continuously grown during use and used for MRI protocol development inference to suggest the best scan combination for new patients. As a graph database, it emphasizes the connection and co-occurrence of different elements, which can provide a means for determining MRI examinations for different clinical problems. This is a critical component for future autonomous MRI scanners (which operate without local trained personnel) and is expected to gradually standardize the MRI sequences used in different clinics and upcoming practices. The present invention not only provides new capabilities to MRI operators, but also creates many possibilities for maintenance providers by automatically collecting and structuring detailed information about MRI scanner usage in different fields (which can be filtered by symptoms and body parts). Applicable dimensionality reduction techniques can provide new views on MRI sequence parameterization and enable new methods for sequence and protocol development.

[0090] Currently, radiologists prescribe a specific set of MRI scans (examinations / protocols) with desired contrast based on the patient's description and the consulting physician's guess as to the likely underlying cause. The contrast of subsequent MRI scans is based on the radiologist / technician's training and a limited set of experience from a few individuals. Their starting point is typically a local database of pre-configured scan cards (vendor presets), which are selected based on the patient's indication and may be fine-tuned by the on-site staff. The local database typically does not retain factory settings but is pre-configured by the local radiology staff. All of this leads to a large variability in the use of MRI at different locations, as each team has its own experience and unique preferences for sequences and settings, which often results in scans from different locations having contrast that is difficult to compare.

[0091] Prior art MRI scanners do not systematically collect structured information about detailed scanner usage at clinical sites. Usage statistics can only be extracted from general local data records, which are only done for maintenance purposes.

[0092] The architecture described herein enables the growth of a graph database that captures the complex relationships between patient symptoms and commonly ordered MRI scans in sufficient detail to be used to suggest appropriate MRI protocols for patients with similar indications. Utilizing machine learning solutions to address this is suboptimal in some examples because it is not understandable or transparent in its decision support, it is difficult to orchestrate and systematically correct errors or updates to the gold standard or specification (requiring complete retraining, excluding the corresponding scan), it is nearly impossible to monitor, and it is unclear when input patient indications cannot be processed sensitively because there is no or too little training data for those input symptoms, and there are other issues regarding scalability, maintainability, and accountability.

[0093] The difficulty in collecting and storing relevant data lies in the different connected layers of interest:

[0094] - connections between different symptoms / indications (from co-occurrence),

[0095] - the concatenation of different MRI sequences (from the combination in the protocol), and

[0096] - Connection between symptom combination and MRI scan / protocol (examination design for the patient).

[0097] The co-occurrence of certain symptoms needs to be recorded and searchable as is, as similar combinations or subsets of symptoms may lead to completely different suspicions about the underlying etiology, thus necessitating different scans. Therefore, connections between different symptom or subject data are of interest, as are connections between individual symptom clusters and MRI (not only individual scans, but also scan combinations; i.e., connections between MRI sequences are important for constructing sensible protocols with minimal acquisition contrast redundancy). Some examples address this by recording all these layers of connections in a graph database in an easily searchable and scalable format, thereby maintaining the freedom to apply different filtering and processing methods or AI algorithms during predictive use of the MRI protocol expert tool, allowing for continuous improvement of the automated scan recommendation system. This approach also shifts the machine learning input solely to the MRI sequence / protocol domain, which is better defined, structured, and circumscribed than the indication / symptom word cloud domain. In our case, training data generation and management may be less problematic, as training data can be retroactively extracted from existing log files to identify which sequences are commonly used together in a protocol. Synthetic training data generation based on simulated contrast similarity can also be applied.

[0098] Examples may provide one or more of the following benefits:

[0099] - Less clinical staff time spent selecting and adjusting exams, and more approval functionality that can be provided by remote operations,

[0100] -Building a database of inherent expert knowledge for the application of MRI scanners in clinics,

[0101] - Enable better diagnostic outcomes and protocol acceleration through highly optimized MRI sequences and their combinations for different body parts and disease categories based on collective radiology experience,

[0102] - and more standardized MRI examinations were assigned, with less imaging variability and better comparability.

[0103] The example can provide a software tool for mapping a patient's medical symptoms / indications to a suitable set of MRI scans for that patient, with an environment for forming time-efficient MRI protocols with a high probability of answering clinical questions. The main application is an automated MRI protocol development tool. The distinguishing feature is its graph database and its use during protocol inference, rather than a trained machine learning model that links indications and useful MRI sequences end-to-end. The underlying system of interconnected sub-databases ("graph databases") is the backbone of the MRI protocol development tool.

[0104] Figure 5Another example of a medical system 500 is shown. In 500, a functional diagram of an MRI protocol expert 502 is shown. As input, the MRI protocol expert 502 obtains object data 124. In this example, there is a new query with detailed specific symptoms. However, the symptoms are only used as examples and machine configurations, and data measured from the object can also be used in addition or alternatively. The MRI protocol expert 502 includes a graph database 122; the graph database 122 includes an object hypergraph and a pulse sequence configuration hypergraph 506, which are connected by a main graph data frame 508, which provides a mapping between object hyperedges in the object hypergraph 504 and configuration hyperedges in the pulse sequence configuration hypergraph 506. The graph database 122 is queried via the object hypergraph 504 using the object data 124. When a matching object hypergraph is found, the main graph data frame 508 is used to find multiple magnetic resonance imaging pulse sequence configuration data 126.

[0105] For example, weighting factors or other data may be included to rate the quality of different MR protocols and individual sequences. A decision module 510 is present, which may be implemented, for example, as a logical decision module or using an artificial intelligence module (such as a neural network or decision tree), which selects a particular sequence from one (or more) protocols 126, and the system then outputs one or more magnetic pulse sequences 342. These magnetic pulse sequences 342 may then be provided to the magnetic resonance imaging scanner 104 to acquire k-space data. In some examples, a radiologist may be able to rate the quality of the image, or a machine learning classifier may rate the image for quality and artifacts, and these ratings may be optionally provided via an approval feedback mechanism 512a to update the weighting factors of the relevant hyperedges in the pulse sequence configuration hypergraph 506. This is accomplished by modifying the properties of the corresponding imaging sequence configuration nodes in the master image data frame 508 and the configuration hypergraph 506 (e.g., frequency of use and diagnostic popularity from one-click feedback).

[0106] In some cases, the object data 124 may not provide a perfect match with the object hyperedge in the object hypergraph 504. Block 514 represents retrying the search for a matching object hyperedge by trying a subset of the object data. If this operation does not find a match, in some examples, the system can then switch to a manual protocol development tool that enables the operator to manually select or construct the magnetic resonance imaging protocol to be used. This can also be added to the database 518, for example, to improve the amount of information in the graph database 122.

[0107] The MRI protocol expert (502) has access to a graph database (122) that contains information about co-occurring symptoms in previous cases and the corresponding MRI protocols performed. It can be described using a hypergraph, where an edge can connect more than two vertices. Each hyperedge in the two separate subgraphs "patient symptoms" (or object data 504) and "MRI scan / setup" (pulse sequence configuration hypergraph 506) represents a previous case by connecting the individual elements (symptoms / MRI sequences) in each subgraph. The hyperedges in the two subgraphs can obtain weighted inter-graph connections in the database to link specific indications with MRI sequence combinations.

[0108] Figure 5 The MRI protocol expert tool (502) queries the graph database by searching for the symptom combination of the new patient to find previously performed MRI protocols for those symptoms. If the queried symptom is not found in the database (case 0), it can be searched with the input of a subset of the original symptoms. If this operation fails or is not desired, manual protocol planning is required. The MRI examination planned in the traditional way is then added to the database together with the corresponding symptom combination. If the database search is initially successful (case 1), it obtains all previously performed MRI protocols for those indications, including detailed sequence settings. In order to compose the most suitable MRI protocol for the new patient, AI can be used to minimize redundancy in contrast and optimize protocol length, possibly using some additional patient information as input (e.g., implants). Due to the clear and comprehensive parameterization of sequence settings in the database, previously used protocols can be mixed and specific sequences can be excluded based on compatibility with location and patient. Once approved, the protocol can be used on the scanner and added to the database.

[0109] Some examples may include one or more of the following features:

[0110] The graph database stores structured information about the nodes in the different subgraphs (individual symptoms / MRI sequences), the hyperedges within each subgraph (complete indications / MRI protocols), and the connections between hyperedges in different subgraphs (which MRI is used for what?). This can be implemented using three separate data tables (details in the next section):

[0111] 1. An indexed list of patient symptoms / indications,

[0112] 2. A table with a combination of indexes from the first table and a joined combination of indexes to a third table, and

[0113] A third table with an index, with columns corresponding to the settings of the real MRI scans.

[0114] - A hardware and software specific transformation function for mapping scanner specific settings to a generalized space of MRI settings (ideally for each scanner version). This generalized scan setting space constitutes the columns of the third table above. This transformation function can have an inverse for the mapping from generic MRI settings to scanner specific sequence specifications.

[0115] - Algorithms for automatically adding new data to the database (described in the next section).

[0116] -MRI Protocol Expert Tools, including:

[0117] - Algorithms for automatically searching the database using the patient indication and the table index, extracting the corresponding information for a given index (previously used MRI protocols).

[0118] - A (possibly AI-powered) software framework that takes a list of scan settings from previously performed MRI exams (output of the above components) and suggests a sensible MRI protocol for a new patient, with the goal of maximizing diagnostic value while minimizing protocol duration.

[0119] A) Database construction:

[0120] The envisioned graph database includes several tables. In this example, these tables are referred to as A.1-A.3.

[0121] Figure 6 Another example of a graph database 122 laid out in table form is shown. There is a symptom hash table (A.1) 504, which is equivalent to the object hypergraph node information. There is an MRI scan setup table (A.3), which is equivalent to the pulse sequence configuration hypergraph node information 506. Finally, there is a main graph data frame (A.2) 508, which provides information about the combination of the object node from (A.1) 504 and the pulse sequence configuration node in (A.3) 506. The hash code in (A.2) 508 is shown together with specific references to the patient symptom table (A.1) 504 and the MRI scan table (A.3) 506.

[0122] Describing this in more detail, Figure 6A schematic example of an implementation of a graph database in the most basic embodiment is shown. The main graph data frame (A.2) 508 connects its elements between independent tables (A.1) 504 and (A.3) 506, but also to each other. Individual symptoms are hashed in (A.1) 504, and the MRI scan settings for a particular individual scan are hashed in (A.3) 506 using an index (idx). Table (A.2) 508 connects symptom combinations with previously performed scan combinations by recording the corresponding hash code combinations in each row. Scan combinations performed for certain symptoms are weighted (shown by a tuple of hash reference x and weight wx). These weights can be multi-layered, for example frequency-based and "diagnostic quality"-based, and these references can include more attributes. Note: For illustrative purposes, (A.3) 506 is presented in plain text. A numerically compressible version of (A.3) 506 is discussed below in subsection (A.3) 506.

[0123] A.1. Symptom Hash Table - A list of hash codes and associated medical conditions / symptoms, for example:

[0124]

[0125] Elements of the hash list can be extracted from the doctor's prescription label (e.g., ICD-10 code or stated indication), or a list of all available ICD-10 codes can be used. It may be possible to scan the prescribing physician's report with AI for NLP (natural language processing) to extract more comprehensive information about the patient from the free text. New terms deemed relevant by the NLP-AI can be added to the hash list upon approval by the data manager or manually.

[0126] A.2. Main Graph Data Frame - A table that records the co-occurrence of symptoms and the associated MRI scans performed. This is the main data frame that holds the information of the graph's edges (ie, the connections between patient symptoms (A.1) 504 and MRI scan parameters (A.3) 506).

[0127] When a new patient undergoes an MRI exam and is to be added to the database, the symptoms that led to the exam are converted to their hash codes using lookup table (A.1) 504. The hash codes obtained from (A.1) 504 are summed to obtain a "total" hash code containing all current symptoms (which can undoubtedly be broken down again into several individual symptoms). This total hash code is used as an index into the main graph data frame (A.2) 508, making it easy to search and modify as the database grows and is used. Each such hash code combination represents a hyperedge in the symptom subgraph, with the elements of (A.1) 504 as nodes.

[0128] Under a certain index (symptom combination), the data frame (A.2) 508 stores weighted references to previously performed MRI exams (scan combination) for these symptoms. Essentially, table (A.2) 508 stores connections between hyperedges of different subgraphs; subgraph hyperedges are stored by combinations of indices from (A.1) 504, (A.3) 506, and possibly other tables, while inter-graph edges are generated by connections between indices from subtables that are complementary to (A.2) 504 in the rows of (A.2) 508.

[0129] At scan time, new patients (anonymized; in this embodiment, only the symptoms and the scans performed are of interest) are added to the database in the following automated manner. Symptoms (extracted from the prescribing physician's annotations) are converted into a hash code combination, and the index of (A.2) 508 is searched for this hash code. If the combination does not yet exist, the operator needs to plan the examination manually, as is current standard practice. A new row is added to the data frame (A.2) 508, which has information about the MRI scan performed for the new symptom combination. This can be achieved by a weighted reference to a third database (A.3) 506, which stores the detailed settings of each previously used MRI sequence. If the symptom hash combination already exists in (A.2) 508, the protocol development expert can suggest a protocol that can be accepted, edited, or rejected by the staff. Successfully performed MRI scans are added to the corresponding row of (A.2) 508, and an occurrence counter is incremented for this index, which typically records the popularity of different symptom combinations and MRI sequences used.

[0130] Add the new MRI exam reference to the line (A.2)508 as follows (see Figure 6 ):

[0131] For each individual scan in the new patient's MRI exam, it is checked with these settings whether it already exists in (A.3) 506. If so, then note that the (A.3)-index 506 is added to the corresponding indices of the other scans in the exam. If the scan is not yet in (A.3) 506, then it is queued to be added to (A.3) 506 under the new index used for that hash code sum. The "total exam" hash code sum (hyperedge on (A.3)-element 506) is used as a reference and recorded in (A.2) 508 (see Figure 6 In the third column of table (A.2) in the corresponding symptom combination row. If the reference already exists in the same row of (A.2) 508, i.e., such a protocol has been used for these symptoms before, then the weight w of the check reference x in this (A.2)-row 508 is xIncrement. In table (A.3) 506, the usage counter (own column) at each scan's index is incremented to record how many times it has been used in total, and optional one-touch feedback given by the radiologist on good or poor image results can be recorded in the same way.

[0132] Figure data frame (A.2) 508 can hold more information about the connection between databases (A.1) 504 and (A.3) 506. For example, references to (A.3) 506 can have frequency and quality weights, indicating how often a certain combination of scans was performed for a certain combination of symptoms (frequency) and how likely the scan was to produce a diagnosis (diagnostic value / quality), respectively. Quality ratings can be obtained by implementing a simple one-click feedback option into the viewer used by the radiologist. For example, there can be a "thumbs up" icon in the corner of the displayed image. Optionally, the radiologist can give one-click feedback if the scan achieved a diagnosis. This positive rating can be collected in its own column in table (A.3) 506 for general, scan-by-scan diagnostic value statistics, and also collected in references to table (A.2) 508 for specific indications. Over time, this quality rating may have more influence on the recommended scans than the frequency weighting (the prioritization may be continuously adjusted in an interchangeable AI or classical algorithm by an MRI protocol expert, as described in more detail in Subsection B below). For the implementation of such weights, the reference in the third column of Table (A.2) 508 to (A.3) 506 may be a more general data structure with a combined index and its corresponding weight / attribute (denoted by Figure 6 tuple representation in ).

[0133] A.3. MRI Scan Settings Table 506—A table containing the settings for all MRI scans performed.

[0134] Some previous notes: The design of this data structure can allow for correct coarse-grained processing of information about different MRI scans, i.e., identifying when two scans are similar enough to be recorded as essentially the same scan. To this end, we can define two different groups of scan settings: what we call here hard parameters and soft parameters. Hard MRI settings are parameters with a categorical or discrete nature, where only a few different values ​​are possible and define sequence characteristics (e.g., scan technique, fat suppression, etc.). Soft parameters are quantitative settings with a fairly continuous domain (e.g., echo time, gradient bandwidth, etc.) and that gradually adjust the contrast or acquisition settings. Each available scan setting for MRI can be manually classified as a hard parameter or a soft parameter.

[0135] In order to generalize the data representation across different MRI hardware and software versions, a generalized MRI scan settings space can be defined that treats each possible setting parameter as an individual numeric dimension. Each column of Table (A.3) 506 is a dimension of this "generalized scan settings space" (G3S). For each MRI scanner and software version, a function needs to be defined to map the actual scan settings that can be adjusted in the scanner UI to a G3S representation (numeric values ​​are given for all settings), and this function can be reversible for each system (so that the scan can be converted from G3S to a specific scanner later). Here we call this function the "Hardware Transform Function" (HTF). It implements a shared database for all scanners and versions. In principle, such a function can also be recognizable for scanners from other vendors.

[0136] The indexing of table (A.3) 506 can allow for unambiguous combinations, similar to the hash code indexing of table (A.1) 504. This is because the combination of different MRI scans in one examination can be identified as one entity in the graph database (A.2) 508, since the combined scans are often complementary to each other and necessary to answer the clinical question. Each individual new scan is recorded in table (A.3) 506 with a new index, but the references made in (A.2) 508 are to the scan combination (see Figure 6 (A.2) in the third column of 508).

[0137] The large number of columns in (A.3) 506 can make adding a new MRI scan to the database (A.3) 506 computationally demanding at certain times, since all column values ​​(sets) must be compared to find a match and referenced using existing indexes. This is only relevant when adding a new patient to the database, which does not have to be fast and can be done in the cloud or on your own servers with a queue system. The computational load and data storage load can also be reduced by dimensionality reduction, which also provides other advantages (details below).

[0138] In the early stages, the representation of the MRI scan in this database (A.3) 506 can be very detailed and include all settings translated by the HTF from the scanner UI (from all parameters that may be listed under all tabs: contrast, acceleration, etc.). The body part (or parts) being scanned are important parameters, which are recorded in categorical columns to make the scan database (A.3) 506 easy to filter by body part. Hard parameters already only allow a limited number of discrete values. The soft parameter domain can be defined as a histogram bin with a sensible bin width (e.g., 2-10 ms for TE values ​​- not necessarily uniform across the range). Soft parameters can be binned for a limited number of possible values ​​to aggregate closely related scans and record them as one scan in G3S. If exact values ​​are taken, the index to table (A.3) 506 may be oversold as very similar scans will be recorded as new scans.

[0139] Dimensionality reduction:

[0140] Once added to (A.3) 506, the MRI scans can be represented by points in the high-dimensional G3S. As more scans are collected in the database, dimensionality reduction techniques (e.g., singular value decomposition (SVD), principal component analysis (PCA), or AI-based autoencoders) can be applied to reduce the dimensionality of G3S, thereby creating G3S2, which can be transformed back into G3S via the basis vectors provided by the dimensionality reduction technique. This not only results in a compressed data load in the database (A.3) 506, but it can also provide new insights into the relationships between MRI scans based on actual clinical use (see Figure 3 This can enable data-based metrics that relate different sequence types to each other and can be filtered by body part or even patient indication. This can be used to identify "blind spots" and trigger a more systematic development of new sequences by studying holes in this abstract lower-dimensional G3S2 and creating new sequences simply by placing new points into the holes.

[0141] Figure 7 Several examples of MRI scan setup tables 506, 506', 506" are shown. At the top of the figure is shown an MRI scan setup table (A.3.1) 506, which is Figure 6is the same as shown. In this scan table 506, there are multiple specifications, which are in textual or descriptive form. For example, there is an acquisition mode; this is Cartesian for all three rows, and is also the shot mode and the mode for fast imaging. In order to implement more complex mathematical methods, these various quantities can be encoded using numbers. MRI scan settings table (A.3.2) 506' shows the same MRI scan settings table 506 after the digital encoding has been performed. The conversion of the scan settings to a purely digital form can enable the use of dimensionality reduction, and the soft parameters can be binned into several sensible ranges to achieve coarse-grained settings. This can be part of a hardware transfer function or HTF, which converts the system-specific settings into a generalized settings space (G3S), as shown in table 506'.

[0142] Once enough data has been collected, the features in the G3S table 506' can be recombined in a basis change. This new basis change can have a vector (e.g. SVD axis) that is a linear combination of the original sequence features in G3S and can be ordered according to decreasing degree of variance across all the different scans, for example using principal component analysis. This can reveal new relationships between different magnetic resonance imaging sequences and settings, potentially adding new sequences or aiding new sequence development. The MRI scan settings table (A.3.3) 506" shows the table 506' after the basis change has been performed. Here, the singular value decomposition provides the SVD axes as the new basis. Starting from the plain text of the diagram (A.3.1) 506, each setting parameter is assigned a numerical discrete value by the HTF to map the scan into the G3S representation (A.3.2) 506'. Dimensionality reduction can be used to exploit the relationships and constraints between the settings and reduce the number of "independent" setting parameters across the (ideally) lower dimensional G3S2 (A.3.3) 506".

[0143] B) Database usage: when a new patient requires an MRI examination.

[0144] i. The prescribing physician may give a reason for the MRI scan for a new patient for whom an MRI scan is prescribed. The reason(s) are extracted during or after patient registration at the MRI scan site. Depending on the state of the graph database, the reason may be a medical code or several such (e.g., ICD-10) conditions or term-based conditions extracted from the prescribing physician's report based on a match with a hash list maintained in (A, 1). NLP-AI may be used to support this extraction and add flexibility with respect to wording and synonyms. The extracted symptoms are converted to hash code combinations using a lookup algorithm using table (A.1) 504.

[0145] ii. Search the index of the graph database (A.2) 508 for the obtained hash code combination.

[0146] ii.a) If found:

[0147] The MRI Protocol Expert tool uses a list of references to previous MRI scans performed for these symptoms ( Figure 6 The third column of Table (A.2) 508 in FIG. 5 is used to suggest possible MRI protocols for new patients. Details on how this is achieved are given in the next subsection (iii).

[0148] ii.b) If not found:

[0149] The hash codes with the highest similarity to the sought symptom combination can be considered, for example, by removing individual symptoms and searching for a match in the (A.2) 508 index (or searching for the symptoms individually). A list of references to MRI scans specified for similar symptoms or subsets thereof can be compiled in this way and used to suggest scans for new patients. In the worst case, if no useful match is found, the expert tool cannot suggest any scans. Then, as in current practice, manual protocol development is necessary. A new protocol can be added to the database for this new symptom combination, as described in the previous section.

[0150] iii. The previous MRI sequence information extracted from the graph database in step (B.ii) is used as input to an MRI protocol expert algorithm (which may be AI-powered). This is an interchangeable part of the invention which is expected to become more sophisticated as its database and experience grows. The reference weights from table (A.2) 508 can help to rate the sequence suggestions. Furthermore, some relevant patient information (such as the presence of implants) as well as locally available hardware and methodological constraints (such as the availability of contrast agents) can be included as input in order to exclude incompatible sequences. The scan expert can be designed to: simulate previous scan cards, or, for example, to span the maximum distance in G3S (2) with the minimum scan to create a new protocol with high contrast diversity. Depending on the stage of the database, this can look like the following:

[0151] iii.a) Early stage (no dimensionality reduction in (A.3)506 yet - only high-dimensional G3S):

[0152] Each previous scan input includes coordinates in G3S, where the dimensions represent each scanner setting (which are converted to digital values ​​and binned where appropriate). For on-site MRI, these coordinates can be converted to scanner-specific settings by inverse HTF. This provides a list of MRI exams that can be performed for that patient, theoretically populated with all sequence-related settings (roughly soft parameters). These can be filtered based on local hardware and patient constraints, selected by staff, and used as exam cards before future fine-tuning by staff or algorithms to resolve conflicts and further adjust parameters for local conditions, patient specificity, and diagnostic goals. The AI ​​model trained using the unbinned contents of (A.2) 508 can additionally fine-tune the rough settings for different indications (using continuous model training as new exams are added to the database). The final choice of which exam to select from the available list can be made by staff at this time (possibly remotely), but can also be automated later using usage frequency and diagnostic quality metrics recorded as in (A.2) 508 and (A.3) 506.

[0153] iii.b) Later stage (for (A.3) 506 there is dimensionality reduction - using low-dimensional G3S2):

[0154] In this case, each previous scan obtained from (B.ii) is a point coordinate in the lower dimensional G3S2. Using the basis vectors of the dimensionality reduction method, the point coordinates in G3S2 are transformed back to G3S and an inverse HTF specific to the particular scanner setup is used. This can then be used similarly to (B.iii.a) to deliver a list of possible exams, initialized with the previous settings that can be further fine-tuned. In cases where the previous scan cannot be converted to the current system due to hardware or software incompatibilities, the compressed G3S2 and its derived distance metric can be used to find a "neighboring" scan setting that can deliver similar contrast or insight for the current patient (as an optionally implemented "discovery mode"). This possibility may require further research, but may also provide new insights into how different contrasts for different tissues and pathologies are related, potentially facilitating the development of new diagnostic gold standards or further optimizing sequences for specific purposes / questions.

[0155] The MRI protocol expert 502 and access to the graph database 122 can be provided in a cloud-based software service. This allows for continuous updating and easy deployment of new features, usage monitoring, and ongoing growth contributions.

[0156] In addition to the MRI protocol expert 502, the graph database 122 can enable many applications, some of which may currently be beyond our scope and imagination. The advantage of this approach to building a database that maintains connections between physiological symptoms, detailed MRI scan information, and possibly associated diagnoses and other patient information is that it simply represents a way to clearly collect and structure relevant information for later use and analysis. The graph database can be used to extract multiple subgraphs, allowing different filtering and a separate focus on intra-graph connections and inter-graph connections, meaning connections within a particular subgraph and connections between different subgraphs, respectively.

[0157] As new technologies and algorithms develop, the way these connections are analyzed and used can be adjusted. Just some examples include:

[0158] - Explore individual subgraphs that can be extracted from this database. For example, you can use symptom combination hash codes to extract how often individual symptoms typically occur together. From this, you can easily construct a hypergraph where nodes represent individual symptoms (the node "size" indicates how often the symptom typically occurs), and hyperedges between these nodes indicate co-occurrences (the edge weights indicate frequency).

[0159] - Index permutation: Parse database (A.2) 508 to create a separate graph database similar to (A.2) 508, but with a different searchable index (e.g., based on MRI scan combinations or diseases rather than symptoms). Such a reorganization would list different symptoms for each MRI scan combination or for each diagnosed disease (combination), providing new views of the data and new filtering options. - Use graph theory methods, such as clustering and shortest path analysis, to study the relationships between different symptoms and MRI scans, within subgraphs, and between subgraphs.

[0160] -Continuous delivery: Develop AI for the scan suggestion process using this database as a priori. Continuous development during production is likely not a problem for the described architecture.

[0161] Back-end Market Monitoring: Detailed information about scanner usage across different sectors is collected in a structured, easily searchable format. Automated methods and algorithms can be developed to extract information from the database, which can aid in sequence and protocol development and refinement. This can enable protocol acceleration across sequences, for example, by combining contrasts that are frequently used together into a single optimized acquisition with joint reconstruction, information sharing, and overall protocol acceleration.

[0162] - Predictive maintenance: Using the collected scanner usage information, sequences that typically deliver problematic image quality (e.g., due to poor signal-to-noise ratio or artifacts) can be identified in an automated manner. This can occur through optional one-click feedback given by the radiologist during image review, and having the monitoring algorithm in Table (A.3) 506 flag sequences with unacceptable descriptive rating rates. Furthermore, the AI-enabled algorithm can automatically rate images based on artifacts, noise, and / or other image quality metrics. The resulting image ratings can be recorded in a database (A.3) 506 and reviewed by the monitoring algorithm.

[0163] A big advantage of this strategy of indexing in (A.3) 506 and referencing in (A.2) 508 is that it allows for the extraction of a large amount of information about MRI sequences used in conjunction, which can be filtered by symptoms and / or body part. Such graph data is valuable to vendors and manufacturers and can guide the design of future standardized scan cards for different purposes and body parts. We can answer questions like: which combination of neuroscans can answer the majority (e.g., 90%) of clinical questions in neurology? Moreover, this makes the database very suitable for use in automated full exam recommendations, rather than just suggesting corresponding scans for different symptoms as in the previous proof of principle.

[0164] Figure 8 The graph database 122 is shown in graph form. An object hypergraph 801 is shown as comprising object nodes 800 connected by object hyperedges 802. A pulse sequence configuration hypergraph 803 is shown as comprising configuration nodes 804 connected by configuration hyperedges 806. Configuration nodes 804 represent individual pulse sequences, and configuration hyperedges 806 represent a collection of pulse sequences or pulse sequence protocols. This can be, for example, a group of magnetic resonance imaging acquisitions performed together.

[0165] Figure 8A conceptual diagram of two subgraphs 801 and 803 extracted from a hypothetical database. At the top 801, a symptom subgraph is drawn by representing nodes as circles (size corresponding to the number of occurrences) and edges "within the graph" as lines (thickness corresponding to edge weights, i.e., the number of co-occurrences). More precisely, edges within the graph are hyperedges that typically connect several nodes. In the second cloud 803 below, an MRI sequence subgraph is shown. Here, the individual nodes correspond to individual MRI scans recorded in Table (A.3) 506, but if some clustering is applied, they could also be clustered groups of sequences. The dashed lines between the subgraphs represent inter-graph edges 805 of different weights (thickness). Inter-graph connections can be extracted from the database to connect individual nodes (scans from (A.3) 506 and symptoms from (A.1) 504) or to connect entire scan combinations with all symptom combinations (essentially, connections between hyperedges from different subgraphs). Clustering algorithms can perform coarse-grained processing of subgraphs and inter-graph connections, revealing different information depending on the clustering method.

[0166] Figure 9 An additional view of the graph database 122 is shown. In this figure, a search for the closest matching object hyperedge 900 has been performed and emphasized. The thick dashed line 902 represents a connection between the closest matching object hyperedge 900 and the configuration hyperedge with a weighting factor. The thick dashed line indicates a higher weighting factor. In the pulse sequence configuration hypergraph 803, the connection 902 goes to several re-adjusted configuration hyperedges 904.

[0167] Furthermore, by studying neighborhoods and holes in the abstract sequence setting space G3S2, dimensionality reduction of G3S can provide a new approach for the systematic development of new sequences for specific symptoms / diseases. Coils can be optimized for a specific range of settings as they are actually used in the clinic.

[0168] While the invention has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative or exemplary and not restrictive; the invention is not limited to the disclosed embodiments.

[0169] Those skilled in the art may understand and implement other variations of the disclosed embodiments in practicing the claimed invention by studying the drawings, the present disclosure and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. A single processor or other unit may perform the functions of several items recited in the claims. The fact that certain measures are recited only in mutually different dependent claims does not indicate that a combination of these measures cannot bring advantages. The computer program may be stored / distributed on a suitable medium, such as an optical storage medium or solid-state medium, provided together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunications systems. Any reference signs in the claims should not be construed as limiting the scope. Although the present invention has been described with reference to specific embodiments, many variations of these embodiments are contemplated. Therefore, the present invention is further described without limitation and is exemplified only by the following examples. There may be preferred embodiments. Therefore, the term "clause" as used herein may refer to such "preferred embodiments."

[0170] Clause 1. A medical system (100, 300, 500), comprising:

[0171] - a memory (116) storing machine-executable instructions (120) and a map database (122), wherein the map database is configured to output magnetic resonance imaging pulse sequence configuration data (126) in response to receiving object data; and

[0172] - a computing system (110), wherein execution of the machine-executable instructions causes the computing system to:

[0173] - receiving (200) said object data; and

[0174] - receiving (202) the magnetic resonance imaging pulse sequence configuration data in response to inputting the object data into the map database.

[0175] Clause 2. The medical system according to clause 1, wherein the graph database comprises an object data hypergraph (801) and a pulse sequence configuration hypergraph (803),

[0176] wherein the object data hypergraph comprises object nodes (800) encoding the object data (504), wherein the object data hypergraph further comprises object hyperedges (802) connecting the object nodes and encoding joint occurrences of the object data,

[0177] wherein the pulse sequence configuration hypergraph comprises configuration nodes (804) encoding individual configuration data for individual magnetic resonance imaging pulse sequences (506), wherein the pulse sequence configuration hypergraph further comprises configuration hyperedges (806) connecting the configuration nodes to encode combinations of pulse sequences forming the magnetic resonance imaging pulse sequence configuration data, and

[0178] The database further includes a main graph data frame (508), wherein the main graph data frame (508) lists each object hyperedge and the connection to the configuration hyperedge (805).

[0179] Clause 3. The medical system of clause 2, wherein the connection to the configuration hyperedge and the configuration hypergraph node includes a weighting factor, and wherein the graph database is configured to select the magnetic resonance imaging pulse sequence configuration data using the object data and the weighting data, comprising:

[0180] - using the object data, identifying a closest matching object hyperedge in the object data hypergraph (900);

[0181] - returning the configuration hyperedge (904) and weighting data (902) associated with the closest matching object hyperedge in the main graph data frame; and

[0182] - selecting said magnetic resonance imaging pulse sequence configuration data from the returned configuration hyperedges using at least in part said weighting data.

[0183] Clause 4. The medical system of clause 3, wherein each object data hyperedge is identified by a unique hash number, and wherein the execution of the machine-executable instructions further comprises:

[0184] - converting the object data into an object hash number; and

[0185] - searching the main graph data frame for the closest matching object hyperedge using the object hash number.

[0186] Clause 5. The medical system of any one of clauses 2 to 4, wherein the encoding of the magnetic resonance imaging pulse sequence configuration data for individual pulse sequences is numerical.

[0187] Clause 6. The medical system of clause 5, wherein the graph database is configured to add new configuration nodes to the configuration hypergraph by binning pulse sequence parameters.

[0188] Clause 7. The medical system of clause 5 or 6, wherein the method further comprises:

[0189] - calculating distances within the magnetic resonance imaging pulse sequence configuration data for configuration nodes connected by configuration hyperedges associated with the closest object hyperedge in said main image data frame; and

[0190] - selecting the magnetic resonance imaging pulse sequence configuration data from the returned configuration hyperedges using the weighted data and the calculated distance in combination with the magnetic resonance imaging pulse sequence configuration data.

[0191] Item 8. A medical system according to Item 7, wherein the configuration node encodes the pulse sequence settings in a reduced-dimensionality state, wherein the memory further comprises: a mapping between the reduced-dimensionality state and the magnetic resonance imaging system pulse sequence configuration parameters, wherein providing the magnetic resonance imaging pulse sequence configuration data comprises: converting between the reduced-dimensionality state and the magnetic resonance imaging system pulse sequence configuration parameters.

[0192] Clause 9. The medical system of any preceding clause, wherein execution of the machine-executable instructions further causes the computing system to:

[0193] - receiving (400) magnetic resonance imaging detection scan data (334) describing the subject;

[0194] - deriving (402) at least a portion of the object data from the probe scan data.

[0195] Clause 10. The medical system of clause 9, wherein deriving the at least a portion of the object data from the scout scan data comprises:

[0196] - determining an image segmentation of the probe scan data using an automatic segmentation module; and

[0197] - computing said at least part of said object data using said image segmentation.

[0198] Clause 11. The medical system of clause 10, wherein the memory further comprises an image classification machine learning module, wherein deriving the at least a portion of the object data comprises:

[0199] - receiving an image classification in response to inputting the detection image data into the image classification machine learning module; and

[0200] - providing said image classification as said at least part of said object data.

[0201] Clause 12. The medical system of any preceding clause, wherein execution of the machine-executable instructions further causes the computing system to:

[0202] - receiving (404) a selection of a magnetic resonance imaging system;

[0203] - converting (406) the received magnetic resonance imaging pulse sequence configuration data into one or more pulse sequences configured to control the magnetic resonance imaging system to acquire k-space data of the subject.

[0204] Clause 13. A medical system according to clause 12, wherein the medical system further comprises one or more magnetic resonance imaging systems (104, 106, 108), wherein execution of the machine-executable instructions further causes the computing system to: acquire (408) the k-space data of the object by controlling the one or more magnetic resonance imaging systems using the one or more pulse sequences.

[0205] Clause 14. A method of operating a medical system (100, 300, 500), wherein the medical system includes a computing system (110), wherein the method comprises:

[0206] - receiving (200) object data; and

[0207] - receiving (202) magnetic resonance imaging pulse sequence configuration data (126) in response to inputting the subject data into a map database (122), wherein the map database is configured to output magnetic resonance imaging pulse sequence configuration data in response to receiving the subject data.

[0208] Clause 15. A computer program comprising machine-executable instructions (120) for execution by a computing system (110), wherein execution of the machine-executable instructions causes the computing system to:

[0209] - receiving (200) said object data; and

[0210] - receiving (202) magnetic resonance imaging pulse sequence configuration data in response to inputting the subject data into a map database (122), wherein the map database is configured to output magnetic resonance imaging pulse sequence configuration data in response to receiving the subject data.

[0211] Reference Signs List

[0212] 100 Medical System

[0213] 102 Computer

[0214] 104 Magnetic Resonance Imaging System

[0215] 106 Magnetic Resonance Imaging System

[0216] 108 Magnetic Resonance Imaging System

[0217] 110 Computing Systems

[0218] 112 User Interface

[0219] 112'User Interface

[0220] 114 Network interface or hardware interface

[0221] 114'Network interface or hardware interface

[0222] 116 memory

[0223] 116' storage

[0224] 120 machine-executable instructions

[0225] 122 Graph Database

[0226] 124 Object Data

[0227] 126 MRI pulse sequence configuration data

[0228] 200 Receive object data

[0229] 202 Receiving magnetic resonance imaging pulse sequence configuration data in response to inputting the object data into the map database

[0230] 302 Magnetic Resonance Imaging System

[0231] 304 magnet

[0232] 306 magnet hole

[0233] 308 Imaging Area

[0234] 309 Field of View

[0235] 310 Magnetic Field Gradient Coil

[0236] 312 Magnetic Field Gradient Coil Power Supply

[0237] 314 RF Coil

[0238] 316 transceiver

[0239] 318 objects

[0240] 320 object support

[0241] 330 Detection scan pulse sequence command

[0242] 332 Detection scan k-space data

[0243] 334 detection scan data

[0244] 336 Local Object Data

[0245] 338 Image Classification Machine Learning Module

[0246] 340 Image Classification

[0247] 342 One or more pulse sequences

[0248] 344 k-space data

[0249] 346 One or more magnetic resonance images

[0250] 400 receiving magnetic resonance imaging probe scan data describing a subject;

[0251] 402 derives at least a portion of object data from the probe scan data.

[0252] 404 Receive Selection of Magnetic Resonance Imaging System

[0253] 406 Convert the received magnetic resonance imaging pulse sequence configuration data into one or more pulse sequences, wherein the one or more pulse sequences are configured to control the magnetic resonance imaging system to acquire k-space data of the object.

[0254] 408 acquires k-space data of the subject by controlling one or more magnetic resonance imaging systems using the one or more pulse sequences.

[0255] 410 Reconstruct one or more magnetic resonance images from k-space data

[0256] 500 Medical System

[0257] 502 MRI Protocol Expert

[0258] 504 Object Hypergraph

[0259] 506 Pulse Sequence Configuration Hypergraph

[0260] 508 Main image data frame

[0261] 510 Decision Module

[0262] 512 Approval Feedback Mechanism

[0263] 514 Retry Symptom Subset

[0264] 516 Manual Protocol Development

[0265] 518 Add new pulse sequence protocol to database

[0266] 800 object nodes

[0267] 801 Object Data Hypergraph

[0268] 802 Object Hyperedge

[0269] 803 Pulse Sequence Configuration Hypergraph

[0270] 804 Configuration Node

[0271] 805 Connection between object hyperedge and configuration hyperedge

[0272] 806 Configuring Hyperedge

[0273] 900 closest matching object hyperedge

[0274] 902 Connection between the closest matching object hyperedge and configuration hyperedge with weighting factor

[0275] 904 Return to configure hyperedge

Claims

1. A medical system (100, 300, 500), comprising: a memory (116) storing machine-executable instructions (120) and a map database (122), wherein the map database is configured to output magnetic resonance imaging pulse sequence configuration data (126) in response to receiving object data; and A computing system (110), wherein execution of the machine-executable instructions causes the computing system to: receiving (200) the object data; and receiving (202) the magnetic resonance imaging pulse sequence configuration data in response to inputting the subject data into the map database; The graph database includes an object data hypergraph (801) and a pulse sequence configuration hypergraph (803), wherein the object data hypergraph comprises object nodes (800) encoding the object data (504), wherein the object data hypergraph further comprises object hyperedges (802) connecting the object nodes and encoding joint occurrences of the object data, wherein the pulse sequence configuration hypergraph comprises configuration nodes (804) encoding individual configuration data for individual magnetic resonance imaging pulse sequences (506), wherein the pulse sequence configuration hypergraph further comprises configuration hyperedges (806) connecting the configuration nodes to encode combinations of pulse sequences forming the magnetic resonance imaging pulse sequence configuration data, and The graph database further includes a main graph data frame (508), wherein the main graph data frame (508) lists each object hyperedge and its connection to the configuration hyperedge (805), The method is characterized in that the connection to the configuration hyperedge and the configuration node include a weighting factor, and wherein the graph database is configured to select the magnetic resonance imaging pulse sequence configuration data by using the object data and the weighting data, comprising: Using the object data, identifying a closest matching object hyperedge in the object data hypergraph (900); Returning the configuration hyperedge (904) and weighting data (902) associated with the closest matching object hyperedge in the main graph data frame; and The magnetic resonance imaging pulse sequence configuration data is selected from the returned configuration hyperedges using, at least in part, the weighted data.

2. The medical system according to claim 1, wherein each object data hyperedge is identified by a unique hash number, wherein Execution of the machine-executable instructions further includes: Converting the object data into an object hash number; and The object hyperedge that is most closely matched is searched in the main graph data frame using the object hash number.

3. The medical system according to any one of claims 1 or 2, wherein: The encoding of the magnetic resonance imaging pulse sequence configuration data for individual pulse sequences is digital.

4. The medical system according to claim 3, wherein: The graph database is configured to add new configuration nodes to the configuration hypergraph by binning pulse sequence parameters.

5. The medical system according to claim 3 or 4, wherein: Execution of the machine-executable instructions causes the computing system to further: calculating distances within magnetic resonance imaging pulse sequence configuration data for configuration nodes connected by configuration hyperedges associated with the closest object hyperedge in the main image data frame; as well as The magnetic resonance imaging pulse sequence configuration data is selected from the returned configuration hyperedges using a combination of the weighted data and the calculated distance with the magnetic resonance imaging pulse sequence configuration data.

6. The medical system according to claim 5, wherein: The configuration node encodes the pulse sequence settings in a reduced dimensionality state, wherein the memory further comprises: a mapping between the reduced dimensionality state and magnetic resonance imaging system pulse sequence configuration parameters, wherein providing the magnetic resonance imaging pulse sequence configuration data comprises: converting between the reduced dimensionality state and the magnetic resonance imaging system pulse sequence configuration parameters.

7. A medical system according to any one of the preceding claims, wherein: Execution of the machine-executable instructions further causes the computing system to: receiving (400) magnetic resonance imaging probe scan data (334) describing the subject; At least a portion of the object data is derived (402) from the probe scan data.

8. The medical system according to claim 7, wherein: Deriving the at least a portion of the object data from the probe scan data comprises: determining an image segmentation of the probe scan data using an automatic segmentation module; and The at least a portion of the object data is calculated using the image segmentation.

9. The medical system according to claim 8, wherein: The memory further comprises an image classification machine learning module, wherein deriving the at least a portion of the object data comprises: receiving an image classification in response to inputting the probe image data into the image classification machine learning module; and The image classification is provided as the at least part of the object data.

10. The medical system according to any one of the preceding claims, wherein: Execution of the machine-executable instructions further causes the computing system to: receiving (404) a selection of a magnetic resonance imaging system; The received magnetic resonance imaging pulse sequence configuration data is converted (406) into one or more pulse sequences configured to control the magnetic resonance imaging system to acquire k-space data of the subject.

11. The medical system according to claim 10, wherein: The medical system also includes one or more magnetic resonance imaging systems (104, 106, 108), wherein execution of the machine-executable instructions further causes the computing system to acquire (408) the k-space data of the subject by controlling the one or more magnetic resonance imaging systems using the one or more pulse sequences.

12. A method of operating a medical system (100, 300, 500), wherein: The medical system comprises a computing system (110), wherein the method comprises: receiving (200) object data; and receiving (202) magnetic resonance imaging pulse sequence configuration data (126) in response to inputting the object data into a graph database (122), wherein the graph database is configured to output the magnetic resonance imaging pulse sequence configuration data in response to receiving the object data, wherein the graph database includes an object data hypergraph (801) and a pulse sequence configuration hypergraph (803), wherein the object data hypergraph comprises object nodes (800) encoding the object data (504), wherein the object data hypergraph further comprises object hyperedges (802) connecting the object nodes and encoding joint occurrences of the object data, wherein the pulse sequence configuration hypergraph comprises configuration nodes (804) encoding individual configuration data for individual magnetic resonance imaging pulse sequences (506), wherein the pulse sequence configuration hypergraph further comprises configuration hyperedges (806) connecting the configuration nodes to encode combinations of pulse sequences forming the magnetic resonance imaging pulse sequence configuration data, and The graph database further includes a main graph data frame (508), wherein the main graph data frame (508) lists each object hyperedge and its connection to the configuration hyperedge (805), wherein the connection to the configuration hyperedge and the configuration node includes a weighting factor, and wherein the graph database is configured to select the magnetic resonance imaging pulse sequence configuration data by using the object data and the weighting data, comprising: Using the object data, identifying a closest matching object hyperedge in the object data hypergraph (900); Returning the configuration hyperedge (904) and weighting data (902) associated with the closest matching object hyperedge in the main graph data frame; and The magnetic resonance imaging pulse sequence configuration data is selected from the returned configuration hyperedges using, at least in part, the weighted data.

13. A computer program comprising machine-executable instructions (120) for execution by a computing system (110), wherein: Execution of the machine-executable instructions causes the computing system to: receiving (200) object data; and receiving (202) magnetic resonance imaging pulse sequence configuration data in response to inputting the subject data into a map database (122), wherein the map database is configured to output the magnetic resonance imaging pulse sequence configuration data in response to receiving the subject data, The graph database includes an object data hypergraph (801) and a pulse sequence configuration hypergraph (803), wherein the object data hypergraph comprises object nodes (800) encoding the object data (504), wherein the object data hypergraph further comprises object hyperedges (802) connecting the object nodes and encoding joint occurrences of the object data, wherein the pulse sequence configuration hypergraph comprises configuration nodes (804) encoding individual configuration data for individual magnetic resonance imaging pulse sequences (506), wherein the pulse sequence configuration hypergraph further comprises configuration hyperedges (806) connecting the configuration nodes to encode combinations of pulse sequences forming the magnetic resonance imaging pulse sequence configuration data, and The graph database further includes a main graph data frame (508), wherein the main graph data frame (508) lists each object hyperedge and its connection to the configuration hyperedge (805), wherein the connection to the configuration hyperedge and the configuration node includes a weighting factor, and wherein the graph database is configured to select the magnetic resonance imaging pulse sequence configuration data by using the object data and the weighting data, comprising: Using the object data, identifying a closest matching object hyperedge in the object data hypergraph (900); Returning the configuration hyperedge (904) and weighting data (902) associated with the closest matching object hyperedge in the main graph data frame; and The magnetic resonance imaging pulse sequence configuration data is selected from the returned configuration hyperedges using, at least in part, the weighted data.

Images