CN107004059A - System and method for encrypting, changing and interact medical image - Google Patents

Abstract

A kind of system for transmitting image, the system includes：Imaging device, the imaging device is used to catching, be imaged and generating digital image file, and the imaging device includes device identifier；A series of routines, a series of routines are used to mark the digital image file, accounts information is associated with the digital image file, the device identifier is associated with the digital image file, and the digital image file is sent to server；And server, the server is used to receiving digital image file and at least one according to the label associated with the digital image file, the accounts information associated with the digital image file and in the device identifier associated with the equipment of the seizure digital image file is handled the digital image file.

Description

Systems and methods for encrypting, converting and interacting with medical images

technical field

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

related technology

In recent years, medical diagnostic equipment and medical imaging systems have become increasingly complex. In response to the increasing challenges of digital imaging technology, the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) developed the Digital Imaging and Communications in Medicine (DICOM) standard. DICOM is a standard for processing, storing, printing and transmitting information in medical imaging. It includes file format definitions and network communication protocols. A network communication protocol is an application protocol for communicating between systems using TCP/IP. One of the goals of the standard is to make the transfer of medical images and information consistent between viewing sources and scanning sources, so that users of different imaging software and/or hardware can share information. DICOM files can be exchanged between two entities capable of receiving images and patient data in DICOM format. DICOM enables the integration of scanners, servers, workstations, printers and network hardware from multiple manufacturers into a Picture Archiving and Communication System (PACS) for storing and downloading digital images. The different devices are accompanied by a DICOM Conformance Statement which clearly states which DICOM categories they support. DICOM has been widely adopted by hospitals and is gaining popularity in smaller dentist's and doctor's offices.

DICOM files usually contain images; therefore, they are often called DICOM images. However, it is to be understood that DICOM files do not necessarily need to include images. Rather, such files may include metrics or reporting data. Thus, a DICOM file may contain media data, such as video and audio data, or no media data at all. In this case, the DICOM file may only contain metadata identifying the originating modality, operator or patient being examined. Modality here refers to any image producing device in medical imaging, such as ultrasound (US), magnetic resonance imaging (MRI), computed tomography (CT), positron emission tomography (PET), radiographs, etc.

The type and amount of data available in any one DICOM image file varies. DICOM files are typically structured in this hierarchical order using data identifying Patient, Study, Series, and Instance. A patient can be included in several tests (cases), which in turn can contain several series (examinations or visits), which in turn can contain several instances (files usually containing images). This means that DICOM files can be unambiguously identified and placed into this hierarchy. All DICOM files contain an identifier for the resulting modality. In other words, the identifier will reflect the device or location from which the file originated. These files also contain timestamps on both the file itself (instance) and the series. By using a timestamp and an originating identifier, this data can be used to unambiguously identify the image without involving any identifiable patient information, protecting against patient privacy concerns. Additionally, the DICOM file format differs from other data formats because it groups information into data sets. For example, a file for a chest x-ray image actually contains the patient ID within the file so that the image can never be mistakenly separated from this information.

Most PACS process images from various medical imaging instruments (including US, MRI, PET, CT, etc.). Electronic images and reports are transmitted digitally through the PACS; this eliminates the need for manual filing, retrieval or shipping of film folders. A PACS consists of four main components: imaging modalities, such as CT and MRI; a secure network, for transferring patient information; workstations, for interpreting and reviewing images; and long-term and short-term archives, for storage and retrieval images and reports. Combined with available emerging Web technologies, PACS has the ability to deliver images, interpretations, and related data in a timely manner and to access images, interpretations, and related data efficiently. PACS breaks down the physical and temporal barriers associated with traditional film-based image retrieval, distribution and display.

Medical imaging devices typically output digital image data. The vast majority, if not all, of such devices use the DICOM standard for both image file format and network transfer. These images are generally not readable by consumer image viewers or mobile devices. Accordingly, patients wishing to share their medical images strive for conversion and delivery of these images. A good example is sharing images from ultrasound exams during pregnancy. Future parents often want to preserve, share and display images of their future children. They may also want to send these images to the cell phone or email accounts of their friends and relatives. They might even want to post them on social networks, or they might want to keep them in their personal digital "album". All of these events will require them to scan a printed hard copy of the image, or find, purchase, install and learn to use a DICOM viewer package with export capabilities. These packages are often not readily available, or they are uneconomical for limited use.

It should also be noted that this problem is not necessarily limited to DICOM files. Often, patients have no practical way to view images related to their disease, treatment, state, etc. Furthermore, there are few, if any, effective means by which doctors or clinicians can quickly and remotely retrieve images for diagnostic or other purposes.

In fact, many smaller medical practices, such as small clinics, doctors' offices, and dentists' offices, suffer from the inability to convert, transmit, and receive medical images economically and in a timely manner. These facilities typically do not have the technical support staff or funds to run an entire PACS for image archiving and delivery of images to remote specialist physicians for second opinions and consultations. They usually rely on the use of film or writable CDs sent by mail or courier. This is slow, an unfriendly environment, and unsafe when using unregistered mail. The cost of running a PACS goes beyond paying the license fee. Major investments in high-level architecture including surrounding software, hardware and facilities, as well as costs for educating staff and time spent on administration will add to the cost of running a PACS. These major investments are expensive and, therefore, generally out of reach for most small businesses.

Additionally, many medical practices may not have a local network to which the medical imaging equipment transmits, or the local network may not be secure or properly used to receive and transmit medical images. Medical imaging equipment itself also lacks the ability to encrypt or convert captured images. A local network (if none exists) may not be able to incorporate network equipment such as a PACS for digital image management.

Contents of the invention

The present invention provides a peripheral device for attaching to medical imaging equipment, which realizes the encryption of medical images and converts medical images into safe and standard image file formats, and realizes the encryption of encrypted images on a remote network. and/or converted images to a secure server.

According to one aspect, a system for communicating images includes an imaging device for capturing images and generating digital image files, the imaging device including a device identifier; a series of routines, the series of routines for tagging the digital image file, associating account information with the digital image file, associating a device identifier with the digital image file, and transmitting the digital image file to a server; and a server for receiving the digital image file and The digital image file is processed by at least one of a tag associated with the digital image file, account information associated with the digital image file, and a device identifier associated with a device that captured the digital image file.

According to another aspect, an imaging device includes a modality for capturing an image and generating a digital image file; a device identifier; a shared secret; and a series of routines using For marking the digital image file, associating the account information with the digital image file, associating the device identifier with the digital image file, encrypting the digital image file by using a shared key, and transmitting the digital image file to a server; wherein, the tag , account information and device identifier instructs the server how to process the digital image file.

These and other features, aspects, and embodiments are described in the following section entitled "Detailed Description."

Description of drawings

Features, aspects and embodiments are described in conjunction with the accompanying drawings, in which:

1 is a diagram illustrating an exemplary system for automatically converting and distributing medical images to any of a variety of output modalities, according to one embodiment;

FIG. 2 is a high-level block diagram illustrating certain components of an exemplary data conversion and delivery system that may be included in the system of FIG. 1, according to one embodiment;

3 is a flowchart illustrating an exemplary automated message creation process performed by the data conversion and delivery system of FIG. 2, according to one embodiment;

Figure 4 is a flow diagram illustrating exemplary types of information and data that may be examined during the process of Figure 3, according to one embodiment;

5 is a flowchart illustrating an exemplary process for using information embedded within metadata included with an input file by the data conversion and delivery system of FIG. 2, according to one embodiment;

FIG. 6 is a flowchart illustrating the operation of an image conversion module that may be included in the data conversion and delivery system of FIG. 2;

