Automated configuration of magnetic resonance imaging system

Abstract

A medical system (100, 300, 500) is disclosed that includes a memory (116) storing machine executable instructions (120) and a graph database (122). The map database is configured to output magnetic resonance imaging pulse sequence configuration data (126) in response to receiving the 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 receiving (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 more particularly to the configuration of a magnetic resonance imaging system. Background Art

[0002] As part of the process for 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 a magnetic resonance imaging system can be complex and can require years of training.

[0003] Publication article: "Automated Protocoling for MRI Exams-Challenge and Solutions" by Deneck et al., Journal of Digital Imaging (2022) 35: 1293-1302, https: / / doi.org / 10.1007 / s10278-022-00610-1, discloses that automated protocoling for MRI examinations is a modifiable goal for workflow automation using artificial intelligence. However, there are still challenges to overcome for a successful and robust approach. A literature review was conducted, which analyzed the limitations of currently published methods for automated protocol development. These limitations were quantitatively evaluated based on data from a private radiology practice. To this end, the information content provided by clinical indications was further evaluated by calculating the overlap coefficients of the set of ICD-10 coded allowed diagnoses for different MRI protocols. In addition, the heterogeneity of protocol trees from three different MRI scanners was evaluated based on the overlap coefficients, MRI protocols, and sequence levels. In addition, sequence name standardization was applied to demonstrate its impact on the heterogeneity assessment (i.e., overlap coefficient) of different protocol trees. The overlap coefficient 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 coefficient between the sets of sequences 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 a database that uses graph structures and encodes “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 object, to describe the magnetic resonance imaging system, to provide information about a medical problem or suspected health problem of the object, and to provide measurement data or control data from the magnetic resonance imaging system. For example, the object data may be data measured during a previous procedure of the magnetic resonance imaging system 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 the object data or the type or item of the 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 point 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 measured 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. Then, in some cases, configuration hyperedges can be considered to form a magnetic resonance imaging protocol or a set of magnetic resonance imaging pulse sequences to be performed on a specific subject.

[0012] The database also includes a master graph data frame that lists each object hyperedge and the connection to the configuration hyperedge. The master graph data frame list can, for example, be a table containing this information. Where specific object hyperedges or combinations of hyperedges can be listed (if the hyperedge is formally decomposed into smaller hyperedges), these links to the 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 by using 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. Then, it can be considered as a matching object hyperedge. However, the same match for a specific object hyperedge may not be found. 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 or fragment 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 an object hyperedge that matches when the least number of object data elements are excluded. In some cases, when searching for the closest matching object hyperedge, there may be a list or rating or specific order for excluding various elements of the object data.

[0015] The graph database is also configured to select magnetic resonance imaging pulse sequence configuration data by using the object data, including the steps of returning configuration hyperedges and weighted data associated with the closest matching object hyperedge in the main graph data frame. Selecting magnetic resonance imaging pulse sequence configuration data using the object data also includes selecting the magnetic resonance imaging pulse sequence configuration data from the returned configuration hyperedges using, at least in part, the weighted 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 weighted data may provide a rating or ranking of each of these configuration hyperedges in the master graph data frame list. As the simplest means for selecting the closest matching object hyperedge, the object hyperedge with the highest weighting factor may be simply selected.

[0017] In other examples, other considerations may also be taken into account when selecting configuration hyperedges. For example, the weighted 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 symptoms), which may also be used when selecting or constructing magnetic resonance imaging 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. By this, it 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. The 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 for the closest matching object hyperedge in the main graph data frame. For example, the main graph data frame can be a table that lists various hash values ​​and then lists 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 may be selectively excluded from the object data to see if a match can be obtained by reducing the amount of data to match against. In some cases, there may be a list such that particular elements of the object data are selected in a particular order.

