Method and system for a new data storage and management method for medical imaging solutions

Abstract

A system and method for a new data storage and management scheme for medical imaging solutions is provided. A medical data storage and management process may be applied to a medical dataset, the process including at least a separation process and a recovery process. The separation process identifies blob data elements in the medical dataset, moves data of the identified blob data elements to corresponding separated data objects, and generates data indicating the movement of the data of the identified blob data elements and for tracking the location of the moved data. The recovery process identifies removed blob data elements in the separated medical dataset, moves data of the identified removed blob data elements to corresponding separated data objects, and for each identified removed blob data element, determines a location of the corresponding separated data object based on the corresponding separation data, and retrieves data of the removed blob data element based on the determined location.

Description

Technical Field

[0001] Aspects of the present disclosure relate to medical imaging solutions. More specifically, certain embodiments relate to methods and systems for a new data storage and management approach for medical imaging solutions.

Background Art

[0002] A variety of medical imaging techniques can be used, such as imaging of organs and soft tissues within the human body. Examples of medical imaging techniques include ultrasound imaging, computed tomography (CT) scans, magnetic resonance imaging (MRI), and the like. The method by which an image is generated during medical imaging depends on the particular technique.

Prior Art Documents

Patent Documents

[0003] U.S. Patent Application Publication No. 2012 / 0060035

[0004] For example, ultrasound imaging uses real-time, non-invasive, high-frequency sound waves to typically generate ultrasound images of organs, tissues, and objects (e.g., a fetus) inside the human body. Images generated or being generated during medical imaging may be two-dimensional (2D) images, three-dimensional (3D) images, and / or four-dimensional (4D) images (essentially real-time / continuous 3D images). During medical imaging, an imaging data set (including, for example, a volume imaging data set during 3D / 4D imaging) is acquired and used to generate and render the corresponding image in real-time (e.g., via a display).

[0005] In some cases, there may be a need to store the imaging data generated during medical imaging. Such storage of imaging data can pose certain challenges, particularly with respect to the use of resources in one or more medical imaging systems where this imaging data is used.

[0006] Further limitations and disadvantages of the prior art and prior approaches will become apparent to those skilled in the art through comparison of such systems with some aspects of the present disclosure, as described in the remainder of the present application with reference to the drawings. SUMMARY OF THE INVENTION

[0007] There is provided a system and method for a new data storage and management scheme for medical imaging solutions, substantially as more fully defined by the claims, shown in at least one figure and / or described in relation to at least one figure.

[0008] These and other advantages, aspects, and novel features of the present disclosure, as well as details of one or more illustrated exemplary embodiments thereof, will be more fully understood from the following description and the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0009]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Best Mode for Carrying Out the Invention

[0010] Certain embodiments in accordance with the present disclosure may be directed to new data storage and management schemes for medical imaging solutions. In particular, the following detailed description of certain embodiments will be better understood when read in conjunction with the accompanying drawings. To the extent that the figures show diagrams of functional blocks of various embodiments, the functional blocks do not necessarily represent a partitioning between hardware circuits. Thus, for example, one or more of the functional blocks (e.g., a processor or memory) may be implemented in a single piece of hardware (e.g., a general-purpose signal processor or a block of random access memory, a hard disk, etc.) or multiple pieces of hardware. Similarly, a program may be a stand-alone program, may be incorporated as a subroutine of an operating system, or may be a function of an installed software package, etc. It should be understood that the various embodiments are not limited to the arrangements and apparatus shown in the drawings. Also, embodiments may be combined, other embodiments may be utilized, and structural, logical, and electrical changes may be made without departing from the scope of the various embodiments. Thus, the following detailed description is not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims and their equivalents.

[0011] As used herein, an element or step recited in the singular and preceded by the word "a" or "an" should be understood to exclude the plural of the element or step unless such exclusion is explicitly recited. Further, references to "exemplary embodiments", "various embodiments", "certain embodiments", "representative embodiments", etc. are not intended to be construed as excluding the existence of additional embodiments that also incorporate the recited features. Further, embodiments "comprising", "including", or "having" an element or elements with a particular characteristic may include additional elements that do not have that characteristic, unless expressly stated to the contrary.

[0012] Also, as used herein, the term "image:image" broadly refers to both a displayable image and the data representing the displayable image. However, many embodiments generate (or are configured to generate) at least one viewable image. Further, as used herein, the term "image" is used in B-mode (2D mode), M-mode, three-dimensional (3D) mode, CF mode, PW Doppler, CW Doppler, MGD, and / or ShearWaveElasticityImaging (SWEI), TVI, Angio, B-flow, BMI, BMI_Angio, which are sub-modes of B-mode and / or CF, and in some cases MM, CM, TVD, etc.

[0013] Further, as used herein, the term "pixel" also includes embodiments in which the data is represented by "voxels". Thus, the terms "pixel" and "voxel" can be used interchangeably throughout this specification.

[0014] Further, the term processor or processing unit as used herein refers to any type of processing unit capable of performing the calculations required for various embodiments, such as single-core or multi-core, and includes a CPU, APU (Accelerated Processing Unit), graphics board, DSP, FPGA, ASIC, or combinations thereof.

[0015] Note that the various embodiments described herein for generating or forming an image may include beamforming in some embodiments and may include processing for forming an image without beamforming in other embodiments. For example, an image can be formed without performing beamforming, such as by multiplying a matrix of coefficients by a matrix of demodulated data so that the product is the image, in which case the processing does not form any "beams:beams". Further, the formation of an image can be performed using a combination of channels (e.g., synthetic aperture techniques) from multiple transmission events.

[0016] In various embodiments, the processing for forming an image including beamforming is performed by software, firmware, hardware, or a combination thereof. As shown in FIG. 2, one exemplary embodiment of an ultrasonic system having a software beamforming architecture formed in accordance with various embodiments is shown.

[0017] FIG. 1 shows an exemplary medical imaging processing arrangement that may be configured to assist in using a histogram view to improve visualization of three-dimensional (3D) medical imaging. Shown in FIG. 1 is an exemplary setup 100 that includes one or more medical imaging systems 110 and one or more computing systems 120.

[0018] The medical imaging system 110 is composed of suitable hardware, software, or a combination thereof for assisting in medical imaging (i.e., for enabling the acquisition of data used in generating and / or rendering images during a medical imaging examination). Examples of medical imaging include ultrasonic imaging, computed tomography (CT) scans, magnetic resonance imaging (MRI), and the like. This may, in certain aspects, involve the capture of specific types of data, which may be used in generating data for an image. For example, the medical imaging system 110 may be an ultrasonic imaging system configured to generate and / or render ultrasonic images. An example of an ultrasonic system that may correspond to the medical imaging system 110 will be described in more detail with respect to FIG. 2.

[0019] As shown in FIG. 1, the medical imaging system 110 may be composed of a portable and movable scanner device 112 and a display / control unit 114. The scanner device 112 may be configured to generate and / or capture a specific type of imaging signal (and / or corresponding data) by being moved over a patient's body (or a part thereof), and may be configured to include appropriate circuitry for performing and / or supporting such functions. The scanner device 112 may be an ultrasonic probe, an MRI scanner, a CT scanner, or any appropriate imaging device. For example, when the medical imaging system 110 is an ultrasonic system, the scanner device 112 can emit ultrasonic signals and capture echo ultrasonic images.