7 is a diagram illustrating a typical use of a Web GUI that may be included in the data conversion and delivery system of FIG. 2 and its use to pass through an origination modality without any identifiable patient information, according to one embodiment. Find the flow chart of the image's streamlined interface;

Figure 8 is a flowchart illustrating a variation of a typical use of the Web GUI and its streamlined interface for finding an image using a piece of identifiable patient data, according to one embodiment;

9 is a diagram illustrating an exemplary system for automatically converting and distributing medical images to any of a variety of output modalities, according to another embodiment; and

10 is a diagram of a peripheral device connected to a medical imaging device and a remote server for converting and encrypting medical image files from the medical imaging device according to one embodiment of the present invention.

11 is a diagram of a network device connected to a medical imaging device and a remote server for converting and encrypting medical image files from the medical imaging device according to an embodiment of the present invention; and

Figure 12 is a flow diagram of signal flow through the network.

13 is a diagram of a system, a medical imaging device, and a remote server for converting and encrypting a medical image using an encryption and conversion unit according to an embodiment of the present invention;

Figures 14 and 15 illustrate traditional workflows for medical image sharing in primary care and emergency room settings;

Fig. 16 is a flowchart of an embodiment of a system for real-time remote interactive cooperation for medical diagnosis;

Figure 17 illustrates the user interface that a user of the real-time remote interaction system will see;

Figure 18 illustrates the user interface that a user of the real-time remote interaction system will see;

Figure 19 illustrates the user interface that a user of the real-time remote interaction system will see;

Figure 20 illustrates the user interface that a user of the real-time remote interaction system will see;

Figure 21 illustrates the user interface that a user of the real-time remote interaction system will see;

Figure 22 illustrates the user interface that a user of the real-time remote interaction system will see;

Figure 23 illustrates the user interface that a user of the real-time remote interaction system will see;

Figure 24 illustrates the user interface that a user of the real-time remote interaction system will see;

Figure 25 illustrates the user interface that a user of the real-time remote interaction system will see;

26 is a diagram of a mobile device connected to a medical imaging device and a remote server for converting and encrypting medical image files from the medical imaging device according to one embodiment of the present invention.

27 and 28 illustrate exemplary processes that may run on a device or computer system that transmits images to a server using IP networking; and

FIG. 29 illustrates a diagram of an example system including the routines of FIGS. 27 and 28 .

detailed description

FIG. 1 is a diagram illustrating an exemplary system 100 for automatically converting and distributing medical images to any of a variety of output modalities. The term output modality is used to refer to various types of devices, systems and services, several examples of which are provided below. It can be seen that the system 100 can include a variety of source medical imaging modalities 10 such as ultrasound, MRI, CT and PET equipment, a local PACS 20 (typically a source image archive server) or capable of sending medical data such as DICOM data (typically any other device for medical images). The modality 10 and PACS 20 can be connected to, for example, a Central Computer System (CCS) 30 via the Internet 60 via a router 50, which is typically 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. A CCS may include one or more servers, and may include one or more processors or CPUs, memory associated with the processor(s), data storage modules, display components, and input/output interface components. It should be appreciated that various other peripheral devices and modules may be connected to the CCS, such as other servers, other data storage modules or instruction detection systems. The CCS can also be a farm of interoperable servers, each interoperable server being responsible for a specific task within the system. Similarly, all the modules shown in Figure 2 and described below can be individual servers in such a cluster in order to distribute the load and increase the capacity of the system.

DCDS 32 may be used to convert medical images associated with medical data into, for example, consumer-friendly images, videos, or both. The DCDS 32 may then in turn send these converted images to several destinations or output modalities 40 as indicated by the user/operator of the DCDS 32 or dictated by information included in the medical data. These destinations 40 may be, for example, websites, such as social networking sites (including, for example, Twitter, Facebook, and Google Health), cell phones, PDAs, email accounts, or any computer system capable of receiving data through protocols such as SOAP and REST. The DCDS 32 works in such a way that it allows the source modality ( 10 , 20 ) to be protected by the strictest firewall settings 50 while still allowing transmission over the Internet 60 . Raw source image data may optionally be sent to destination 40 without any processing or conversion.

For example, when a patient undergoes an ultrasound examination during pregnancy, the ultrasound images can be sent to the DCDS 32 for conversion into a video that can be sent to the patient's social networking pages, their mobile devices, their friends and family's devices or webpages, etc. A set of images. More specifically, during an ultrasound examination, the operator can capture and store a good sequence of the fetus waving his arms. The sonographer (usually a nurse or technician) sends the stored (eg DICOM) file to DCDS 32 . A nurse, technician, or any recruited employee (user) at the patient facility can use a remote graphical user interface (GUI) interfaced with the DCDS 32 to come up with the desired sequence sent by the source modality 10 . The user can then enter a cell phone number, web account information, email address, etc., and any personal information indicated by the patient, and then initiate the delivery process. For example a DICOM file now converted to a cell phone compatible video format (e.g. 3gpp) can then be sent as a multimedia message to the mobile phone, and files converted to other suitable formats can also be sent to a given e-mail and web account.

Alternatively, a nurse or technician at the patient's facility may enter the patient's cell phone number in a patient information field on the ultrasound machine. When receiving eg a DICOM data file, the DCDS 32 can be configured to then find this number embedded in the DICOM data file and automatically forward the converted image or processed video file to the desired location specified by the patient. Examples of these processes are described in detail below.

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

Storage and parser 204 may be used to parse the received data and store any image data 205 and all metadata 206 in storage system 214 . For example, image data 205 may be stored as binary data, while metadata may be stored as structured data, allowing typical structured access to the data, such as searching and association between different items. The storage and parser 204 may be configured to remove all sensitive patient information from input data files in certain implementations or under certain conditions. For example, a system operator may use a graphical user interface (GUI) such as Web GUI 208 to selectively set portions of metadata that are considered sensitive. Alternatively, the system can be programmed to automatically determine which fields in the metadata are sensitive. This process is called anonymization and is performed to protect patient privacy. Anonymization is discussed in more detail below.

In some 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 can be used to determine what action (if any) should be taken as a result. For example, if automatic output rules have been set and appropriate metadata values are found in newly received data stored in the structured database 206, the event system module 209 can be used to signal a command to the output module 213 to send these automatic output rules The indicated conversion data. This process is described in more detail below.

The output module 213 may be used to receive calls from other portions of the DCDS 32 that contain general data, information to be sent, and delivery destination numbers (including e-mail addresses). For example, the data may include text messages, references to, say, DICOM images, two cell phone numbers, and an email address. The output module 213 may be used to assemble a suitably formatted output "package" or message and send the resulting message using a modular plug-in based architecture. Plug-ins (not shown) for each corresponding type of destination may be included and used by the export module 213 .

In the example provided above, when the DCDS 32 receives a service call, the output module 213 may assemble an MMS message package containing a jpeg version of the image and message text, all assembled and encoded according to the MMS specification. The message may then be sent twice, first to each phone number destination requested and a second time to each email address destination specified.

The output module 213 may request the converted image from the image converter 211, thereby identifying the original image and specifying the requested format and size. The image converter 211 can then be used to look up an existing image in the converted image cache 212 that matches the request. It can generate an image from the raw image data 205 if no match is found. Image converter 211 may be used to determine whether the requested format is suitable using metadata 206 of the original image stored in the database. If not, it may respond with an error. For example, requesting an mp3 audio version of a still image would result in an error, while requesting a jpeg still image of a multi-frame DICOM image file (valid for video) would be fine.

Image converter 211 may be used to respond to events from parser 204 and pre-emptively perform common conversions. This will improve the responsiveness of the system components (specifically, the output module 213 and the Web GUI 208); however, at the cost of increased memory required and a slight decrease in the overall security level.