[0020] In another embodiment, the encoding of the magnetic resonance imaging pulse sequence configuration data for individual pulse sequences is numerical. There are usually different values ​​in a pulse sequence, which are digital. These can be, for example, various time elements in the pulse sequence, and various values, such as the gradient strength or the strength of the generated RF pulses. There are also other values ​​that can be considered non-numerical. In order to encode it digitally, digital values ​​can simply be assigned to these non-numerical values ​​and a mapping can be provided, which is then digital. This can have the following advantages: 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 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 magnetic resonance imaging protocols that can provide more variable results. In some cases, the distance within the magnetic resonance imaging pulse sequence configuration data can be considered as a metric. Since the configuration nodes have been digitally encoded, the distance can be calculated using these purely digital configuration data. As mentioned above, it can be, for example, a simple Euclidean distance, or it can be a more complex metric that can measure 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 reduced dimensionality. This can thereby reduce the number of variables required to represent a particular pulse sequence. The calculation of distances within the magnetic resonance imaging pulse sequence configuration data can be more meaningful in this reduced dimensionality. For example, this can help select a magnetic resonance imaging protocol with greater diversity of magnetic resonance imaging settings. This can provide a greater variety of magnetic resonance images with a minimum amount 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 detection scan includes an MRI scan that is performed before other MRI scans in an MRI protocol. The MRI detection scan is typically performed at a lower resolution so that it can be quickly performed and provides a preview of a larger area of ​​the object. This can be, for example, used to perform alignment of the imaging volume and to provide a preview to a clinician or technician to determine what further MRI scans are to be performed and what the geometric settings of the imaging scans can 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 detection scan using a large imaging field of view. In this embodiment, the preliminary scan or detection 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 the image segmentation of the scout scan using an automatic segmentation module. For example, there are various image segmentation modules available. For example, shape deformable or even segmentation algorithms for specific areas of the body, such as locating the position of a diaphragm or using edge detection. Deriving 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. For example, this is very useful when aligning or configuring the size or orientation of the field of view or imaging volume in a magnetic resonance imaging system.

[0029] In another embodiment, deriving at least a portion of the object data from the scoping scan further comprises: calculating at least a portion of the configuration data using the image segmentation and the pre-scan or scoping data. Deriving at least a portion of the object data from the scoping scan data further comprises: giving a suggestion to an operator on how to adjust the imaging configuration settings to obtain a better expected 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 detection 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, the image classification machine learning module can be implemented as a convolutional neural network, random forest, or support vector machine. These are basically various technologies that can be used to receive images or three-dimensional data and output classifications. For example, if a convolutional neural network is used, it can be trained using various labeled detection scans with various classifications. Various types of neural network architectures can be used to implement the image classification learning module. In some cases, U-net, ResNet, or other types of convolutional neural networks that are commonly used to perform classification on images can be used.

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

[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 abnormal geometries) can be presented to the operator in a prominent manner. In a non-expert user interface mode, sequence parameters that are not recommended to be changed 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 they 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 object. 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 enables one database to host information for all scanners without the need for 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 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 with one or more pulse sequences. In most cases, the medical system will include the computing system and a graph database that communicates with the one or more magnetic resonance imaging systems. For a specific object located at a specific magnetic resonance imaging system, the object data will be sent, and then in response, the one or more pulse sequences will be provided to perform 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 objects 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 acquires the k-space data. In other cases, the k-space data may be sent to a cloud-based or internet-based service for use in reconstructing the images. The service may or may not be located at the same location as the graph database.

[0038] In another embodiment, when the magnetic resonance images are acquired, the magnetic resonance images 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 further object data can be used to select further magnetic resonance imaging protocols or to modify magnetic resonance imaging protocols that have already been partially executed. This can result in a closed-loop control loop when operating a magnetic resonance imaging system in conjunction with the use of a 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 object data. The method includes: the computing system receives the object data. The method also includes: receiving the magnetic resonance imaging pulse sequence configuration data in response to inputting the object data into the graph database. Inputting the object data into the graph database can also be interpreted as querying the graph database using the object 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 object data. Execution of the machine executable instructions also causes the computing system to receive magnetic resonance imaging pulse sequence configuration data in response to inputting the object 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 object 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 an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, which may all be generally referred to herein as "circuits," "modules," or "systems." Additionally, 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" covers any tangible storage medium that can store instructions that can be executed by a processor or a computing system of a computing device. The computer-readable storage medium can be referred to as a computer-readable non-temporary storage medium. The computer-readable storage medium can also be referred to as a tangible computer-readable medium. In some embodiments, a computer-readable storage medium can also store data that can be accessed by a computing system of a computing device. Examples of computer-readable storage media include, but are not limited to, floppy disks, magnetic hard disk drives, solid-state hard disks, flash memory, USB thumb drives, random access memories (RAM), read-only memories (ROM), optical disks, magneto-optical disks, and register files of computing systems. Examples of optical disks include compact disks (CDs) and digital versatile disks (DVDs), such as CD-ROMs, CD-RWs, CD-Rs, DVD-ROMs, DVD-RWs, or DVD-R optical disks. The term computer-readable storage medium also refers to various types of recording media that can be accessed by a computer device via a network or a 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, embodied 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 conjunction 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, "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 "computing system" should be interpreted as possibly 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 among multiple computer systems. The term computing system should also be interpreted as possibly 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 that may be within the same computing device or even distributed across multiple computing devices.

