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

Abstract

A system for communicating an image is configured to capture and image and generate a digital image file, the system comprising: an imaging device comprising a device identifier; A series of routines that label the digital image file to 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; Receiving a digital image file and processing 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 capturing the digital image file Lt; / RTI >

Description

TECHNICAL FIELD The present invention relates to a system and a method for encrypting, converting, and interacting with a medical image,

The embodiments described herein relate to the 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.

Medical diagnostic devices and medical imaging systems have become increasingly complex in recent years. In response to the increasing challenges of digital imaging technology, the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) have developed the Digital Imaging and Communication In Medicine (DICOM) ) 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 for communicating between systems using TCP / IP. One of the goals of the standard is to uniformly transfer medical images and information between viewing and scanning sources so that users of other imaging software and / or hardware can share information. DICOM files can be exchanged between two entities that can receive images and patient data in DICOM format. DICOM can integrate scanners, servers, workstations, printers and network hardware from a number of manufacturers into the Picture Archiving and Communication System (PACS) for storing and downloading digital images. Other devices include a DICOM conformance statement that explicitly specifies the DICOM classes they support. DICOM is widely adopted in hospitals, gaining popularity in small dental and private hospitals.

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

The type of data and the 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 in their hierarchical distribution. The patient may participate in multiple studies (cases), and in turn may include multiple series (examinations or visits), multiple instances (typically images containing files). This clearly identifies the DICOM file and means that it is suitable for that hierarchy. Every DICOM file contains an identifier to generate the form. That is, the identifier reflects the equipment or location from which the file originated. The file also includes a timestamp related to both the file itself (instance) and the series. Using the timestamp and the original identifier, the image can be clearly identified using the data without including any identifiable patient information, thereby protecting the patient ' s privacy problems. In addition, 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 can not inadvertently separate the image from this information because the patient ID is actually contained in the file.

Most PACSs process images from a variety of medical imaging devices, including US, MRI, PET, CT, and so on. Electronic images and reports are transmitted digitally via PACS; This eliminates the need to manually store, retrieve, or transfer files to the film jacket. PACS consists of four main components: imaging formats such as CT and MRI; A secure network for transmitting patient information; Workstations for image interpretation and review; And long-term and short-term archives for storing and retrieving images and reports. PACS, coupled with available emerging web technologies, has the ability to provide fast and efficient access to images, interpretations, and associated data. PACS is divided into traditional film-based image retrieval, distribution and physical and time barriers associated with display.

Medical imaging devices typically output digital image data. Many, if not all, of these devices use the DICOM standard for both image file format and network transmission. These images are generally not readable in consumer image viewers or mobile devices. Thus, patients who share medical images have difficulty converting and delivering these images. A good example is to share images from ultrasound during pregnancy. Future parents usually want to store, share, and show images of future children. In addition, they may want to transfer these images to friends and relatives' mobile phones or email accounts. You can post it on a social network or keep it in your personal digital "photo album". All of these events require one of scanning, buying, installing and using a DICOM viewer software package with a scanned or hard-copy of a printed hardcopy of the image. 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. In general, there is no real way for patients to see images associated with their condition, treatment, condition, and the like. In addition, there is little effective means for a doctor or clinician to quickly and remotely retrieve images for diagnostic or other purposes.

In fact, most small-scale medical practices, such as small clinics, private hospitals, and dentists, have difficulties in converting and delivering medical images in an economical and timely manner. These facilities typically have no technical support staff or financial resources to run the entire PACS for image retention and deliver them to a remote specialist for a second opinion and consultation. They often rely on film, or recordable CDs that are sent by mail or messenger. This is not safe if you are using slow, non-encrypted, and unregistered mail delivery. The cost of running PACS is not just about paying for licenses. In addition to the major investments in advanced infrastructure, including peripheral software, hardware and facilities, the cost of training and management of staff is added to the cost of implementing PACS. Since these major investments are expensive, most SMEs do not generally fall short.

Also, many medical actions may not have a local network with which the medical imaging device communicates, or the local network may not be stable or properly configured to receive and communicate medical images. The medical imaging device itself often lacks the ability to encrypt or transform the captured image. If the local network exists, it may not be possible to integrate network devices such as PACS for managing digital images.

Peripheral devices for connection to a medical imaging device can be used to communicate encrypted and / or transformed images to a secure server on a remote network, as well as to provide encryption and translation of medical images in a secure, standardized image file format to provide.

According to an aspect, a system for communicating an image comprises: an imaging device configured to capture and image and generate a digital image file comprising a device identifier; A series 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; Receiving a digital image file and processing 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 capturing the digital image file Lt; / RTI >

According to another aspect, an imaging device includes a form configured to capture and image and generate a digital image file; Device identifier; Shared key; And labeling the digital image file, associating account information with the digital image file, associating the device identifier with the digital image file, encrypting the digital image file using the shared key, To the server; and < RTI ID = 0.0 > a < / RTI > 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 of the invention will be described with reference to the accompanying drawings.
1 is a diagram illustrating an exemplary system for automatic conversion and distribution of a medical image into one of a plurality of output forms according to an embodiment.
Figure 2 is a high-level block diagram illustrating certain components of an exemplary data transformation and delivery system that may be included in the system of Figure 1 according to one embodiment.
3 is a flow diagram illustrating an exemplary automated message generation process performed by the data transformation and delivery system of FIG. 2 in accordance with one embodiment.
4 is a flow diagram illustrating exemplary types of information and data that may be examined in the process of Fig. 3 in accordance with one embodiment.
Figure 5 is a flow diagram illustrating an exemplary process for use of information embedded within metadata included in a file being invoked by the data transformation and delivery system of Figure 2 according to one embodiment.
Figure 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 Figure 2;
Figure 7 is a typical use of a Web GUI that may be included in the data transformation and delivery system of Figure 2 and is a flow diagram illustrating a simplified interface for locating an image in its original form without any identifiable patient information according to an embodiment .
Figure 8 is a flow chart illustrating a variation of a typical use of a Web GUI and is a simplified interface for locating images by using a portion of the identifiable patient data according to one embodiment.
9 is a diagram illustrating an exemplary system for automatic conversion and distribution of medical images to one of a plurality of output forms according to another embodiment.
10 shows a medical imaging device according to an embodiment of the invention and a peripheral device connected to a remote server for converting and encrypting a medical image file from the medical imaging device.
11 shows a medical imaging device according to an embodiment of the invention and a network device connected to a remote server for converting and encrypting a medical image file from the medical imaging device.
12 is a flow diagram of signal flow over a network.
13 shows a system for converting and encrypting a medical image to an encryption and translation unit, a medical imaging device and a remote server according to an embodiment of the present invention.
Figures 14 and 15 illustrate a conventional workflow for medical image sharing in a primary care and emergency room environment.
16 is a flow diagram of one embodiment of a system for real-time remote interaction collation for medical diagnosis.
17 shows a user interface that can be viewed by a user of a real-time remote interaction system.
18 shows a user interface that can be viewed by the user of the real-time remote interaction system.
FIG. 19 shows a user interface viewable by the user of the real-time remote interaction system.
20 shows a user interface that can be viewed by the user of the real-time remote interaction system.
Figure 21 shows a user interface that can be viewed by the user of the real-time remote interaction system.
Figure 22 shows a user interface that can be viewed by the user of the real-time remote interaction system.
23 shows a user interface that can be viewed by the user of the real-time remote interaction system.
24 shows a user interface that can be viewed by the user of the real-time remote interaction system.
25 shows a user interface viewable by the user of the real-time remote interaction system.
26 shows a medical imaging device according to an embodiment of the invention and a mobile device connected to a remote server for converting and encrypting a medical image file from the medical imaging device.
27 and 28 illustrate an exemplary process that may be performed on a device or computer system for communicating an image to a server using IP networking.
29 is a diagram illustrating an exemplary system including the routines of Figs. 27 and 28. Fig.

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