[0020] The display / control unit 114 may be configured to display an image (e.g., via the screen 116). In some embodiments, the display / control unit 114 may further be configured to at least partially generate the displayed image. Further, the display / control unit 114 can also support user input / output. For example, in addition to the image, the display / control unit 114 may provide user feedback (e.g., information related to the system, its functions, its settings, etc.) (e.g., via the screen 116). The display / control unit 114 can also support user input (e.g., via the user control unit 118) to enable control of medical imaging. User input may be directed towards controlling the display of images, selecting settings, specifying user preferences, requesting feedback, etc.

[0021] In some embodiments, the medical imaging system 110 may also incorporate additional and dedicated computing resources, such as one or more computing systems 120. In this regard, each computing system 120 may include appropriate circuitry, interfaces, logic, and / or code for processing, storing, and / or communicating data. The computing system 120 may be a dedicated device specifically configured for use with medical imaging, or it may be a general-purpose computing system (e.g., a personal computer, a server, etc.) that is set up and / or configured to perform the operations described below with respect to the computing system 120. The computing system 120 may be configured to support the operation of the medical imaging processing system 110 as described below. In this regard, various functions and / or operations may be offloaded from the imaging system. This may be done to reduce costs by rationalizing and / or centralizing certain aspects of processing and, for example, avoiding the need to increase processing resources in an image processing system.

[0022] Computing system 120 can be configured and / or arranged for use in another way. For example, in some embodiments, a single computing system 120 can be used. In other embodiments, multiple computing systems 120 are configured to operate together (e.g., based on a distributed processing configuration), or separately, where each computing system 120 is configured to process a particular aspect and / or function and / or is configured to process only data for a particular medical imaging processing system 110. Further, in some embodiments, computing system 120 may be local (e.g., co-located with one or more medical imaging processing systems 110, such as within the same facility and / or within the same local network), and in other embodiments, computing system 120 may be remote and thus can only be accessed via a remote connection (e.g., via the Internet or other available remote access techniques). In certain embodiments, computing system 120 may be configured in a cloud-based manner and may be accessed and / or used in substantially the same way as other cloud-based systems are accessed and used.

[0023] Once data is generated and / or configured in computing system 120, the data can be copied and / or loaded to medical imaging system 110. This can be done in a variety of ways. For example, the data may be loaded via directed connections or links between medical imaging system 110 and computing system 120. In this regard, communication between different elements within setup 100 may be performed using available wired and / or wireless connections and / or in accordance with any suitable communication (and / or networking) standards or protocols. Alternatively, or additionally, the data may be indirectly loaded to medical imaging processing system 110. For example, the data may be stored on a suitable machine-readable medium (e.g., a flash card, etc.), and this medium may then be used (by a user of the system (e.g., imaging clinicians) or an authorized person) to load the data to medical imaging processing system 110, or the data may be downloaded to a locally communicable electronic device (e.g., a laptop, etc.), and this electronic device may then be used on-site (by a user of the system or an authorized person) to upload the data to medical imaging system 110 via a direct connection (e.g., a USB connector, etc.).

[0024] During operation, medical imaging processing system 110 can be used for the generation and presentation (e.g., rendering or display) of images during a medical examination and / or for supporting associated user input / output. The images may be 2D, 3D, and / or 4D images. The specific operations or functions performed in medical imaging system 110 to facilitate the generation and / or presentation of the images depend on the type of system - i.e., the way in which the data corresponding to the images is acquired and / or generated. For example, in ultrasonic imaging, the data is based on emitted ultrasonic signals and echo ultrasonic signals, as described in more detail with respect to FIG. 2.

[0025] In accordance with the present disclosure, a medical imaging system (e.g., medical imaging system 110) may be configured to support a new data storage and management scheme for medical imaging solutions. In this regard, medical data, particularly diagnostic image data, may be archived as "data blobs" in a multi - tier hierarchical storage system, and small records of metadata for each of the data blobs may be stored in a relational database (hereinafter referred to as an "index"). The metadata record may include the file path where the corresponding data blob is located. Such a scheme is adopted in various medical data archiving systems, vendor neutral archives (VNA), picture archiving and communication systems (PACS), etc. However, when using existing data storage schemes and solutions based thereon, various issues and problems may arise.

[0026] In this regard, the total amount of medical data is steadily (and even exponentially) increasing, especially with various advanced medical examinations and image processing. Such an increase poses special challenges to conventional one or more data storage schemes. This is particularly a problem due to the inefficiencies inherent in conventional one or more data storage schemes. For example, data access is supported at the level of the entire data blob, even though in many workloads only partial content may be required and / or may not be requested. Further, if a part of the internal information is changed, it may be necessary to rewrite the entire data blob. Additionally, although the entire data blob may be processed by the same storage mechanism, if the internal fragmentation is different, a more efficient mechanism may be different.

[0027] Thus, in various embodiments according to the present disclosure, a modified data storage scheme can be used to improve access to and use of medical data, particularly data archived as data blobs. In particular, according to the new data storage method, the entire data blob can be separated into a metadata portion and a blob data portion. In this regard, as described above, conventional one or more data storage methods may typically rely on an indexed database to access the metadata of the stored data objects, may be limited by the index content for metadata access, and may also suffer from performance drawbacks when a large amount of metadata fetches (and / or data updates based thereon) are required.

[0028] However, the proposed data scheme addresses such problems by, in particular, separating medical data objects into a metadata portion and a blob data portion, and further by mutually referring to them bidirectionally with a clearly defined standard format and high data integrity protection. This enables separation of the metadata workload and the blob data workload in a data storage / management system, optimization of resource utilization, a dramatic improvement in operational performance, and realization of a flexible system architecture. Furthermore, a new application programming interface (API) can also be used to separately access the metadata and the blob data. Additionally, rich metadata information can be provided to the application without updating the data indexing method. An implementation example based on Digital Imaging and Communications in Medicine (DICOM) is shown in the figures and will be described with reference to the figures. Description will be made with reference to FIGS. 3 and 4. However, it should be understood that the present disclosure is not limited to implementations based on DICOM.

[0029] Figure 2 shows an exemplary ultrasound system that may be configured to assist in utilizing histogram views to improve the visualization of three-dimensional (3D) medical imaging. Shown in Figure 2 is an ultrasound system 200.

[0030] The ultrasound system 200 may be configured to provide ultrasound imaging and, as such, may be composed of suitable circuitry, interfaces, logic, and / or code for performing and / or assisting in ultrasound imaging-related functions. The ultrasound system 200 may correspond to the medical imaging system 110 of Figure 1. The ultrasound system 200 includes, for example, a transmitter 202, an ultrasound probe 204, a transmit beamformer 210, a receiver 218, a receive beamformer 220, an RF processor 224, an RF / IQ buffer 226, a user input module 230, a signal processor 240, an image buffer 250, a display system 260, an archive 270, and a training engine 280.

[0031] The transmitter 202 may be composed of suitable circuitry, interfaces, logic, and / or code operable to drive the ultrasound probe 204. The ultrasound probe 204 may be composed of a two-dimensional (2D) array of piezoelectric elements. The ultrasound probe 204 may typically be composed of a transmit transducer element 206 and a receive transducer element 208 that make up the same elements. In certain embodiments, the ultrasound probe 204 may be operable to acquire ultrasound image data covering at least a substantial portion of an anatomy such as the heart, blood vessels, or any suitable anatomical structure.

[0032] The transmit beamformer 210 can be composed of appropriate circuits, interfaces, logics, and / or codes operable to control a transmitter 202 that drives a group of transmit transducer elements 206 to emit an ultrasonic transmission signal to a region of interest (e.g., a human, an animal, an underground cavity, a physical structure, etc.) via a transmit sub-aperture beamformer 214. The transmitted ultrasonic signal can be backscattered from structures within the object of interest such as blood cells and tissues to generate an echo. This echo is received by the receive transducer elements 208.