[0047] Machine executable instructions or computer executable code may include instructions or programs that cause a processor or other computing system to perform an aspect of the present invention. Computer executable code for performing the operations of various aspects of the present invention may be written in any combination of one or more programming languages, and compiled into machine executable instructions, including 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 may be in the form of a high-level language or in a precompiled form, and 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 may 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., through the Internet using an Internet service provider).

[0049] Various aspects of the present invention are described with reference to the flowcharts 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 flowchart, 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 flowcharts, 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 implementing the function / action specified in the frame of the flowchart 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 a product that 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 into a computer, other programmable data processing apparatus or other device to enable a series of operable steps to be executed 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 processing 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. 'User interface' may also be referred to as a 'human-machine interface device'. A user interface may provide information or data to an operator, and / or receive information or data from an operator. A user interface may enable input from an operator to be received by a computer, and may provide output from a computer to a user. In other words, a user interface may allow an operator to control or manipulate a computer, and an interface may allow a computer to indicate the effects of the operator's control or manipulation. 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, indicator bar, graphic tablet, joystick, game controller, webcam, head-mounted device, pedal, wired gloves, remote controller, and accelerometer are all examples of user interface components that are capable of receiving information or data from an operator.

[0053] As used herein, "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 may allow a computing system to send control signals or instructions to an external computing device and / or apparatus. A hardware interface may 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 (VF), 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-dimensional or three-dimensional visualization of anatomical data contained within the 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 and 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] Fig. 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. Elements that have been discussed previously will not need to be discussed in subsequent figures if the function is equivalent.

[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 integrating multiple magnetic resonance imaging systems 104, 106, 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. Likewise, the computing system 110 can also represent multiple computing systems or 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 may enable 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 may 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] The memory 116 is shown as containing machine executable instructions 120. The machine executable instructions 120 may include instructions that enable the computing system 110 to perform basic image and digital tasks. In some examples, the machine executable instructions 120 may enable the computing system 110 to control other components of the medical system 100, such as the magnetic resonance imaging systems 104, 106, and 108. The memory 116 is further shown as containing a graph database 122. The memory 116 is further shown as containing object data 124, which may be used as input or for querying the graph database 122. The 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 will have to undergo a conversion process to convert it into one or more pulse sequences that will 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 Flowchart of a method of the medical system 100 of the present invention. 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, which 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 the arrangement of the Helmholtz coil. Open magnets are popular because the restrictions on the object are less. There is a collection of superconducting coils inside the cryostat of the cylindrical magnet.

[0078] Within the bore 306 of the cylindrical magnet 304 there is an imaging zone 308 in which the magnetic field is strong enough and uniform enough 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. The region of interest may be the same as the field of view 309, or it may be a sub-volume 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] There is also a set of magnetic field gradient coils 310 within the bore 306 of the magnet, which is used to acquire measured k-space data to spatially encode magnetic spins within the imaging zone 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 provided 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 for manipulating the orientation of magnetic spins within the imaging zone 308 and for receiving radio transmissions from spins also within the imaging zone 308. The radio frequency antenna may include multiple coil elements. The 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 transmitting coils and receiving coils and 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 transmitting antenna and a dedicated receiving antenna. Similarly, the transceiver 316 may also represent a separate transmitter and receiver. The radio frequency coil 314 may also have multiple receiving elements / transmitting elements, and the radio frequency transceiver 316 may have multiple receiving channels / transmitting channels.