The Web GUI 208 provides remote access to the DCDS 32 through a secure Web browser connection (https) 202 to, for example, medical personnel. Such a Web GUI 208 may provide an interface for performing administrative tasks, such as establishing rules for the event system module 209, as well as an optimized interface for identifying images and sending output messages. Typical operations of these interfaces are described in detail below.

Web GUI 208 can operate on structured metadata 206 to find and identify images. The Web GUI 208 can be used to request the image converter 211 for conversion, such as to display thumbnails and previews of images, and to provide a service request form where output messages can be specified and sent to the output module 213 for delivery.

The adaptive garbage collector 207 can continuously evaluate the state of all data and compare the state to the configuration made by the system administrator. The configuration can set certain criteria that items need to meet in order to remain in or be removed from the system. A basic criterion can be the age of the item. For example, an item may be automatically deleted if it has been stored a week ago or a few days ago. Other auto-deletion criteria could be the number of times the item was previously sent, stored system state information, and the value of any metadata. This feature is useful in part to reduce resource usage, and also aids in patient confidentiality by removing patient data that is no longer required by the system for maintenance.

It should be noted that in some embodiments the images will be used for clinical or diagnostic purposes. In such cases, it is usually required that the image finally displayed on the device used to view the image maintain a certain resolution or image quality. As such, in some embodiments, one or more of parser 204, event system module 209, and image converter 211 may be configured individually or in combination to identify the image being viewed in a diagnostic or clinical application. image. Such identification may be based on information included in metadata, information stored in image system 214 , or information provided through GUI 208 .

For example, an address or device identified in metadata for receiving an image may be identified as an address or device associated with a clinical or diagnostic application, an image or series identifier may also be associated with a clinical or diagnostic application, or the like. Alternatively, the operator may indicate through the GUI 208 that the images to be sent are intended for clinical or diagnostic purposes.

When it is determined that an image is to be used for clinical or diagnostic purposes, image converter 211 may be used to determine a desired resolution or image quality, such as based on information stored in storage system 214 . For example, resolution, image quality, or both, for various types of images, clinical applications, etc. may be stored in storage system 214 . The image converter can then determine the correct image resolution and quality and convert the image according to the image resolution and quality. In some embodiments, DCDS 32 may be used to determine whether the identified output device or address is capable of displaying the image before sending the converted image at the desired image resolution and quality. If the device or address cannot, the DCDS may generate an error message or other notification indicating this. Error messages can be displayed on the device through the GUI 208, or both.

As noted above, the DCDS 32 can be used to take input medical image files and automatically convert them for distribution to and viewing by any of a variety of input modalities. FIG. 3 is a flowchart illustrating an exemplary embodiment of automated message creation operations performed by DCDS 32 according to one embodiment. In the example of FIG. 3 , it is assumed that destination information (eg, output modality information) is included in the medical image file received by DCDS 32 . In other embodiments, a user can access DCDS 32, such as through GUI 208, and specify which files should be sent to which output modalities; however, a powerful aspect of DCDS 32 constructed in accordance with the systems and methods described herein is that it can The destination is determined automatically and the data is converted and formatted appropriately as described below.

In step 320, a file is received and the file header associated with the file is examined to determine various information. Medical image files received via input 203 will typically include metadata providing information related to the medical data or images included with the medical data. For example, in a DICOM file, a medical image file will include a file header that includes a number of fields. These fields are generally the same for each input modality 10 . Accordingly, DCDS 32 may be used to examine file header fields to determine various information described in detail below with respect to FIG. 4 .

In step 322, an output destination type or modality may be determined. For example, a file header may include information identifying a recipient of an image included in the image file. Or more specifically, the header may include information identifying an output modality associated with a respective recipient or service (eg, such as an online photo album page, website or service; social networking page or service, mobile device, etc.). Basic types of destinations may include: mobile devices, such as cell phones; email accounts; web application-specific interfaces (APIs) such as those associated with online websites or services, and the like. Thus, DCDS 32 can be used to examine header files and determine the associated output device or service (ie, modality).

The DCDS 32 can then be used to retrieve the specific characteristics for each destination type indicated in step 324 whenever possible. These characteristics may include the capabilities and physical characteristics of the destination device as well as 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 modality. For example, this information can be used to alter image data based on the specifications for the type of message being sent, e.g. email has regulatory restrictions and common practices that can be altered; and MMS has very different restrictions that can be altered.

Capabilities and characteristics determined in step 324 may include: frame size, i.e. the pixel size of an image or video, such as 640*480, etc.; data rate or data size, such as MMS messages generally may not exceed 300KB total size, exceeding 10MB e-mail attachments are generally not accepted, etc.; supported encoding formats, e.g. mpeg4, jpeg, etc.; A page can display a single image or video and a single text to accompany the video, an email can be laid out in HTML and can accommodate attachments of any file type, and so on.

In 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 modality. For example, if the image data includes video data, it may be determined whether the output modality is capable of receiving and displaying video data.

The most appropriate delivery format is then selected in step 328 to ensure that the resulting output information includes the best quality data that the output modality can handle. This may be important, for example, in clinical settings or settings where the data is used for examination or diagnostic purposes. Resolution information suitable for diagnostic purposes and the ability of DCDS 32 to provide such resolution are discussed in detail below.

Then, in step 330, the data can be extracted and transformed as needed. For example, MMS messages only allow a very limited total message size. Therefore, images or videos in particular often need to be altered and optimized so that the final message meets the format and specification requirements of a particular output modality. In contrast, e-mail messages usually have no strict size restrictions, so larger files, such as higher-resolution images or videos, can be received. However, even e-mail accounts may include rules restricting extremely large files, so even e-mail messages may require, for example, video files to be optimized to ensure sufficient quality, but also respect the size limit.

If the input file has already been encoded into a format compatible with the output modality, typically no conversion is performed in step 330 in order to preserve the highest possible image quality.

In step 332, the data may be anonymized as required by any applicable anonymization rules. For example, data can be extracted and copied into a common format so that certain data can be removed, edited, etc. Then, the data can be transformed into the final output format. Step 330 and step 332 may be performed in parallel, or reversed as desired for a particular implementation.

In step 334, the transformed data may then be assembled into an output message according to the applicable format and specification determined in the previous steps. Optionally, other data may be included with the message. This information may be entered manually, such as through GUI 208, or it may be extracted from metadata accompanying the received file. Still further, this data may be data retrieved from configuration settings based on the set of properties described above.

In some embodiments, the data components that will comprise the output message are assembled according to template rules for the type of message being created. For example, various template rules may be stored in storage system 214 and accessed by output module 213 to assemble output messages. For example, MMS messages are based on a page metaphor where each page can contain images or videos, text elements and audio elements. Thus, sending two or more images or including text, audio, or both together with the image(s) would require assembling the message into several pages. In contrast, email messages may include any number of images, attachments, etc., subject to eg message size limitations.

The output module 213 may then be used to select an appropriate output gateway for transmitting the assembled output message in step 336 . For example, the output module 213 may be used to send email messages to an SMTP server (not shown) and send MMS messages to an MMS gateway (not shown).

FIG. 4 is a flow diagram illustrating exemplary types of information and data that may be examined in step 320 . As can be seen in FIG. 4, when a file is imported, in step 420, the metadata (or more specifically, the file header) can be checked to identify the input modality. In step 422, compatibility of the modality determined in step 420 with the system may be determined. If compatible, then in step 424, certain characteristics of the data included in the image file may be determined. For example, in step 424, it may be determined whether the file actually includes any image or video data or whether the data is merely reports or metrics. When the input file includes, for example, report or metric data, then in step 426 such information may be extracted and stored in, for example, a common structured format. In step 428, any image data can then also be extracted and stored, and various characteristics can be determined, such as binary encoding format, frame size, color bit depth, still image or video, etc.

