KR102679915B1 - Systems and methods for encrypting, converting and interacting with medical images - Google Patents

Abstract

A system for communicating images includes: an imaging device configured to capture, image, and generate a digital image file, the imaging device comprising a device identifier; a set of routines configured to label the digital image file, associate account information with the digital image file, associate the device identifier with the digital image file, and communicate the digital image file to a server; configured to receive a digital image file and process the digital image file according to at least one of a label associated with the digital image file, account information associated with the digital image file, and a device identifier associated with the device that captured the digital image file. Includes servers that are

Description

SYSTEM AND METHODS FOR ENCRYPTING, CONVERTING AND INTERACTING WITH MEDICAL IMAGES}

Embodiments described herein relate to the delivery of medical image records, and particularly to automatic encryption and conversion of medical image files for delivery to mobile devices and/or telecommunication systems.

Medical diagnostic devices and medical imaging systems have become increasingly complex in recent years. In response to the growing challenges of digital imaging technology, the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) launched the Digital Imaging and Communication In Medicine (DICOM) initiative. ) developed standards. DICOM is a standard for processing, storing, printing, and transmitting information in medical imaging. This includes file format definitions and network communication protocols. The network communication protocol is an application protocol that communicates between systems using TCP/IP. One of the goals of the standard is to transmit medical images and information uniformly between viewing and scanning sources so that users of different imaging software and/or hardware can share the information. DICOM files can be exchanged between two entities capable of receiving images and patient data in DICOM format. DICOM can integrate scanners, servers, workstations, printers and network hardware from multiple manufacturers into a Picture Archiving and Communication System (PACS) for storing and downloading digital images. Other devices include DICOM conformance statements that clearly state the DICOM classes they support. DICOM is widely adopted in hospitals and is gaining popularity in small dental and private practices.

DICOM files typically contain images; Therefore, it is sometimes called a DICOM image. However, it is believed that DICOM files do not necessarily need to contain images. More precisely, these files may contain measurement or report data. Accordingly, a DICOM file may contain media data such as video and audio data, or may not contain media data at all. In this case, the DICOM file may contain only metadata that identifies the original form, operator, or patient being examined. Here, modality refers to any image-generating equipment in medical imaging, such as ultrasound (US), magnetic resonance imaging (MRI), computed tomography (CT), positron emission tomography (PET), and radiography.

The type and amount of data available in any one DICOM image file varies. DICOM files are typically constructed using data that identifies patients, studies, series, and instances with their hierarchical distribution. A patient may participate in multiple studies (cases), which in turn may contain multiple series (exams or visits), multiple instances (typically files containing images). This means that it unambiguously identifies the DICOM file and fits into its hierarchy. Every DICOM file contains an identifier for creating a form. That is, the identifier reflects the device or location from which the file originates. Additionally, the file contains timestamps related to both the file itself (instance) and the series. Using the timestamp and original identifier, the data can be used to unambiguously identify the image without including any identifiable patient information, thereby protecting patient privacy concerns. Additionally, the DICOM file format differs from other data formats in that it groups information into data sets. For example, a file of a chest X-ray image actually includes the patient ID within the file, so the image cannot be accidentally separated from this information.

Most PACS process images from a variety of medical imaging devices, including US, MRI, PET, CT, etc. Electronic images and reports are transmitted digitally via PACS; This eliminates the need to manually save, retrieve or transfer files to the film jacket. PACS consists of four major components: imaging modalities, such as CT and MRI; Secure network for transmission of patient information; workstation for image interpretation and review; and long-term and short-term archives for storage and retrieval of images and reports. PACS, combined with available and emerging web technologies, has the ability to provide rapid and efficient access to images, interpretations, and associated data. PACS is divided by the physical and time barriers associated with traditional film-based image retrieval, distribution, and display.

Medical imaging devices typically output digital image data. The overwhelming majority, if not all, of these devices use the DICOM standard for both image file format and network transmission. These images generally cannot be read by consumer image viewers or mobile devices. Therefore, patients who want to share medical images have difficulty converting and communicating these images. A good example is sharing images from an ultrasound scan during pregnancy. Future parents usually want to save, share and show images of their future children. Additionally, they may want to send these images to their friends and relatives' mobile phones or email accounts. You can also post them on social networks or keep them in your personal digital “photo album.” All of these events require either scanning a printed hard copy of the image or finding, purchasing, installing and using a DICOM viewer software package with export capabilities. These software packages are generally not readily available or economical for limited use.

It should also be noted that this problem is not necessarily limited to DICOM files. Generally, there is no real way for patients to view images associated with their condition, treatment, condition, etc. Additionally, there are few effective means for a physician or clinician to quickly and remotely retrieve images for diagnostic or other purposes.

In fact, most small medical practices, such as small clinics, private hospitals, and dental clinics, have difficulty converting, delivering, and receiving medical images economically and in a timely manner. These facilities typically do not have the technical support staff or finances to run a full PACS for image archiving and delivery to remote specialists for second opinions and consultations. They often rely on film or recordable CDs sent by mail or messenger. This is slow, unenvironmentally friendly, and unsafe when using unregistered postal delivery. The cost of running PACS isn't just paying the license fee. Major investments in advanced infrastructure including peripheral software, hardware and facilities, as well as staff training costs and management time, add to the cost of running a PACS. These major investments are expensive and are generally beyond the reach of most small and medium-sized businesses.

Additionally, many medical practices may not have a local network with which medical imaging equipment communicates, or the local network may not be reliable or properly configured to receive and communicate medical images. The medical imaging devices themselves often lack the ability to encrypt or convert captured images. If the local network exists, it may not be possible to integrate network devices such as PACS for management of digital images.

Peripheral devices for connection to medical imaging devices provide encryption and conversion of medical images into secure, standardized image file formats, as well as communication of encrypted and/or converted images to a secure server on a remote network. to provide.

According to one aspect, a system for communicating images includes: an imaging device configured to capture, image, and generate a digital image file that includes a device identifier; a set of routines configured to label the digital image file, associate account information with the digital image file, associate the device identifier with the digital image file, and communicate the digital image file to a server; configured to receive a digital image file and process the digital image file according to at least one of a label associated with the digital image file, account information associated with the digital image file, and a device identifier associated with the device that captured the digital image file. Includes servers that are

According to another aspect, an imaging device includes a modality configured to capture, image, and generate digital image files; device identifier; shared key; and label the digital image file, associate account information with the digital image file, associate the device identifier with the digital image file, encrypt the digital image file using the shared key, and Contains a set of routines configured to communicate to a server; Here, the label, account information, and device identifier instruct the server as to how to process the digital image file.

These and other features, aspects and embodiments are described below in the section entitled “Detailed Description of the Invention.”

