Communicating medical image data with metadata

Abstract

The proposed concepts are directed to providing schemes, solutions, concepts, designs, methods and systems relating to transmitting, receiving and / or communicating medical imaging data for remote real-time examinations. In particular, a medical image is encoded (120) with an identifier based on at least part of metadata associated with the medical image. As medical images and metadata may have different transmission requirements (i.e., bandwidth, latency, loss, etc.), they are communicated over different communication channels (130, 140). In this way, the medical image and the metadata may be delivered appropriately, while the identifier enables the medical image and the metadata to match at the recipient.

Description

Technical Field

[0001] The present invention relates to delivering medical image data with metadata, and more particularly to delivering medical imaging data with metadata for remote real-time inspection. Background Art

[0002] US2022 / 0005585A1 and US2022 / 0319673A1 disclose methods of separating DICOM medical imaging data into anonymous DICOM medical imaging data and personal health information identifying a patient.

[0003] et al. 2017 disclosed a method for embedding QR codes containing patient information on medical images.

[0004] Recently, the process of transmitting medical images (i.e., ultrasound images, magnetic resonance images, computed tomography images, etc.) in real time to a remote viewer is a subject of particular interest. There are many situations in which a specialized, trained medical professional cannot be physically present at a scanning session. For example, a professional consultant may not be in the same medical facility, or may need to be accessed at once to assist with many scans. Therefore, providing concepts for enabling remote medical viewing may achieve improved patient outcomes.

[0005] However, reduced latency in the delivery of medical images must be achieved in order to avoid frustration and improve the effectiveness of the scanning session. Medical imaging data can be extremely large, and therefore a communication link with large bandwidth is necessary to avoid excessive latency. This problem is complicated because remote real-time medical examination / viewing typically requires an additional video communication channel between the remote viewer(s) and the sonographer (i.e., the person physically performing the scan) for proper guidance and to ensure that the desired information is collected.

[0006] Furthermore, for remote viewing, the focus is often on the transmission of ultrasound images, with no / little metadata (e.g., gain, depth, acquisition mode, and color map) associated with the image being transmitted to the remote viewer. In contrast, many scanners / medical devices are capable of exporting a medical image data stream in real time. This data stream may contain not only a variety of different types of image frames, but also metadata about the image frames. Such metadata may prove particularly useful for extended auditing purposes as well as processing applications and / or services for feature recognition and quantification of medical images. Summary of the invention

[0007] The invention is defined by the independent claims. The dependent claims define advantageous embodiments.

[0008] Concepts related to communicating medical imaging data for remote real-time medical examinations are presented. In particular, a medical image is encoded with an identifier based at least in part on metadata associated with the medical image. Because the medical image and metadata may have different transmission requirements (i.e., bandwidth, latency, loss, etc.), they are communicated over different communication channels. In this way, the medical image and metadata may be communicated appropriately, and the identifier enables the medical image and metadata to be matched at the recipient.

[0009] According to an example according to one aspect of the present invention, a method for transmitting medical imaging data for remote real-time inspection is provided, comprising:

[0010] receiving, at an interface module of a sender, a medical image and metadata, the metadata comprising information describing one or more parameters of the medical image;

[0011] encoding the medical image at a processing module of the sender with an identifier based on at least a portion of the metadata;

[0012] transmitting the encoded medical image from the sender to the receiver via a first communication channel; and

[0013] transmitting the metadata from the sender to the recipient via a second communication channel different from the first communication channel;

[0014] wherein the first communication channel is adapted for real-time data transmission and the second communication channel is adapted for reliable data transmission, and wherein the step of transmitting the encoded medical image and the step of transmitting the metadata are performed substantially in parallel.

[0015] As a result of transmitting the medical image and the associated metadata over different communication channels, different portions of the medical imaging data may be transmitted more appropriately. Indeed, in some cases, a medical image stream may be provided at a recipient over a fast data channel while also benefiting from metadata received over a reliable data channel. This benefit and other benefits are provided by the ability to send different portions of the medical imaging data over different channels while linking the medical image with the metadata via an identifier.

[0016] In other words, medical imaging data may be received in real time from a scanning device. The medical imaging data comprises a medical image / frame (or multiple images / frames) of an object, and metadata describing one or more parameters / properties of the image. It has been recognized that the medical image and the metadata may be linked by using an identifier based on (at least part of) the metadata itself, which metadata is encoded / embedded / linked to the medical image. This therefore enables the medical image and the metadata to be transmitted separately over different communication channels, while ensuring that the medical image and the metadata remain linked (i.e., they can be matched at the recipient).

[0017] Thus, the present invention enables the transmission of medical images and associated metadata over different communication channels without introducing problems associated with receiving the images and metadata separately at the recipient.

[0018] As a result of the present invention, real-time (i.e., while the medical image(s) are being acquired) remote (i.e., at a location separate from where the scan is being performed) examinations may be improved. More specifically, the medical image(s) may be sent over a communication channel suitable for efficient real-time transmission of the medical image, while metadata may be sent more sparsely (but reliably) over a different communication channel.

[0019] Furthermore, the first communication channel and the second communication channel may be selected based on their desired characteristics. For example, the first communication channel may be more suitable for transmitting a medical image stream (i.e., having appropriate bandwidth, latency characteristics, and security requirements). The second communication channel may be more suitable for transmitting metadata that is not updated frequently (i.e., ensuring accuracy / quality). Thus, given transmissions over different communication channels, system resources may be more appropriately allocated.

[0020] Ensuring that the first communication channel is used for real-time data transmission means that the remote observer can continuously see the (up-to-date) medical images representing the results of the ongoing scan. Thus, latency is reduced, as the first communication channel may (although not ideally) sacrifice some quality (i.e., reduced resolution or reduced frame rate) in order to ensure instant delivery of the medical images. This may be particularly beneficial over unreliable / inconsistent network connections.

[0021] At the same time, metadata may be sent via a second communication channel suitable for reliable (ie, high quality) data transmission.In practice, it has been recognized that metadata may not need to be transmitted immediately or guaranteed real-time delivery, as metadata may change at a much slower rate than medical images.

[0022] In other words, medical images may change dramatically from frame to frame, and therefore continuous transmission of new medical images is important to facilitate real-time inspection. However, metadata may change less frequently, and therefore the quality of the transmitted data is more important than the transmission frequency. Therefore, within a certain range of subsequent image frames, metadata associated with the first image frame in the range may also be linked to other image frames in the range. This is particularly useful when (conventional) image frame loss occurs due to limited network bandwidth or other network conditions. In some embodiments, encoding the medical image may include generating a machine-readable code based on an identifier, and embedding the machine-readable code within the medical image.