The central computer system (CCS) 30 may include a data conversion and delivery system (DCDS) 32 for processing medical data. The CCS can include one or more servers and includes one or more processors or CPUs, a memory associated with the processor (s), a data storage module, display means, and input / output interface means. It should be appreciated that various other peripherals and modules may be connected to CCS such as other servers, other data storage modules, or intrusion detection systems. In addition, the CCS may be a cluster of interworking servers, each of which handles certain tasks in the system. Similarly, all modules are shown in FIG. 2 and may be separate servers in such a cluster to distribute the load and increase capacity of the system as described below.

The DCDS 32 is configured to convert a medical image associated with the medical data into, for example, a consumer friendly image, video, or both. The DCDS 32 then sends these transformed images to a number of destination or output forms 40, as instructed by the user / operator of the DCDS 32 or as instructed by the information contained in the medical data . These destinations 40 may include, for example, web sites such as social networking sites including Twitter, Facebook and Google Health; Cell Phone; PDA; Email account; Or any computer system capable of receiving data over a protocol such as, for example, SOAP and REST. The DCDS 32 functions in a manner that allows the source forms 10 and 20 to be protected by the most stringent firewall environment 50 while still allowing transmission using 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 is undergoing ultrasound during pregnancy, the ultrasound image may be transformed into a series of images that can be transmitted to the parent's social networking web page, their mobile device, their friends & (32). More specifically, a good sequence of the fetus waving the arm may be captured and stored during the ultrasound examination by the operator. The ultrasonic operator, typically a nurse or technician, for example transmits a DICOM file stored in the DCOM 32. A nurse, technician or trusted employee at the patient's facility (user) can use the remote graphical user interface (GUI) interfaced with the DCDS 32 to retrieve the sequence of the destination sent by the source form 10 have. Thereafter, the user can enter his / her cell phone number, web account information, e-mail address, etc., and can start delivery after inputting any personal message commanded by the patient. Thereafter, the DICOM file, for example a file converted to a mobile phone compatible video format such as 3gpp, may be transmitted as a multimedia message to the mobile phone, and the converted file in another suitable format may be sent to the designated email and web account have.

In addition, the nurse or technician at the patient facility may enter the patient ' s mobile telephone number in the patient information field of the ultrasound machine. For example, upon receipt of a DICOM data file, the DCDS 32 may be configured to automatically find the corresponding number embedded in the DICOM data file and then automatically transfer the converted image or video file to a designated destination location 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 in accordance with one embodiment. It should be understood that the diagram of FIG. 2 is for the purposes of explanation and illustration, and is not intended to limit the embodiments described herein to any particular architecture or design. 2 is not considered to provide a detailed view of all the components of the exemplary DCDS 32. [ In operation, a request from the form 10 may be processed by an input stage comprised of a receiver 203 and a store and parser 204. The receiver 203 may be configured to authenticate a connection from the source form 10 and to process network transactions necessary to complete the request.

The storage and parser 204 may be configured to analyze the received data and to store any image data 205 and all of the metadata 206 in the storage system 214. For example, the image data 205 may be stored as binary data, but the metadata may be stored as structured data that allows structured access (such as search and association among other items) to the data. The store and parser 204 may be configured to remove all sensitive patient information from the data file being received under a particular transition or specific condition. For example, an operator of the system may selectively use a graphical user interface (GUI), such as Web GUI 208, to select portions of metadata that are considered sensitive. The system can also be programmed to automatically determine if a field in the metadata is sensitive. This process is called anonymization and is performed to protect the patient's personal information. Anonymization will be described in more detail below.