Features, aspects and embodiments are described in conjunction with the accompanying drawings.
1 is a diagram illustrating an example system for automatic conversion and distribution of medical images to one of a plurality of output formats in accordance with one embodiment.
FIG. 2 is a high-level block diagram illustrating certain components of an example data conversion and delivery system that may be included in the system of FIG. 1 in accordance with one embodiment.
FIG. 3 is a flow diagram illustrating an example automated message creation process performed by the data conversion and delivery system of FIG. 2 in accordance with one embodiment.
FIG. 4 is a flow diagram illustrating example types of information and data that may be examined in the process of FIG. 3 in accordance with one embodiment.
FIG. 5 is a flow diagram illustrating an example process for use of information embedded within metadata included in files incoming by the data conversion and delivery system of FIG. 2 in accordance with one embodiment.
FIG. 6 is a flow diagram illustrating the operation of an image converter module that may be included in the data conversion and delivery system of FIG. 2.
FIG. 7 is a flow chart illustrating a typical use of a Web GUI that may be included in the data conversion and delivery system of FIG. 2 and a simplified interface for retrieving images in their original form without any identifiable patient information, according to one embodiment. .
8 is a flow diagram illustrating a variation of the typical use of a Web GUI, a simplified interface for finding images by using a portion of identifiable patient data according to one embodiment.
9 is a diagram illustrating an example system for automatic conversion and distribution of medical images to one of a plurality of output formats in accordance with another embodiment.
Figure 10 shows a medical imaging device and a peripheral device connected to a remote server for converting and encrypting a medical image file from the medical imaging device according to an embodiment of the present invention.
FIG. 11 shows a medical imaging device and a network device connected to a remote server for converting and encrypting medical image files from the medical imaging device according to an embodiment of the present invention.
12 is a flow diagram of signal flow through a network.
13 shows an encryption and conversion unit, a medical imaging device, and a system for converting and encrypting medical images on a remote server according to an embodiment of the present invention.
14 and 15 illustrate a conventional workflow for medical image sharing in primary care and emergency room settings.
Figure 16 is a flow diagram of one embodiment of a system for real-time remote interaction collaboration for medical diagnosis.
17 illustrates a user interface visible to a user of a real-time remote interaction system.
Figure 18 shows a user interface viewable by a user of the real-time remote interaction system.
Figure 19 shows a user interface viewable by a user of the real-time remote interaction system.
Figure 20 shows a user interface visible to a user of the real-time remote interaction system.
Figure 21 shows a user interface visible to a user of the real-time remote interaction system.
Figure 22 shows a user interface viewable by a user of the real-time remote interaction system.
Figure 23 illustrates a user interface viewable by a user of the real-time remote interaction system.
Figure 24 illustrates a user interface viewable by a user of the real-time remote interaction system.
Figure 25 shows a user interface visible to a user of the real-time remote interaction system.
Figure 26 shows a medical imaging device and a mobile device connected to a remote server for converting and encrypting medical image files from the medical imaging device according to an embodiment of the present invention.
27 and 28 illustrate example processes that can be executed on a device or computer system for communicating images to a server using IP networking.
Figure 29 is a diagram illustrating an example system including the routines of Figures 27 and 28.

1 is a diagram illustrating an example system 100 for automatic conversion and distribution of medical images to one of a plurality of output formats. The above output format is used to refer to various types of devices, systems and services, some examples of which are provided below. As can be seen, system 100 can support multiple source medical imaging modalities, such as ultrasound, MRI, CT and PET equipment, a local PACS 20 (typically a source imaging archive-server), or DICOM data, typically medical images, etc. Includes any other device capable of transmitting medical data. The forms 10 and PACS 20 may be connected to a central computer system (CCS) 30, for example, via the Internet 60 via a router 50, which is usually provided with encryption and firewall protection.

Central computer system (CCS) 30 may include a data conversion and delivery system (DCDS) 32 for processing medical data. The CCS may include one or more servers, and includes one or more processors or CPUs, memory associated with the processor(s), data storage modules, display means, and input/output interface means. It should be recognized that a variety of other peripheral devices and modules may be connected to the CCS, such as other servers, other data storage modules, or intrusion detection systems. Additionally, the CCS may be a cluster of interconnected servers, each processing a specific task within the system. Similarly, all modules can be individual servers in this cluster to distribute the load and increase capacity of the system as shown in Figure 2 and described below.

DCDS 32 is configured to convert medical images associated with medical data into, for example, consumer-friendly images, videos, or both. DCDS 32 may then transmit these converted images to a number of destinations or output formats 40, as commanded by the user/operator of DCDS 32 or by information contained in the medical data. You can. These destinations 40 include, for example, websites such as social networking sites including Twitter, Facebook, and Google Health; Cell Phone; PDAs; email account; Or it may be any computer system capable of receiving data through protocols such as SOAP and REST, for example. DCDS 32 functions in a manner that allows source modalities 10, 20 to be protected by the most stringent firewall environment 50, while still allowing transmission over the Internet 60. The original source image data may be selectively transmitted to the destination 40 without processing or conversion.

For example, if a patient undergoes an ultrasound during pregnancy, DCDS converts the ultrasound image into a series of images that can be transmitted to the parents' social networking web pages, their mobile devices, their friends and family's devices or web pages, etc. It can be sent to (32). More specifically, a good sequence of the fetus waving its arms can be captured and stored during an ultrasound examination by the operator. The ultrasound operator, usually a nurse or technician, transmits the DICOM file stored in DCOM 32, for example. A nurse, technician, or trusted staff member at the patient's facility (user) can retrieve the target sequence transmitted by source form 10, using a remote graphical user interface (GUI) interfaced with DCDS 32. there is. Afterwards, the user can enter his or her mobile phone number, web account information, email address, etc., and can also enter any personal message commanded by the patient and then begin delivery. Afterwards, the DICOM file converted to a mobile phone-compatible video format, such as 3gpp, can be sent to the mobile phone as a multimedia message, and the converted file to other suitable formats can also be sent to designated email and web accounts. there is.

Additionally, a nurse or technician at the patient's facility can enter the patient's cell phone number into the ultrasound machine's patient information field. For example, upon receiving a DICOM data file, DCDS 32 may be configured to automatically transmit the converted image or video file to the destination location specified by the patient after locating the corresponding number embedded in the DICOM data file. You can. Examples of these processes are described in detail below.

2 is a high-level block diagram illustrating certain components of an exemplary DCDS 32 according to one embodiment. It should be understood that the diagram of FIG. 2 is for explanatory and illustrative purposes and is not intended to limit the embodiments described herein to any particular architecture or design. 2 is not intended to provide a detailed view of all components of the exemplary DCDS 32. In operation, requests from form 10 may be processed by an input stage consisting of a receiver 203 and a store and parser 204. The receiver 203 may be configured to authenticate the connection from the source form 10 and process the network transactions necessary to complete the request.

Storage and parser 204 may be configured to analyze the received data and store any image data 205 and any metadata 206 in storage system 214 . For example, the image data 205 may be stored as binary data, while the metadata may be stored as structured data that allows structured access to the data (such as search and associations between other items). Store and parser 204 may be configured to remove all sensitive patient information from incoming data files under certain performance or certain conditions. For example, an operator of the system may use a graphical user interface (GUI), such as Web GUI 208, to selectively set portions of metadata that are considered sensitive. Additionally, the system can be programmed to automatically determine whether a field in the metadata is sensitive. This process is called anonymization and is done to protect the patient's personal information. Anonymization is explained in more detail below.

In certain embodiments, an event signal may be triggered indicating that newly stored data has been added. When the event system module 209 receives an event signal from the parser 204, it may be configured to determine what action should be taken as a result. For example, if rules for automatic forwarding are set and appropriate metadata values are found for newly received data stored in structured database 206, event system module 209 then automatically forwards to output module 213. It may be configured to send a signal transmitting converted data commanded by a rule. This processor is described in more detail below.

Output module 213 may be configured to accept calls from other parts of DCDS 32 containing general data, information to be sent, and a number of forwarding destinations, including email addresses. For example, the data may include a text message, for example a reference to a DICOM image, two cell phone numbers and one email address. The output module 213 may be configured to assemble appropriately formatted output “packages” or messages and transmit the resulting messages using a module plug-in based architecture. Plug-ins (not shown) for each corresponding type of destination may be included and used in the output module 213.

In the example provided above, when a service call is received by DCDS 32, output module 213 may assemble one MMS message packet containing a JPEG version of the image and message text, and MMS documentation. All are combined and encoded by . This message may then be sent twice, first to each requested phone number recipient, and then twice to each specified email address recipient.

The output module 213 may request a converted image from the image converter 211 by identifying the original image and specifying the requested format and size. Image converter 211 may then be configured to find an existing image in converted image cache 212 that matches the request. If a match is not found, an image can be created from the original image data 205. The image converter 211 may be configured to use metadata 206 of the original image stored in a database to determine whether the requested format is appropriate. Otherwise, it may respond with an error. For example, requesting an mp3 audio version of a still image would result in an error, whereas requesting a JPEG still image of a multi-frame DICOM image file (effectively video) would be appropriate.