FIG. 5 is a flow diagram illustrating an exemplary process by which DCDS 32 uses information embedded within metadata included with an input file, according to one embodiment. Metadata (eg, file header fields) may be used to ensure safe and secure delivery of the image data included therewith. For example, a DICOM image file may include header fields that are key-value pairs in several data types (such as strings, numbers, dates, special metric types, etc.). Fields can be embedded in the file that provides metadata to them, or they can be linked to that file. This way, files and associated data cannot be confused because they are not separate.

In step 520, DCDS 32 may be used to automatically track and record the file header fields of each network device used to send the image. In this way, DCDS 32 can identify the specific device associated with the input file. The DSDC 32 can do this by recording in step 522 which fields are present for a particular modality 10, and then recording in step 524 which fields are included in the device-independent file header fields for the associated modality. data. A particular device should always report the same values for things like manufacturer, model name, model number, etc. Thus, DCDS 32 can use this information to represent a particular device.

In step 526, the DCDS can detect any changes in the data and then take appropriate action. For example, changes in file header field data that should not be changed (eg, manufacturer information) can indicate that the file has been tampered with or that someone is trying to break into the system. In response to detecting such a change, the system can log an event, notify an operator, place incoming data in an audit queue, quarantine the data or any other data from the associated device, reject the data, reject all future requests from the device data, to name but a few possible actions.

In step 528, the DCDS may be used to search the file header fields for data that may identify the intended recipient as noted above. The identification can be in the form of something physical such as an email address, a mobile station International Subscriber Directory Number (ISDN), a website address, and the like. In fact, such direct identification may be preferable, since it exploits the presence of file header fields. The identification can also be indirect, such as an ID that can be used to look up a direct address, such as in a registry stored in storage system 214 . It should also be noted that each field can contain more than one piece of data and different types of data. Thus, any identification field or address field can include phone numbers as well as email addresses and the like. Further, identification data may be included in more than one field.

The DCDS 32 may then be used in step 530 to determine the action to take in step 528 based on any identification data detected. Such actions may include sending a suitable message to any address found, formatting the message appropriately as described above, notifying an operator, adding the message to a queue (say, for manual review), to name a few examples, Additional data or information is found and added to the output message.

Accordingly, FIG. 6 is a flowchart illustrating the operation of the DCDS 32 in more detail. Referring to FIG. 6, a conversion request 301 including at least an internal identifier for an image and a destination format may be received. As noted above, the conversion request may be the result of information and data included in metadata associated with the input file. However, as noted below, requests may also be the result from input received through GUI 208 . Optionally, the request may contain a new image size that will be scaled to the output image to be sent. The image converter 211 is operable to then determine the existence of the requested image 304 by attempting to find metadata associated therewith in the metadata database 303 . If no record exists for the requested image, the converter may optionally return a placeholder image (305, 308) or terminate the conversion attempt 306. Placeholders are typically images, videos, or similar media that convey that the requested image is not available. At this point, the converter can also be used to determine whether the requested output format is possible.

If the metadata 303 in the database does exist, the converter can be used to load eg DICOM images from the image store 302 into raw binary format. Converter 211 may then be used to determine whether the image data should be resized to the dimensions provided in the request or to the dimensions required by the requested output format. For example, a jpeg preview of a Web GUI 208 can be rendered at any size that fits in the layout of an html document, while a video of an MMS message has very specific dimensions to follow the specification.

Next, the image data may be converted 311 to the requested destination format. The results can be saved 312 in an image cache, and a metadata record can be updated 313 to indicate the presence of a transformed image. Finally, the transformed image can be returned as a response to the request. Converter 211 can then return the converted binary data directly or return a reference to its location 313 in the image cache.

As noted, DCDS 32 may also be operated and interfaced through Web GUI 208 . GUI 208 may enable both remote and local access to DCDS 32 , and enable images to be found within storage system 208 . Images may need to be located, or analyzed, or diagnosed, or sent to a specified destination or address.

Two main ways of accessing files can be provided. The first way involves finding files without any identifying information. This way is explained in detail below in conjunction with FIG. 7 . However, it should be noted first that each device sending a file to DCDS 32 can be identified by recording and mapping the file header fields of the incoming file transfer. Devices may also be identified based at least in part on their network addresses, AE headers used for delivery, or both. Each device can then be given a unique and preferably meaningful name to the operator. The files and their series, inspection, or both, can then be identified by the device they originated from, the time and date of image capture, file header fields identifying the operator of the device used to capture the image.

Since no patient information is required, the DCDS 32 can process anonymized data and no patient information will be collected due to system abuse. Additionally, most used highlights can be stored in the system as recent images. Therefore, finding images can be made very efficient in this way. Once a file, series, checkout, etc. has been found, the GUI 208 can provide the operator with direct access to features for viewing images, sending images, etc.

With this in mind, FIG. 7 is a diagram illustrating a typical use of the Web GUI 208 and its use to find an image (401-404) through an originating modality without any identifiable patient information, according to one embodiment. Flowchart for a streamlined interface. When the image has been 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 validated (407), the required conversion is requested (408) from the image converter (211). For all successful requests, the data is assembled by the appropriate output plugin (409-411), and the result is sent to the appropriate destination (412-414). Status information about each individual output is collected (415) and returned (416 or 417) to the form view (405) for display. At this point, the user may choose to repeat the sending process or return to finding another image.

The Web GUI 208 allows sending groups of images belonging to the same (eg DICOM) series. The operating steps are similar to those illustrated in FIGS. 7 and 8 . The Web GUI 208 also presents an interface for constructing the event system 209, organizing and storing output destination addresses, and other administrative tasks as necessary. It is important to note that, as a security measure, the Web GUI 208 does not handle any authorization of source modalities that are allowed to store images or access privileges to these images. These important settings are only available through separate access methods, either locally or remotely. In the case of DCDS running on a Unix-style operating system, remote access will typically be via the Secure Shell (SSH) protocol. If DCDS is running on a Windows operating system, remote access will typically be through Terminal Services. These two protocols are examples of secure remote access to an operating system.

The second way to access files is by using identification information. For example, an operator may use patient information (such as name, birthday, patient ID, etc.) to search for files. The operator can, for example, enter a search term, and if there is a match, the system can present all available tests. If multiple patients are returned, these patients can be presented for selection. Once a patient is selected and associated files, series, tests, etc. are found, the GUI 208 can provide the operator with direct access to features for viewing images, sending images, and the like.

Figure 8 is a flowchart illustrating a variation of a typical use of the Web GUI 208 and its streamlined interface for finding images (501-504) by using each identifiable piece of patient data such as patient name and birthday, etc. Alternatively, any extraneous identification code or PIN code can be used to avoid using actual patient information to ensure patient privacy. Thereafter, processing steps as described above with respect to FIG. 7 may follow.

In some embodiments, as illustrated in Figure 9, the CCS 30 can interface with a server 902 that can be used to host and support information related to images being captured by the modality 10, for example, for patients and family members. Various value-added services. For example, if the image is a fetal ultrasound image, the server 902 can be used to provide various services to parents, family members, friends, and the like. For example, DCDS 32 may be used to convert images to an appropriate format or formats supported by server 902 and related services. The images may be sent to server 902 and stored in storage system 904 .

It is to be understood that server 902 may actually include multiple servers, computers, routers, etc., as well as suitable software and firmware required to perform the functions described herein. Additionally, storage system 904 may include one or more databases, one or more storage servers, and other physical storage media as desired.

The server 902 is then available to, for example, host a website on which users can create accounts. The user can then access the images on the website and purchase images, pregnancy calendars, custom mugs, key chains, t-shirts, sketch pads, and the like. Additionally, the Site may be used to present pictures, diagrams and information about fetal and child development, health and nutrition tips, and more. Such a website may enable services such as: for example, about baby showers; automatic updates to friends and family; digital gifts and viral gifts, such as images of babies with digital lullabies; invitation cards and thank you cards; and more.