In certain embodiments, an event signal may be triggered indicating that newly stored data has been added. The event system module 209 may be configured to determine an action to be taken as a result of receiving an event signal from the parser 204. [ For example, if a rule for automatic delivery is set and an appropriate metadata value is found for the newly received data stored in the structured database 206, then the event system module 209 may automatically forward it to the output module 213 And send a signal to transmit the transformed data commanded by the rule. This processor is described in more detail below.

The output module 213 may be configured to accept calls from other parts of the DCDS 32, including general data, information to send, and the number of delivery destinations including email addresses. For example, the data may include a text message, for example, a reference to a DICOM image, two mobile phone numbers, and one email address. The output module 213 can be configured to assemble an appropriately formatted output "package" or message, and to send a message obtained using the module plug-in architecture. A plug-in (not shown) for each corresponding type of destination may be included in the output module 213 and used.

In the example provided above, when a service call is received by the DCDS 32, the output module 213 may assemble one MMS message packet containing a JPEG version of the image and message text, Are all combined and encoded. Thereafter, this message may be sent twice to each of the requested phone number receivers first, then to each next specified email address destination.

The output module 213 can request the converted image from the image converter 211 by identifying the original image and designating the requested format and size. Thereafter, the image converter 211 can be configured to look for an existing image in the transformed image cache 212 that matches the request. If no match is found, an image can be generated from the original image data 205. The image converter 211 may be configured to use the original image metadata 206 stored in the database to determine if the requested format is appropriate. Otherwise, you can respond with an error. For example, it is appropriate to request a JPEG still image of a multi-frame DICOM image file (in fact, video) while an error occurs when requesting an mp3 audio version of a still image.

The image converter 211 may be configured to respond to events from the parser 204 and to perform common transforms in advance. This improves the responsiveness of the system components, particularly the output module 213 and the Web GUI 208; The trade-off increases in the requested storage and also decreases slightly in the overall security level.

The Web GUI 208 provides the DCDS 32 with remote access to a medical practitioner, for example, via a secured web browser connection (https) 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.

The Web GUI 208 may operate on the structured metadata 206 to locate and identify images. For example, to request a conversion from image converter 211 to display a thumbnail and preview of the image and to provide a service request format in which an output message is specified and sent to the output module 213 for delivery Lt; / RTI >

The adaptable garbage collector 207 can continuously evaluate the state of all data and can be compared to the configuration made by the administrator of the system. The configuration may set a particular standard on which an item must be met in order to remain in or remove from the system. One base standard may be the lifetime of an item. For example, an item may have been stored a week ago or a certain number of days may be automatically deleted. Other auto-deletion standards may be the number of times an item was previously transmitted, the stored system state information, and the value of the metadata. This functionality is also useful for partially confining the use of resources and helping to provide patient confidentiality by removing patient data that the system no longer needs to maintain.

It should be noted that in some embodiments, the image should be used for clinical or diagnostic purposes. In such a case, it is often the case that the image ultimately displayed on the device used to view the image must maintain a certain resolution or image quality. As such, in a particular embodiment, one or more of the parser 204, the event system module 209, and the image converter 211 may be used either alone or in combination to recognize that the image is being viewed in a diagnostic or clinical application Lt; / RTI > This recognition may be based on information contained in the metadata, information stored in the image system 214, or information provided through the GUI 208. [

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

Once an image that can be used for clinical or diagnostic purposes is determined, then the image converter 211 can be configured to determine the resolution or image quality requested, for example, based on the information stored in the storage system 214. [ For example, resolution, image quality, or both, for various types of images, clinical applications, etc., may be stored in the storage system 214. Thereafter, the image converter determines the exact image resolution and quality and converts the image accordingly. In a particular embodiment, the DCDS 32 may be configured to determine whether the identified output device or address can display the image converted to the required image resolution and quality before transmitting the image. If the device or address is not possible, then the DCDS may generate an error message or other alert indicating it. The error message may be displayed on the GUI 208, on the device, or both.

As described above, the DCDS 32 may be configured to take an incoming medical image file and automatically convert it for distribution and viewing by any of a plurality of output formats. 3 is a flow diagram illustrating one embodiment of an automated message generation operation performed by the DCDS 32 in accordance with one embodiment. In the example of FIG. 3, it is assumed that the destination information, for example, the output format information, is included in the medical image file received by the DCDS 32. In another embodiment, the user can access the DCDS 32 via, for example, GUI 208 and specify a file to be sent in an output form; As configured in accordance with the systems and methods described herein, the strong aspect of the DCDS 32 is the ability to automatically determine the destination and transform and format the data as appropriate as described below.

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

In step 322, an output destination type or form may be determined. For example, the header may include information identifying a recipient of an image included in the image file. More specifically, the header may include an online photo album page, site or service; Social networking page or service; Mobile devices, and the like. ≪ RTI ID = 0.0 > [0040] < / RTI > The basic types of destinations are mobile devices such as mobile phones; Email account; A web application specific interface (API) associated with an online site or service, and the like. Thus, the DCDS 32 can be configured to examine the header file and determine the associated output device or service, i.e., the form.

If possible, then the DCDS 32 may be configured to retrieve a particular characteristic of each destination type, as shown in step 324. These characteristics may include the capabilities and physical characteristics of the destination device and the specifications and limitations of the network class and message type. This information is then used to determine the output formatting and other specifications needed for each output format. For example, this information can be used for adaptation of image data based on the specification of the type of message being transmitted, for example e-mail has limitations of the specification and common practice that can be applied; MMS has very different limitations that can be applied.

The performance and characteristics determined in step 324 include the frame size, i.e. the pixel size of the image or video, e.g., 640 x 480; Email attachments in excess of 10 MB in size are often not allowed, such as data rates or data sizes, e.g., MMS messages; Supported encoding formats, such as MPEG 4, JPEG, etc.; And message layout rules, that is, how a message can be configured for a destination, e.g., an MMS is configured as a "page ", each of which includes a single image or video and a single text with audio While email can be HTML layout and can keep attachments of all file formats.

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 format. For example, if the image data includes video data, then a determination can be made whether the output format is capable of receiving and displaying video data.

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

Thereafter, in step 330, the data can be extracted and converted as needed. For example, MMS messages allow only a very limited total message size. Thus, images or video often need to be tailored and optimized to specifically 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 video. However, since an email account may also contain rules that restrict very large files, an email message may require optimization of the video file, for example, to ensure sufficient quality, but it may also have to adhere to size limits.

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

In step 332, the data may be anonymized as required by any applicable anonymization rule. For example, the data may be extracted and copied in a general format to remove or edit specific data. Thereafter, the data may be converted to a final output format. Steps 330 and 332 may be performed in parallel or latest order as required by a particular implementation.

In step 334, the transformed data may be assembled into an output message according to the applicable format and specification 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 extracted from the metadata accompanying the received file. In addition, the data may be data retrieved from configuration settings based on the above-described series of characteristics.

In a particular embodiment, the data components that will contain the output message are assembled according to the template rules for the type of message being generated. For example, various template rules may be stored in the storage system 214 and accessed by the output module 213 to assemble the output message. For example, an MMS message is based on a page metaphor where each page may contain images or video, text elements, and audio elements. Thus, it may be required to transmit two or more images, or to assemble the message into several pages if it includes text, audio or both with the image (s). In contrast, an email message may include, for example, a number of arbitrary images, an attachment, etc. according to the message size limitations.

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

4 is a flow diagram illustrating exemplary types of information and data that may be inspected at step 320. [ As can be seen in FIG. 4, if the file is incoming, the metadata or more specifically the header may be examined to identify the input format in step 420. In step 422, compatibility with the system determined in step 420 and the system can be determined. If so, then a specific characteristic of the data contained in the image file may be determined at step 424. [ For example, whether the file actually contains any image or video data, or whether the data is a simple report or a measurement, may be determined at step 424. [ If the incoming file contains, for example, a report or measurement data, then this information is then extracted and stored in step 426, for example, in a general structured format. In step 428, any image data may be extracted and stored, and various properties such as a binary encoding format, frame size, color bit depth, still image or video may be determined.

FIG. 5 is a flow diagram illustrating an exemplary process for use of information embedded within metadata including files received by the DCDS 32 in accordance with an embodiment. The metadata, e. G., A header field, may be used to ensure secure and secure delivery of image data included with it. For example, a DICOM image file may include a plurality of header fields that are key value pairs in a number of data types, such as strings, numbers, dates, and special measurement types. A field that can be embedded can be strongly linked to a file that provides metadata. In this way, the header file and the associated data are not mixed up because they are not separate.

In step 520, the DCDS 32 may be configured to automatically track and record header fields for each network device transmitting the image. In this manner, the DCDS 32 may identify a particular device associated with the incoming file. The DCS 32 may do this by recording the data contained in the device dependent header field for the associated form in step 524 after recording in step 522 whether a header field exists for the particular form 10. A particular device may always be recorded for the same value, e.g. manufacturer, model name, model number, etc. Thus, the DCDS 32 can use this information to identify a particular device.

In step 526, the DCDS may take appropriate action after detecting any change in the data. For example, changing the header field data, which should not change the manufacturer information, etc., may be an indication that the file has been tampered with or that someone is attempting to hack the system. In response to this change, for example, the system may record events, inform the operator, place data to be received in the approved wait, isolate the data or additional data from the associated devices, Reject the data, and reject all future data from the device.

In step 528, the DCDS may be configured to retrieve a header field for data that can identify the intended recipient as described above. The identification may be in the form of an actual, e. G., E-mail address, a mobile station ISDN (International Subscriber Directory Number), a website address, In practice, this direct identification may be desirable since it utilizes the presence of a header field. The identification may also be indirect, such as, for example, an ID that can be used to retrieve addresses directly from the registry stored in the storage system 214. [ Further, each field may contain one or more pieces of data and other types of data. Thus, any identification or address field may include an email address, as well as a telephone number. Further, the identification data may be included in two or more fields.

The DCDS 32 may then be configured to determine the action to take in step 528 based on any identification data detected in step 530. [ In some examples, such actions may include sending an appropriate message to any address found, appropriately formatting the message as described above, informing the operator, for example adding a message to the queue for manual acknowledgment, It may include placing and adding other data or information to the message.

6 is a flowchart showing the operation of the DCDS 32 in more detail. Referring to FIG. 6, the conversion request 301 may be received, at a minimum, including an internal identifier for the image and a destination format. As described above, the conversion request may be the result of information and data included in the metadata associated with the incoming file. However, as described below, the request may originate from an input received via GUI 208. [ Optionally, the request may include a new image size to be scaled as an output image to be transmitted. The image converter 211 may then be configured to determine the presence of the requested image 304 by attempting to locate the metadata associated with the metadata in the metadata database 303. [ If there is no record for the requested image, the transducer may optionally return the placeholder image 305, 308 or abort the translation attempt 306. The 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 the metadata record of the database 303 is present, then the transducer may be configured to load the DICOM image 307 from the image storage device 302, for example, in a low binary format. The converter 211 may be configured to determine whether the image data should be resized to the size provided by the request or to the size required by the requested output format. For example, the JPEG preview for the Web GUI 208 may be rendered to any size suitable for the layout of the html document, while the video for the MMS message has a very specific size to follow the specification.

Next, the image data may be converted to the requested destination format (311). The result may be stored in the image cache 312, and the metadata record may be updated 313 to indicate the presence of the transformed image. Finally, the transformed image may be returned in response to the request. Thereafter, the converter 211 may return the converted binary data directly, or may return a reference to that position in the image cache 313.

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

Two basic methods for accessing a file may be provided. The first is to find the file without identifying it. This is described in detail with reference to Figure 7; It should be noted that each device that sends files to the DCDS 32 may be identified by recording and mapping the header fields of the incoming file transfer. In addition, the devices may be partially identified based on their network address, the AE title used for transmission, or both. Each device may be given a unique and desirable meaningful name to the operator. In addition to the file, the series, study, or both can be identified by the time and date at which the image was captured, and by the device resulting from the header field identifying the operator of the device used to capture the image.

Because patient information is not needed, the DCDS 32 can handle anonymized data, and patient information can not be collected by misuse of the system. Also, the most used images may be stored as the most recent images in the system. Thus, finding an image can be done very efficiently in this way. Once the file, series, research, etc. are found, the GUI 208 allows the operator to directly access functions such as viewing an image, transmitting the image, and the like.

With this in mind, Figure 7 is a flow chart illustrating exemplary use of the Web GUI 208 and is a simplified interface for locating an image in its original form without any identifiable patient information 401-404 according to one embodiment . If an 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), a necessary conversion is requested from the image converter (211) (408). In the case of all successful requests, the data is assembled by appropriate output plug-ins 409-411 and the results are sent to the appropriate destination (412-414). Status information for each individual output is collected 415 and returned to the form view 405 (416 or 417). At this point, the user may choose to repeat the transfer process or look for another image.

The Web GUI 208 allows, for example, to transmit groups of images belonging to the same DICOM series. The operation steps are similar to those shown in Figs. 7 and 8. Fig. The Web GUI 208 also configures the event system 209 and provides an interface for organizing and storing output destination addresses and other required management tasks. As a security measure, it should be noted that the Web GUI 208 does not handle the acceptance of source forms that store images or allow access privileges to their images. These important settings can only be used locally or remotely through separate access methods. In the case of DCDS running on a Unix-style operating system, remote access is typically accomplished through the Secure Shell (SSH) protocol. If the DCDS is run on a Windows operating system, remote access can typically be done through Terminal Services. Both protocols are examples of secure remote access to the operating system.

The second way to access the file is to use the identification information. For example, an operator can retrieve a file using patient information such as name, date of birth, patient ID, and the like. For example, the operator can enter a search term, and if there is a match, the system can provide all available research. If multiple patients are returned, they can then be presented for selection. Once the patient is selected and the associated file, series, study, etc. is found, the GUI 208 allows the operator to directly access functions such as viewing images and transmitting images.

Figure 8 is a flow diagram illustrating a variation of the exemplary use of the Web GUI 208 and its simplified interface for locating images by using a portion of identifiable patient data 501-504, such as patient name and date of birth. In addition, to avoid using actual patient information, an irrelevant identification cipher or PIN code may be used to ensure the privacy of the patient. Thereafter, the processing steps as described above with reference to Fig. 7 can be performed.

In certain embodiments, the CCS 30 may be configured to host and support various value-added services, for example, to patients and families, in connection with images captured by the form 10, as shown in FIG. 9 Lt; RTI ID = 0.0 > 902 < / RTI > For example, if the image is a fetal ultrasound image, the server 902 may be configured to provide various services for parents, family members, friends, and the like. For example, the DCDS 32 may be configured to transform an image into a suitable format or a format supported by the server 902 and the associated service. The image may be sent to server 902 and stored in storage system 904.

It should be appreciated that the server 902 may actually include a plurality of servers, computers, routers, and also the appropriate software and firmware required to perform the functions described herein. In addition, the storage system 904 can include one or more databases, one or more storage servers, and optionally other physical storage media.

The server 902 may be configured, for example, to host a web site from which a user may create an account. The user can then access images of the site to purchase images, pregnancy calendars, custom mugs, key chains, t-shirts, canvases, and the like. The site may also be configured to provide pictures, illustrations, fetal and child development information, health and nutritional information, and the like. Such sites include, for example, a registry such as a baby shower; Automatic updates to friends and family; Digital and viral gifts such as baby videos with digital lullabies; These services are enabled as invitation and thank you cards.

The user may charge a fee to set up the account once or on a periodic basis, for example a subscription fee, and the user and family and friends may charge various products and / or services.

The kiosk 908 may also be set up in a maternity ward that may, for example, provide at least some of the same services. The kiosk 908 can be interfaced to the server 902 alone, that is, either directly with the CCS 30 or as shown. Families and friends can, for example, order photos and other items from the waiting room.

In addition, the user can continue to use the account after the child is born. For example, the site may track children during childhood, or at least several months or years. The site may be configured to send birthday reminders and notifications to friends and family, or to announce other special events, development indicators, and the like. In addition, the site may be configured to continue to display health and nutrition information, as well as development information for both the mother and the child.

In fact, it may be desirable to have parent upload contact information for friends and family. In this manner, the server 902 can be configured to continue sending birthday reminders to friends and family. In certain embodiments, a site hosted by server 902 may be associated with or hosted with a "gift store" that provides a variety of products and services. In addition, the site may provide discounts, coupons, etc. to various other businesses and stores. The site will have similar demographics to children and families, as the server 902 will have appropriate demographic information associated with the child, e.g., residence information, gender, age, race, and even parental age, You can send appropriate reminders, gift recommendations, discount offers, etc. for the public.

In this regard, it may be desirable to provide the user with an opportunity to provide such demographic information. Thus, in an embodiment, a user may access the site to customize or provide profile information, contacts, preferences, and the like. Thereafter, the algorithm executed in the server 902 may be configured to use information available for product recommendation, and the like. Indeed, since the server 902 has information about individuals around the world, the algorithm can be configured to recommend using information about populations sharing similar demographics, income levels, preferences, and the like.

In certain embodiments, a user may purchase an item through a site, i. For example, the server 902 may be configured for credit card payments, PayPal accounts, or for mobile billing. Thus, the server 902 may be configured to process the transaction, deduct the appropriate fee, or charge a transaction fee to the associated business, affiliate, partner, Purchasing information is also provided to the algorithm and can be used to create future recommendations. In fact, you can make more targeted and relevant recommendations through the purchase of the entire relevant population.

Thus, as the child grows, the algorithm can be constantly updated and refined, e.g., to make a gift recommendation. Recommendations can be sent automatically to friends and family for years. As the database increases over time and as more and more users increase, the algorithm can be refined to provide more relevant and more targeted recommendations.

It should be noted that the database must contain vast amounts of 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 buying habits. This can be very useful for simply tracking and mapping interactions between large populations, as well as advertising and product recommendations that target the information of the interconnection.

It should be noted that such sites may be built around other conditions or events, such as cancer support sites, physical therapy support sites, and the like. In addition, the merging of interconnection data for these various different conditions and events can extend the power of the information and lead to better algorithms for targeted information and products and services.

It should also be noted that the user may access the site via the Internet, for example, using the computer 914 and the mobile device 912. In addition, the site may be interfaced with other social networking sites such as Twitter, Facebook, and the like. In certain embodiments, the site may be transformed into an application or widget that can actually be sent to another site. For example, a grandmother can easily update and be notified without having to log on to the server 902 with the application on her Facebook page. This may increase the interaction with the site, e.g., increase the amount of information and data, and the server 902 is available as an input to the algorithm described above.

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

Peripheral encryption and conversion device

In one embodiment, the peripheral device is attached to the medical imaging device for encryption and translation of the medical image in a secure and standardized image file format, and may also convey the encrypted and / or translated image to the security server on the remote network . 10, the peripheral device 102 may be a different type of dongle or stand-alone device that may be physically attached to the medical imaging device 101 and may be a remote server 103 ), ≪ / RTI > a medical image file of a medical imaging device (e. The peripheral device 102 may be attached to a communication port on a medical imaging device, such as a network port, a serial port or other communication interface. The peripheral device monitors all the medical image files generated in the medical imaging device and acts as a filter for encrypting and converting the selected medical image file to transmit to a remotely connected device on another network such as a server or mobile device .

The dongle may be configured as a separate network connection to a local area network (LAN) or a wide area network (WAN), or it 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 is not capable of transmitting medical images, the dongle has network hardware so that the dongle communicates via a WiFi or cellular network, or directly connects an Ethernet cable to the medical imaging device It is possible to allow connection to the local network which is not available.

In another embodiment, the cryptographic dongle 102 may be connected to the imaging device 101 in an unstable connection, in which case the cryptographic dongle 102 may take a medical image stored in the medical imaging device 101, Encrypting the image for transmission over a connection to function as a remote security server or a remote device such as a mobile device that is the ultimate destination of the medical image.

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

An embodiment of the present invention may listen on a known port for unprotected communication and automatically encrypt and reroute the connection in its encrypted form via the encrypted counterpart's port. For example, a typical DICOM connection on TCP port 104 or 11112 may be encrypted with SSL / TLS and routed from TCP port 2762 to DICOM / TLS. This can effectively make a connection to the remote server as a secure TLS connection to the client device as an unprotected connection. A high level of security is maintained 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.

Likewise, a conventional "web" connection over the HTTP protocol on the TCP port 80 may be encrypted with SSL / TLS and routed from TCP port 443 to HTTPS. This makes it possible to effectively connect to an HTTP server as an HTTPS connection and to indicate to an HTTP client as an unprotected connection. It should be noted here that encrypting HTTP traffic is only useful for legacy clients and servers with secure connections. However, this is a known pair of network ports that provide a description of the general embodiment of the present invention.

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

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

Embodiments of the present invention may use any and all associated encryption methods to protect the connection. Yes or they include not only the SSL / TLS standard described above, but also other common cryptographic standards. The point is that the present invention can imitate a unique encryption standard for each type of connection supporting the embodiment. Encryption can be encoded and decoded with a combination of dedicated chips (electronic hardware components), software, or software with hardware acceleration capabilities.

Network encryption and conversion device

A network device for connection with a local network comprising at least one medical imaging device includes means for encrypting and translating medical images from at least one medical imaging device into a secure and standardized image file format as well as a secure server on a remote network And provides communication of encrypted and / or transformed images. The network device acts as a router or gateway on the local network to monitor the traffic of the medical image from the medical imaging device to a destination device external to the local network and to transmit the medical data file to an appropriate format To 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 and the network device 104 acts as an encryption router to receive a medical image file from one or more medical imaging devices 101 over a local network, . Thereafter, the encryption router 104 will be configured for encryption and conversion of the medical image in a secure, standardized image file format. Thereafter, the encryption router 104 will be configured for communication of encrypted and / or translated images over a secure connection to a secure 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 may then send the DICOM image encrypted over the WiFi, cellular (3G), or cable connection to the remote network. In this configuration, the network device 104 serves 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 data flow of a medical image file from a local area network (LAN) 301 to a remote device on a remote wide area network (WAN) The network device 104 includes a cryptographic receive port 302 for monitoring network traffic on the LAN for transmission of a medical image file that is encrypted or unencrypted in a suitable format. . The encryption database 305 may store encryption settings that provide commands for the type of encryption that 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 (303) for encryption of the file, and then mapped (304) for transmission of the file. The encrypted file is transmitted to the remote WAN network 307 via a firewall or other local router 306. [

In one example, the Vscan imaging device captures a medical image that is not DICOM but is unencrypted, but is selected to be transmitted from the Vscan to a remote security server on the remote network. Thereafter, the medical image is transmitted to the network device 104 and the network device 104 converts the image to a DICOM image and encrypts the image before transmitting it to the remote security server.

The network device may be useful in a non-secure or untrusted local network because it creates a secure connection with the medical imaging device and a remote access server or device on another network. In addition, the network device may be useful in highly secure networks with strict firewalls that interfere with access to remote security servers.

In one embodiment, the network device acts as a remote security server that is attached to the local network but one or more medical imaging devices transmit the image to the network satellite under the impression that the network satellite is the final destination of the medical image file And may be configured as a network satellite. The network satellite then takes a medical image (either), encrypts or transforms it, and then sends the encrypted and transformed image to the actual remote security 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, and instead sends a file, believed to be the ultimate destination of the medical file, To a remote security server on the network.

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

One embodiment of the present invention is capable of listening on a known port for unprotected communication and automatically encrypting and routing the connection in its encrypted form via an encrypted counterpart of the port. For example, a typical DICOM connection on TCP port 104 or 11112 may be encrypted with SSL / TLS and routed from TCP port 2762 to DICOM / TLS. This can effectively make a connection to the remote server as a secure TLS connection to the client device as an unprotected connection. A high level of security is maintained 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.

Likewise, a conventional "web" connection over the HTTP protocol on the TCP port 80 may be encrypted with SSL / TLS and routed from TCP port 443 to HTTPS. This can effectively make a connection to the HTTP server as a secure HTTPS connection to the HTTP client as an unprotected connection. It should be noted here that encrypting HTTP traffic is only useful for legacy clients and servers with secure access. However, this is a known pair of network ports that provide a description of the general embodiment of the present invention.

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

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

Embodiments of the present invention may use any and all associated encryption methods to protect the connection. Yes or they include not only the SSL / TLS standard described above, but also other common cryptographic standards. The point is that the present invention can imitate a unique encryption standard for each type of connection supporting the embodiment. Encryption can be encoded and decoded with a combination of dedicated chips (electronic hardware components), software, or software with hardware acceleration capabilities.

Encryption and conversion plug-ins

A system and method for encrypting and transforming a medical image file on a device within a network is provided. The encryption and translation unit may be integrated within the hardware and software of the medical imaging device or other network device to encrypt the medical image for transmission to the remote network and to convert the medical image into a format compatible with the destination device or network . The encryption and conversion unit may be configured to package and transmit the converted and encrypted image to a suitable destination such as a security server on a remote network.

The encryption and translation unit monitors the traffic of the medical image from the medical imaging device to a destination device outside the local network and ensures that the medical data file is encrypted and translated in a suitable format for delivery to the device on the remote network , It can act as a router or gateway on the local network. Upon detection, the encryption and translation 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 translation unit is shown in FIG. 13, wherein the encryption and translation unit 104 receives a medical image file from one or more medical imaging devices 101 over a local network that may be unsafe It acts as an encryption router. The encryption and translation unit 104 may be integrated within each medical imaging device 101 as software, hardware or a combination of software and hardware. In another embodiment, the encryption and translation unit 104 may be a router, a gateway, a firewall, or some other network device that monitors and coordinates traffic over the network. Thereafter, regardless of the type of device in which it is deployed, the encryption and conversion unit 104 will be configured to encrypt and transform the medical image in a secure, standardized image file format. Thereafter, the encryption and conversion unit 104 will be configured for communication of encrypted and / or translated images over a secure connection to a secure server 103 on a remote network, such as the Internet.

12 shows a flow diagram of data flow of a medical image file from a local area network (LAN) 301 to a remote device on a remote wide area network (WAN) The encryption and conversion unit 104 includes any one of the software, hardware, or a combination of both, which is one or more of the components described herein. In one embodiment, the encryption and conversion unit 104 includes a cryptographic receive-waiting port 302 that monitors network traffic in the LAN for transmission of a medical image file that has not been encrypted or transformed in the proper format. The encryption database 305 may store encryption settings that provide commands for the type of encryption that 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 (303) to encrypt the file, and then maps (304) the port for transmission of the file. The encrypted file is forwarded to the remote WAN network 307 via a firewall or other local router 306.

In one example, the Vscan imaging device captures a medical image that is selected for transmission from the Vscan to a remote security server on the remote network, although it is non-DICOM and not encrypted. Since the encryption and conversion device 104 is embedded as software running on the Vscan device, it converts the image to a DICOM image and encrypts the image before transmitting it from the Vscan device to a remote security server.

The encryption and translation unit may be useful in an unsecured or untrusted local network because it creates a secure connection with a medical imaging device and a remotely connected server or device on another network. In addition, the network device may be useful in highly secure networks with strict firewalls that interfere with access to remote security servers.

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

In an embodiment of the present invention, it is possible to listen on a known port for unprotected communication and automatically encrypt and route the connection in its encrypted form via an encrypted counterpart of the port. For example, a typical DICOM connection on TCP port 104 or 11112 may be encrypted with SSL / TLS and routed from TCP port 2762 to DICOM / TLS. This can effectively make a connection to the remote server as a secure TLS connection to the client device as an unprotected connection. A high level of security is maintained 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.

Likewise, a conventional "web" connection over the HTTP protocol on the TCP port 80 may be encrypted with SSL / TLS and routed from TCP port 443 to HTTPS. This can effectively make a connection to the HTTP server as a secure HTTPS connection to the HTTP client as an unprotected connection. It should be noted here that encrypting HTTP traffic is only useful for legacy clients and servers with secure access. However, this is a known pair of network ports that provide a description of the general embodiment of the present invention.

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

Embodiments of the invention may be preconfigured only to forward protected traffic to a single remote endpoint. Embodiments of the present invention may use any and all associated encryption methods to protect the connection. Yes or they include not only the SSL / TLS standard described above, but also other common cryptographic standards. The point is that the present invention can imitate a unique encryption standard for each type of connection supporting the embodiment. Encryption can be encoded and decoded with a combination of dedicated chips (electronic hardware components), software, or software with hardware acceleration capabilities.

Mobile device implementation of encryption and conversion unit

In certain embodiments, the encryption and conversion functions described above with respect to Figures 10-13, for example, may be implemented on a mobile device, such as a smartphone, tablet, or other mobile device. This is shown in Fig. 26, and the encryption and conversion unit 105 of Fig. 13, for example, is provided with the mobile device 107 in which the mobile device 107 has the encryption and conversion function as well as the software 109 for performing the routing function, .

In many embodiments, the encryption and conversion functions may be integrated with the mobile device 107 by downloading the application 111 to the device 107. Thereafter, the application 111 may include or allow the user to download the software 109 and perform the necessary functions. Thus, the software 109 may be compiled for the processor architecture of the device 107.

The software 109 may act as a router or TCP proxy through the data transmitted from the device 101, for example, a portable ultrasound machine. In view of the ultrasonic machine, it will communicate directly with the hosted server 103 though it appears to be in direct communication with the Dicom server on the device 107, but actually through an encrypted tunnel or secure connection provided by the device 107.

The port used by the device 107 is often 104, but there is also an alternate port 1112 that is used whenever it is necessary to stay in the upper port 1024.

In certain embodiments, the software may require either one use or subscription. Therefore, the system can be configured so that the certificate can be provided to the software 111 by the server 103, for example. Typically, the certificate may be set to expire, so that the application 109 may enable the process by which the customer pays for reissuing, e.g., extending the certificate validity period. This is simply called "subscription". Automatic expiration can be very useful in this scenario. Thus, the application 109 may include the ability to fake a new certificate and automatically install it, for example.

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

In certain other embodiments, a more advanced user interface may be included in the application 109 that actually enables the user to interact, monitor, troubleshoot, or otherwise act as a function of the software 1111. This may include connectivity verification, presence of a secure connection, upload and download speed, and the like.

In certain embodiments, the mobile device 107 and the imaging device 101 may communicate via a wireless communication link such as NFC, BlueTooth ™ or WiFi. Thus, 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 in turn communicate with the server 103 or the like via, for example, a 3G / 4G WAN system. However, in other embodiments, the device 107 may use a WiFi connection, for example, to communicate with the server 103. [ For example, this serves as a cryptographic device by connecting to tablets that do not have 3G / 4G performance still on the local network (which can be reached by any form 101 that can use it) over Wi-Fi.

For example, if the device 107 and the device 107 use the wireless WAN to communicate with the server 103 after the device 101 has used Wi-Fi, then the device 107 is able to communicate with the Wi- And, for example, as a router to which the ultrasonic machine 101 is connected. The IP address to which the ultrasonic machine connects is the IP address of the device 107 and is the same as the IP address of the router that the ultrasonic machine brings when it is configured through DHCP.

Image management integration

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

In one embodiment of the integrated software, a medical imaging user interface, such as a GE viewpoint interface, generates a plurality of medical images in a portable document format (PDF). Thereafter, the system and method described herein converts a PDF document to an image document in DICOM format and then to a specific destination and then converted to PDF for viewing on a suitable electronic device, such as a personal computer, portable electronic device, .

In another embodiment, the HL7 protocol device is used for medical software communications and includes packets at the destination of a particular document. For example, an image produced by an HL7 device needs to be transmitted to a physician or a patient. The integration software obtains information about the image, adds it to the DICOM message after combining it with the command information at the destination for the image.

The integrated software operates by obtaining the necessary information from the third party software system and determining the information needed to transform, encrypt and transfer 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 a patient taken with a medical imaging device such as an MRI. The system may be implemented as a network having a plurality of computing and display devices that display a graphical user interface (GUI) to each user so that the user can view all of the same medical images in real time. The user is also provided with the option of annotating the image in real time, chatting an image through an instant messaging program, or communicating using a Voice over Internet Protocol (VOIP) or traditional conventional conferencing system. The system provides a plurality of menus for collaborating with a plurality of users in real time to organize images, select diagnostics and other actions, and otherwise perform medical diagnostics based on one or more medical images .

Figure 16 shows the overall workflow for real-time remote interaction, and the user first presents a dashboard or home screen showing various options for the collaboration to diagnose. The dashboard is further shown in Fig. A medical image can be presented to the user from the Vscan device, and then an inspection screen process can be initiated. During the screening, the image is transmitted to the patient, a test is sent to the patient, and the result information can be transmitted for diagnosis. After that, live or real time diagnostics can be done. In a real emergency situation, the flow chart indicates that these steps can be omitted for emergency diagnosis without collaboration with the remote user.

17 shows an overall GUI for a user viewing a display of a computing device on a network. A main menu, a main content area, and a navigation and information section may all be provided.

18 shows a "dashboard" GUI that enumerates a medical imaging device that is connected to the entire network or to the actual computing device of the user (such as a medical imaging device on the user's local network at a hospital or medical facility). In addition, the dashboard may enumerate the images captured by their devices and then arrange them in capture order, patient, doctor, etc. When a new image is received, it is moved to the top of the list and highlighted, allowing the user to easily find them. In one embodiment, when a new image or images are captured by a particular device, an alert will be delivered to the appropriate physician or health care provider to handle the patient's case, such as an SMS or email message. The dashboard may also provide a search function that allows a user to search through the database of the image and the image and the patient ' s information.

19 shows more details of the main menu GUI; An option to select a DICOM image (where the main image workflow is found); An inbox where a user receives a message from the system or another user; A recipient icon of a contact of a patient or other user who can easily find and contact to send images and messages; Setting icons for setting up imaging devices, anonymizing or automating patient messages and labels to classify research; Statistics icons representing traffic over the entire application over time; An administration icon indicating that the administrator manages the user account and establishes the branding of the patient image; An account icon that allows non-administrators to review their profile and other account details; And a logout icon allowing the user to log out of the system. It is to be understood that the icons and options recited herein may be altered and are not limited to their description.

Figure 20 illustrates one embodiment of an image workflow, and the study of images or images may be selected from a list for further review. The research information may include not only the number of files and labels assigned to each study, but also the number of specific studies and comments on images by other users. Other icons for still images, videos, comments, etc. may be provided. The label may be applied to the proposed diagnosis, or to certain types of images or images included in the study.

Figure 21 shows a series of images as thumbnails that can be reviewed quickly before selecting one or more images for further review. A list of actions is provided at the top of the GUI, and other icons of the thumbnails provide an indication of whether the thumbnails represent video and whether they are particular image formats (such as DICOM). The user may click or select one of the thumbnails to open the entire image or video.

Figure 22 shows a real-time remote interaction collation GUI in which a medical image is displayed with annotations created on the image by one or more users. In the course of discussing the diagnosis of the patient by the user, a chat screen for inputting an instant message may be displayed to each user, and a list of thumbnails of other images of the research may be provided at the top. The thumbnail may be updated when a new image is received. The "live diagnostic screen" is a real-time collaboration tool that updates all information in real time and synchronizes editing between users, including annotations, chats, actions, selected images, pins and other changes. The live diagnostic screen may be particularly useful in an emergency situation where immediate diagnosis is required. In the chat screen, the user may invite additional participants and take one or more other actions associated with the case.

Figure 23 illustrates one embodiment of an action that may be selected in a chat screen and may be a method of providing unambiguous instructions to other users, such as a physician or nurse, who provide treatment to the patient. The Action tab may also provide tracking of the selected action, and may be provided to the person who performed the action and suggested to the patient so that the treatment of the patient can be appropriately documented. In the Invite Collaboration tab, the user can invite more users to the Live Diagnostics process. The invited user may receive a text message, e-mail, or telephone to join a live chat session. The user interface may be adapted to any type of computing device, including mobile phones and tablets, so that other users can participate in and from any location and any portable electronic device type.

Fig. 24 shows a GUI that can be diagnosed for a particular patient based on a series of images. The user may select other options for the interest being investigated and possible diagnosis. When a request is sent, it can be notified to one or more users via e-mail, text, or telephone, and an inbox screen that can be displayed when a response arrives can be provided.

As shown in Fig. 25, a GUI for diagnosis is provided in which several images and a plurality of menus are provided in order to select an appropriate diagnosis. The image may be downloaded to a computer desktop for further viewing with other software tools. You can highlight or select options for potential diagnostics. Once the final decision is made, the certificate is sent and recorded for future review and study.

Receive pipeline implementation

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

29 is a diagram illustrating an exemplary system 2900 configured with a communication routine, process, or the like (routine 2906) that performs such message generation functions in accordance with one embodiment. In the example of FIG. 29, the routines 2906 may be included in a device, such as in a terminal 2904 or device 101 itself, associated with the device 101. Terminal 2904 may be a computing device that includes a portable computing device, such as a laptop, tablet, or smart phone. The routines 2906 take images from the device 101 and generate other information that can provide information about image data, labeling, account information, and how to process the image data, Encrypt the entire message, and deliver the message to one or more servers 2912 and storage locations 2910 via the network 2908. [

The network 2908, the storage location 2910, and the server 2912 may represent a basic cloud structure.

As described above, the labeling and accounting information may command or at least provide, for example, the information necessary for the server 2912 to be able to process the message and the image data contained therein. For example, the label and account information may instruct the server 2912 to store the image data and associate it with an account of a particular clinician, a group of clinicians, a hospital, etc., Applications can be accessed and viewed later. The labeling and accounting information may also instruct the server 2912 to forward the image to a clinician or patient device or website.

Routines 2906 may also provide functionality in certain embodiments to allow the image data to be converted into a format that is easily transferred to and processed by the server 2912, in other formats, or with a destination. Routine 2906 may also eliminate the need for DNS or special port usage.

Figures 27 and 28 illustrate an exemplary implementation of a daemon process called these two routines 2906 or 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 an image data receiver 2702 (Dcmtk :: storescp). As can be seen, the sub-process 2704 (Trice :: sendFile) can be linked and these processes can be configured to send an image file, such as a DICOM image file, to the receiver routine 2710 (Trice: receiver) .

Transport Layer Security (TLS) may be achieved using a device-specific personal preshared key in certain embodiments. The key is an encryption key that both the sender and the recipient must successfully compute the same key to succeed in transmission. Account information and labeling can be entered in this calculation in two ways. The depicted configuration should provide a robust file copy function that can succeed if there is any connection between the device 101 and the cloud. Any failure of the communication pipeline shown in Figures 27 and 28 can result in a failure to respond to the device 101 and cause the device 101 to attempt to retransmit the image data.

The communication routine 2704 may also be configured to communicate with the receiver 2710 as shown in Fig. The communication routine 2704 may be responsible for initialization, "heartbeat" transmission to the cloud, failure 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 an argument to both daemon processes 2702 and 2704. In most embodiments, there is no requirement for that disk location for the directory 2706. The directory 2706 may store information such as port #, local-ip address, DICOM dictionary, error log, and the like. If the device 101 is a DICOM imaging device, then the DICOM service may, for example, load the DICOM dictionary from this directory 2706. As described herein, a heartbeat message is sent to and read from a cloud receiver that includes port # and local-ip addresses. Logging information may also be stored in this directory 2706. [

A unique name may be calculated for the device 101. If there is a device ID associated with the device 101, then the device ID should be used instead of the calculated name. If there is a device ID, a file name including the device ID may be passed to the communication routine 2704. [ This device ID may be a primary key for everything related to uplink / device in the cloud database. The cloud service is as follows: when the last heartbeat has occurred from the device; The device is first brought online; What version of the software is loaded on the device ?; Which account is associated with the device? And so on. The uplink depicted in Figures 27 and 28 can be referred to as a heartbeat and uses the device ID as a primary key to transmit periodic state information that can persist in the cloud. It should also be noted that a standard port (e.g., 443) is used for all communications.

Claims (14)

An imaging device configured to capture and image and generate a digital image file, the imaging device including a device identifier;
A series of routines configured to label the digital image file to 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;
Receiving a digital image file and processing 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 capturing the digital image file Lt; RTI ID = 0.0 > and / or < / RTI > The method according to claim 1,
Wherein the imaging device further comprises a shared key, and wherein the routine is configured to encrypt the digital image file using the shared key. 3. The method of claim 2,
Wherein the server comprises a plurality of shared keys each associated with a particular imaging device and the server is configured to decrypt the message from a particular imaging device using the shared key associated with the particular device. The method according to claim 1,
Wherein the routine is stored in the imaging device. The method according to claim 1,
Further comprising a terminal coupled to the imaging device, wherein the routine is stored in the terminal. 6. The method of claim 5,
Wherein the terminal is a mobile device. The method according to claim 6,
Wherein the mobile device is a portable computing device, tablet or smartphone. The method according to claim 1,
The system further comprising one or more storage locations, wherein the accounting information identifies file locations in the one or more storage locations. The method according to claim 1,
Wherein the routine is further configured to convert the digital image file to a format associated with the digital image file before communicating to a server. The method according to claim 1,
Wherein the routine is further configured to perform at least one of initialization, heartbeat transmission to the server, failure reporting, configuration update and software update. A form that is configured to capture and image and create a digital image file;
Device identifier;
Shared key; And
Labeling the digital image file to 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, An imaging device comprising a series of routines configured to communicate with the imaging device,
Wherein the label, account information, and device identifier instruct the server as to how to process the digital image file. 12. The method of claim 11,
Wherein the imaging device is an ultrasonic device. 12. The method of claim 11,
Wherein the routine is configured to communicate the digital image data over a standard port. 12. The method of claim 11,
Wherein the routine is further configured to perform at least one of initialization, heartbeat transmission to the server, failure reporting, configuration update and software update.

Images