Image converter 211 may be configured to respond to events from parser 204 and perform common conversions proactively. This improves the responsiveness of the system components, especially output module 213 and Web GUI 208; The trade-off is an increase in requested storage, but also a slight decrease in overall security level.

The Web GUI 208 provides remote access to the DCDS 32 to medical staff, for example, via a secure web browser connection (https) 202. This Web GUI 208 can provide an interface for performing management tasks such as setting rules for the event system module 209, and also provides an optimized interface for identifying images and sending output messages. do. The general operation of these interfaces is described in detail below.

Web GUI 208 can operate on structured metadata 206 to find and identify images. For example, to display thumbnails and previews of images and to request conversion from image converter 211 to provide a service request format in which an output message can be specified and sent to output module 213 for delivery. It can be configured.

The adaptable garbage collector 207 can continuously evaluate the status of all data and compare it to configurations made by the administrator of the system. The configuration can set specific standards that an item must meet in order to remain in or be deleted from the system. One basic criterion may be the lifespan of the item. For example, an item may have been saved a week ago or may have been automatically deleted a certain number of days ago. Other automatic deletion criteria may be the number of times the item has been previously transferred, stored system state information, and values of metadata. This feature is also useful in helping with patient confidentiality, in part by limiting resource usage and removing patient data that the system no longer needs to maintain.

It should be noted that in some embodiments, images are to be used for clinical or diagnostic purposes. In these cases, it is often necessary that the image that is ultimately displayed on the device used to view the image must maintain a certain resolution or image quality. As such, in certain embodiments, one or more of parser 204, event system module 209, and image converter 211, either alone or in combination, recognizes that the image is being viewed in a diagnostic or clinical application. It can be configured. This recognition may be based on information included in the metadata, information stored in the imaging system 214, or information provided through the GUI 208.

For example, an address or device identified in metadata for receiving an image may be recognized as an address or device associated with a clinical or diagnostic application, an image or series identifier may be associated with a clinical or diagnostic application, etc. Additionally, the operator may indicate via GUI 208 that images may be transmitted that are intended for clinical or diagnostic purposes.

Once the images that can be used for clinical or diagnostic purposes are determined, image converter 211 may then be configured to determine the requested resolution or image quality based on information stored in storage system 214, for example. For example, resolution, image quality, or both for various types of images, clinical applications, etc. may be stored in storage system 214. Afterwards, the image converter determines the exact image resolution and quality and converts the image accordingly. In certain embodiments, DCDS 32 may be configured to determine whether the identified output device or address is capable of displaying the converted image at the required image resolution and quality prior to transmitting the image. If the device or address is not available, DCDS may then generate an error message or other alert indicating this. The error message may be displayed via GUI 208, on the device, or both.

As discussed above, DCDS 32 may be configured to take incoming medical image files and automatically convert them for distribution and viewing in any of a plurality of output formats. 3 is a flow diagram illustrating one embodiment of an automated message creation operation performed by DCDS 32 in accordance with one embodiment. In the example of Figure 3, it is assumed that destination information, such as output format information, is included in the medical image file received by DCDS 32. In other embodiments, a user may access DCDS 32, for example via GUI 208, and specify which files should be sent in output form; A powerful aspect of DCDS 32, as configured in accordance with the systems and methods described herein, is its ability to automatically determine the destination and convert and format data appropriately as described below.

At step 320, a file is received and its associated headers are examined to determine various information. Medical image files received by input 203 will often include metadata that provides medical data or information related to the images contained therein. For example, in a DICOM file, the medical image file will include a header containing multiple fields. These fields are generally the same for each input form 10. Accordingly, DCDS 32 may be configured to examine header fields to determine various information with respect to FIG. 4, as described below.

At step 322, the output destination type or format may be determined. For example, the header may include information identifying the recipient of the image included in the image file. More specifically, the header refers to an online photo album page, site or service; social networking pages or services; It may contain information identifying various recipients, such as mobile devices, or output formats associated with the service. The basic types of destinations are mobile devices such as cell phones; email account; It may include web application-specific interfaces (APIs) related to online sites or services, etc. Accordingly, DCDS 32 may be configured to examine the header file and determine the associated output device or service, i.e., format.

If possible, DCDS 32 may then be configured to retrieve specific characteristics of each destination type, as shown in step 324. These characteristics may include capabilities and physical characteristics of the destination device, and specifications and limitations of network classes and message types. This information is then used to determine the output formatting and other specifications required for each output format. For example, this information may be used for adaptation of image data based on specifications for the type of message being transmitted, for example email has limitations in specifications and common practices that may be applied; MMS has very different restrictions that can be applied.

The performance and characteristics determined at step 324 include frame size, i.e., pixel size of the image or video, such as 640×480; Typically cannot exceed a total size of 300 KB, and email attachments exceeding 10 MB often have unacceptable data rates or data sizes, for example MMS messages; Encoding formats supported, such as MPEG 4, JPEG, etc.; and message layout rules, etc., i.e. how the message may be organized for the recipient, for example an MMS may be organized into "pages", each containing a single image or video and a single text with audio. On the other hand, email is capable of HTML layout and can maintain attachments of all file formats.

At step 326, a basic compatibility check may be performed to determine whether the data contained in the image file can be delivered in a format compatible with the output format. For example, if the image data includes video data, a determination can then be made as to whether the output format is capable of receiving and displaying video data.

The most appropriate delivery format is then selected at step 328 to ensure that the output message ultimately generated contains the best quality data for which the output format can be processed. For example, this may be important in clinical settings or settings where the data is used for testing or diagnostic purposes. Suitable resolution information for diagnostic purposes and the ability of DCDS 32 to provide such resolution are described in detail below.

Thereafter, in step 330, the data can be extracted and transformed as needed. For example, MMS messages allow only a very limited total message size. Therefore, images or videos often need to be adjusted and optimized, especially to allow the final message to meet the format and specification requirements of a particular output format. In contrast, email messages are not strictly limited in size and can accommodate larger files, such as high-resolution images or videos. However, email accounts may also contain rules limiting very large files, so email messages may require optimization of video files, for example, but may need to adhere to size limits to ensure sufficient quality.

If the incoming file is already encoded in a format compatible with the output format, then no conversion will often occur at step 330 to maintain the highest possible image quality.

At step 332, the data may be anonymized as required by any applicable anonymization rules. For example, the data can be extracted and copied in a general format to remove or edit specific data. Afterwards, the data can be converted to the final output format. Steps 330 and 332 may be done in parallel or in sequential order as required by the particular implementation.

In step 334, the converted data may be assembled into an output message according to the applicable format and specifications determined in the previous step. Optionally, other data may be included in the message. This information may be entered manually, for example via GUI 208, or may be extracted from the received file and accompanying metadata. Additionally, the data may be data retrieved from configuration settings based on a series of characteristics described above.

In certain embodiments, the data elements that will contain the output message are assembled according to template rules for the type of message being generated. For example, various template rules may be stored in storage system 214 and accessed by output module 213 to assemble the output message. For example, MMS messages are based on a page metaphor where each page can contain images or videos, text elements, and audio elements. Therefore, sending more than one image, or including text, audio, or both along with the image(s), may require assembling the message into several pages. In contrast, an email message may contain any number of images, attachments, etc., depending on the message size limitations above, for example.

Thereafter, output module 213 may be configured to elect an appropriate output gateway for transmission of the assembled output message at step 336. For example, output module 213 may be configured to transmit email messages to an SMTP server (not shown) and MMS messages to an MMS gateway (not shown).

4 is a flow diagram illustrating example types of information and data that may be searched at step 320. As can be seen in Figure 4, when the file is received, the metadata, or more specifically the header, can be inspected at step 420 to identify the input format. At step 422, compatibility of the format determined at step 420 with the system may be determined. If compatible, specific characteristics of the data contained in the image file may then be determined at step 424. For example, it may be determined at step 424 whether the file actually contains any image or video data, or whether the data is simply a report or measurement. If the incoming file contains, for example, reports or measurement data, this information is then extracted and stored at step 426, for example, in a common structured format. At step 428, arbitrary image data may be extracted and stored, and various characteristics may be determined, such as binary encoding format, frame size, color bit depth, still image or video.