[0033] A group of receive transducer elements 208 within the ultrasonic probe 204 can be operable to convert the received echo into an analog signal, undergo sub-aperture beamforming by a receive sub-aperture beamformer 216, and then be communicated to a receiver 218. The receiver 218 can be composed of appropriate circuits, interfaces, logics, and / or codes operable to receive a signal from the receive sub-aperture beamformer 216. The analog signal is transmitted to one or more of a plurality of A / D converters 222.

[0034] The plurality of A / D converters 222 can be composed of appropriate circuits, interfaces, logics, and / or codes operable to convert the analog signal from the receiver 218 into a corresponding digital signal. The plurality of A / D converters 222 are disposed between the receiver 218 and the RF processor 224. However, the present disclosure is not limited in this regard. Thus, in some embodiments, the plurality of A / D converters 222 may be integrated within the receiver 218.

[0035] The RF processor 224 can be composed of suitable circuitry, interfaces, logic, and / or code operable to demodulate the digital signals output by the plurality of A / D converters 222. According to one embodiment, the RF processor 224 may include a complex demodulator (not shown) operable to demodulate the digital signals to form I / Q data pairs representative of corresponding echo signals. The RF or I / Q signal data can then be communicated to the RF / IQ buffer 226. The RF / IQ buffer 226 can be composed of suitable circuitry, interfaces, logic, and / or code operable to provide temporary storage of the RF or I / Q signal data generated by the RF processor 224.

[0036] The receive beamformer 220 can be composed of suitable circuitry, interfaces, logic, and / or code operable to execute digital beamforming processing to sum the delayed channel signals received from the RF processor 224, for example, via the RF / IQ buffer 226, and output a beam sum signal. The resulting processed information may be a beam summed signal output from the receive beamformer 220 and communicated to the signal processor 240. According to some embodiments, the receiver 218, the plurality of A / D converters 222, the RF processor 224, and the beamformer 220 may be integrated into a single beamformer, which may be digital. In various embodiments, the ultrasonic system 200 includes a plurality of receive beamformers 220.

[0037] The user input device 230 can be used for entering patient data, scan parameters, settings, selecting protocols and / or templates, interacting with an artificial intelligence segmentation processor for selecting tracking targets, etc. In an exemplary embodiment, the user input device 230 may be operable to configure, manage, and / or control the operation of one or more components and / or modules within the ultrasonic system 200. In this regard, the user input device 230 may be operable to configure, manage, and / or control the operation of the transmitter 202, the ultrasonic probe 204, the transmit beamformer 210, the receiver 218, the receive beamformer 220, the RF processor 224, the RF / IQ buffer 226, the user input device 230, the signal processor 240, the image buffer 250, the display system 260, and / or the archive 270.

[0038] For example, the user input device 230 can include one or more buttons, one or more rotary encoders, a touch screen, motion tracking, voice recognition, a mouse device, a keyboard, a camera, and / or any other device capable of receiving one or more user commands. In certain embodiments, one or more of the user input devices 230 may be integrated into other components, such as, for example, the display system 260 or the ultrasonic probe 204.

[0039] As an example, the user input device 230 can include a touch screen display. As another example, the user input device 230 can include an accelerometer, gyroscope, and / or magnetometer attached to and / or integrated with the probe 204 to provide gesture motion recognition of the probe 204 for identifying, for example, the pressing of one or more probes against the patient's body, predefined probe movement or tilting operations, etc. In some embodiments, the user input device 230 can alternatively or additionally include image analysis processing for identifying probe gestures by analyzing the acquired image data. In accordance with the present disclosure, the user input and related functions may be configured to support the use of a new data storage method as described in the present disclosure. For example, the user input device 230 can be configured to receive user input directed to triggering and (optionally) managing the application of a separation process as described herein, and / or to support providing or setting parameters used in performing such a process. Similarly, the user input device 230 can be configured to receive user input directed to triggering and managing (optionally) the application of a recovery process as described herein, and / or to support providing or setting parameters used in performing such a process.

[0040] The signal processor 240 can be composed of suitable circuitry, interfaces, logic, and / or code operable to process ultrasonic scan data (i.e., the summed IQ signal) to generate an ultrasonic image for presentation on the display system 260. The signal processor 240 is operable to perform one or more processing operations on the acquired ultrasonic scan data according to a plurality of selectable ultrasound modalities. In an exemplary embodiment, the signal processor 240 can be operable to perform, among other things, display processing and / or control processing. The acquired ultrasonic scan data may be processed in real time during a scan session in which echo signals are received. Additionally or alternatively, the ultrasonic scan data may be temporarily stored in the RF / IQ buffer 226 during the scan session and processed at less than real time in live or offline operation. In various embodiments, the processed image data can be presented in the display system 260 and / or stored in the archive 270. The archive 270 may be a local archive, a Picture Archiving and Communication System (PACS), or any suitable device for storing images and associated information.

[0041] The signal processor 240 may be one or more central processing units, microprocessors, microcontrollers, and / or the like. The signal processor 240 may be an integrated component or, for example, may be distributed in various locations. The signal processor 240 may be configured to receive input information from the user input device 230 and / or the archive 270, generate an output displayable by the display system 260, and manipulate the output in response to the input information from the user input device 230. The signal processor 240 may be capable of executing, for example, any of one or more of the methods and / or one or more instruction sets discussed herein according to various embodiments.

[0042] The ultrasonic system 200 may be operable to continuously acquire ultrasonic scan data at a frame rate suitable for the imaging situation in question. A typical frame rate is in the range of 20 to 220, although it may be lower or higher. The acquired ultrasonic scan data may be displayed on the display system 260 at a display rate that is the same as, slower than, or faster than the frame rate. The image buffer 250 is included to store processed frames of the acquired ultrasonic scan data that are not scheduled to be immediately displayed. Preferably, the image buffer 250 has a capacity sufficient to store frames of ultrasonic scan data for at least several minutes. The frames of ultrasonic scan data are stored in a manner that facilitates their retrieval according to their order or acquisition time. The image buffer 250 can be embodied as any known data storage medium.

[0043] In an exemplary embodiment, the signal processor 240 may include a data management module 242, which may be configured to perform and / or support various functions or operations related to or assisting in new data storage and management schemes for medical imaging solutions as described in this disclosure, and may include appropriate circuitry, interfaces, logic, and / or code.

[0044] In some implementations, the signal processor 240 (and / or its components such as the data management module 242) may be configured to implement and / or use artificial intelligence and / or machine learning techniques to enhance and / or optimize imaging-related functions or operations. For example, the signal processor 240 (and / or its components such as the data management module 242) may be configured to implement and / or use deep learning techniques and / or algorithms, such as the use of a deep neural network (e.g., a convolutional neural network (CNN)), and / or may utilize any suitable form of artificial intelligence image analysis technology or machine learning processing function configured to analyze the acquired ultrasonic images, such as identifying, segmenting, labeling, and tracking a structure (or its organization) that meets certain criteria and / or has certain characteristics.

[0045] In an exemplary implementation, the signal processor 240 (and / or its components such as the data management module 242) may be provided as a deep neural network that can be composed of, for example, an input layer, an output layer, and one or more hidden layers between the input layer and the output layer. Each layer may be composed of a plurality of processing nodes called neurons. For example, the deep neural network includes an input layer having neurons corresponding to each pixel or group of pixels from the scan plane of the anatomical structure, and the output layer has neurons corresponding to a plurality of predefined types of structures or structures (or one or more tissues therein). Each neuron in each layer can execute a processing function and pass the processed ultrasonic image information to one of a plurality of neurons in the downstream layer for further processing.