[0023] By embedding the medical image with a machine-readable code, the medical image and metadata can be automatically linked / matched by a machine at the recipient. This can achieve efficient and fast linking of the medical image and metadata, which means that the user may not be aware that the medical image and metadata are transmitted over different communication channels (i.e., as an opaque process).

[0024] Particular embodiments may provide that the machine-readable code is any of the following: a QR code, a dot pattern, or a watermark.

[0025] Thus, known machine-readable codes may be employed to link medical images with metadata in a cost-effective manner without requiring any additional skills and / or specific understanding by the user.

[0026] In some embodiments, the machine-readable code may be embedded in one of: a portion of the medical image that does not contain any medical information, a randomized portion of the medical image, or an extended portion of the medical image.

[0027] Thus, the machine readable code may not obscure the remote observer's view of the medical image. This is because the machine readable code may be provided so that it cannot be seen by the user, or so that it is in a different position than the structure / anatomy of the object.

[0028] In certain cases, the first communication channel may be a WebRTC (Web Real-Time Communications) video channel, and the second channel may be a WebRTC data channel.

[0029] Two existing communication schemes exist in the form of web real-time communication channels: the WebRTC video channel is suitable for fast real-time communication of images, while the WebRTC data channel is suitable for reliable communication of data.

[0030] In some embodiments, the method may further include generating a unique code; and adding the unique code to the metadata. In this case, the identifier is based on a portion of the metadata corresponding to the unique code.

[0031] In other words, a unique code / identifier (e.g., based on a timestamp or acquisition sequence number) is generated for each medical image, metadata pair. This unique code / identifier is then added / appended to the metadata. The identifier encoded into the medical image can thus be based on the portion of the metadata that corresponds to the unique code / identifier, so that they can be matched at the recipient.

[0032] Thus, metadata can be linked to the medical image based on the generated unique code. The generated unique code encoded in the medical image and present in the metadata can also provide useful information - such as a serial number or acquisition time corresponding to the medical image, thereby enabling classification of the medical image and metadata at the recipient.

[0033] In some embodiments, obtaining the medical image and metadata may include retrieving the medical image and metadata from a capture application configured to capture the medical image in real-time from an imaging device.

[0034] Therefore, the proposed method can be used with existing medical image acquisition applications. This can increase the compatibility of the proposed method with existing workflows and systems.

[0035] In further embodiments, obtaining the medical image and metadata may include obtaining a digital navigation link (DNL) data object including the medical image and metadata, and extracting the medical image and metadata from the DNL data object.

[0036] DNL data objects provide a simple way to encapsulate and communicate real-time medical image data (eg, ultrasound image data).

[0037] In some embodiments, the method may further include serializing the metadata into a byte or string format suitable for transmission over a second communication channel.

[0038] Therefore, the metadata can be efficiently transmitted through the second communication channel.

[0039] Furthermore, the metadata may include an acquisition mode of the medical image. In some cases, the acquisition mode may include at least one of the following: image gain, image depth mode, image color map, image rotation, image translation, and image coordinate system.

[0040] The above information may be particularly useful for a remote viewer to fully understand the medical image(s) being received, as well as for real-time or future audits of scanning sessions.

[0041] In some embodiments, the medical image may be an ultrasound image. In this case, the ultrasound image may optionally include at least one of the following: a B-mode image component, a color flow Doppler image component, and a pulsed wave Doppler image component.

[0042] Duplex ultrasound scanning sessions that produce two live streams of medical images can particularly benefit from the proposed method. In this case, different image components can be produced, each of which can be transmitted over a different communication channel.

[0043] According to another example according to another aspect of the present invention, there is provided a method for receiving medical imaging data for remote real-time examination, comprising:

[0044] receiving, at a recipient from a sender via a first communication channel, an encoded medical image, the encoded medical image comprising an identifier encoded in the medical image;

[0045] receiving metadata at the recipient from the sender via a second communication channel, wherein the second communication channel is different from the first communication channel, wherein the metadata includes information describing one or more parameters of the medical image, and wherein the identifier is based at least in part on the metadata;

[0046] extracting an identifier from the encoded medical image at an extraction module (450) of the recipient; and

[0047] matching the medical image with the metadata based on the identifier at a matching module (460) of the recipient;

[0048] wherein the first communication channel is adapted for real-time data transmission and the second communication channel is adapted for reliable data transmission, and wherein the step of receiving the encoded medical image and the step of receiving the metadata are performed substantially in parallel.

[0049] According to an alternative example according to another aspect of the present invention, a method for transmitting medical imaging data for remote real-time examination is provided, the method comprising: transmitting encoded medical images and metadata according to any of the above-mentioned transmission methods, and receiving encoded medical images and metadata according to the above-mentioned receiving method.

[0050] According to other examples according to yet another aspect of the present invention, there is provided a computer program product comprising computer program code, which, when the computer program is run on a computer, is suitable for implementing any of the above methods for transmitting, receiving and / or delivering medical imaging data for remote real-time examination. The computer program product may be software that can be downloaded from a server, for example, via the Internet. Alternatively, the computer program product may be a suitable (non-transient) computer-readable medium on which instructions are stored, such as an optical storage medium or solid-state medium provided with or as part of other hardware.

[0051] According to an additional example according to yet another aspect of the present invention, a system for transmitting medical imaging data for remote real-time examination is provided, the system being configured to perform any of the above-described transmission methods.

[0052] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] For a better understanding of the invention and in order to more clearly show how it may be implemented, reference will now be made, by way of example only, to the accompanying drawings, in which:

[0054] Figure 1 A flow chart of a method of transmitting medical imaging data for remote real-time inspection according to an embodiment of the present invention is presented;

[0055] Figure 2 A flow chart of a method for receiving medical imaging data for remote real-time examination according to another embodiment of the present invention is presented;

[0056] Figure 3 A flow chart of a method for delivering medical imaging data for remote real-time inspection according to another embodiment of the present invention is presented;

[0057] Figure 4 is a simplified block diagram of a system for communicating medical imaging data for remote real-time inspection according to additional embodiments; and