The user may be charged once or periodically for establishing an account, such as a network access fee, or may be charged to the user and family and friends for various products and services, or both.

Additionally, a kiosk 908 that can provide at least some of the same services can be established, such as in a maternity ward. The kiosk 908 may be standalone, ie, interface directly with the CCS 30, or may interface with the server 902 as illustrated. Thus, family and friends can order pictures and other merchandise, for example, right in the waiting room.

In addition, users can continue to use the account even after the child is born. For example, a website could track a child throughout their childhood, or at least for the first few months or years. The website can be used to send birthday reminders and announcements to friends and family or to notify friends and family of other special events, milestones, etc. Also, the website can be used to continue to present growing information as well as health and nutrition tips for both mother and child.

In fact, it may be preferable to have parents upload contact information about friends and family. In this manner, server 902 can be used to continue sending birthday reminders to friends and family. In some embodiments, the website hosted by server 902 may be affiliated with or host a "gift shop" that offers various products and services. Alternatively, or in addition, the website may offer discounts, coupons, etc. for various other businesses and stores. Because the server 902 will have relevant demographic information relevant to the child, such as residence information, gender, age, race, and possibly even parental age, occupation, and other affiliations, the website can send similar demographic information appropriate to the child and family. Wait for welcome reminders, gift recommendations, discounts, and more.

In this regard, it may be preferable to give users the opportunity to provide such demographic information. Thus, in one embodiment, a user may visit a website and customize or provide profile information, contacts, preferences, and the like. Algorithms running on the server 902 can be used to then use the available information to make product recommendations and the like. In fact, since the server 902 will have information about individuals all over the world, the algorithm can be used to make recommendations using information from groups that share similar demographics, income levels, preferences, etc.

In some embodiments, users may purchase items through a website (ie, through server 902). For example, server 902 may be used to accept credit card payments, PayPal accounts, or to perform mobile billing. Accordingly, the server 902 may be used to process the transaction and deduct an appropriate fee or bill the associated business, affiliate, partner, etc. for the transaction. Moreover, purchase information can also be fed into the algorithm and used to make future recommendations. In fact, the purchases of the entire relevant group can be used to make more targeted and suitable recommendations.

Thus, as the child grows, the algorithm can be continuously updated and honed for, say, gift recommendations. Recommendations can be automatically sent to friends and family over a period of years. As the database grows over time and has more and more users, the algorithm can be honed to provide more relevant and targeted recommendations.

It should also be noted that the database will have to include a great deal of information about relationships and linkages between large groups of people. This includes direct links like friends and family, but also more indirect links like preferences, similar buying habits, etc. This type of interconnection information can be extremely valuable for targeted advertising and product recommendations, as well as for simply tracking and mapping the interconnectedness of large groups of people.

It should be noted that such websites may be structured around other diseases or events, such as cancer support websites, physical therapy support websites, and the like. It should also be noted that combining these various other disease and event interconnectivity data can amplify the power of information and lead to better algorithms for targeting information as well as products and services.

It should also be noted that users can use computers 914 and mobile devices 912 to access websites through, for example, the Internet. Additionally, the website can interface with other social networking sites (such as Twitter, Facebook, etc.). In some embodiments, a website can actually be converted into an application, or a widget that can be exported to other websites. For example, grandma can place the application on her Facebook page and receive updates and notifications more easily without logging on to the server 902 . This can increase the interaction with the website, which can increase the amount of information and data available, for example, to server 902 as input to the algorithms described above.

While certain embodiments have been described above, it is to be understood that the described implementations are exemplary only. Accordingly, the systems and methods described herein should not be limited based on the described embodiments. Rather, the systems and methods described herein should be limited only by the following claims in conjunction with the foregoing description and accompanying drawings.

Peripheral Encryption and Transformation Devices

In one embodiment, a peripheral device may be attached to a medical imaging device to encrypt and convert medical images to a secure and standard image file format, and to upload the encrypted and/or converted Images are sent to a secure server. As shown in Figure 10, the peripheral device 102 can be a dongle or other type of independent device, which can be physically attached to the medical imaging device 101, and has its own processor and memory to perform conversion and encryption of medical images. Various functions related to the transmission of medical images from the medical imaging device to the remote server 103 on another network. Peripheral device 102 may be attached to a communication port (eg, network port, serial port, or other communication interface) on the medical imaging device. Peripherals can be used as filters to monitor all medical image files generated on a medical imaging device and to encrypt and convert selected medical image files for transmission to remotely connected devices on another network , such as a server or a mobile device.

The dongle can be configured with a separate network connection to a local area network (LAN) or wide area network (WAN), or the dongle can be used 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 can have networking hardware that allows the dongle to communicate over WiFi or cellular networks or even accept direct communication with a local network to which the medical imaging device is not connected Ethernet cable connection.

In another embodiment, the dongle 102 may be connected to the imaging device 101 through an unsecured connection, in which case the dongle 102 performs the following functions: acquire medical images stored on the medical imaging device 101 and These images are encrypted for transmission over a secure network connection to a remote device, such as a remote secure server or mobile device as the final destination of the medical images.

One embodiment provides a method and technical system for encrypting and routing a DICOM network connection from a device without any encryption capabilities built in.

An embodiment of the present invention may listen on a known port for unprotected communications and automatically encrypt and route the connection in encrypted form through the port's encrypted peer. For example, a normal DICOM connection on TCP port 104 or 11112 can be encrypted as SSL/TLS and routed as DICOM/TLS on TCP port 2762. This will effectively make the connection appear to the remote server as a secure TLS connection and as an unsecured connection to the client device. A high level of security is maintained by attaching embodiments of the present invention to the imaging device's network port or as a network router on the same protected local network as the device.

Likewise, normal "web" connections over HTTP protocol on TCP port 80 can be encrypted as SSL/TLS and routed as HTTPS on TCP port 443. This will effectively make the connection appear to the HTTP server as a secured HTTPS connection, and make the connection appear to the HTTP client as an unsecured connection. At this point, it should be noted that HTTP traffic is only useful on legacy clients and servers capable of secure connections. However, it is a pair of well-known network ports that are used to illustrate the general embodiment of the invention.

Embodiments of the present invention include a wireless network connection, such as WiFi capability or cellular modem capability, to allow not only encryption but also Internet access in the absence of existing network infrastructure 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 present invention can be preconfigured to forward protected traffic only to a single remote endpoint.

Embodiments of the present invention may use any encryption method and all relevant encryption methods to secure the connection. Examples of these include the aforementioned SSL/TLS standard and other common encryption standards. The point is that the present invention will emulate the native encryption standard for each connection supported by the embodiment. Encryption can be encoded and decoded by a dedicated chip (electronic hardware component), software, or a combination of software and hardware acceleration.

Network Encryption and Transformation Appliance

A network device for connecting to a local network, comprising at least one medical imaging device, for encrypting and converting medical images from the at least one medical imaging device into a secure and standard image file format, and converting the encrypted and/or Or the converted image is sent to a secure server on a remote network. A network device may act as a router or gateway on a local network to monitor the traffic of medical images from a medical imaging device to a destination device outside the local network and to ensure that medical data files are encrypted and converted into an appropriate format for Send it to a device on the remote network. After detection, the network device encrypts and converts the selected medical image files for transmission of the medical image files to a remotely connected device on a remote network, such as a server or a mobile device.