[0081] The magnetic resonance imaging system 104 is shown as including a computer 102', which also includes a computing system 110', a hardware interface 114', an optional user interface 112', and a memory 116'. In other examples, the features and components of the computers 102' and 102' may be combined. Figure 3 While shown having 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 ′ which controls the magnetic resonance imaging system 104 locally.

[0082] The memory 116 ′ of the computer 102 ′ is shown as including machine-executable instructions 120 ′. The machine-executable instructions 120 ′ contain 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] The memory 116' is shown as containing a probe scan pulse sequence command 330. In an automated system, the probe scan pulse sequence command 330 may be, for example, a pulse sequence command that is automatically executed when the subject 318 is inserted into the magnetic resonance imaging system 304 and reaches the imaging zone 308. The memory 116' is further shown as containing a probe scan k-space data 332. This is acquired k-space data that is acquired by controlling the magnetic resonance imaging system 104 using the probe scan pulse sequence command 330. The memory 116' is further shown as containing a probe scan data 334, which may be a probe scan image reconstructed from the probe scan k-space data 332. The memory 116' is further shown as containing local object data 336. This may contain things such as a selection of an area of ​​the subject 318 to be imaged, details about the subject 318 such as weight, age, or other metadata describing the subject 318.

[0084] The memory 116 in the computer 102 is shown as also containing the detection 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, there may be a standard convolutional neural network for classifying images. The image classification 340 may be cascaded with the local object data 336, for example, to produce the object data 124. This may 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 may then be converted into one or more pulse sequences 342 that are 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 with 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 object data 324 is derived from the detection scan data 334. In step 404, a selection of a magnetic resonance imaging system 104 is received. Steps 200 and 202 are performed, as shown in FIG. Figure 2 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 back end includes a graph database (122), which 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 between different scanners, sites and suppliers, which potentially solves many open problems in the automation of MRI protocol development. The envisioned database will cause the object data (124) (magnetic resonance imaging pulse sequence configuration data 126) of the MRI sequence to be connected with the appropriate MRI protocol and possible other relevant patient information. The database can continue to grow during use and be used for MRI protocol development inference, thereby suggesting 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 crucial 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 specify a specific set of MRI scans (examinations / protocols) with desired contrast based on the patient's description and the consulting physician's guess about the possible underlying cause. The contrast of subsequent MRI scans is based on the training of the radiologist / technician and a limited set of experience from several people. Their starting point is usually a local database of pre-configured scan cards (supplier presets), which are selected based on patient indications and may be fine-tuned by on-site staff. Local databases usually do not retain factory settings, but are pre-configured by local radiology staff. All of this leads to large variability in the use of MRI in different locations, because 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 generic local data records, which is done only 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 use the database to suggest appropriate MRI protocols for patients with similar indications. In some examples, utilizing machine learning solutions to address this is suboptimal because it is not understandable or transparent in its decision support, it is difficult to curate and systematically correct errors or updates to the gold standard or specification (requiring complete retraining, excluding the corresponding scan), it is barely monitorable, and it is unclear when inputs of patient indications cannot be processed sensitively because there is no training data or too little training data for those input symptoms, and there are other issues regarding scalability, maintainability, and liability.

[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, because similar combinations of symptoms or subsets thereof may lead to completely different suspicions about the underlying etiology, thereby requiring different scans. Therefore, connections between different symptom or object 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 sensible protocol construction with minimal acquisition contrast redundancy). Some examples can handle this by recording all these connection layers in a graph database in an easily searchable and extensible format, thereby maintaining the freedom to apply different filtering and processing methods or AI algorithms during the predictive use of the MRI protocol expert tool, thereby allowing continuous improvement of the automated scan suggestion system. This approach also transfers the machine learning input only to the MRI sequence / protocol domain, which is better defined, more structured and limited than the indication / symptom word cloud domain. In our case, the generation and management of training data may be less problematic, as training data can be extracted retroactively from existing log files to find out which sequences are commonly used together in the protocol. Synthetic training data generation can also be applied based on simulated contrast similarity.

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