5 is a flow diagram illustrating an example process for use of information embedded within metadata containing files received by DCDS 32 in accordance with one embodiment. The metadata, for example header fields, may be used to ensure safe and secure delivery of the image data contained therewith. For example, a DICOM image file may contain multiple header fields that are key-value pairs from multiple data types, such as strings, numbers, dates, and special measurement types. Fields that can be embedded can be strongly linked to files that provide metadata. This way, header files and associated data are not separated and therefore do not mix up.

At step 520, DCDS 32 may be configured to automatically track and record header fields for each network device transmitting images. In this way, DCDS 32 can identify the specific device associated with the incoming file. The DCS 32 may do this by recording whether a header field is present for a particular form 10 at step 522 and then recording the data contained in the device dependent header fields for the associated form at step 524. A specific device can always be recorded for the same value, eg manufacturer, model name, model number, etc. Accordingly, DCDS 32 can use this information to identify a specific device.

At step 526, DCDS can take appropriate action after detecting any changes in the data. Changing header field data that should not be changed, for example manufacturer information, can be an indication that the file has been tampered with or that someone is attempting to hack the system. Some possible actions in response to these changes include: the system logs the event, notifies the operator, places the incoming data on an authorized hold, isolates the data or additional data from the associated device, and You can reject the data and reject all future data from the device.

At step 528, DCDS may be configured to search header fields for data that can identify the intended recipient, as described above. The identification may be physical, for example in the form of an email address, mobile station International Subscriber Directory Number (ISDN), website address, etc. In practice, such direct identification may be desirable as it takes advantage of the presence of header fields. Identification may also be indirect, such as, for example, an ID that may be used to retrieve an address directly from a registry stored in storage system 214. Additionally, each field may contain one or more pieces of data and other types of data. Accordingly, any identification or address field may include not only a phone number, but also an email address, etc. Additionally, identification data may be included in more than one field.

DCDS 32 may then be configured to determine an action to take at step 528 based on any identification data detected at step 530. To name a few examples, these actions may include sending the appropriate message to any address found, formatting the message appropriately as described above, notifying the operator, adding the message to the queue for manual acknowledgment, for example, and sending the message. It may involve placing and adding other data or information to the message.

Accordingly, Figure 6 is a flowchart showing the operation of DCDS 32 in more detail. Referring to Figure 6, a conversion request 301 may be received that includes, at a minimum, an internal identifier for the image and a destination format. As discussed above, the conversion request may be a result of information and data included in metadata associated with the incoming file. However, as described below, the request may also originate from input received via GUI 208. Optionally, the request may include a new image size to be scaled as the output image to be transmitted. Image converter 211 may then be configured to determine the presence of the requested image 304 by attempting to find metadata associated with the metadata in metadata database 303. If no record exists for the requested image, the converter may optionally return a placeholder image (305, 308) or abort the conversion attempt (306). A placeholder is typically an image, video, or similar media that communicates that the requested image is not available. At this point, the converter may be configured to determine whether the requested output format is feasible.

If a metadata record in database 303 exists, the converter may then be configured to load the DICOM image 307 in raw binary format, for example from image storage device 302. The converter 211 may be configured to determine whether the image data should be resized to the size provided in the request or to the size required by the requested output format. For example, a JPEG preview for a Web GUI 208 may be rendered at an arbitrary size suitable for the layout of an HTML document, while a video for an MMS message has a very specific size to conform to specifications.

Next, the image data may be converted to the requested destination format (311). The results may be stored in the image cache (312) and the metadata record may be updated to indicate the existence of the converted image (313). Finally, the converted video may be returned as a response to the request. Afterwards, the converter 211 may directly return the converted binary data or return a reference to its location in the image cache 313.

As mentioned above, DCDS 32 may be operated and interfaced via Web GUI 208. GUI 208 may enable both remote and local access to DCDS 32 and images to be located within storage system 208 . The image needs to be located for analysis or diagnosis, or for transmission to a designated destination or address.

Two basic methods can be provided to access files. The first method is to find files without any identifying information. This is explained in detail in relation to Figure 7; It should be noted that each device transferring files to DCDS 32 can be identified by recording and mapping the header fields of the incoming file transfers. Additionally, the devices may be identified in part based on their network address, the AE title used for transmission, or both. Each device can be given a meaningful name that is unique and desirable to the operator. A file, as well as its series, study, or both, can be identified by device derived from a header field that identifies the time and date the image was captured and the operator of the device used to capture the image.

Since no patient information is needed, DCDS 32 can handle anonymized data, and patient information cannot be collected by misuse of the system. Additionally, the most frequently used images may be stored as the most recent images in the system. Therefore, finding images can be done very efficiently in this way. Once the file, series, study, etc. is located, GUI 208 allows the operator direct access to functions such as viewing the image, sending the image, etc.

With this in mind, Figure 7 is a flow diagram illustrating a typical use of the Web GUI 208, according to one embodiment, a streamlined interface for retrieving images in their original form without any identifiable patient information 401-404. . Once the image is identified (405), the interface displays a service request form in which the user enters output destination information and other message details. If the data is valid (407), the necessary conversion is requested from the image converter 211 (408). For all successful requests, the data is assembled by the appropriate output plug-in (409-411) and the results are sent (412-414) to the appropriate destination. Status information for each individual output is collected (415) and returned to the form view (405) (416 or 417). At this point, the user can choose to repeat the transfer process or find another image.

Web GUI 208 allows transferring groups of images belonging to the same DICOM series, for example. The operating steps are similar to those shown in Figures 7 and 8. Additionally, the Web GUI 208 configures the event system 209 and provides an interface for organizing and storing output destination addresses and other necessary management tasks. It should be noted that as a security measure, the Web GUI 208 does not store images or process authorization of source forms to be granted access privileges to their images. These important settings are only available through separate access methods: locally or remotely. For DCDS running on Unix-style operating systems, remote access can typically be achieved via the Secure Shell (SSH) protocol. If the DCDS runs on a Windows operating system, remote access can typically be achieved through Terminal Services. Both protocols are examples of secure remote access to the operating system.

The second way to access files is using identifying information. For example, operators can search files using patient information such as name, date of birth, and patient ID. For example, the operator can enter a search term, and if a match is found, the system can provide all available studies. If multiple patients are returned, they can then be presented for selection. Once a patient has been selected and the associated files, series, studies, etc. have been found, GUI 208 allows the operator direct access to functions such as viewing images and sending images.

8 is a flow diagram illustrating a variation of a typical use of the Web GUI 208 and its simplified interface to find images by using some of the identifiable patient data 501-504, such as patient name and date of birth. Additionally, patient privacy can be ensured by using an unrelated identification password or PIN code to avoid using actual patient information. Thereafter, processing steps as described above with respect to FIG. 7 may be performed.

In certain embodiments, CCS 30 may be configured to host and support various value-added services to patients and families, for example, in connection with the images captured by modality 10, as shown in Figure 9. It can be interfaced with a server 902. For example, if the image is a fetal ultrasound image, the server 902 may be configured to provide various services to parents, family, friends, etc. For example, the DCDS 32 may be configured to convert images to an appropriate format or format supported by server 902 and associated services. The image may be transmitted to server 902 and stored in storage system 904.

It should be understood that the server 902 may actually include multiple servers, computers, routers, as well as appropriate software and firmware as required to perform the functions described herein. Storage system 904 may also include one or more databases, one or more storage servers, and other physical storage media as needed.