One embodiment of a network device is illustrated in FIG. 11 , where the network device 104 acts as an encrypted router to receive medical image files from one or more medical imaging devices 101 over a potentially insecure local network. The encryption router 104 will then be used to encrypt and convert the medical images into a secure and standard image file format. The encryption router 104 is then used to transmit the encrypted and/or converted images over a secure connection to the secure server 103 on a remote network, such as the Internet.

In one embodiment, the network device 104 will create a private network for the one or more medical imaging devices 101 to communicate. The network device 104 may 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 gateway to ensure that all medical images transmitted from the local network are converted and encrypted.

FIG. 12 illustrates a flow diagram of 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 include one or more of the components illustrated herein, including: an encrypted listening port 302 that monitors network traffic in the LAN for medical images that are not encrypted or converted to an appropriate format Files are transferred. The encryption database 305 may store encryption settings indicating which type of encryption should be used to encrypt a particular medical image file, which may depend on the type of network or destination device on the remote WAN network 307 . The medical image file is processed 303 to encrypt the file, and after the encryption operation, a certain port is mapped 304 to transmit the file. The encrypted file is then transmitted through a firewall or other local router 306 to a remote WAN network 307 .

In one example, the Vscan imaging device captures medical images that are not in DICOM format and are not encrypted, but are selected for transmission from the Vscan to a remote secure server on a remote network. The medical image is then sent to network device 104, which converts the image to a DICOM image and encrypts it before sending it to a remote secure server.

Network devices are useful in unsecured or unreliable local networks because the network device creates a secure connection with medical imaging equipment as well as remotely connected servers or devices on another network. Additionally, networking devices are useful in highly secure networks with strict firewalls that block network connections to remote secure servers.

In one embodiment, the network device can be configured as a network satellite, which is attached to the local network, but which acts as a remote security server, and where the network satellite is the final destination of the medical image file, the one or multiple medical imaging devices to send images to network satellites. The network satellite will then take the medical images, encrypt or convert them (or both) and send the encrypted and converted images to the actual remote secure server. In this embodiment, there is no need to instruct the medical imaging device to send the medical image file to a New locations, such as network devices.

One embodiment provides a method and technical system for encrypting and routing a DICOM network connection from a device without any encryption capabilities built in.

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

Likewise, normal "web" connections over HTTP protocol on TCP port 80 can be encrypted as SSL/TLS and routed as HTTPS on TCP port 443. This will effectively make the connection appear to the HTTP server as a secured HTTPS connection, and make the connection appear to the HTTP client as an unsecured connection. At this point, it should be noted that HTTP traffic is only useful on legacy clients and servers capable of secure connections. However, it is a pair of well-known network ports that are used to illustrate the general embodiment of the invention.

Embodiments of the present invention include a wireless network connection, such as WiFi capability or cellular modem capability, to allow not only encryption but also Internet access in the absence of existing network infrastructure 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 present invention can be preconfigured to forward protected traffic only to a single remote endpoint.

Embodiments of the present invention may use any encryption method and all relevant encryption methods to secure the connection. Examples of these include the aforementioned SSL/TLS standard and other common encryption standards. The point is that the present invention will emulate the native encryption standard for each connection supported by the embodiment. Encryption can be encoded and decoded by a dedicated chip (electronic hardware component), software, or a combination of software and hardware acceleration.

Encryption and Transformation Plugins

The present invention provides a system and method for encrypting and converting medical image files on a device within a network. The encryption and conversion unit can be incorporated in the hardware and software of a medical imaging device or another network Encryption for transmission to a remote network and the ability to convert the medical image into a format compatible with the destination device or network. The encryption and conversion unit may also be used to package and transmit the converted and encrypted images to an appropriate destination on a remote network, such as a secure server.

The encryption and conversion unit can be used as a router or gateway on the local network to monitor the traffic of medical images from medical imaging devices to destination devices outside the local network and to ensure that medical data files are encrypted and converted into appropriate format for delivery to devices on the remote network. After detection, the encryption and conversion unit will encrypt and convert selected medical image files for transmission to a remotely connected device on a remote network, such as a server or a mobile device.

One embodiment of an encryption and translation unit is illustrated in FIG. 13 , where the encryption and translation unit 104 acts as an encryption router to receive medical image files from one or more medical imaging devices 101 over a potentially insecure local network. . The encryption and conversion unit 104 may be incorporated in each medical imaging device 101 as software, hardware, or a combination of software and hardware. In another embodiment, the encryption and conversion unit 104 may be part of a router, gateway, firewall, or other network device that monitors and regulates traffic on the network. Regardless of the type of device on which the encryption and conversion unit 104 resides, the encryption and conversion unit 104 will be used to encrypt and convert medical images into a secure and standard image file format. The encryption and conversion unit 104 is then configured to transmit the encrypted and/or converted image to the secure server 103 on a remote network, such as the Internet, over a secure connection.

FIG. 12 illustrates a flow diagram of 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 conversion unit 104 may include one or more of the components illustrated herein as software, hardware, or a combination of software and hardware. In one embodiment, the encryption and conversion unit 104 includes an encryption listening port 302 that monitors network traffic in the LAN for transmission of medical image files that are not encrypted or converted to an appropriate format. The encryption database 305 may store encryption settings indicating which type of encryption should be used to encrypt a particular medical image file, which may depend on the type of network or destination device on the remote WAN network 307 . The medical image file is processed 303 to encrypt the file, and after the encryption operation, a certain port is mapped 304 to transmit the file. The encrypted file is then transmitted through a firewall or other local router 306 to a remote WAN network 307 .

In one example, the Vscan imaging device captures medical images that are not in DICOM format and are not encrypted, but are selected for transmission from the Vscan to a remote secure server on a remote network. The encryption and conversion unit 104 is embedded as software running on the Vscan device and thereby converts the image to a DICOM image and encrypts it before sending it from the Vscan device to a remote secure server.

The encryption and translation unit is useful in an unsecured or unreliable local network because it creates a secure connection with the medical imaging device and a remotely connected server or device on another network. Additionally, networking devices are useful in highly secure networks with strict firewalls that block network connections to remote secure servers.

One embodiment provides a method and technical system for encrypting and routing a DICOM network connection from a device without any encryption capabilities built in.

An embodiment of the present invention may listen on a known port for unprotected communications and automatically encrypt and route the connection in encrypted form through the port's encrypted peer. For example, a normal DICOM connection on TCP port 104 or 11112 can be encrypted as SSL/TLS and routed as DICOM/TLS on TCP port 2762. This will effectively make the connection appear to the remote server as a secure TLS connection and as an unsecured connection to the client device. A high level of security is maintained by having an embodiment of the present invention communicate with the imaging device's network port or with a network router on the same protected local network as the device.

Likewise, normal "web" connections over HTTP protocol on TCP port 80 can be encrypted as SSL/TLS and routed as HTTPS on TCP port 443. This will effectively make the connection appear to the HTTP server as a secured HTTPS connection, and make the connection appear to the HTTP client as an unsecured connection. At this point, it should be noted that HTTP traffic is only useful on legacy clients and servers capable of secure connections. However, it is a pair of well-known network ports that are used to illustrate the general embodiment of the invention.

Embodiments of the present invention include a wireless network connection, such as WiFi capability or cellular modem capability, to allow not only encryption but also Internet access in the absence of existing network infrastructure 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 present invention can be preconfigured to forward protected traffic only to a single remote endpoint. Embodiments of the present invention may use any encryption method and all relevant encryption methods to secure the connection. Examples of these include the aforementioned SSL/TLS standard and other common encryption standards. The point is that the present invention will emulate the native encryption standard for each connection supported by the embodiment. Encryption can be encoded and decoded by a dedicated chip (electronic hardware component), software, or a combination of hardware acceleration.

Mobile Device Implementation of Encryption and Transformation Units