[0046] As an example, the neurons in the first layer can be trained to recognize the edges of structures in the ultrasonic image data. The neurons in the second layer can be trained to recognize shapes based on the edges detected from the first layer. The neurons in the third layer can learn the positions of the recognized shapes relative to the landmarks in the ultrasonic image data. The neurons in the fourth layer may learn features such as specific tissue types present in specific structures. Thus, the processing performed by a deep neural network (e.g., a convolutional neural network (CNN)) may be able to identify biological and / or artificial structures within the ultrasonic image data with a high probability.

[0047] In some implementations, the signal processor 240 (and / or its components such as the data management module 242) can be configured to execute or otherwise control at least some of the functions thereby performed based on user instructions via the user input device 230. As an example, the user can issue specific instructions such as providing voice commands, probe gestures, button presses, etc. to initiate and / or control various aspects of a new data management scheme including AI-based operations as described in this disclosure, and / or to provide or otherwise specify various parameters or settings related thereto.

[0048] The training engine 280 may include appropriate circuitry, interfaces, logic, and / or code operable to train the neurons of one or more deep neural networks of the signal processor 240 (and / or its components such as the data management module 242). For example, the signal processor 240 may be trained to identify specific structures and / or tissues (or types thereof) provided within the ultrasonic scan plane, and the training engine 280 may train its one or more deep neural networks to perform some of the necessary functions such as using one or more databases of classified ultrasonic images of various structures.

[0049] As an example, the training engine 280 can be configured to utilize ultrasonic images of specific structures for training the signal processor 240 (and / or its components such as the data management module 242) with respect to characteristics of specific structures, such as the appearance of edges of one or more specific structures, the appearance of the shape of a structure based on an edge, the position of a shape relative to a landmark within ultrasonic image data, and / or with respect to characteristics of specific tissue (e.g., its softness). In various embodiments, the database of training images can be stored in the archive 270 or any suitable data storage medium. In certain embodiments, the training engine 280 and / or the training image database may be one or more external systems communicatively coupled to the ultrasonic system 200 via a wired or wireless connection.

[0050] In operation, the ultrasonic system 200 can be used to generate ultrasonic images including two-dimensional (2D), three-dimensional (3D), and / or four-dimensional (4D) images. In this regard, the ultrasonic system 200 can be operable to continuously acquire ultrasonic scan data at a specific frame rate suitable for the imaging situation in question. For example, the frame rate may be in the range of 20 to 70, but can be lower or higher. The acquired ultrasonic scan data can be displayed on the display system 260 at a display rate that is the same as, slower than, or faster than the frame rate. The image buffer 250 is included to store processed frames of the acquired ultrasonic scan data that are not intended to be displayed immediately. Preferably, the image buffer 250 has a capacity sufficient to store frames of ultrasonic scan data for at least several seconds. The frames of ultrasonic scan data are stored in a manner that facilitates their retrieval according to their order or acquisition time. The image buffer 250 can be implemented as any known data storage medium.

[0051] In some embodiments, the ultrasonic system 200 may be configured to support grayscale and color-based operations. For example, the signal processor 240 may be operable to perform grayscale B-mode processing and / or color processing. Grayscale B-mode processing may include processing B-mode RF signal data or IQ data pairs. For example, grayscale B-mode processing may enable the formation of an envelope of the beam sum received signal by calculating the quantity (I2+Q2)1 / 2. The envelope can undergo additional B-mode processing, such as logarithmic compression, to form display data.

[0052] The display data can be converted to an X-Y format for video display. The scan-converted frame can be mapped to grayscale for display. The B-mode frame provided to the image buffer 250 and / or the display system 260. Color processing may include processing color-based RF signal data or IQ data pairs to form a frame that overlays on the B-mode frame provided to the image buffer 250 and / or the display system 260. Grayscale and / or color processing may be adaptively adjusted based on user input (e.g., a selection from the user input device 230 for enhancing the grayscale and / or color of a particular region).

[0053] In some embodiments, ultrasonic imaging may include generating and / or displaying volumetric ultrasonic images - that is, an object (e.g., an organ, tissue, etc.: organs, tissues, etc.) is displayed in three dimensions (3D). In this regard, in 3D (and similarly 4D) imaging, a volumetric ultrasonic data set including voxels corresponding to the imaged object may be acquired. This can be done, for example, by transmitting sound waves not simply in one direction (e.g., straight down), but at different angles and capturing the sound waves that reflect back. Next, the reflected echoes (from the transmissions at different angles) are captured and processed (e.g., via signal processor 240) to generate a corresponding volumetric data set, which can be used to create and / or display a volumetric (e.g., 3D) image, such as via display 250. This may involve the use of specific processing techniques to provide the desired 3D perception.

[0054] For example, volume rendering techniques can be used when displaying a projection (e.g., a 2D projection) of a volumetric (e.g., 3D) data set. In this regard, rendering a 2D projection of a 3D data set may involve setting or defining a perception angle in space with respect to the object being displayed and defining or calculating the necessary information (e.g., opacity and color) for all voxels within the data set. This can be done, for example, using an appropriate transfer function for defining the RGBA (red, green, blue, alpha) values of each voxel.

[0055] In various embodiments, the ultrasonic system 200 may be configured to support a new data storage and management scheme for medical imaging solutions as described in this disclosure. For example, when imaging data is acquired or generated, the signal processor 240 (and / or its components such as the data management module 242) may store the processed image in the archive 270, which is independent of the signal processor 240 (and / or its components such as the data management module 242) or under the control of the signal processor 240 (and / or its components such as the data management module 242), apply archive-based encoding (e.g., DICOM-based encoding) to the data, and then apply a separation process as described herein to perform storage and management including executing the communication functions necessary to transmit the resulting data object to the corresponding storage location (local or remote). The archive 270 may also be configured to send back data and may be configured to execute a recovery process including on-the-fly recovery. In this regard, the archive 270 may be configured to execute the communication functions necessary to request and receive the corresponding data object from a storage location (local or remote) and to decode the data to enable generation of the corresponding image, such as display via the display system 260, to apply a recovery process to the previously archived data. These functions may be controlled or managed by the signal processor 240 (and / or its components such as the data management module 242). Alternatively, the archive 270 may be configured to execute at least some of these functions independently, in which case the processor 240 may not know that the data has undergone any separation. In some cases, the processor 240 (and / or its components such as the data management module 242) may process the data according to a scheme (e.g., a scheme configured to separately retrieve metadata and blobs) to further improve response time and throughput.

[0056] Figure 3 shows an exemplary process for metadata separation for use in a new data storage and management scheme for medical imaging solutions. Shown in Figure 3 is a block diagram 300 showing the use of a new data storage and management scheme based on a DICOM (Digital Imaging and Communications in Medicine)-based data structure.

[0057] In this regard, the new data storage scheme is applicable to many types of medical data (e.g., images, waveforms, clinical observations, etc.: images, waveforms, clinical observations, etc.), which can be modeled as a collection of attributes so as to represent the captured examination, measurement, observation, and monitoring data and their subjects and clinical context. However, Figure 3 shows an example of the application of the new data storage scheme to a DICOM Service Object Pair (SOP) instance to explain how the new data storage scheme functions.