Server 902 may be configured, for example, to host a website where users can create accounts. The user can then access the site's images and purchase images, pregnancy calendars, personalized mugs, keychains, t-shirts, canvases, etc. Additionally, the site may be configured to provide pictures, illustrations, information about fetal and child development, health and nutritional information, etc. These sites include, for example, registries such as baby showers; Automatic updates to friends and family; Digital and viral gifts such as baby videos with digital lullabies; Invitation and thank you cards make this service possible.

Users may be charged a one-time or periodic fee to set up an account, such as a subscription fee, and users and their family and friends may be charged for various products and services, or both.

Kiosk 908 could also be set up, for example, in a maternity ward where it could provide at least some of the same services. Kiosk 908 can be interfaced alone, i.e., directly with CCS 30, or with server 902, as indicated. Family and friends can therefore order photos and other items, for example, from the waiting room.

Additionally, users can continue to use their accounts even after the child is born. For example, the site may track a child throughout childhood, or at least for several months or years. The site may be configured to send birthday reminders and notifications to friends and family, other special events, developmental milestones, etc. Additionally, the site may be configured to continue to display health and nutritional information, as well as developmental information for both mother and child.

In fact, it may be desirable to have parents upload contact information for friends and family. In this way, server 902 can be configured to continually send birthday reminders to friends and family. In certain embodiments, the site hosted by server 902 may be affiliated with or hosted a “gift store” that offers a variety of products and services. Additionally, the site may provide discounts, coupons, etc. to various other businesses and stores. Since the server 902 will have pertinent demographic information related to the child, such as residence information, gender, age, race, and even parental age, occupation, and other affiliations, the site can be used to provide information about children and families with similar demographics; You can send appropriate reminders, gift recommendations, discount offers, etc. to the public.

In this regard, it may be desirable to provide users with the opportunity to provide such demographic information. Accordingly, in one embodiment, a user may access the site to customize or provide profile information, contact information, preferences, etc. Algorithms running on server 902 may then be configured to use the available information to make product recommendations, etc. In fact, since server 902 has information about individuals from all over the world, the algorithm can be configured to make recommendations using information about populations that share similar demographics, income levels, preferences, etc.

In certain embodiments, users may purchase items through the site, i.e., through server 902. For example, server 902 may be configured to accept credit card payments, PayPal accounts, or mobile billing. Accordingly, server 902 may be configured to process transactions and deduct appropriate fees or charge transaction fees to associated businesses, affiliates, partners, etc. Additionally, purchase information can be fed into the algorithm and used to make future recommendations. In fact, through buy-in from the entire relevant population, more targeted and relevant recommendations can be made.

Therefore, as the child grows, the algorithm can be constantly updated and refined, for example to make gift recommendations. Recommendations can be automatically sent to friends and family for years. As the database grows over time and includes more and more users, the algorithm can be refined to provide more relevant and more targeted recommendations.

It should be noted that the database must contain extensive information about relationships and connections between large populations. This includes direct links such as friends and family, as well as indirect links such as preferences and similar purchasing habits. This could be very useful for simply tracking and mapping interconnections between large populations, as well as for targeted advertising and product recommendations.

It should be mentioned that such sites may be built around other conditions or events, such as cancer support sites, physical therapy support sites, etc. Additionally, merging interconnected data about these various different conditions and events can expand the power of information and lead to better algorithms for targeting information, products and services.

Additionally, it should be noted that users may access the site using computers 914 and mobile devices 912, for example, via the Internet. Additionally, the site may be interfaced with other social networking sites such as Twitter and Facebook. In certain embodiments, the site can actually be converted into an application or widget that can be sent to other sites. For example, a grandmother could place an application on her Facebook page and easily receive updates and notifications without having to log on to server 902. This may increase interaction with the site, for example, increasing the amount of information and data that server 902 can use as input to the algorithm described above.

Although specific embodiments are described above, the above-described embodiments are to be understood as examples only. Accordingly, the systems and methods described herein are not limited based on the described embodiments. Rather, the systems and methods described herein should be limited in light of the claims when taken together with the foregoing description and accompanying drawings.

Peripheral encryption and conversion devices

In one embodiment, a medical imaging device for encrypting and converting medical images into a secure and standardized image file format is attached to the peripheral device, and can also transmit the encrypted and/or converted images to a secure server on a remote network. . As shown in FIG. 10 , the peripheral device 102 may be a dongle that can be physically attached to the medical imaging device 101 or another type of stand-alone device, and may be connected to a remote server 103 on a different network from the medical imaging device. ) may have its own processor and memory to execute various functions related to the conversion, encryption, and transmission of medical image files. The peripheral device 102 may be attached to a communication port on the medical imaging device, such as a network port, serial port, or other communication interface. The peripheral device monitors all medical image files generated by the medical imaging device and acts as a filter to encrypt and convert selected medical image files for transmission to remotely connected devices on other networks, such as servers or mobile devices. You can.

The dongle may be configured with a separate network connection to a local area network (LAN) or a wide area network (WAN), or may be configured to use a network already connected to the medical imaging device. If the medical imaging device is not connected to a network or is connected to a network that cannot transmit medical images, the dongle does not have network hardware that allows the dongle to communicate via WiFi or a cellular network or directly connect an Ethernet cable to the medical imaging device. You can allow access to local networks that are not connected to the network.

In other embodiments, the encryption dongle 102 may be connected to the imaging device 101 with an insecure connection, in which case the encryption dongle 102 can take medical images stored on the medical imaging device 101 and place them on a secure network. The image can be encrypted for transmission through a connection and function as a remote device, such as a remote security server or a mobile device that is the final destination of the medical image.

One embodiment provides a method and technical system for encrypting and routing DICOM network connections from devices without such encryption functionality built-in.

One embodiment of the invention can listen on a known port for unsecured communications and automatically encrypt and route the connection in its encrypted form through the port's encrypted counterpart. For example, a normal DICOM connection on TCP port 104 or 11112 could be encrypted with SSL/TLS and routed with DICOM/TLS on TCP port 2762. This effectively allows the connection to appear to the remote server as a secure TLS connection, and to the client device as an unsecured connection. By connecting embodiments of the invention to a network port of an imaging device or a network router on the same protected local network as the device, a high level of security is maintained.

Likewise, a normal “web” connection via the HTTP protocol on TCP port 80 may be encrypted with SSL/TLS and routed as HTTPS on TCP port 443. This effectively allows the connection to appear to the HTTP server as an HTTPS connection and to the HTTP client as an unprotected connection. Here, it should be noted that encrypting HTTP traffic is only useful on older clients and servers with secure connections. However, it is a well-known pair of network ports that serve to illustrate a general embodiment of the invention.

Embodiments of the invention include wireless network connectivity, such as WiFi or cellular modem capabilities, to provide encryption as well as access to the Internet without a network infrastructure existing in the vicinity of the imaging device. This is very useful for portable devices that can run on battery power while on the go.

Embodiments of the invention may be pre-configured to only forward protected traffic to a single remote endpoint.

Embodiments of the invention may use any and all relevant encryption methods to secure the connection. Examples or these include the SSL/TLS standards described above, as well as other common encryption standards. The point is that the present invention can emulate native encryption standards for each type of connection that the embodiments support. Encryption can be encoded and decoded by a dedicated chip (electronic hardware component), software, or a combination of software with hardware acceleration.

Network encryption and conversion devices

A network device for connection to a local network that includes at least one medical imaging device is capable of encrypting and converting medical images from the at least one medical imaging device to a secure, standardized image file format, as well as to a secure server on a remote network. Provides communication of encrypted and/or converted images. The network device acts as a router or gateway on the local network, monitoring traffic of medical images from medical imaging devices to destination devices outside the local network, and ensuring that the medical data files are formatted appropriately for delivery to devices on the remote network. It can be encrypted and converted. Upon detection, the network device will encrypt and convert the selected medical image file for transmission to a remotely connected device on a remote network, such as a server or mobile device.