In some embodiments, the encryption and conversion functions described above (eg, described with respect to FIGS. 10-13 ) may be implemented on a mobile device, such as a smartphone, tablet, or other mobile device. It is illustrated in FIG. 26 , wherein the encryption and conversion unit 105 as in FIG. 13 is replaced by a mobile device 107 on which software 109 has been installed which enables the mobile device to execute the above The encryption function and the conversion function and the routing function are described.

In many embodiments, the encryption function and conversion function can be integrated with the mobile device 107 by downloading the application 111 to the device 107 . The application 111 will then include or allow the user to download the software 109 needed to perform the desired function. Accordingly, software 109 may be compiled for the processor architecture of device 107 .

The software 109 may then act as a router or tcp proxy server through which data sent from the device 101, such as a portable ultrasound machine, travels. From the perspective of the ultrasound machine, it appears that the ultrasound machine is communicating directly with the dicom server on the device 107, but in fact the ultrasound machine is communicating directly with the hosted server 103 through an encrypted tunnel or secure connection provided by the device 107.

The port used by the device 107 is usually 104, but there is an alternate port 11112 which is used whenever it needs to stop on port 1024, although this is rare.

In some embodiments, software may require payment for a one-time use or subscription. Thus, the system may be configured such that the certificate is provided to the software 111 eg by the server 103 . Usually, the certificate will be set to expire, so the application 109 can perform the following processing: the user pays for reissuing the certificate, for example, extending the validity period of the certificate. This is simply called a "subscription". In this case, automatic expiration is quite useful. Accordingly, application 109 may include the ability to obtain new certificates and install new certificates (eg, automatically install).

Application 109 may include a payment function that allows the user to use a credit card, mobile wallet or other account to pay for a subscription or one-time use, for example, to extend or obtain a new validity period during which the software has a valid certificate.

In some other embodiments, the application 109 may include a more advanced user interface that allows the user to actually interact with the functionality of the software 111, monitor, troubleshoot, or all of the above. This can include the ability to verify connectivity, whether a secure connection exists, upload and download speeds, and more.

In some embodiments, mobile device 107 and imaging device 101 may communicate via a wireless communication link such as NFC, BlueTooth ^™ or WiFi. Accordingly, a communications dongle (not shown) may interface with device 101 to enable such wireless connectivity, or such functionality may be included in device 101 .

The mobile device 107 may in turn communicate with eg the server 103 via eg a 3G/4G WAN system. However, in other embodiments the device 107 can also communicate with eg the server 103 using eg a WiFi connection. This means, for example, that a non-3G/4G capable tablet can still be used as an encryption device by connecting it via WiFi to a local network (accessible via any modality 101 using a local network).

For example, if device 101 is using Wi-Fi and mobile device 107 is using a wireless wide area network to communicate with server 103, mobile device 107 can act as a Wi-Fi base station and router to which ultrasound machine 101 is connected, for example. The IP address to which the ultrasonic machine is connected is the IP address of the device 107. When the device 107 configures itself through DHCP, no matter what router IP address the ultrasonic machine obtains, the IP address is the same.

Integrated image management

The present invention provides systems and methods 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 interface to enable 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 portable document format (PDF) medical images. The systems and methods described in this invention then convert the PDF files into DICOM-formatted image files, which are then sent to specific destinations and then converted back to PDF for display on a suitable electronic device such as a personal computer. , portable electronic devices, etc.) for viewing.

In another embodiment, the HL7 protocol device is used for medical software communication, and the device includes data packets on the destination of a specific document. For example, images created by HL7 devices need to be transmitted to doctors or patients. The integration software takes the information on the image, combines that information with the command information on the image's destination, and then adds that information to the DICOM message.

The integration software works by taking the required information from the third-party software system and determining what is needed to convert, encrypt, and send the image to the appropriate destination.

real-time remote interaction

The systems and methods described in the present invention provide on-site, or real-time, remote diagnosis of a patient's medical problem by using one or more patient medical images taken with a medical imaging device such as an MRI. The system can be embodied as a network with multiple computing devices and display devices that displays a graphical user interface (GUI) to each user, enabling all users to view the same medical images in real time. The user may also be given the option of annotating the image in real time, chatting about the image via an instant messaging program, and even having a conversation using Voice over Internet Protocol (VOIP) or traditional land-based conferencing systems. The system provides multiple menus for users to organize images, select diagnoses and other actions, and collaborate in real time with multiple users to make a diagnosis based on one or more medical images.

Figure 16 illustrates the overall workflow for real-time remote interaction, where the user is first presented with a dashboard, or home screen, showing different options for collaboratively making a diagnosis. The dashboard is further illustrated in FIG. 18 . Medical images from the Vscan device can be displayed to the user, after which the examination screening process can be performed. In the examination screening process, images may be sent to the patient, examination results may be sent to the patient, and the resulting information may be sent for diagnosis. An on-site, or real-time diagnosis can then be made. In a true emergency situation, the steps illustrated in the flowchart can be skipped in order to make an emergency diagnosis without the cooperation of the remote user.

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

18 illustrates a "dashboard" GUI that lists medical imaging connected to the overall network or to the user's actual computing device, such as a medical imaging device on the user's local network at a hospital or medical facility equipment. The dashboard also lists images that have been captured by these devices and can be arranged by the patient, physician, etc. in the order of capture. If new images arrive, they can be moved to the top of the list and highlighted so users can easily find them. In one embodiment, when one or more images are captured by a particular device, an alert, such as an SMS or email message, is sent to the appropriate physician or healthcare provider responsible for the patient's condition. The dashboard may also provide a search feature where a user may search within the images, as well as a database of information related to the images and the patient.

Figure 19 shows further details of the main menu GUI which provides: the option to select a DICOM image (where the main image workflow is found); Recipient icons for patients or other users and contacts who can be easily found and contacted to send images and messages; anonymity to handle imaging device settings, patient messages, and tags to categorize tests Settings icons for automation or automation; statistics icons to show traffic across the app over time; admin icons to show administrators managing user accounts and setting patient image categories; non-admins can view their own profile and other an account icon for account details; and a logout icon that allows the user to log out of the system. It is to be appreciated that the icons and options listed here may vary and are not limited to those described above.

Figure 20 illustrates one embodiment of an image workflow where an image or inspection of images can be selected from a list for further review. Inspection information may include the number of files and tags assigned to each inspection, and the number of comments made by other users on specific inspections and images. Different icons are available for still images, videos, comments, etc. These tags may be about a suggested diagnosis or about a specific category or categories of images included in the test.

Figure 21 illustrates a series of images that can be quickly viewed as thumbnails before selecting one or more images for further viewing. A list of actions is provided at the top of the GUI, and other icons on the thumbnails provide an indication of whether the thumbnail represents video and whether the thumbnail is of a particular image format such as DICOM. Users can click or select one of the thumbnails to open the entire image or video.

22 is an illustration of a real-time remote interactive collaboration GUI in which a medical image is displayed with annotations made to the image by one or more users. A chat screen is shown where users can instant message each other while discussing the patient's diagnosis, and a thumbnail list of other images in the examination can be placed on top. Thumbnails can be updated as new images arrive. The "live diagnostic screen" is a real-time collaboration tool that updates all information in real-time and synchronizes edits between users, including annotations, chats, actions, selected images, pins, and other changes. On-site diagnostic screens are especially beneficial for emergency room situations where immediate diagnosis is required. In the chat screen, the user may choose to invite additional participants or take one or more other actions related to the situation.

Figure 23 illustrates one embodiment of an action that can be selected in a chat screen and that can be used as a way to provide explicit instructions to another user, such as a doctor or nurse serving a patient. The "Actions" tab can also provide tracking of selected actions and who performed and suggested them so that the patient's treatment can be properly documented. In the "Invite Collaborators" tab, the user can invite multiple users to participate in the on-site diagnostic process. Invited users may receive a text message, email or phone call inviting them to a live chat session. The user interface can be used with any type of computing device, including mobile phones and tablets, to allow users to participate in a conversation from any location with any type of portable electronic device.