[0058] Figure 5 is a simplified block diagram of a computer within which one or more portions of the embodiments may be employed. DETAILED DESCRIPTION

[0059] The present invention will be described with reference to the accompanying drawings.

[0060] It should be understood that the detailed description and specific examples, while indicating exemplary embodiments of the device, system and method, are intended only for illustrative purposes and are not intended to limit the scope of the invention. These and other features, aspects and advantages of the device, system and method of the present invention will be better understood from the following description, attached claims and accompanying drawings.

[0061] It should also be understood that the drawings are merely schematic and are not drawn to scale.It should also be understood that the same reference numerals are used throughout the various drawings to indicate the same or similar parts.

[0062] The present invention proposes a concept for delivering medical imaging data to remote observers so that they can participate in the real-time examination of an object. Specifically, the use of identifiers encoded in the medical images facilitates the transmission of the medical images and associated metadata along different communication channels. In fact, by using the identifiers, the metadata and the medical images can be matched at the recipient. The use of different separate communication channels means that the communication channels can be individually formatted / adapted / configured to suit different requirements for the transmission of medical images and metadata.

[0063] By way of explanation, establishing a connection between a scanner / machine and a remote viewer is often cumbersome. This may be especially true if the scanner and remote viewer are not on the same subnet.

[0064] The Digital Navigation Link (DNL) data format and communication protocol may be used to stream images / frames as structured data objects containing medical images (ie, ultrasound images, magnetic resonance images, etc.) and metadata associated with the medical images in each DNL data packet.

[0065] Furthermore, the transmission of medical imaging data (e.g., DNL data objects) cannot be guaranteed to be achieved in real time using existing techniques (i.e., there may be significant latency). This problem is compounded when the transmission of medical imaging data is combined with two-way audio / video communication (i.e., between the person performing the scan and a remote observer), which is often required for remotely guided examinations. In this case, the required bandwidth increases significantly with the associated increase in latency.

[0066] Although many services provide data channels for reliable data transmission, there is no real-time delivery guarantee. Medical imaging data can be transmitted in real time through existing data channels. However, when operating under imperfect network conditions, frequent multi-second timeouts may occur. This makes existing solutions unsuitable for guaranteed real-time medical imaging data (e.g., DNL data objects) delivery.

[0067] Some proposed embodiments may aim to overcome the above-mentioned problems by using separate communication channels to ensure real-time delivery of medical images and reliable transfer of associated metadata.

[0068] A first channel (e.g., a WebRTC video channel) can be used to send a specific medical image component. In the case where the medical imaging is spectral Doppler ultrasonography, there are three image components, namely B-mode, Doppler mode, and spectral waveform, thereby requiring three of such channels to operate in real time. In other words, the first channel can transmit the medical image component quickly, potentially at the expense of some loss of frames or resolution (although ideally lossless). A second channel (e.g., a WebRTC data channel) can be used to send associated metadata. The second channel can operate at a low bit rate and may not necessarily be real-time. The transmission of medical images and associated metadata can be performed in parallel (i.e., approximately simultaneously) over the two types of channels.

[0069] Thus, by utilizing two different communication channels, the transmission of different medical image data components may be adjusted based on individual needs. In an embodiment, the medical image is transmitted rapidly to ensure real-time transmission, while the metadata is transmitted in a reliable manner to ensure accuracy. In practice, it has been recognized that real-time transmission of metadata may not be necessary because the metadata may not change rapidly or unpredictably between frames in the same way that the medical image data may change between frames.

[0070] Furthermore, metadata may be linked to a specific medical image at the recipient due to the identifier encoded / inserted / added to the medical image. The identifier is based on at least a portion of the metadata that may have been added to the original image metadata at the sender, such that metadata linked to the medical image may be easily identified. In some embodiments, it may be advantageous that the medical image is encoded invisibly (i.e., not visible to a human observer) such that the observer is not distracted / annoyed / misled by the identifier. Alternatively, the identifier may be inserted in a portion of the medical image that does not contain any image information.

[0071] In this way, metadata associated with each medical image / frame within a medical image stream can be correctly associated at the receiving endpoint. This can be used by the recipient or an artificial intelligence agent in the cloud to implement medical image processing and image interpretation to provide fast and accurate medical diagnosis feedback at the point of care (i.e., the source of the medical imaging data).

[0072] Those skilled in the art will appreciate that embodiments of the present invention may be applied to remotely guided diagnosis and intervention. For example, a relatively untrained user may be guided by a remote observer via teleconferencing technology while receiving medical imaging data according to embodiments of the present invention. This may save time for a skilled observer and stress on the subject being scanned.

[0073] The additional transmission of metadata (and linking to the medical image via an identifier) ​​may be very beneficial to an observer in diagnosing and understanding the medical image. For example, an observer may choose to subsequently input the medical image(s) and associated metadata to an artificial intelligence agent that may be connected to the examination session at any time (e.g., during the same WebRTC call). Such an artificial intelligence agent may require such metadata to accurately assess the situation and thereby provide an accurate conclusion.

[0074] Some embodiments may support the examination itself (such as probe movement, tilt, rotation), and may provide image enhancements such as segmentation and annotation. This can help establish a medical diagnosis for the user performing the examination in real time. In such a case, a remote human observer or remote AI agent will provide an annotated video stream showing probe manipulation instructions back to the operator of the probe, and / or may provide a data stream containing the manipulation instructions or directly feed into the probe for remote control of acquisition settings.

[0075] Other embodiments may also facilitate detailed audit trails of medical examinations (stored elsewhere) and improve instruction in educational settings.

[0076] The present invention may be applied to many imaging modalities that can generate multiple image streams simultaneously. Indeed, in these cases, remote viewing may be beneficial but may be impractical due to the high latency levels experienced due to the size of such data sets and the associated bandwidth requirements. Examples of these are ultrasound imaging, C-arm fluoroscopy, and multi-planar image modalities, including 3D ultrasound and multi-planar X-ray.

[0077] In some specific exemplary embodiments of the present invention, the following main features may be employed on the sender side to enable the transfer of medical imaging data:

[0078] (i) Medical imaging data acquisition module. This may be in the form of an application that can control a scanning device (e.g., an ultrasound probe) to capture and transmit medical images and metadata in real time.

[0079] (ii) Interface module. This can retrieve data from the operation of the medical imaging data acquisition module. In addition, the interface can encode the data into DNL data objects that can be retrieved by processing and visualization applications.