One embodiment of the network device is shown in Figure 1, where the network device 104 acts as an encryption router to receive medical image files from one or more medical imaging devices 101 over a local network that may be insecure. Do it. Afterwards, the encryption router 104 will be configured for encryption and conversion of medical images into a secure and standardized image file format. Thereafter, the encryption router 104 will be configured for communication of the encrypted and/or converted image through a secure connection to a security server 103 on a remote network such as the Internet.

In one embodiment, the network device 104 will create a private network for one or more medical imaging devices 101 to communicate. The network device 104 can then transmit the encrypted DICOM image to a remote network via WiFi, cellular (3G), or cable connection. In this configuration, the network device 104 acts as a network gate to ensure that all medical images transmitted outside the local network are converted and encrypted.

12 shows a flow diagram of the data flow of medical image files from a local area network (LAN) 301 to a remote device on a remote wide area network (WAN) 307. The network device 104 may be one or more of the components described herein, including an encrypted listening port 302 that monitors network traffic on the LAN for transmission of unencrypted or unconverted medical image files in an appropriate format. Includes. The encryption database 305 may store encryption settings that provide instructions for the type of encryption with which a particular medical image file should be encrypted, possibly depending on the type of network or destination device on the remote WAN network 307. The medical image file is processed for file encryption (303) and then mapped for transmission of the file (304). The encrypted file is transmitted to the remote WAN network 307 through a firewall or other local router 306.

In one example, the Vscan imaging device is non-DICOM and non-encrypted, but captures medical images that are selected for transmission from Vscan to a remote secure server on a remote network. The medical image is then transmitted to network device 104, which converts the image into a DICOM image and encrypts the image before transmission to a remote secure server.

The network device can be useful in insecure or untrusted local networks because it creates secure connections to medical imaging devices and remote access servers or devices on other networks. Additionally, the network device may be useful in highly secure networks with strict firewalls preventing access to remote secure servers.

In one embodiment, the network device is attached to a local network but acts as a remote secure server from which one or more medical imaging devices transmit the images to the network satellite with the caveat that the network satellite is the final destination for the medical image files. It can be configured as a network satellite. The network satellite then takes the medical images, encrypts or converts them (both), and transmits the encrypted and converted images to an actual remote secure server. In this embodiment, the medical imaging device does not need to be instructed to transfer the medical image file to a new location on the network, such as a network device, but instead sends the file to a remote network for what it believes to be the final destination for the medical file. It is transmitted to a remote secure server on the computer.

One embodiment provides a method and technology system for encrypting and routing DICOM network connections from devices that do not have any such encryption capability built-in.

One embodiment of the invention can listen on a known port for unsecured communications and automatically encrypt and route the connection in its encrypted form through the port's encrypted counterpart. For example, a normal DICOM connection on TCP port 104 or 11112 could be encrypted with SSL/TLS and routed with DICOM/TLS on TCP port 2762. This effectively allows the connection to appear to the remote server as a secure TLS connection, and to the client device as an unsecured connection. By connecting an embodiment of the invention to a network port of an imaging device or a network router on the same protected local network as the device, a high level of security is maintained.

Likewise, a normal “web” connection via the HTTP protocol on TCP port 80 may be encrypted with SSL/TLS and routed as HTTPS on TCP port 443. This effectively allows the connection to appear to the HTTP server as a secure HTTPS connection and to the HTTP client as an unsecured connection. Here, it is important to note that encrypting HTTP traffic is only useful for older clients and servers with secure connections. However, it is a well-known pair of network ports that serve to illustrate a general embodiment of the invention.

Embodiments of the invention include wireless network connectivity, such as WiFi or cellular modem capabilities, to provide encryption as well as access to the Internet without a network infrastructure existing in the vicinity of the imaging device. This is very useful for portable devices that can run on battery power while on the go.

Embodiments of the invention may be pre-configured to only forward protected traffic to a single remote endpoint.

Embodiments of the invention may use any and all relevant encryption methods to secure the connection. Examples or these include the SSL/TLS standards described above, as well as other common encryption standards. The point is that the present invention can emulate native encryption standards for each type of connection that the embodiments support. Encryption can be encoded and decoded by a dedicated chip (electronic hardware component), software, or a combination of software with hardware acceleration.

Encryption and conversion plugins

Systems and methods are provided for encrypting and converting medical image files on devices within a network. An encryption and conversion unit may be integrated within the hardware and software of a medical imaging device or other network device to encrypt medical images and convert the medical images into a format compatible with the destination device or network for transmission to a remote network. You can. The encryption and conversion unit may be configured to package and transmit the converted and encrypted image to an appropriate destination, such as a secure server on a remote network.

The encryption and conversion unit monitors traffic of medical images from the medical imaging device to a destination device outside the local network and ensures that the medical data file is encrypted and converted into an appropriate format for delivery to the device on the remote network. For this purpose, it can act as a router or gateway on the local network. Upon detection, the encryption and conversion unit will encrypt and convert the selected medical image file for transmission to a remote access device on a remote network, such as a server or mobile device.

One embodiment of the encryption and transformation unit is shown in Figure 13, wherein the encryption and transformation unit 104 receives medical image files from one or more medical imaging devices 101 over a local network, which may be insecure. Acts as an encryption router. The encryption and conversion unit 104 may be integrated within each medical imaging device 101 as software, hardware, or a combination of software and hardware. In other embodiments, the encryption and conversion unit 104 may be part of a router, gateway, firewall, or other network device that monitors and regulates traffic through the network. Thereafter, regardless of the type of device on which it is deployed, the encryption and conversion unit 104 will be configured to encrypt and convert medical images into a secure and standardized image file format. Thereafter, the encryption and conversion unit 104 may be configured for communication of the encrypted and/or converted image via a secure connection to a security server 103 on a remote network such as the Internet.

12 shows a flow diagram of the data flow of medical image files from a local area network (LAN) 301 to a remote device on a remote wide area network (WAN) 307. The encryption and transformation unit 104 includes either one or more of the components described herein: software, hardware, or a combination of both. In one embodiment, the encryption and conversion unit 104 includes an encryption listening port 302 that monitors network traffic within the LAN for transmission of unencrypted or converted medical image files in the appropriate format. The encryption database 305 may store encryption settings that provide instructions for the type of encryption with which a particular medical image file should be encrypted, possibly depending on the type of network or destination device on the remote WAN network 307. The medical image file is processed to encrypt the file (303), and then the port is mapped for transmission of the file (304). The encrypted file is transmitted to the remote WAN network 307 through a firewall or other local router 306.

In one example, a Vscan imaging device is non-DICOM and unencrypted, but captures medical images that are selected for transmission from the Vscan to a remote secure server on the remote network. The encryption and conversion device 104 is embedded in software running on the Vscan device, thereby converting the image to a DICOM image and encrypting the image before transmission to a remote secure server outside the Vscan device.

The encryption and conversion unit may be useful in insecure or untrusted local networks because it creates secure connections with medical imaging devices and other remotely connected servers or devices on the network. Additionally, the network device may be useful in highly secure networks with strict firewalls preventing access to remote secure servers.

In one embodiment, a method and technical system is provided for encrypting and routing DICOM network connections from devices that do not have any such encryption capability built-in.

One embodiment of the invention can listen on a known port for unprotected communications and automatically encrypt and route the connection in its encrypted form through the port's encrypted counterpart. For example, a normal DICOM connection on TCP port 104 or 11112 could be encrypted with SSL/TLS and routed with DICOM/TLS on TCP port 2762. This effectively allows the connection to appear to the remote server as a secure TLS connection, and to the client device as an unsecured connection. By connecting embodiments of the invention to a network port of an imaging device or a network router on the same protected local network as the device, a high level of security is maintained.

Likewise, a normal “web” connection via the HTTP protocol on TCP port 80 may be encrypted with SSL/TLS and routed as HTTPS on TCP port 443. This effectively allows the connection to appear to the HTTP server as a secure HTTPS connection and to the HTTP client as an unsecured connection. Here, it should be noted that encrypting HTTP traffic is only useful for older clients and servers with secure connections. However, it is a well-known pair of network ports that serve to illustrate a general embodiment of the invention.