[0058] As shown in FIG. 3, according to the new data storage method, the DICOM-based data blob can be separated into a metadata part and a blob data part. In this regard, although the DICOM header and pixel data may be split in some existing solutions, especially as an internal storage format, the separation applied to the data blob according to the new data storage scheme involves more. In particular, according to the new data storage method using open industry standards, all data files are structured according to the standard format, and thus can be verified independently and linked together, such as by using Uniform Resource Identifiers (URIs) like Uniform Resource Locators (URLs). This leads to a significant improvement in the integrity and resilience of high-level data, flexibility in data management and storage, performance improvement, and productivity improvement. The following text will describe some possible new use cases.

[0059] Regarding separating the data blob into metadata and blob data parts, at the top level, instead of treating the DICOM SOP instance as a whole data blob, the image pixel data (and other binary data if desired) and other large-sized tags (both standard and private tags) can be removed and saved in separate data files. The resulting object will be referred to below as DICOM SOP instance metadata. Thus, each DICOM SOP instance is split into one metadata object (denoted as “D(meta)”) and zero to N blob data objects, and the data can be image pixel data or other binary large-sized data tag contents (denoted as “D(blob)”).

[0060] Separation processes, and the objects generated based thereon, may have various useful properties that enable more efficient and / or other new data management and archiving paradigms. Such properties include, for example, the following. 1) D(meta) may contain subject information and clinical context information regarding D(blob), and most consumer applications typically need to access D(meta) first before determining whether the blob data is needed. 2) D(meta) and D(blob) may have different properties in terms of data management and access availability. For example, D(meta) may be subject to modification (e.g., subject information reconciliation, study / series structure re-organization), and a very fast response to access may be required, while D(blob) may be completely immutable, and high throughput may be emphasized for access. 3) D(meta) may be complete protected health information (PHI) data, and thus may be highly confidential information. However, this does not necessarily imply that these objects are not PHI, rather, the level of confidentiality may vary, which may be an important consideration especially in hybrid cloud, distributed storage infrastructures. 4) The size of D(meta) (e.g., in megabytes (MB)) may be dramatically smaller than the size of D(blob). For example, the size ratio of D(meta) to D(blob) is 100 or more. In a separation scheme, such properties can be utilized to optimize access performance, storage efficiency, and high security standards without trade-offs.

[0061] An example of the metadata separation process is shown in FIG. 3, where binary standard tags (e.g., pixel data) and large-sized private tag values are removed from the original DICOM SOP instance 310 and saved in a separate binary data file. The specific data structure and the URI link based thereon are also illustrated and will be further described with reference to FIG. 3 (especially the right side).

[0062] D(blob) can be composed of pixel data or other binary data. In the case of pixel data, whether it is a single frame or a multi-frame, D(blob) can be encoded as a continuous list of frames in a binary data file. For example, D(blob) is encoded in the following format: 1) file signature, 2) unique identifier (UID) indicating the SOP instance UID to which this blob data file belongs, 3) offset table of each image frame relative to the end of the table, continuously stored in the file, 4) image frames stored frame by frame in the same order as encoded in the original SOP instance, 5) image frame data stored in a compressed byte stream (e.g., JPEG File Interchange Format (JFIF)) in the same format as the original SOP instance. The compressed frame byte stream has an even byte length required by the DICOM sequence item. Therefore, padding bytes may be included. By saving the JFIF stream, one more data integrity check is added. Other (general) binary blob D(blob) may be stored in a binary file of the same byte stream as in the original SOP instance. For example, in such a case, D(blob) is encoded in the following format: 1) file signature, 2) UID representing the SOP instance UID to which this blob data file belongs, 3) byte stream of binary blob data encoded in the metadata context. Therefore, D(blob) may be a valid DICOM encoded stream that can be decoded by applying the transfer syntax of the original SOP instance. In an implementation of an example, the file signature is 4 bytes, the unique identifier (UID) is 64 bytes, the offset table is (N + 1) 4-byte integers, the first integer value represents the length of the table, and then the offsets of each image frame relative to the end of the table are continuously stored in the file.

[0063] D(meta) may be encoded in a DICOM Part 10 file, but may also be modified slightly. For example, D(meta) is encoded as follows. 1) Replace the pixel tag with a pixel data provider tag, including a URI (e.g., a URL) pointing to a D(blob) file. 2) Delete the values (data) of all large-sized blob data elements stored in the binary blob file (thus, one or more D(blob) files are created). In an implementation example, the file signature is 4 bytes and the unique identifier (UID) is 64 bytes.

[0064] Restoring the original DICOM SOP instance can be achieved simply by performing the reverse operation of the separation process. Such a restoration process is shown in FIG. 4 and will be described in more detail with respect to FIG. 4.

[0065] FIG. 4 shows an exemplary usage scenario for deriving an imaging study metadata document from a metadata object. Shown in FIG. 4 is a block diagram 400 showing a usage scenario based on the implementation of a new data storage and management scheme.

[0066] By using the new data storage and management scheme and the data structure generated based on it, it may be possible to perform various functions that are not possible or not available in existing solutions. For example, various functions can be enabled based only on the metadata workload without accessing the blob data object at all. For example, an image examination metadata document can be derived from the metadata object of an individual DICOM SOP instance of the examination to provide one-stop shopping for a viewer application, as shown in FIG. 4.

[0067] In this regard, restoring the original DICOM SOP instance may simply be the reverse operation of the separation process. In particular, a high level of data protection can be achieved by the signed signature. For example, based on the security policy, requirements, and available infrastructure, additional security means including a blockchain-based ledger can be used to protect all of D(meta) and D(blob). For example, it may be possible to reconstruct DICOM SOP instances with or without large-sized blob data elements in order to optimize network traffic and data throughput based on a specific access profile configuration. The bidirectional link between D(meta) and D(blob) further enhances the integrity of the data.

[0068] Viewer applications (e.g., in systems used to analyze the results of medical imaging diagnoses) can use the image diagnosis study metadata document to plan the presentation of DICOM SOP instances without performing expensive, multiple queries to the index database. The new storage and management scheme and the separation process based thereon may enable numerous new use cases. Examples of such use cases include the separation of the metadata workload and the blob data workload for system performance, flexible storage architectures for metadata and blob data, and data protection and security implementation for metadata and blob data.

[0069] In an example of separating the metadata workload and the blob data workload for use cases based on system performance, the standard DICOM API may be supported by reassembling D(meta) and D(blob) into the original DICOM SOP instance. An API (e.g., DICOM Web) may be provided to enable separate access to the metadata and the blob data, which allows for much faster access to the metadata even when all images of a large-scale study are searched, while the image pixel data may be accessed on demand. The data management function can modify D(meta) directly, rather than modifying the indexed metadata in the database and later applying the modifications to the DICOM SOP instance. The metadata object can be loaded into a data lake / document query processing engine for data discovery. After the target collection of the data object is found, the blob data can be seamlessly retrieved using the URI in the metadata.

[0070] In an example of a flexible storage architecture for metadata and blob data, the metadata can be stored independently of the use case of the blob database. The metadata can be stored independently from the use case of the blob database. If the user desires to do so, the metadata is managed on-premises, while the immutable pixel data can be moved to cloud-based storage. This allows the user to reduce computer and storage resources while tightly managing the contextual data (metadata), while the (mostly) context-free data (blob data) can utilize cloud storage. More efficient mass data access and export. For example, for research or AI model training, an archive can be set up with anonymized metadata and the immutable blob data, which is managed in a store separate from the operational archive, can be shared. The metadata is placed at the edge (and may be replicated), and the blob data is archived in deep storage, achieving both response time and throughput goals.

[0071] In an exemplary data protection and security implementation for use cases based on metadata and blob data, the metadata and blob data can be handled with different security measures that best meet the underlying storage mechanism and business needs. For example, blob data archived in the public cloud may be audited and traced with a blockchain ledger, and user-selected keys may be used to encrypt the metadata in the user's own data center.