[0099] - Less clinical staff time spent on selecting and adjusting exams, and more approval capabilities 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 specified, 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 the patient, with an environment for forming a time-efficient MRI protocol 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 a magnetic resonance imaging 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 may 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, multiple magnetic resonance imaging pulse sequence configuration data 126 are found using the main graph data frame 508.

[0105] For example, weighting factors or other data may be included to rate the quality of different MR protocols and individual sequences. There is a decision module 510, 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 specific 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 are 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 go to a manual protocol development tool that enables an operator to manually select or construct a magnetic resonance imaging protocol to be used. For example, it can also be added to the database 518 to improve the amount of information in the graph database 122.

[0107] The MRI protocol expert (502) has access to a graph database (122) containing 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 the previously performed MRI protocol 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 what is expected, 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 form 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 the sequence settings in the database, previously used protocols can be mixed based on compatibility with locations and patients and specific sequences can be excluded. 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 different subgraphs (individual symptoms / MRI sequences), the hyperedges within each subgraph (complete indications / MRI protocols), and the connections between hyperedges of different subgraphs (which MRI is used for what?). This can be implemented with three separate data tables (details in the next section):

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

[0112] 2. A table that has 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 settings space constitutes the columns of the third table above. The transformation function may 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 a magnetic resonance imaging 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 a 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 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, such as 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 digitally 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 this hash list may be extracted from the physician's prescription label (e.g., ICD-10 code or stated indication), or a list of all available ICD-10 codes may be used. It may be possible to scan the prescribing physician's report with an AI for NLP (natural language processing) to extract more comprehensive information about the patient from free text. New terms deemed relevant by the NLP-AI may be added to the hash list upon approval by the data manager or manually.

[0126] A.2. Main Graph Data Frame - A table recording the co-occurrence of symptoms and 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 examination and is to be added to the database, the symptoms that led to the examination 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 decomposed into several individual symptoms again). This total hash code is used as an index in the main graph data frame (A.2) 508, making it easy to search and modify when growing and using the database. 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), this data frame (A.2) 508 stores weighted references to previously performed MRI examinations (scan combinations) 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 of subtables complementary to (A.2) 504 in the rows of (A.2) 508.