Embodiments of the invention include wireless network connectivity, such as WiFi or cellular modem capabilities, to provide encryption as well as access to the Internet without a network infrastructure existing in the vicinity of the imaging device. This is very useful for portable devices that can run on battery power while on the go.

Embodiments of the invention may be pre-configured to only forward protected traffic to a single remote endpoint. Embodiments of the invention may use any and all relevant encryption methods to secure the connection. Examples or these include the SSL/TLS standards described above, as well as other common encryption standards. The point is that the present invention can emulate native encryption standards for each type of connection that the embodiments support. Encryption can be encoded and decoded by a dedicated chip (electronic hardware component), software, or a combination of software with hardware acceleration.

Mobile device implementation of encryption and conversion unit

In certain embodiments, for example, the encryption and transformation functions described above with respect to FIGS. 10-13 may be implemented on a mobile device, such as a smartphone, tablet, or other mobile device. This is shown in Figure 26, for example the encryption and conversion unit 105 in Figure 13 is a mobile device 107 on which software 109 is installed which allows the mobile device to perform encryption and conversion functions as well as routing functions. is replaced with

In many embodiments, the encryption and transformation functions may be integrated with mobile device 107 by downloading application 111 to device 107. The application 111 may then include or allow the user to download software 109 to perform the required function. Accordingly, the software 109 may be compliant for the processor architecture of the device 107.

Software 109 may act as a router or TCP proxy through data transmitted from device 101, such as a portable ultrasound machine. From the ultrasound machine's perspective, it may appear that it is communicating directly with the Dicom server on the device 107, but in reality it will be communicating directly with the hosted server 103 through an encrypted tunnel or secure connection provided by the device 107.

The port used by device 107 is often 104, but in rare cases there is also an alternate port 1112 that is used whenever there is a need to stay at the upper port 1024.

In certain embodiments, the software may require either a one-time use or a subscription. Accordingly, the system may be configured so that a certificate can be provided to the software 111 by, for example, the server 103. Typically the certificate may be set to expire, so the application 109 may enable a process where the customer pays for a reissue, for example, to extend the validity period of the certificate. This can simply be called “signing up.” Auto-expiration can be very useful in this scenario. Accordingly, the application 109 may include functionality to patch new certificates and, for example, automatically install them.

The application 109 may include payment capabilities that allow the user to sign up or pay for one-time use, e.g., for an extended or new period for which the software has a valid certificate, using a credit card, mobile wallet, or other account.

In certain other embodiments, a more advanced user interface may be included in the application 109 that allows the user to interact, monitor, troubleshoot, or virtually all of the functions of the software 1111. This may include connection verification, existence of a secure connection, upload and download speeds, etc.

In certain embodiments, mobile device 107 and imaging device 101 may communicate via a wireless communication link, such as NFC, BlueTooth™, or WiFi. Accordingly, a communication dongle, not shown, may interface with the device 101 to enable such wireless communication, or such capability may be included in the device 101.

The mobile device 107 may sequentially communicate with the server 103, etc. through, for example, a 3G/4G WAN system. However, in other embodiments, device 107 may use a WiFi connection to communicate with server 103, for example. For example, it acts as an encryption device by allowing a tablet without 3G/4G capabilities to still connect to the local network via Wi-Fi (which can be reached by any modality 101 capable of using it).

For example, if device 101 uses Wi-Fi and then device 107 uses a wireless WAN to communicate with server 103, then device 107 uses a Wi-Fi base station. and serves as a router to which, for example, the ultrasound machine 101 is connected. The IP address to which the ultrasound machine connects is the IP address of the device 107, and is the same as the router IP address that the ultrasound machine obtains when configuring itself through DHCP.

Image management integration

Systems and methods are provided for integrating various communication protocols and file types related to medical imaging. The system integrates current interfaces with third-party software by adding software and intelligence to the current interfaces to provide communication with third-party image management software.

In one embodiment of the integrated software, a medical imaging user interface, such as the GE Viewpoint Interface, generates a plurality of medical images in portable document format (PDF). Thereafter, the systems and methods described herein convert the PDF document into an image document in DICOM format, which is then transmitted to a specific destination and then converted to PDF for viewing on a suitable electronic device, such as a personal computer or portable electronic device. You can.

In another embodiment, the HL7 protocol device is used for medical software communication and includes packets at the destination of specific documents. For example, images created by the HL7 device need to be transmitted to a doctor or patient. The integration software obtains information about the image, combines this with command information to the destination for the image, and adds it to a DICOM message.

The integrated software operates by obtaining the necessary information from third party software systems and determining what information is needed to convert, encrypt and transmit the image to the appropriate destination.

Real-time remote interaction

The systems and methods described herein provide live or real-time remote diagnosis of a patient's medical problem using one or more medical images of the patient taken with a medical imaging device, such as an MRI. The system can be implemented as a network with multiple computing and display devices that present a graphical user interface (GUI) to each user so that the users can all view the same medical image in real time. The user is also provided with the option to annotate the image in real time, chat the image through an instant messaging program, or communicate using Voice over Internet Protocol (VOIP) or a traditional conference call system. The system provides multiple menus for a user to organize images, select diagnoses and other actions, and otherwise collaborate with multiple users in real time to perform a medical diagnosis based on one or more medical images. .

Figure 16 shows the overall workflow for real-time remote interaction, where the user first displays a dashboard or home screen showing various options for collaboration to diagnose. The dashboard is further shown in Figure 18. Medical images from the Vscan device can be presented to the user, after which the examination screen process can be undertaken. During test screening, the image may be sent to the patient, the test may be sent to the patient, and the resulting information may be sent for diagnosis. Afterwards, live or real-time diagnostics can be performed. In a true emergency situation, the flow chart indicates that these steps can be omitted for emergency diagnosis without collaboration with remote users.

Figure 17 shows the overall GUI presented to the user when viewing the display of a computing device on a network. A main menu, main content area, and navigation and information sections may all be provided.

Figure 18 shows a "dashboard" GUI that lists medical imaging devices connected to the entire network or the user's actual computing device (such as a medical imaging device on the user's local network at a hospital or medical facility). Additionally, the dashboard lists images captured by their devices, which can then be sorted by capture order, by patient, by doctor, etc. When new images are received, they are moved to the top of the list and highlighted, allowing users to easily find them. In one embodiment, when a new image or images are captured by a particular device, an alert will be sent to the appropriate physician or healthcare provider handling the patient's case, such as an SMS or email message. Additionally, the dashboard may provide a search function that allows the user to search through a database of the images and information related to the images and the patient.

Figure 19 shows more details of the main menu GUI; Option to select DICOM images (where the main image workflow is found); an inbox where a user receives messages from the system or from other users; Recipient icons for patient or other user contacts that can be easily found and contacted for sending images and messages; Settings icons to handle settings of imaging devices, anonymization or automation of patient messages and labels to categorize studies; Statistics icon showing traffic through the entire application over time; Admin icon to indicate that the administrator manages user accounts and sets branding for patient images; An account icon that allows non-administrators to review their profile and other account details; and a logout icon that allows the user to log out of the system. It should be understood that the icons and options listed herein are subject to change and are not limited to their descriptions.

20 illustrates one embodiment of an image workflow, where an image or study of images can be selected from a list for further review. The study information may include the number of files and labels assigned to each study, as well as the number of comments on a particular study and image by other users. Different icons may be provided for still images, videos, comments, etc. The label may be applied to a proposed diagnosis, or to a specific type of image or images included within the study.

Figure 21 presents a series of images as thumbnails that can be quickly reviewed before selecting one or more images for further review. A list of actions is provided at the top of the GUI, and different icons on the thumbnail provide an indication of whether the thumbnail represents video and whether it is a specific image format (DICOM, etc.). The user can open the entire image or video by clicking or selecting one of the thumbnails.