[0080] (iii) A processing module. This may retrieve the medical imaging data (in the form of DNL data objects) from the interface module and:

[0081] (a) Extract medical images and metadata from each DNL data object;

[0082] (b) serializing the metadata into a byte or string format that can be transmitted over a network;

[0083] (c) extracting a frame identifier (e.g., a frame sequence number) and encoding each medical image. For example, a medical image can be encoded with a watermark representing the frame sequence number;

[0084] (d) providing the encoded image as a new frame to a video source module of a video communication channel controller (e.g., a WebRTC video channel module); and

[0085] (e) Provide the serialized metadata to a data communication channel controller (e.g., a WebRTC data channel module).

[0086] (iv) The data channel client module sends the metadata packet to the specified destination.

[0087] (v) The video channel client module receives the updated frames and encodes them into a video stream and sends the video stream to the destination (server or peer) through the video channel.

[0088] For clarity, the processing module can generate a pattern of visible dots of a small total size (e.g., 40x40 pixels, containing 16 dots of 8x8 pixels with high brightness values) based on the frame sequence number. The pattern can be extended with a fixed (or slowly changing) set of unique points to enable confirmation of the presence of the dot pattern and its location / boundaries. The complete pattern can then be inserted into one or more of the following: a fixed area containing no information, a different location for each frame, or as an extension of the original image frame (effectively increasing the image size).

[0089] In other specific exemplary embodiments of the present invention, the following main features may be employed on the receiver side in order to capture the transmitted medical imaging data:

[0090] (i) A data communication channel module which, upon receiving a metadata packet, checks whether the received metadata packet is a metadata packet, and if so, notifies a metadata buffer module and stores the packet in the buffer.

[0091] (ii) A metadata buffer module which, upon receiving a notification and a new metadata packet, extracts the frame identifier and stores the complete metadata packet in an internal array indexable by the extracted frame identifier.

[0092] (iii) The video communication channel module receives the encoded video stream (ie, a sequence of encoded medical images) and decodes each medical image. In the case where there are multiple video streams (ie, multiple types of medical images), multiple video communication channel modules can each process a different video stream.

[0093] (iv) View sink module. After receiving a new medical image frame, the view sink module (or multiple sink modules in the case of multiple different video streams):

[0094] (a) The medical image is checked for the presence of an expected dot pattern at an expected location. If no compatible dot pattern is detected at the expected location, the medical image is drawn and displayed without any changes. If a valid dot pattern is detected, the pattern is decoded, the resulting identifier value is stored in an ID buffer and the medical image is modified.

[0095] The modification may be one of: the dot pattern is masked to make it invisible, the medical image is enhanced with an alphanumeric string representing the (decoded) dot pattern and placed at the location of the dot pattern to cover the dot pattern; and / or the size of the medical image is reduced, wherein the hidden area is an extension of the original image, wherein the dot pattern was placed at the sender. Alternatively, no changes may be made to the medical image (i.e., the dot pattern remains part of the complete medical image).

[0096] (v) a reformatter module, which, upon receiving a notification of the presence of a newly received medical image frame (including a frame identifier):

[0097] (a) Retrieve the most recent ID from the ID buffer;

[0098] (b) matching the frame identifier with available metadata (from a metadata buffer) and an available medical image frame associated with the frame identifier (within a given range);

[0099] (c) reconstructing the raw data (i.e., DNL data packets) for storage (e.g., for use by advanced (AI) image / data analysis tools);

[0100] (d) converting the medical image and metadata into a DICOM (Digital Imaging and Communications in Medicine) RTV (Real Time Video) stream for storage in a DICOM storage device; and

[0101] (e) Rendering selected portions of the metadata in a readable format and displaying them in an information window or over one or more of the displayed incoming medical image streams at a specific location. This may depend on user-selected settings regarding what metadata needs to be displayed.

[0102] Of course, the above embodiments contain specific examples of how to implement the present invention, but the skilled person will understand that not all indexes are necessary to implement the present invention.

[0103] In summary, the main features that may be encapsulated by embodiments of the present invention are:

[0104] (i) Reliable and real-time delivery of medical images with associated metadata;

[0105] (ii) reliable and real-time DNL delivery;

[0106] (iii) seamless connectivity due to the use of standard WebRTC services;

[0107] (iv) using a standard client such as a web browser as the (receiving) endpoint;

[0108] (v) There is no frame-accurate communication between the metadata and the image display, but visual inspection is possible by viewing the acquisition controls and / or probe on the screen, or performing remote control actions of the acquisition that are visualized in the DNL metadata (feedback loop);

[0109] (vi) provide frame-accurate relinking of medical images and metadata;

[0110] (v) enabling advanced AI applications / services at the recipient for analyzing medical images;

[0111] (vi) enable extensive auditing and monitoring of inspections by remote observers for legal and educational purposes;

[0112] (vii) provide practical implementations for DICOM RTV transport;

[0113] (viii) transmitting multiple medical image streams in parallel over different video communication channels. In some examples, this can cater for different types of ultrasound, including 3D ultrasound and bi-plane; and

[0114] (ix) Multiple two-way video communication channels can be extended using standard WebRTC solutions to provide additional audio and video guidance and inspection options.

[0115] Go to Figure 1 , a flow chart of a method for transmitting medical imaging data for remote real-time inspection is shown. Optional sub-steps are shown in dashed boxes.

[0116] The method is suitable for sending / transmitting medical imaging data to a recipient in such a way that a person remote from (i.e., physically removed from) the examination / scanning session may be able to participate in the examination in real time. For example, the method may be useful for a person acting in a supervisory capacity who cannot be physically present at the examination, or may be useful for teaching purposes. Of course, these situations benefit from being able to participate in real time (i.e., while the examination is being conducted), as many insights, suggestions and guidance may be lost when viewing the examination after the fact.

[0117] At step 110, a medical image and metadata are received from, for example, an image acquisition system or a memory. The metadata includes information that describes one or more parameters (properties) of the medical image.

[0118] The medical image can be a medical image of an object, and more specifically, a medical image of the anatomical structure / pathology / structure of the object. For example, the medical image can be an ultrasound image, a computed tomography image, a magnetic resonance image, a positron emission tomography image, etc. In fact, it should be understood that the medical image can be any image useful in a medical context (i.e., for diagnosis / prognosis / treatment of an object).