[0072] FIG. 5 shows an example use scenario of the separation of data into blob objects and metadata objects based on DICOM (Digital Imaging and Communications in Medicine). Shown in FIG. 5 is a block diagram 500 showing an example of the separation of a DICOM data set 510.

[0073] The DICOM data set 510 may be composed of a collection of data elements. As a result of the application of a separate process as described herein, a common metadata object 520 (e.g., D(meta) as described with respect to FIG. 3) and separated blob data 530 may be generated. In this regard, the separated blob data 530 may be composed of one or more blob data objects including binary data and media data, and an offset table, as described above.

[0074] For separation, a threshold value may be defined to determine blob elements (labeled "other blob" in FIG. 5), and the data values thereof may be moved to another blob data file or object. The blob elements remain in the metadata, but their values may be set to NULL. To track these elements and provide a link to the corresponding moved blob data values, such as by using a URI, new elements for tracking (labeled "Blob Data URI Sequence") may be added. The pixel data elements may be directly replaced with new elements (labeled "Pixel Data Provider").

[0075] Blob data includes both general-purpose byte streams that are only useful in a metadata context and MIME-type accessible data that is useful independent of a metadata context (such as JPEG). In particular, general-purpose byte streams are only useful in the context of a DICOM data element context. When compressed, the compression format must conform to the DICOM data element context under the specific transfer syntax of the containing data set. MIME-type data may be compressed or plain, based on a media format that conforms to the transfer syntax of the containing data set. Such data is useful independent of the context of DICOM data elements.

[0076] In some cases, blob data (and metadata as well) may be further consolidated into larger blobs for efficiency in storage and management.

[0077] FIG. 6 shows an example usage scenario for separating Integrated Healthcare Enterprise (IHE) Patient Care Device (PCD) Device Enterprise Communication (DEC)-based data into blob and metadata objects. Shown in FIG. 6 is a block diagram 600 showing an example separation of an IHE PCD DEC data set 610.

[0078] The IHE PCD DEC data set 610 can be composed of a collection of data elements. As a result of the application of separate processes as described herein, a common metadata object 620 (e.g., D(meta) as described with respect to FIG. 3) and separated blob data 630 can be generated. In this regard, the separated blob data 630 can be composed of one or more blob data objects, including binary blob data, media blob data, protocol blob data, and an offset table, as described above.

[0079] Separation can be applied in substantially the same manner as described with respect to FIG. 5. In this regard, the binary blob data and pixel blob data may be substantially similar to the same blob data as described with respect to FIG. 5. A third type of blob data is added in the separation process applied to the IHE PCD DEC dataset 610, i.e., it is only useful in the metadata context and is protocol blob data consisting of data blocks formatted in an application protocol (e.g., data segments formatted in HL7 (Health Level Seven)) that are parsed according to the underlying application protocol. Such datasets according to standard protocols may be inserted directly into the containing protocol dataset or compressed with general-purpose tools.

[0080] In some cases, the blob data (and also the metadata) may be further integrated into larger blobs for storage and management efficiency.

[0081] FIG. 7 shows an example of an encoded dataset based on DICOM (Digital Imaging and Communications in Medicine). Shown in FIG. 7 is the DICOM dataset 700.

[0082] The DICOM dataset 700 is a collection of data elements. Each data element is composed of and / or can be specified by fields such as a tag, a value type (VR: value type), a value length, and a value. When the value type (VR) of a data element is "SQ" (indicating a sequence), that data element contains multiple items. In this regard, each item with a start and an end is actually a normal DICOM dataset and is composed in order from a set of data elements. As shown in FIG. 7, the data elements within the items of a sequence (at one level) may also be SQ, which may contain several items (at the next level).

[0083] FIG. 8 is a diagram showing an example of a DICOM (Digital Imaging and Communications in Medicine)-based encoded data set after separating blob data into blob objects and metadata objects. Shown in FIG. 8 is a DICOM data set 800 after application of the separation process according to the present disclosure. In this regard, the DICOM data set 800 may be the same as the DICOM data set 700 of FIG. 7 before application of the separation process. The separation process may be applied as described above with particular reference to FIGS. 3 and 5.

[0084] As shown in FIG. 8, after application of the separation process, all identified blob data elements remain in the data set, but the respective value fields of these blob data elements may be set to NULL. Further, in order to reflect the change in value, the length of each value of these blob data elements may be set to "0". However, the tag and value type (VR) fields, and the positions of the blob data elements within the data set remain unchanged. The binary values of the blob data elements may be stored in a separated file that can be retrieved via a uniform resource identifier (URI), such as a uniform resource locator (URL). A new sequence element (denoted as "blob data URL sequence") is added to track the NULL-valued blob elements and the location of their actual values. For example, the blob data URL sequence consists of a list of elements, each containing two fields: a "tag path" field for tracking the position of a specific NULL-valued blob element within the data set, and a URI pointing to the location where the actual value of the NULL-valued blob element is stored. The pixel data element is also replaced with a pixel data provider URI as described above.

[0085] FIG. 9 shows a flowchart of an example of a separation and recovery process based on a new data storage and management method according to the present disclosure.

[0086] Shown in FIG. 9 are flowcharts 900 and 950, each comprising a plurality of exemplary steps (represented as blocks 902-912 and 952-962) that can be executed in a suitable system (e.g., the medical imaging system 110 and / or the computing system 120 of FIG. 1) for separating and retrieving imaging data sets based on a new data storage and management scheme for medical imaging solutions.

[0087] Regarding flowchart 900, in start step 902, the system may be set up and operation may be initiated. In step 904, archive encoding (e.g., DICOM, IHE PCD DEC, etc.) may be applied to the imaging data. In this regard, the imaging data may be generated in the same system or obtained from another system. In step 906, blob elements within the encoded data set may be identified. This may be done, for example, by using a threshold value. The threshold value may be predefined or set or adjusted by an operator. In step 908, based on the identified blob elements, metadata and blob data objects may be generated and / or updated. This may include, for example, moving the values (data) of the identified blob elements to separate blob data objects (including different types in some cases, such as byte blob data, media blob data, protocol blob data, etc.). This step may also include updating the remaining fields within the identified blob data elements (e.g., setting values to NULL, adding links to data objects, etc.), and adding new fields / elements (e.g., blob data Uri sequences, pixel data provider elements, etc.). In step 910, the metadata and blob data objects are stored (locally and / or remotely). In step 912, an offset table may be generated and / or updated.

[0088] Regarding flowchart 950, in start step 952, the system may be set up and operation may be started. In step 954, the required blob elements in the encoded data set are identified. In this regard, in some cases, the entire data set may be required, and thus the values (data) of all blob elements in the data set are required. However, in other embodiments, the data set may be used in a more selective manner, such as when only a part (or a part thereof) of a previously obtained image is required for viewing (or inspection). Thus, only some of the blob elements in the data set may be required and thus recovered. In step 956, the identified blob elements can be processed. This includes evaluating the fields of these blob elements and determining where their values (data) are held (e.g., directly held within the data set or within a data object). For example, if the value is set to NULL, the actual location of the value can be determined, such as by using a URI and / or an offset table. In step 958, the values of the identified blob elements maintained separately from the data set are obtained. This obtaining can be performed using a URI and an offset table. In step 960, the required decoding and decompression are applied. In step 962, imaging data can be generated (reconstructed) based on the values (data) of the data set or a part thereof.