22 illustrates a real-time remote interaction collaboration GUI in which medical images are displayed with annotations made on the images by one or more users. A chat screen is displayed where the users can enter instant messages to each other in the process of discussing the patient's diagnosis, and a list of thumbnails of other images from the study may be provided at the top. The thumbnail may be updated as new images are received. The “Live Diagnostic Screen” is a real-time collaboration tool that updates all information in real time and synchronizes edits between users, including comments, chats, actions, selected images, pins, and other changes. The live diagnostic screen can be particularly useful in emergency room situations where immediate diagnosis is needed. From the chat screen, the user can invite additional participants and take one or more other actions related to the case.

Figure 23 shows one embodiment of an action that can be selected on a chat screen, and may be a method of providing unambiguous commands to other users, such as doctors or nurses providing treatment to a patient. Additionally, the Action tab provides tracking of selected actions and can be provided to those who have performed or suggested actions so that the patient's treatment can be properly documented. In the Invite Collaboration tab, users can invite more users to the live diagnostic process. The invited user may receive a text message, email, or phone call inviting him or her to participate in a live chat session. The user interface may be adapted to any type of computing device, including mobile phones and tablets, to allow other users to participate from any location and from any type of portable electronic device.

Figure 24 shows a GUI in which a diagnosis may be requested for a specific patient based on a series of images. The user can select different options for the interests and possible diagnoses being investigated. When a request is sent, one or more users may be notified via email, text, or phone, and an inbox screen may be provided to display when a response arrives.

As shown in Figure 25, a GUI for diagnosis is provided in which several images and a plurality of menus are provided to select an appropriate diagnosis. The image can be downloaded to a computer desktop for more detailed viewing with other software tools. Options for potential diagnoses can be highlighted or selected. Once a final decision has been reached, the medical certificate is sent and recorded for future review and research.

Receive pipeline implementation

In an embodiment, DNS and specific ports are requested as described with respect to FIGS. 10, 11, and 13. However, in certain embodiments, standard ports can be used to eliminate the need for DNS. In this embodiment, the specific communication routine is an application that can be loaded on the imaging device 101 or a computing system that interfaces with the device 101. These communication routines may communicate, for example, with a DICOM imaging application on the device to take a DICOM image, encrypt the image, provide labeling and accounting information, and then forward this information to a server or servers. Among other things, the label and account information may be used as input to the calculation of a personal pre-shared key, which may be used for encryption, as described in more detail below. Additionally, this information may be used to determine whether the account has been suspended to prevent random transmissions when the account is suspended.

FIG. 29 is a diagram illustrating an example system 2900 comprised of communication routines, processes, etc. (routines 2906) that perform this message generation function, according to one embodiment. In the example of FIG. 29 , the routines 2906 may be included in a device, such as a terminal 2904 coupled to device 101 or within device 101 itself. Terminal 2904 may be a computing device, including a portable computing device such as a laptop, tablet, or smartphone. The routines 2906 take images from device 101, generate image data, labeling, accounting information, and other information that may provide information on how to process the image data, and generate the image data or The entire message may be encrypted and delivered over the network 2908 to one or more servers 2912 and storage locations 2910.

Network 2908, storage location 2910, and server 2912 may represent the basic cloud structure.

As discussed above, labeling and accounting information may, for example, direct or at least provide information necessary to enable server 2912 to process the message and the image data contained therein. For example, the label and account information may instruct server 2912 to store and associate the image data with an account of a particular clinician, group of clinicians, hospital, etc., and the image data may be stored in a view such as that described above. You can access and view them later with the application. Additionally, labeling and accounting information may direct the server 2912 to forward the images to a clinician or patient device or website.

Routines 2906 may also, in certain embodiments, provide functionality that allows the image data to be converted to another format that can be more easily transmitted to and processed by server 2912, or to a format associated with a destination. Additionally, routine 2906 may eliminate the need for DNS or the use of special ports.

27 and 28 show example implementations of these two routines 2906 or daemon processes called Image Data Receiver 2702 and Communications 2704. The following is a description of these daemon processes. First, as shown in FIG. 27, routines 2906 may include image data receiver 2702 (Dcmtk::storescp). As can be seen, subprocesses 2704 (Trice::sendFile) can be linked and these processes can be configured to send image files, such as DICOM image files, from the cloud to receiver routine 2710 (Trice:receiver). .

Transport Layer Security (TLS) may, in certain embodiments, be achieved using a private pre-shared key unique to the device. The key is an encryption key that requires both the sender and receiver to successfully calculate the same key for the transmission to succeed. Account information and labeling can be two inputs into this calculation. The depicted configuration should provide a robust file copy function that can succeed when there is random connectivity between device 101 and the cloud. Any failure in the communication pipeline shown in FIGS. 27 and 28 may result in a failure to respond to device 101 and may cause device 101 to attempt to retransmit image data.

Additionally, the communication routine 2704 can be configured to communicate with the receiver 2710 as shown in FIG. 28. Communications routines 2704 may be responsible for initialization, sending "heartbeats" to the cloud, failure reporting, configuration updates, and software updates, if permitted.

A local directory 2706 with read/write access may be included to store configuration information. The location of this directory 2706 can be passed as an argument to both daemon processes 2702 and 2704. In most embodiments, there is no requirement regarding its disk location for directory 2706. The directory 2706 can store information such as port #, local-ip address, DICOM dictionary, and error log. If device 101 is a DICOM imaging device, then the DICOM service can load a DICOM dictionary, for example, from this directory 2706. As described herein, a heartbeat message is sent to the cloud receiver containing the port# and local-ip address and can be read from this directory 2706. Additionally, logging information may be stored in this directory 2706.

A unique name can be calculated for the device 101. If there is a device ID associated with device 101, then the device ID should be used instead of the calculated name. If the device ID is present, the file name including the device ID can be passed to the communication routine 2704. This device ID may be the primary key for everything related to the uplink/device in the cloud database. The cloud service: When the last heartbeat occurred from the device; When the device first comes online; What version of software is loaded on the device?; What account is associated with the device? You can search etc. The uplink depicted in Figures 27 and 28 can be called a heartbeat and transmits periodic status information that can be persisted to the cloud using the device ID as the primary key. Additionally, it should be noted once again that a standard port (e.g., 443) is used for all communications.

Claims (14)

In a dongle that can be physically attached to a port of a medical imaging device,
The dongle:
Network hardware for communicating over a network; and
When the dongle is physically attached to a port of the medical imaging device, it monitors medical image files generated by the medical imaging device, encrypts at least one of the medical image files, and transmits one or more encrypted medical image files to a network. A dongle, including a processor, configured to transmit to at least one remote device via a dongle. According to claim 1,
The network is a wireless network, a dongle. According to paragraph 2,
A dongle wherein the network hardware is a Wi-Fi modem and the wireless network is a Wi-Fi network. According to paragraph 2,
The dongle wherein the network hardware is a cellular modem and the wireless network is a cellular network. According to paragraph 1,
The network hardware is a dongle, which allows for Ethernet cable connection. According to paragraph 1,
wherein the connection between the medical imaging device and the dongle is unstable and the connection between the dongle and the at least one remote device is secure. According to clause 6,
wherein the processor monitors a known port of a medical imaging device for unencrypted medical image files and routes the encrypted medical image file through an encrypted counterpart of the known port. According to paragraph 1,
The processor dongle provides Internet access to the medical imaging device. According to paragraph 1,
The dongle transmits all encrypted medical imaging files to only a single remote device. According to paragraph 1,
wherein the processor is further configured to associate a device identifier of the medical imaging device with each of the one or more medical image files. According to paragraph 1,
wherein the processor is further configured to associate account information with each of the one or more medical image files. According to paragraph 1,
wherein the processor is further configured to convert each of the one or more medical image files from an input format to an output format. According to clause 12,
wherein the input format is not compatible with the at least one remote device and the output format is compatible with the at least one remote device. According to clause 12,
The input format and the output format are round, different in one or both of image resolution or image quality.