[0119] In some specific embodiments / examples, the medical image is an ultrasound image. In this case, the medical image can include one of a B-mode component, a Doppler mode component, and a spectral waveform component. In some cases (to be described in more detail below), multiple different images and image streams can be provided. In other words, many different image components can be acquired during a single ultrasound examination session, and these image components can all be processed and transmitted through different communication channels.

[0120] By way of example, the metadata describes the characteristics / properties of the medical image and the context in which it was acquired. Specifically, the metadata can include the acquisition mode of the medical image. The acquisition mode can include at least one of the following: image gain, image depth mode, image color map, and in the case of 3D ultrasound, image rotation, image translation, and image coordinate system. In this way, the metadata can provide the context of the examination that a remote observer can understand, or can provide additional data useful for advanced analysis techniques / algorithms.

[0121] Receiving the medical image and metadata can include retrieving the medical image and metadata from an acquisition application configured to acquire medical images in real time from an imaging device. For example, such an acquisition application may already exist and may thus be a ready source of a live stream of medical image data.

[0122] At (optional) sub-step 112, a digital navigation link (DNL) data object can be obtained. The DNL data object includes the medical image (or multiple medical images) and the associated metadata. In this case, at (optional) sub-step 114, the medical image and metadata are extracted from the DNL data object. In this way, the medical image and the (associated / corresponding) metadata can be obtained.

[0123] At step 120, the medical image is encoded using an identifier. The identifier is based on at least part of the metadata. In this way, the medical image and the identifier are linked in the form of an encoded medical image.

[0124] In some embodiments, the identifier may be a frame sequence number (either unique, or following a predictable repeating pattern) that is part of the metadata. Of course, any identifier that is related to (i.e., based on at least a portion of) the metadata may be used, which may then be compared to the metadata at the recipient to match the metadata to the identifier.

[0125] In a further embodiment, an (optional) sub-step 122 is provided. At sub-step 122, a unique code is generated. The unique code may be based on a serial number of the acquired medical imaging data or the time at which the medical imaging data was obtained. The unique code is then added / appended to the metadata. This results in the generation of extended metadata.

[0126] When the extended metadata (including the generated unique code) is generated, the identifier encoded within the medical image is based on the unique code. In other words, the medical image is encoded with an identifier based on the portion of the metadata corresponding to the unique code (i.e., the code added to the metadata). In this way, the medical image and the metadata can be uniquely linked.

[0127] In other words, the sender can first extend the metadata with a unique code. The unique code is generated to ensure that it is unique, and it can then form a unique basis for linking metadata and medical images. In addition, the unique code can also have specific characteristics (e.g., based on a sequence number and / or a timestamp) to achieve an approximate match of metadata and medical images. For example, the receiver can match the unique identifier within the medical image with metadata within a certain range (the metadata can be matched with the previous / next medical image). In practice, regular medical image discarding may occur in the video channel to ensure real-time, low jitter and latency, while metadata is generally not discarded. Therefore, by intentionally generating a unique code with specific characteristics, inserting the unique code into the metadata, and basing the identifier encoded within the medical image on the portion of the metadata corresponding to the unique code, the above advantages can be achieved.

[0128] A medical image encoded / embedded / merged with an identifier means that the medical image and the identifier are linked in some way such that both are sent together along the first communication channel (as described below).

[0129] Furthermore, at an (optional) sub-step 126, a machine readable code is generated based on the identifier. The code is configured such that a machine may be able to read / interpret the code from the medical image in order to extract the identifier.

[0130] The machine-readable code may be generated using any known technique. For example, the machine-readable code may be one of a QR code, a dot pattern, or a watermark. As previously described, the machine-readable code may have a portion based on at least a portion of the metadata (i.e., an identifier), and may have another portion to specify the size, borders, and presence of the machine-readable code for automatic machine reading at the recipient.

[0131] At (optional) sub-step 128, the machine-readable code is embedded within the medical image (ie, placed within the medical image).

[0132] In some embodiments, the machine-readable code is embedded in one of a portion of the medical image that does not contain any medical information (i.e., the actual image surrounding the object, such as a dark spot), a randomized portion of the medical image (i.e., changes from frame to frame / image to image, such that it may not be visible at high frame rates), or an extended portion of the medical image. Thus, in some cases, the machine-readable code may not be visible to a viewer at the recipient (or at least does not obscure the view of the medically relevant information) even if the machine-readable code is not removed.

[0133] In other words, the medical image is modified so that it contains a machine-readable code that links the medical image to the metadata. A variety of techniques can be used to obfuscate the machine-readable code so that it is not observable by a person remotely observing the examination.

[0134] At step 130, the encoded medical image is transmitted from a sender to one or more recipients via a first communication channel. For example, the encoded medical image is transmitted from a medical image acquisition system including the sender to a medical image viewing system including the recipient. The first communication channel may be any medium through which data (in the form of a medical image) may be transmitted from a first location (sender) to a second location (receiver). For example, the first communication channel may be wired or wireless.

[0135] At step 140, the metadata is transmitted to the recipient via a second communication channel different from the first communication channel. For example, the metadata is transmitted from a medical image acquisition system including the sender to a medical image viewing system including the recipient. The second communication channel may be any medium through which data (in the form of metadata) may be transmitted from a first location (sender) to a second location (receiver). For example, the second communication channel may be wired or wireless.

[0136] Furthermore, step 130 and step 140 may be performed simultaneously, in other words, in a substantially parallel manner, or step 140 may be performed at a different time than step 130 (ie, later).

[0137] Essentially, the encoded medical image and metadata are transmitted along different communication channels. The different communication channels may include the same physical (wired / wireless) connection, but will have separately allocated resources. In practice, different communication channels simply mean that the encoded medical image and metadata are transmitted at different times, through different networks / systems, etc., according to at least one of the different protocols. Thus, different transmission requirements can be met.

[0138] In practice, the first communication channel is suitable for real-time data transmission and the second communication channel is suitable for reliable data transmission.

[0139] This means that the first communication channel is configured / adapted so that the encoded medical image is transmitted as quickly as possible (i.e., with minimal delay / latency), potentially at the expense of transmission quality. This can be achieved by allocating greater bandwidth relative to the second communication channel, and generally prioritizing resources for the first communication channel. In order to achieve real-time communication under potentially unreliable network conditions, the first communication channel may sacrifice quality (i.e., be undesirably lossy) in order to ensure that the remote observer sees the examination as it occurs.