[0089] Exemplary methods according to the present disclosure include applying, by a processor, one or more medical data storage and management-based processes to store and manage medical data (e.g., including medical imaging data). The medical data storage and management-based processes include at least a separation process and a recovery process. This process includes at least a separation process and a recovery process. The separation process includes identifying one or more blob data elements within a medical data set, moving the data of the identified one or more blob data elements to corresponding separated data objects, and generating data for indicating the movement of the data of the identified one or more blob data elements and data for tracking the location of the moved data of the identified one or more blob data elements. The recovery process includes identifying one or more removed blob data elements within a separated medical data set, wherein the data of the identified one or more removed blob data elements is moved to corresponding one or more separated data objects, the step of determining the location of the corresponding separated data object based on the corresponding separated data associated with the separated medical data set for each of the identified one or more removed blob data elements, and searching for the data of the removed blob data element based on the determined location. The medical data set can be configured and / or generated based on medical imaging data obtained during a medical imaging operation.

[0090] In an exemplary embodiment, the separation process further includes generating a data locator element for tracking the moved data, and the data locator element includes mapping data for tracking each of the identified one or more blob data elements and location information for specifying the location of the corresponding moved data.

[0091] In an exemplary embodiment, the separation process further includes the step of updating each of the identified one or more blob data elements, the update including modifying at least one field to indicate that the data of the identified one or more blob data elements has been moved.

[0092] In one example, the separation process further includes the step of generating and inputting a common metadata block that includes information related to a medical data set, the separation process, and the corresponding separated data object.

[0093] In one example, the separation process further includes the step of generating and inputting an offset table for tracking the storage of the separated data object.

[0094] In an exemplary embodiment, the separation process further includes storing at least a portion of the moved data of the separated data object in a different storage location, the different storage location including one or both of a local storage location and a remote storage location.

[0095] In one example, the medical data set includes a DICOM (Digital Imaging and Communications in Medicine)-based data set or a Healthcare Enterprise (IHE) Patient Care Device (PCD) Device Enterprise Communication (DEC)-based data set.

[0096] An exemplary non-transitory computer-readable medium according to the present disclosure includes a computer program having at least one code portion. The at least one code portion is executable by a machine including at least one processor to cause the machine to perform one or more steps for storing and managing medical data (e.g., medical imaging data). The one or more steps for storing and managing include at least a separation process and a recovery process. The separation process includes identifying one or more blob data elements within a medical data set, moving the data of the identified one or more blob data elements to corresponding separated data objects, and generating data for indicating the movement of the data of the identified one or more blob data elements and data for tracking the location of the moved data of the identified one or more blob data elements. The recovery process includes identifying one or more removed blob data elements within a separated medical data set, wherein the data of the identified one or more removed blob data elements is moved to corresponding one or more separated data objects, determining the location of the corresponding separated data object based on the corresponding separated data associated with the separated medical data set for each of the identified one or more removed blob data elements, and searching for the data of the removed blob data element based on the determined location. The medical data set may be configured and / or generated based on medical imaging data obtained during a medical imaging operation.

[0097] This data locator element includes mapping data for tracking each of the identified one or more blob data elements and location information for specifying the location of the corresponding movement data.

[0098] In an exemplary embodiment, the separation process further updates each of the identified one or more blob data elements, and the update includes modifying at least one field to indicate that the data of the identified one or more blob data elements has been moved.

[0099] In one embodiment, the separation process further includes generating and inputting a common metadata block that includes information related to a medical dataset, the separation process, and the corresponding separated data objects.

[0100] In one embodiment, the separation process further includes generating and inputting an offset table for tracking the storage of separated data objects.

[0101] In one embodiment, the separation process further includes storing at least some of the movement data of the separated data objects in different storage locations, where the different storage locations include one or both of a local storage location and a remote storage location.

[0102] In one embodiment, the medical dataset includes a DICOM (Digital Imaging and Communications in Medicine)-based dataset or a Healthcare Enterprise (IHE) Patient Care Device (PCD) Device Enterprise Communication (DEC)-based dataset.

[0103] An exemplary system according to the present disclosure stores and manages medical data (e.g., including medical imaging data). The system includes at least one processor configured to apply processes based on the storage and management of one or more medical data. The processes based on the storage and management of medical data include at least a separation process and a recovery process. The separation process includes identifying one or more blob data elements within a medical data set, moving the data of the identified one or more blob data elements to corresponding separated data objects, and generating data for indicating the movement of the data of the identified one or more blob data elements and data for tracking the location of the moved data of the identified one or more blob data elements. The recovery process includes identifying one or more removed blob data elements within a separated medical data set, where the data of the identified one or more removed blob data elements is moved to corresponding separated data objects, determining the location of the corresponding separated data object based on the corresponding separated data associated with the separated medical data set for each of the identified one or more removed blob data elements, and searching for the data of the removed blob data element based on the determined location. The medical data set can be configured and / or generated based on medical imaging data obtained during a medical imaging operation.

[0104] In an exemplary embodiment, the separation process further includes generating a data locator element for tracking the moved data, where the data locator element includes mapping data for tracking each of the identified one or more blob data elements and location information for specifying the location of the corresponding moved data.

[0105] In an exemplary embodiment, the separation process further updates each of the identified one or more blob data elements, and the update includes modifying at least one field to indicate that the data of the identified one or more blob data elements has been moved.

[0106] In one example, the separation process further includes generating and inputting a common metadata block that includes information related to the medical data set, the separation process, and the corresponding separated data object.

[0107] In one example, the separation process further includes generating and inputting an offset table for tracking the storage of the separated data object.

[0108] In one example, the separation process further includes storing at least a portion of the movement data of the separated data object in a different storage location, where the different storage location includes one or both of a local storage location and a remote storage location.

[0109] As used herein, the terms "circuits" and "circuitry" refer to physical electronic components (e.g., hardware), and any software and / or firmware ("code") that makes up the hardware, is executed by the hardware, or may otherwise be related to the hardware. As used herein, for example, a particular processor and memory can constitute a first "circuit" when executing a first one or more lines of code, and a second "circuit" when executing a second one or more lines of code. As used herein, "and / or" means any one or more of the items in a list joined by "and / or". As an example, "x and / or y" means any element of the three-element set {(x), (y), (x, y)}. In other words, "x and / or y" means "either or both of x and y". As another example, "x, y, and / or z" means any element of the seven-element set {(x), (y), (z), (x, y), (x, z), (y, z), (x, y, z)}. In other words, "x, y and / or z" means "one or more of x, y and z". As used herein, the terms "block" and "module" refer to functionality that can be performed by one or more circuits. As used herein, the term "exemplary" means serving as a non-limiting example, instance, or illustration. As used herein, the terms "for example" and "e.g." set forth a list of one or more non-limiting examples, instances, or illustrations. As used herein, a circuit is "operable" to perform a function whenever the circuit constitutes the hardware (and code if necessary) necessary to perform the function, regardless of whether the execution of the function is disabled (e.g., by some user-configurable setting, factory trim, etc.) or not enabled.

[0110] Other embodiments of the present invention are non-transitory computer-readable media and / or storage media, and / or non-transitory machine-readable media and / or storage media having at least one code section executable by a machine and / or a computer, with machine code and / or a computer program stored thereon, thereby causing the machine and / or the computer to execute the processes as described herein. A non-transitory machine-readable media and / or storage media can be provided.

[0111] Accordingly, the present disclosure can be implemented in hardware, software, or a combination of hardware and software. The present invention may be implemented in a centralized manner in at least one computing system, or in a distributed manner in which different elements span multiple interconnected computing systems. Any type of computing system or other device adapted to implement the methods described herein is suitable. A typical combination of hardware and software may be a general-purpose computing system having a program or other code that controls the computing system to implement the methods described herein when loaded and executed. Another typical implementation may be in the form of an application-specific integrated circuit or chip.