[0129] 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 at scan time. Symptoms (extracted from the prescribing physician's annotations) are converted to a hash code combination, and the index of (A.2) 508 is searched for the 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 scans 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 MRI sequence previously used. 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 the 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, a check is made in (A.3) 506 to see if it already exists with these settings. If so, 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, 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 (the hyperedge on the (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., this 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 the index of each scan 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 images may 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 is performed for a certain combination of symptoms (frequency) and the likelihood that the scan will result in a diagnosis (diagnostic value / quality), respectively. Quality ratings can be obtained by implementing a simple one-click feedback option into the viewer used by radiologists. For example, there can be a "thumbs up" icon in the corner of the displayed image. Optionally, if the scan achieves a diagnosis, the radiologist can give one-click feedback. 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 weight (the priority ranking may be continuously adjusted in an interchangeable AI or classical algorithm of the MRI protocol expert, which will be described in more detail in Subsection B below). For the implementation of such weights, the reference to (A.3) 506 in the third column of Table (A.2) 508 may be a more general data structure with a combined index and its corresponding weight / attribute (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 substantially 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., scanning technique, fat suppression, etc.). Soft parameters are quantitative settings that have a fairly continuous domain (e.g., echo time, gradient bandwidth, etc.) and 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 on different MRI hardware and software versions, a generalized MRI scan settings space can be defined, which treats each possible setting parameter as an individual digital 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 the 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 reference made in (A.2) 508 is to the scan combination (see Figure 6 (A.2) in the third column of 508).

[0137] The large number of columns of (A.3) 506 can make it computationally demanding to add a new MRI scan to the database (A.3) 506 at certain times, since the values ​​(sets) of all columns 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 alleviated 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 allow only a limited number of discrete values. Soft parameter domains can be defined as histogram bins with sensible bin widths (e.g. 2-10ms 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 explode because 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 to 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 can 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 a shot mode and a 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 digital encoding has been performed. The conversion of scan settings to a purely digital form can enable the use of dimensionality reduction, and 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 system-specific settings into a generalized setting 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 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. MRI Scan Settings Table (A.3.3) 506" shows the table 506' after the basis change has been performed. Here, singular value decomposition provides the SVD axes as the new basis. Starting from the plain text of diagram (A.3.1) 506, a numerical discrete value is assigned to each setting parameter 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 to reduce the number of "independent" setting parameters, spanning the (ideally) lower dimensional G3S2 (A.3.3) 506".

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

[0144] i. The prescribing physician can give a reason for the MRI scan for a new patient for whom an MRI scan is prescribed. The reason (or reasons) are extracted during or after patient registration at the MRI scan site. Depending on the state of the graph database, the reason can 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 can be used to support this extraction and add flexibility with respect to wording and synonyms. Table (A.1) 504 is used to convert the extracted symptoms into hash code combinations through a lookup algorithm.

[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 (A.2) 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 matches 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 matches are 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 supported by AI). 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. Moreover, some relevant patient information (such as the presence of implants) as well as locally available hardware and method 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 a minimum of scans 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 is 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 examinations that can be performed for the patient, with all sequence-related settings (roughly soft parameters) theoretically filled in. These can be filtered according to local hardware and patient constraints, selected by staff, and used as examination 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 examinations are added to the database). The final choice of which examination to select from the available list can be made by staff at this time (possibly remotely), but can also be automated later using the frequency of use and diagnostic quality metrics recorded in (A.2) 508 and (A.3) 506.

[0153] iii.b) Later stage (there is dimensionality reduction for (A.3) 506 - 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 specific scanner settings is used. Subsequently, it can be used similarly to (B.iii.a) to deliver a list of possible examinations, which is initialized with the previous settings that can be further fine-tuned. In the case where the previous scan cannot be converted to the current system due to hardware or software incompatibility, 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 continued 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 establishing a database that maintains connections between physiological symptoms, detailed MRI scan information, and possibly associated diagnoses and other patient information is that it only 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 separate focus on intra-graph connections and inter-graph connections, which respectively mean connections within a specific subgraph and connections between different subgraphs.

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

[0158] - Study individual subgraphs that can be extracted from this database. For example, symptom combination hash codes can be used to extract how often individual symptoms typically occur together. A hypergraph can easily be constructed from this, with nodes representing individual symptoms (node ​​"size" indicating how often the symptom typically occurs), and hyperedges between these nodes indicating co-occurrences (edge ​​weights indicating 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 instead of symptoms). Such a reorganization would list different symptoms for each MRI scan combination or for each diagnosed disease (combination), providing new views on 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 may not be a problem for the described architecture.

[0161] - Market backend monitoring: Detailed information about scanner usage in different areas is captured in a structured, easily searchable manner. Automated methods and algorithms can be developed to extract information from the database, which can aid in the development and refinement of sequences and protocols. This can enable protocol acceleration across sequences, for example, by combining contrasts that are often used together into one 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 may occur through one-click feedback optionally given by the radiologist during image review, and having the monitoring algorithm flag sequences in table (A.3) 506 as having unacceptable descriptive rating rates. Furthermore, the AI-enabled algorithm may automatically rate images based on artifacts, noise, and / or other image quality metrics. The resulting ratings of the images may be recorded in a database (A.3) 506 and checked by the monitoring algorithm.

[0163] A big advantage of this strategy of indexing in (A.3) 506 and references in (A.2) 508 is that it allows to extract 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 neuro scans can answer most (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 may be, for example, a group of magnetic resonance imaging acquisitions performed together.

[0165] Figure 8Conceptual illustration of two subgraphs 801, 803 extracted from an envisioned 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., 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 can also be clustered groups of sequences. The dashed lines between the subgraphs represent inter-graph edges 805 with 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 (basically connections between hyperedges from different subgraphs). Clustering algorithms can perform a coarse-grained treatment of subgraphs and inter-graph connections, revealing different information depending on the clustering method.

[0166] Fig. 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 the connection between the closest matching object hyperedge 900 and the configuration hyperedge with a weighting factor. The thick dashed line represents 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, the dimensionality reduction of G3S can provide a new way 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 can understand and implement other variations of the disclosed embodiments by studying the drawings, the present disclosure and the appended claims when practicing the claimed invention. 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 can implement the functions of several items recorded in the claims. The fact that certain measures are recorded only in mutually different dependent claims does not indicate that the combination of these measures cannot bring advantages. The computer program can be stored / distributed on an appropriate medium, such as an optical storage medium or a solid-state medium, which is provided together with other hardware or as part of other hardware, but can also be distributed in other forms, such as via the Internet or other wired or wireless telecommunications systems. Any figure marks in the claims should not be interpreted as limiting the scope. Although the invention has been described with reference to specific embodiments, many variations of these embodiments are contemplated. Therefore, the present invention can be further described without limitation and only by way of example by the following examples. There may be preferred embodiments. Therefore, the term "clause" 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 pulse sequence combinations 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 comprises 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:

[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 weighted data.

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

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

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

[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 host image data frame; and

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

[0191] Clause 8. A medical system according to clause 7, wherein the configuration node encodes 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.

[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 object;

[0194] - deriving (402) at least a portion of said object data from said 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 probe scan data comprises:

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

[0197] - calculating 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 also includes one or more magnetic resonance imaging systems (104, 106, 108), wherein the execution of the machine executable instructions also 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 comprises 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 object data into an atlas database (122), wherein the atlas database is configured to output magnetic resonance imaging pulse sequence configuration data in response to receiving the object data.

[0211] Reference numerals 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 detection scan data describing a subject;

[0251] 402 derives at least a portion of object data from the exploratory 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 object by controlling one or more magnetic resonance imaging systems using the one or more pulse sequences.

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

[0256] 500 Medical Systems

[0257] 502 Magnetic Resonance Imaging 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 Connections between object hyperedges and configuration hyperedges

[0272] 806 Configure Hyperedge

[0273] 900 The 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) said object data; and - receiving (202) the magnetic resonance imaging pulse sequence configuration data in response to inputting the object 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 pulse sequence combinations forming the magnetic resonance imaging pulse sequence configuration data, and The database further comprises a main graph data frame (508), wherein the main graph data frame (508) lists each object hyperedge and a connection to a configuration hyperedge (805), wherein the connection to the configuration hyperedge and the configuration hypergraph node comprises 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 - selecting said magnetic resonance imaging pulse sequence configuration data from the returned configuration hyperedges using at least in part said 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 - Using the object hash number, searching the main graph data frame for the closest matching object hyperedge.

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: 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 said host image data frame; and - using the weighted data and the calculated distance in combination with the magnetic resonance imaging pulse sequence configuration data, selecting the magnetic resonance imaging pulse sequence configuration data from the returned configuration hyperedges.

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 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.

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 detection scan data (334) describing the object; - deriving (402) at least a portion of said object data from said 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 said scout scan data using an automatic segmentation module; and - calculating said at least part of said object data using said 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 detection image data into the image classification machine learning module; and - providing said image classification as said at least part of said object data.

10. 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 (404) a selection of a magnetic resonance imaging system; - 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.

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 comprises 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 pulse sequence combinations forming the magnetic resonance imaging pulse sequence configuration data, and The database further comprises a main graph data frame (508), wherein the main graph data frame (508) lists each object hyperedge and a connection to a configuration hyperedge (805), wherein the connection to the configuration hyperedge and the configuration hypergraph node comprises 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 - selecting said magnetic resonance imaging pulse sequence configuration data from the returned configuration hyperedges using at least in part said 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 pulse sequence combinations forming the magnetic resonance imaging pulse sequence configuration data, and The database further comprises a main graph data frame (508), wherein the main graph data frame (508) lists each object hyperedge and a connection to a configuration hyperedge (805), wherein the connection to the configuration hyperedge and the configuration hypergraph node comprises 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 - selecting said magnetic resonance imaging pulse sequence configuration data from the returned configuration hyperedges using at least in part said weighted data.

Images