[0140] The second communication is configured so that the metadata is transmitted reliably. This means that the metadata may not be transmitted in real time, but will be accurate.

[0141] Specifically, the first communication channel may be a WebRTC video channel, and the second channel may be a WebRTC data channel. These known channel formats are configured for real-time transmission and reliable transmission, respectively.

[0142] It should also be noted that in some embodiments the method may provide that, prior to transmission, the metadata is serialized into a byte or string format suitable for transmission via the second communication channel (eg, JSON or XML).

[0143] In general, about Figure 1 The described method can deliver medical images in real time (i.e., with minimal delay / latency) while delivering metadata reliably (i.e., without data loss). This will depend on the requirements of the user and the different configurations of the first and second communication channels. Of course, a technician implementing such a method can select alternative requirements for the first and second communication channels based on the desired transmission characteristics of the medical images and metadata.

[0144] Furthermore, it should be understood that reference Figure 1 The described method may be continuously repeated for a series / stream of medical images (ie a video of an examination).At least some of the medical images within the medical image stream are encoded with an identifier to link the stream (or individual medical images) to metadata.

[0145] In addition, in some embodiments, multiple medical images each corresponding to a different view of the examination can be obtained at once. In this case, each medical image can be transmitted via a different (sub) type of first communication channel. In fact, this provides different intermediate image streams. In particular, this can be applied to medical image acquisition in which various different views are obtained simultaneously. For example, the medical image can be an ultrasound image, which includes various images, such as a B-mode image, a pulsed wave Doppler image, or a biplane image set, as well as an X-ray or MR (magnetic resonance) image obtained at the same time and the same region of interest.

[0146] Figure 2 A flow chart of a method for receiving medical imaging data for remote real-time inspection is presented. Figure 1 The described method transmits medical imaging data and the method is performed at a recipient.

[0147] At step 210, an encoded medical image is received by / via a first communication channel. The encoded medical image includes an identifier encoded in the medical image. The identifier is based on at least a portion of metadata (e.g., a frame sequence number, which may have been added to the metadata at the sender prior to transmission), and may take the form of a machine-readable code embedded within the medical image, as described above.

[0148] At step 220, metadata is received by a second communication channel different from the first communication channel. The metadata includes information describing one or more parameters of the medical image (ie, the nature, characteristics, etc. of the acquisition).

[0149] As described above, the first communication channel and the second communication channel are configured differently so that the recipient can properly acquire the encoded medical image and metadata. For example, the first communication channel provides the medical image to the recipient in real time (i.e., with minimal delay and latency from the examination session), while the second communication channel provides the metadata reliably (i.e., with minimal loss).

[0150] At step 230, an identifier is extracted from the encoded medical image. This may be accomplished by any known technique for extracting data from a medical image. For example, known image analysis techniques may be used as would be understood by a person skilled in the art.

[0151] In one specific example, when the identifier is embedded in a medical image in the form of a machine-readable code, optical techniques can be used to recognize the presence and determine the identifier.

[0152] At step 240, the medical image and metadata are matched based on the identifier. In practice, because the identifier is based on at least part of the metadata, the matching can be relatively simple. For example, this can be achieved using known string matching techniques.

[0153] Additionally, it may be the case that identifiers obtained from metadata and identifiers extracted from medical images are matched based on the spacing of the identifiers. For example, in a sequence of acquired medical images, not all medical images may be transmitted by the sender, and / or some medical images may be dropped by the communication channel / network in order to maintain a low-latency real-time behavior of the image transmission. However, metadata is reliably transmitted and therefore will not be dropped by the network. Therefore, an exact match of metadata to medical images is not always possible.

[0154] Therefore, the range of identifiers can be used as a matching criterion. If the identifier represents a frame sequence number or a timestamp, this can be simply implemented at the receiver. In this case, the identifier of the medical image can be matched with a nearby identifier obtained from the received metadata packet.

[0155] It should be understood that the above steps may be repeated continuously for a plurality of medical images (streams / series of medical images). Figure 2 The resulting medical image (and optionally metadata) can be presented to a remote observer. Thus, a video of the examination can be shown to the observer.

[0156] Figure 3 A flow chart of a method of communicating medical imaging data for remote real-time examination is presented. In other words, a method is depicted in which medical imaging data can be transmitted from a sender (a user performing a medical examination on a subject) to a receiver (a user viewing the examination remotely).

[0157] First, at step 310, according to Figure 1 The method described herein transmits the encoded medical image and metadata (by the sender). Then, according to Figure 2 The described method receives (at a recipient) an encoded medical image and metadata. Thus, a continuous separate transmission of a medical image and associated metadata can be achieved, wherein the metadata and the medical image are matched at the recipient.

[0158] Figure 4 A simplified block diagram of a system 400 for transmitting medical imaging data for remote real-time inspection is included. Specifically, a sender side is provided, which includes an interface module 410, a processing module 420, a first communication channel module 430, and a second communication channel module 440. A receiver side is also provided, which includes an extraction module 450 and a matching module 460. Any of these modules may include dedicated hardware and / or a processor configured to implement software configured to implement one or more of the above-mentioned method steps. Two or more of these modules may be integrated to form a combined module.

[0159] The interface module 410 is configured to receive a medical image and metadata including information describing one or more parameters of the medical image. As shown, the medical image and metadata can be acquired directly from a scanner 405 (e.g., a magnetic resonance imaging (MRI) machine, an ultrasound scanner, a computed tomography (CT) machine). Alternatively, the interface module 410 can retrieve the medical image and metadata indirectly, such as from a memory or other storage device.

[0160] The interface module 410 then passes the received information to the processing module 420. The processing module 420 is configured to encode the medical image with an identifier, wherein the identifier is based on at least a portion of the metadata or is generated and added to the metadata by the interface module 410. The encoded medical image and metadata are passed to the first communication channel module 430 and the second communication channel module 440, respectively.

[0161] As shown, the first communication channel module 430 is configured to transmit the encoded medical image to the recipient via a first communication channel. The second communication channel module 440 is configured to transmit the metadata to the recipient via a second communication channel different from the first communication channel.

[0162] The recipient may then receive the encoded medical image and metadata via the first communication channel and the second communication channel, respectively. The recipient's extraction module 450 is configured to extract the identifier from the encoded medical image. The recipient's matching module 460 is configured to match the medical image and metadata based on the identifier.