[0112] Various embodiments in accordance with the present disclosure include all functions enabling the implementation of the methods described herein, and can also be incorporated into a computer program product that can execute these methods when loaded into a computer system. The computer program as used herein means a set of instructions expressed in any language, code, or notation, which is intended to cause a system having information processing capabilities to execute a specific function, either directly or after any one or both of the following: a) conversion into another language, code, or notation; b) reproduction in another physical form.

[0113] Although the present invention has been described with reference to specific embodiments, it will be understood by those skilled in the art that various changes can be made and equivalents can be substituted without departing from the scope of the present invention. Furthermore, many changes can be made to adapt a particular situation or material to the teachings of the present invention without departing from the scope of the present invention. Therefore, the present invention is not intended to be limited to the specific embodiments disclosed, but is intended to cover all embodiments falling within the scope of the appended claims.

Explanation of Reference Numerals

[0114] 100: Setup 110: Medical imaging system 112: Scanner device 114: Display / control unit 116: Screen 118: User control unit 120: Computing system 200: Ultrasonic system 202: Transmitter 204: Ultrasonic probe 206: Transmission transducer element 208: Reception transducer element 210: Transmission beamformer 214: Transmission sub-aperture beamformer 216: Reception sub-aperture beamformer 218: Receiver 220: Reception beamformer 222: A / D converter 224: RF processor 226: RF / IQ buffer 230: User input module 240: Signal processor 242: Data management module 250: Image buffer 260: Display system 270: Archive 280: Training engine 300: Block diagram 310: DICOM SOP instance 510: DICOM dataset 520: Common metadata object 530: Isolated blob data 610: IHE PCD DEC dataset 620: Common metadata object 630: Isolated blob data 700: DICOM dataset 800: DICOM dataset

Claims

1. A method for storing and managing medical data, comprising: a step in which a processor applies one or more processes based on storing and managing medical data, the process based on storing and managing medical data includes at least a separation process and a recovery process, the separation process includes: identifying one or more blob data elements in a medical data set; moving the data of the identified one or more blob data elements to corresponding separated data objects; generating data for indicating the movement of the data of the identified one or more blob data elements and tracking the position of the moved data of the identified one or more blob data elements; and the recovery process includes: identifying one or more deleted blob data elements in a separated medical data set, wherein the data of the identified one or more deleted blob data elements has been moved to corresponding one or more separated data objects; for each of the identified one or more deleted blob data elements, determining the position of the corresponding separated data object based on the corresponding separated data related to the separated medical data set; searching for the data of the deleted blob data element based on the determined position; A method.

2. The method according to claim 1, wherein the separation process further includes a step of generating a data locator element for tracking the moved data, and the data locator element includes mapping data for tracking each of the identified one or more blob data elements and position information for specifying the position of the corresponding moved data.

3. The separation process updates each of the identified one or more blob data elements, and the update includes modifying at least one field indicating that the data of the identified one or more blob data elements has moved. The method according to claim 1.

4. The separation process further includes generating and inputting a common metadata block including information related to the medical data set, the separation process, and the corresponding separated data object. The method according to claim 1.

5. The separation process further includes generating and inputting an offset table for tracking the storage of the separated data object. The method according to claim 1.

6. The separation process further includes storing at least a part of the movement data of the separated data object in a different storage location, and the different storage location includes one or both of a local storage location and a remote storage location. The method according to claim 1.

7. The medical data set includes a DICOM (Digital Imaging and Communications in Medicine)-based data set or an IHE (Healthcare Enterprise) PCD (Patient Care Device) DEC (Device Enterprise Communication)-based data set. The method according to claim 1.

8. A non-transitory computer-readable medium storing a computer program having at least one code portion, the at least one code portion being executable by a machine including at least one processor, and causing the machine to execute one or more steps for storing and managing medical data. including steps of applying one or more processes based on medical data storage and management, wherein the processes based on medical data storage and management include at least a separation process and a recovery process, the separation process includes: identifying one or more blob data elements within a medical data set; moving the data of the identified one or more blob data elements to corresponding separated data objects; generating data for indicating the movement of the data of the identified one or more blob data elements and for tracking the location of the moved data of the identified one or more blob data elements; and including the recovery process includes: identifying one or more deleted blob data elements within a separated medical data set, wherein the data of the identified one or more deleted blob data elements has been moved to corresponding one or more separated data objects; for each of the identified one or more deleted blob data elements determining the location of a corresponding separated data object based on corresponding separated data related to the separated medical data set; searching for the data of the deleted blob data element based on the determined location; and including a non-transitory computer-readable medium.

9. The separation process further includes generating a data locator element for tracking the moved data, wherein the data locator element includes mapping data for tracking each of the identified one or more blob data elements and location information for specifying the location of the corresponding moved data. The non-transitory computer-readable medium according to claim 8.

10. The separation process further updates each of the identified one or more blob data elements, the update including the step of modifying at least one field to indicate that the data of the identified one or more blob data elements has moved, the non-transitory computer-readable medium of claim 8.

11. The separation process further includes the step of generating and inputting a common metadata block including information related to the medical data set, the separation process, and the corresponding separated data object, the non-transitory computer-readable medium of claim 8.

12. The separation process further includes the step of generating and inputting an offset table for tracking the storage of the separated data object, the non-transitory computer-readable medium of claim 8.

13. The separation process further includes the step of storing at least some of the movement data of the separated data object in a different storage location, the different storage location including one or both of a local storage location and a remote storage location, the non-transitory computer-readable medium of claim 8.

14. The medical data set includes a DICOM (Digital Imaging and Communications in Medicine)-based data set or an IHE (Healthcare Enterprise) PCD (Patient Care Device) DEC (Device Enterprise Communication)-based data set, the non-transitory computer-readable medium of claim 8.

15. A system for storing and managing medical data, Including at least one processor configured to apply one or more processes based on medical data storage and management, the processes based on medical data storage and management including at least a separation process and a recovery process, The separation process comprises: identifying one or more blob data elements within a medical dataset; moving the data of the identified one or more blob data elements to corresponding separated data objects; generating data for indicating the movement of the data of the identified one or more blob data elements and for tracking the location of the moved data of the identified one or more blob data elements; and the recovery process comprises: identifying one or more deleted blob data elements within a separated medical dataset, wherein the data of the identified one or more deleted blob data elements has been moved to corresponding one or more separated data objects; for each of the identified one or more deleted blob data elements, identifying the location of the corresponding separated data object based on corresponding separated data associated with the separated medical dataset; searching for the data of the deleted blob data element based on the identified location. A system comprising.

16. The separation process further comprises generating a data locator element for tracking the moved data, the data locator element including mapping data for tracking each of the identified one or more blob data elements and location information for identifying the location of the corresponding moved data. The system according to claim 15.

17. The separation process further comprises updating each of the identified one or more blob data elements, the updating including modifying at least one field indicating that the data of the identified one or more blob data elements has been moved. The system according to claim 15.

18. The system according to claim 15, wherein the separation process further includes the step of generating and inputting a common metadata block including information related to the medical dataset, the separation process, and the corresponding separated data object. **Claim 19** The system according to claim 15, wherein the separation process further includes the step of generating and inputting an offset table for tracking the storage of the separated data object. **Claim 20** The system according to claim 15, wherein the separation process further includes the step of storing movement data of at least a part of the separated data object in a different storage location, and the different storage location includes one or both of a local storage location and a remote storage location.

Images