Figure 24 illustrates a GUI in which, based on a set of images, a diagnosis may be requested for a particular patient. The user may select different options for concerns to be investigated and possible diagnoses. When a request is made, one or more users can be notified via email, text or phone, and an inbox screen can be set to display when a reply is received.

In Fig. 25, a GUI for making a diagnosis is provided, where several images or menus are provided to select the appropriate diagnosis. Images can be downloaded to the computer desktop for more detailed viewing with other software tools. Options for potential diagnoses may be highlighted or selected. Once a final decision is reached, a diagnosis is issued and documented for future inspection and testing.

Receive pipeline implementation

In an embodiment, such as described with respect to Figures 10, 11 and 13, DNS and dedicated ports are required. However, in some embodiments, standard ports can be used to eliminate the need for DNS. In these embodiments, some of the communication routines are applications that may be loaded into imaging device 101 or a computing system that interfaces with device 101 . These communication routines may communicate with, for example, a DICOM imaging application on the device to acquire a DICOM image, encrypt the image, provide tag and account information, and then transmit this information to one or more servers. Tag and account information may be used, among other things, as input to compute a private pre-shared key, which may be used for encryption as described in detail below. This information may also be used to determine whether to deactivate an account to prevent any transfers upon account deactivation.

Figure 29 is a schematic diagram illustrating an example system 2900 configured with a communication routine, process, etc. (routine 2906) that can perform such message creation functionality, according to one embodiment. In the example of FIG. 29 , routine 2906 may be included in a device, such as terminal 2904 coupled with device 101 , or included in device 101 itself. Terminal 2904 may be a computing device, including: a portable computing device such as a laptop, tablet, or smartphone. Routine 2906 may be used to obtain an image from device 101, create a message including image data, tags, account information, and other information that can provide information on how to process the image data, encrypt the image data or the entire message, and send the message over network 2908 Information transmitted to one or more servers 2912 and storage locations 2910.

Network 2908, storage locations 2910, and servers 2912 may be indicative of an underlying cloud structure.

As explained above, the tag and account information may indicate, or at least provide, the necessary information to enable, for example, server 2912 to process the message, as well as the image data included with the message. For example, tag and account information may instruct server 2912 to store and associate image data with a particular clinician, group of clinicians, hospital, etc., where it can be later accessed and viewed using a viewing application such as the one described above. image data. Alternatively, the tag and account information may instruct the server 2912 to forward the image to the clinician's or patient's device or website.

In some embodiments, the routine 2906 may also provide for converting the image data into a different format that is more easily transmitted to and processed by the server 2912, or into a format associated with the destination. Additionally, routine 2906 may eliminate the need for DNS or the need to use dedicated ports.

27 and 28 illustrate example implementations of two such routines 2906 or daemons referred to as image data receiver 2702 and communication 2704 . The following are descriptions of these daemons. First, as shown in FIG. 27, routine 2906 may include image data receiver 2702 (Dcmtk::storescp). It can be seen that a sub-process 2704 (Trice::sendFile) can be linked to an image file and these processes can be used together to send an image file, such as a DICOM image file, to a receiver routine 2710 in the cloud (Trice::receiver).

Transport Layer Security (TLS) may be implemented in some embodiments using a device-specific private pre-shared key. These keys are encryption keys, where both the sender and receiver need to successfully compute the same key for the transmission to succeed. Account information and tags can be two of the inputs to this calculation. The described configuration should provide a robust file copy function that will work successfully if there is any connectivity between the device 101 and the cloud. Any failure in the communication pipeline illustrated in Figures 27 and 28 can cause the response to device 101 to fail, causing device 101 to attempt to send the image data again.

As illustrated in FIG. 28 , a communication routine 2704 may also be used to communicate with a receiver 2710 . Communication routine 2704 may be responsible for initialization, sending "heartbeats" to the cloud, fault reporting, configuration updates, and software updates, if allowed.

A local directory 2706 with read/write access may be included to store configuration information. The location of this directory 2706 may be passed as a parameter to the daemon processes 2702 and 2704. In most embodiments, there is no requirement as to the disk location of directory 2706. Directory 2706 may store information such as port #, local-ip address, DICOM dictionary, error logs, etc. If device 101 is a DICOM imaging device, the DICOM service may load a DICOM dictionary from, for example, this directory 2706 . As described herein, a heartbeat message can be sent to a cloud receiver including a port# and a local-ip address that can be read from this directory 2706. Log information may also be stored in this directory 2706.

A unique name may be calculated for device 101 . If there is a device ID associated with device 101, that device ID should be used instead of the compute name. If there is a device ID, a filename containing the device ID may be passed to the communication routine 2704. This device ID can be the primary key to anything related to the uplink/device in the cloud database. The cloud service can then look up: when the last heartbeat was uploaded from the device; when the device was first online; the version of software loaded on the device; the account associated with the device, etc. The uplink described in Figures 27 and 28 sends periodic state information which may be a heartbeat and which may be persisted as its master key in the cloud using the device ID. It should also be noted that for all communications, standard ports (eg, 443) are used.

Claims (14)

1. a kind of system for transmitting image, the system includes：

Imaging device, the imaging device is used to catching, be imaged and generating digital image file, and the imaging device includes equipment Identifier；

A series of a series of routines, routines are used to mark the digital image file, by accounts information and the digitized map It is as file is associated, the device identifier is associated with the digital image file, and by the digital image file It is sent to server；And

Server, the server is used to receive digital image file and according to the mark associated with the digital image file Label, the accounts information associated with the digital image file and associated with the equipment of the seizure digital image file At least one in device identifier is handled the digital image file.

2. system according to claim 1, wherein, the imaging device also includes shared key, and wherein, the example Journey is used to the digital image file is encrypted by using the shared key.

3. system according to claim 2, wherein, the server includes multiple shared keys, and each is described shared Key is all associated with specific imaging device, and wherein, the server is used for by using associated with particular device Message from specific imaging device is decrypted shared key.

4. system according to claim 1, wherein, the routine is stored on the imaging device.

5. system according to claim 1, the system also includes the terminal coupled with the imaging device, and its In, the routine is stored in the terminal.

6. system according to claim 5, wherein, the terminal is mobile device.

7. system according to claim 6, wherein, the mobile device is portable computing device, tablet personal computer or intelligence Can mobile phone.

8. system according to claim 1, the system also includes one or more storage locations, and wherein, it is described Accounts information identifies document location in one or more of storage locations.

9. system according to claim 1, wherein, the routine is additionally operable to：It is sent to by the digital image file Before server, a pair form associated with the digital image file is changed.

10. system according to claim 1, wherein, the routine is additionally operable to perform initialization, sends heartbeat to described At least one of server, Trouble Report, config update and software upgrading.

11. a kind of imaging device, the imaging device includes：

Mode, the mode is used to catching, be imaged and generating digital image file；

Device identifier；

Shared key；And

A series of a series of routines, routines are used to mark the digital image file, by accounts information and the digitized map It is as file is associated, the device identifier is associated with the digital image file, by using the shared key pair The digital image file is encrypted, and the digital image file is sent into server；Wherein, label, the account Family information and the device identifier indicate how the server is handled the digital image file.

12. imaging device according to claim 11, wherein, the imaging device is ultrasonic device.

13. equipment according to claim 11, wherein, the routine is used to transmit digital picture number via standard port According to.

14. system according to claim 11, wherein, the routine is additionally operable to perform initialization, sends heartbeat to institute State at least one of server, Trouble Report, config update and software upgrading.