[0163] Thus, the recipient acquires the medical image with the associated metadata from the sender via two different communication channels. To reiterate, the communication channels are different and therefore may be configured differently in order to meet different transmission requirements of the medical images and metadata.

[0164] Figure 5 An example of a computer 1000 in which one or more parts of an embodiment may be employed is illustrated. The various operations discussed above may utilize the capabilities of the computer 1000. For example, one or more parts of a system for transmitting, receiving and / or delivering medical imaging data for remote real-time inspection according to another embodiment of the present invention may be incorporated into any element, module, application and / or component discussed herein. In this regard, it should be understood that the system functional blocks may be run on a single computer, or may be distributed across several computers and locations (e.g., remotely connected via the Internet).

[0165] Computer 1000 includes but is not limited to PC, workstation, laptop computer, personal digital assistant, handheld device, server, storage, etc. In general, in terms of hardware architecture, computer 1000 may include one or more processors 1010, memory 1020, and one or more I / O (input / output) devices 1030 communicatively coupled via a local interface (not shown). The local interface may be, for example, but not limited to, one or more buses or other wired connections or wireless connections, as known in the art. The local interface may have additional elements to implement communication, for example, a controller, a buffer (cache), a driver, a repeater, and a receiver. In addition, the local interface may include an address connection, a control connection, and / or a data connection to implement appropriate communication between the above components.

[0166] Processor 1010 is a hardware device for executing software that may be stored in memory 1020. Processor 1010 may be substantially any custom or commercially available processor, central processing unit (CPU), digital signal processor (DSP), or auxiliary processor among several processors associated with computer 1000, and processor 1010 may be a semiconductor-based microprocessor (in the form of a microchip) or a microprocessor.

[0167] The memory 1020 may include any one or a combination of volatile memory elements (e.g., random access memory (RAM), such as dynamic random access memory (DRAM), static random access memory (SRAM), etc.) and non-volatile memory elements (e.g., read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic tape, compact disk read-only memory (CD-ROM), magnetic disk, floppy disk, cassette, cartridge, etc.). In addition, the memory 1020 may contain electronic, magnetic, optical and / or other types of storage media. Note that the memory 1020 may have a distributed architecture in which various components are remote from each other but can be accessed by the processor 1010.

[0168] The software in the memory 1020 may include one or more separate programs, each of which includes a sorted list of executable instructions for implementing logical functions. According to an exemplary embodiment, the software in the memory 1020 includes an applicable operating system (O / S) 1050, a compiler 1060, a source code 1070, and one or more applications 1080. As shown, the application 1080 includes many functional components for implementing the features and operations of the exemplary embodiment. The application 1080 of the computer 1000 can represent various applications, computing units, logics, functional units, processes, operations, virtual entities and / or modules according to exemplary embodiments, but the application 1080 does not mean limitation.

[0169] The operating system 1050 controls the execution of other computer programs and provides scheduling, input-output control, file and data management, memory management, and communication control and related services. The inventors contemplate that the application 1080 used to implement the exemplary embodiments may be applicable to all commercial operating systems.

[0170] Application 1080 may be a source program, an executable program (object code), a script, or any other entity including a set of instructions to be executed. When it is a source program, the program is typically converted via a compiler (e.g., compiler 1060), an assembler, an interpreter, etc. (which may or may not be included in memory 1020) to operate appropriately in conjunction with O / S 1050. In addition, application 1080 may be written as an object-oriented programming language or a procedural programming language with data classes and method classes, which has routines, subroutines and / or functions, such as but not limited to C, C++, C#, Pascal, BASIC, API calls, HTML, XHTML, XML, ASP scripts, JavaScript, FORTRAN, COBOL, Perl, Java, ADA, .NET, etc.

[0171] I / O devices 1030 may include input devices such as, but not limited to, a mouse, keyboard, scanner, microphone, camera, etc. In addition, I / O devices 1030 may also include output devices such as, but not limited to, a printer, a display, etc. Finally, I / O devices 1030 may also include devices that transmit both input and output, such as, but not limited to, a network interface controller or modulator / demodulator (for accessing remote devices, other files, devices, systems, or networks), a radio frequency (RF) or other transceiver, a telephone interface, a bridge, a router, an ultrasound probe, etc. I / O devices 1030 also include components for communicating over various networks (e.g., the Internet or an intranet).

[0172] If the computer 1000 is a PC, workstation, intelligent device, etc., the software in the memory 1020 may also include a basic input output system (BIOS) (omitted for simplicity). The BIOS is a set of necessary software routines that initialize and test the hardware at startup, start the O / S 1050, and support data transfer between hardware devices. The BIOS is stored in some type of read-only memory (such as ROM, PROM, EPROM, EEPROM, etc.) so that the BIOS can be executed when the computer 800 is started.

[0173] When the computer 1000 is in operation, the processor 1010 is configured to execute software stored within the memory 1020, to transfer data to and from the memory 1020, and to generally control the operation of the computer 1000 according to the software. The applications 1080 and the O / S 1050 are read in whole or in part by the processor 1010, possibly buffered within the processor 1010, and then executed.

[0174] When the application 1080 is implemented in software, it should be noted that the application 1080 can be stored on virtually any computer-readable medium for use by or in conjunction with any computer-related system or method. In the context of this document, a computer-readable medium can be an electronic, magnetic, optical, or other physical device or element that can contain or store a computer program for use by or in conjunction with a computer-related system or method.

[0175] Application 1080 may be embodied in any computer-readable medium for use by or in conjunction with an instruction execution system, apparatus, or device (e.g., a computer-based system, a system containing a processor, or other system that can retrieve instructions from an instruction execution system, apparatus, or device and execute the instructions). In the context of this document, a "computer-readable medium" may be any element that can store, communicate, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium.

[0176] about Figure 1 , 2 and 3 described methods and about Figure 4 The described (one or more) systems may be implemented in hardware or software or a mixture of both (e.g., as firmware running on a hardware device). To the extent that an embodiment is partially or entirely implemented in software, the functional steps illustrated in the process flow diagram may be performed by a suitably programmed physical computing device (such as one or more central processing units (CPUs) or graphics processing units (GPUs)). Each process - and its individual constituent steps as illustrated in the flow diagram - may be performed by the same or different computing devices. According to an embodiment, a computer-readable storage medium stores a computer program including computer program code, the computer program code being configured to cause one or more physical computing devices to perform an encoding or decoding method as described above when the program is run on one or more physical computing devices.

[0177] Storage media may include volatile and non-volatile computer memory, such as RAM, PROM, EPROM and EEPROM, optical disks (such as CD, DVD, BD), magnetic storage media (such as hard disks and magnetic tapes). The various storage media may be fixed within the computing device or may be transportable so that one or more programs stored thereon may be loaded into a processor.

[0178] To the extent that the embodiments are implemented partially or entirely in hardware, Figure 4 The blocks shown in the block diagrams may be separate physical components, or logical subdivisions of a single physical component, or may all be implemented in one physical component in an integrated manner. In an embodiment, the function of a block shown in the drawings may be divided between multiple components, or in an embodiment, the functions of multiple blocks shown in the drawings may be combined in a single component. Hardware components suitable for use in embodiments of the present invention include, but are not limited to, conventional microprocessors, application specific integrated circuits (ASICs), and field programmable gate arrays (FPGAs). One or more blocks may be implemented as a combination of dedicated hardware that performs some functions and one or more programmed microprocessors and associated circuits that perform other functions.

[0179] By studying the drawings, the disclosure and the appended claims, those skilled in the art can understand and implement variations to the disclosed embodiments when practicing the claimed invention. In the claims, the word "comprising" does not exclude other elements or steps, and the word "one" or "an" does not exclude multiple. A single processor or other unit can implement the functions of several items recorded in the claims. Measures recorded in mutually different dependent claims can be advantageously combined. If a computer program is discussed above, it can be stored / distributed on a suitable medium, such as an optical storage medium or solid-state medium provided together with other hardware or as part of other hardware, but it can also be distributed in other forms, such as via the Internet or other wired or wireless telecommunications systems. If the term "suitable for" is used in a claim or specification, it should be noted that the term "suitable for" is intended to be equivalent to the term "configured to". Any figure mark in the claim should not be interpreted as limiting the scope.

[0180] The flow chart and block diagram in the accompanying drawings illustrate the architecture, function and operation of the possible implementation of the system, method and computer program product according to various embodiments of the present invention.In this regard, each frame in the flow chart or block diagram can represent a module, segment or part of an instruction, which includes one or more executable instructions for implementing (one or more) specified logical functions.In some alternative embodiments, the function pointed out in the frame can occur in a sequence different from that pointed out in the accompanying drawings.For example, the two frames shown in succession can actually be performed substantially simultaneously, or the square frame can sometimes be performed in reverse order, depending on the function involved.It should also be noted that each frame in the block diagram and / or the flow chart diagram, and the combination of the frames in the block diagram and / or the flow chart diagram can be implemented by a dedicated hardware-based system that performs a specified function or action or performs a combination of special hardware and computer instructions.

Claims

1. A method (100) for transmitting medical imaging data for remote real-time inspection, the method include: Receiving (110) a medical image and metadata at an interface module (410) of a sender, the metadata comprising information describing one or more parameters of the medical image; encoding (120) the medical image at a processing module (420) of the sender with an identifier based at least in part on the metadata; transmitting (130) the encoded medical image from the sender to a receiver via a first communication channel; and transmitting (140) the metadata from the sender to the receiver via a second communication channel different from the first communication channel; wherein the first communication channel is adapted for real-time data transmission and the second communication channel is adapted for reliable data transmission, and wherein the step of transmitting the encoded medical image and the step of transmitting the metadata are performed substantially in parallel.

2. The method according to claim 1, in, Encoding the medical image comprises: generating (126) a machine-readable code based on the identifier; and The machine-readable code is embedded (128) within the medical image.

3. The method according to claim 2, in, The machine readable code is any of the following: a QR code, a dot pattern or a watermark.

4. The method according to claim 2 or 3, in, The machine-readable code is embedded in one of: a portion of the medical image that does not contain any medical information, a randomized portion of the medical image, or an extended portion of the medical image.

5. The method according to any one of claims 1 to 4, in, The first communication channel is a WebRTC video channel and the second channel is a WebRTC data channel.

6. The method according to any one of claims 1 to 5, further comprising: include: Generate (122) a unique code; and The unique code is added to the metadata, and wherein the identifier is based on a portion of the metadata that corresponds to the unique code.

7. The method according to any one of claims 1 to 6, in, Obtaining the medical image and the metadata includes retrieving the medical image and the metadata from an acquisition application configured to acquire a medical image in real time from an imaging device.

8. The method according to any one of claims 1 to 7, in, Obtaining the medical image and the metadata includes: obtaining (112) a digital navigation link data object comprising the medical image and the metadata; and The medical image and the metadata are extracted (114) from the digital navigation link data object.

9. The method according to any one of claims 1-8, further comprising serializing the metadata into a byte or string format suitable for transmission over the second communication channel.

10. The method according to any one of claims 1 to 9, in, The metadata comprises an acquisition mode of the medical image and optionally comprises at least one of: image gain, image depth mode, image color map, image rotation, image translation and image coordinate system.

11. The method according to any one of claims 1 to 10, in, The medical image is an ultrasound image and optionally includes at least one of: a B-mode image component, a Color Flow Doppler image component, and a Pulsed Wave Doppler image component.

12. A method (200) for receiving medical imaging data for remote real-time examination, the method include: receiving (210) at a receiver from a sender via a first communication channel an encoded medical image, the encoded medical image including an identifier encoded in the medical image; receiving (220) metadata at the recipient from the sender via a second communication channel, wherein the second communication channel is different than the first communication channel, wherein the metadata includes information describing one or more parameters of the medical image, and wherein the identifier is based on at least a portion of the metadata; extracting (230) an identifier from the encoded medical image at an extraction module (450) of the recipient; and matching (240) the medical image with the metadata based on the identifier at a matching module (460) of the recipient; wherein the first communication channel is adapted for real-time data transmission and the second communication channel is adapted for reliable data transmission, and wherein the step of receiving the encoded medical image and the step of receiving the metadata are performed substantially in parallel.

13. A method (300) for transmitting medical imaging data for remote real-time inspection, the method include: transmitting (310) the encoded medical image and metadata according to the method according to any one of claims 1-11; and The encoded medical image and the metadata are received (320) according to the method of claim 12.

14. A computer program product comprising computer program code adapted to implement the method according to any one of claims 1 to 13 when said computer program is run on a computer.

15. A system (400) for transmitting medical imaging data for remote real-time examination, the system being configured to perform the method according to any one of claims 1-11.

Images