WO2016061415A2 - Systèmes et procédés permettant de chiffrer des images médicales, de les convertir et d'interagir avec elles - Google Patents

Systèmes et procédés permettant de chiffrer des images médicales, de les convertir et d'interagir avec elles Download PDF

Info

Publication number
WO2016061415A2
WO2016061415A2 PCT/US2015/055832 US2015055832W WO2016061415A2 WO 2016061415 A2 WO2016061415 A2 WO 2016061415A2 US 2015055832 W US2015055832 W US 2015055832W WO 2016061415 A2 WO2016061415 A2 WO 2016061415A2
Authority
WO
WIPO (PCT)
Prior art keywords
digital image
image file
image
server
images
Prior art date
Application number
PCT/US2015/055832
Other languages
English (en)
Other versions
WO2016061415A3 (fr
Inventor
Martin Westin
Johanna Wollert Melin
Asa Sjoblom Nordgren
John Axel Eriksson
Audree Thurman
Original Assignee
Trice Imaging, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US14/614,405 external-priority patent/US10476848B2/en
Application filed by Trice Imaging, Inc. filed Critical Trice Imaging, Inc.
Priority to KR1020177012383A priority Critical patent/KR102571307B1/ko
Priority to CA2964779A priority patent/CA2964779A1/fr
Priority to CN201580067622.9A priority patent/CN107004059A/zh
Priority to KR1020237028526A priority patent/KR20230125352A/ko
Priority to EP15850895.2A priority patent/EP3207480A4/fr
Publication of WO2016061415A2 publication Critical patent/WO2016061415A2/fr
Publication of WO2016061415A3 publication Critical patent/WO2016061415A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H30/00—ICT specially adapted for the handling or processing of medical images
    • G16H30/20—ICT specially adapted for the handling or processing of medical images for handling medical images, e.g. DICOM, HL7 or PACS
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H30/00—ICT specially adapted for the handling or processing of medical images
    • G16H30/40—ICT specially adapted for the handling or processing of medical images for processing medical images, e.g. editing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/18—Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/88—Medical equipments

Definitions

  • the embodiments described herein are related to delivery of medical image records, and more particularly to the automatic encryption and conversion of medical image files for delivery to mobile devices and/or remote communication systems.
  • DICOM Digital Imaging and Communications in Medicine
  • ACR American College of Radiology
  • NEMA National Electrical Manufacturers Association
  • DICOM Digital Imaging and Communications in Medicine
  • the network communication protocol is an application protocol that uses TCP/IP to communicate between systems.
  • One of the goals of the standard is to make uniform the transferring of medical images and information between viewing and scanning sources to allow users of different imaging software and/or hardware to share information.
  • DICOM files can be exchanged between two entities that are capable of receiving image 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 of digital images.
  • PACS Picture Archiving and Communication System
  • the different devices come with DICOM conformance statements that clearly state the DICOM classes they support. DICOM has been widely adopted by hospitals, and is gaining popularity in smaller dentists' and doctors' offices.
  • DICOM files commonly contain images; therefore, they are often referred to as DICOM images. But it will be understood that a DICOM file does not necessarily need to include an image. Rather, such a file can include measurements or report data. Thus, DICOM files may contain media data, such as, video and audio data, or no media data at all. In that case, DICOM files may contain only metadata identifying the originating modality, the operator, or the patient being examined. Modality here refers to any image generating equipment in medical imaging, such as, Ultrasound (US), Magnetic Resonance Imaging (MRI), Computed Tomography (CT), Positron Emission Tomography (PET), radiographs, and the like.
  • US Ultrasound
  • MRI Magnetic Resonance Imaging
  • CT Computed Tomography
  • PET Positron Emission Tomography
  • a DICOM file is generally structured using data identifying Patient, Study, Series and Instance in that hierarchical order.
  • a Patient can be involved in a number of Studies (cases), which in turn may contain a number of Series (examination or visits), which in turn may contain a number of Instances (files usually containing images). It means that a DICOM file can be unambiguously identified and fitted into that hierarchy.
  • All DICOM files contain an identifier for the generating modality. In other words, the identifier will reflect the equipment or location in which the file was originated.
  • the files also contain timestamps pertaining to both the file itself (Instance) and the Series.
  • DICOM file format differs from other data formats in that it groups information into data sets. For example, a file of a chest X-Ray image actually contains the patient ID within the file, so that the image can never be separated from this information by mistake.
  • PACS Most PACSs handle images from various medical imaging instruments, including US, MRI, PET, CT, and the like. Electronic images and reports are transmitted digitally via PACS; this eliminates the need to manually file, retrieve or transport film jackets.
  • a PACS consists of four major components: the imaging modalities, such as, CT and MRI; a secured network for the transmission of patient information; workstations for interpreting and reviewing images; and long and short term archives for the storage and retrieval of images and reports. Combined with available and emerging Web technology, PACS has the ability to deliver timely and efficient access to images, interpretations and related data. PACS breaks down the physical and time barriers associated with traditional film-based image retrieval, distribution and display.
  • Medical imaging devices typically output digital image data.
  • the overwhelming majority, if not all, of such devices use the DICOM standard for both image file format and network transfers. These images are generally not readable by consumer image viewers or mobile devices. Therefore, patients who wish to share their medical images struggle with conversion and delivery of these images.
  • a good example is to share images from an Ultrasound examination during a pregnancy.
  • the future parents usually would like to keep, share and display the images of their future child. They might also conceivably want to send these images to their friends' and relatives' cellular phones or email accounts. They might even want to post them on a social network, or they might just want to keep them in their personal digital "photo album". All of these events would require them to either scan a printed hard-copy of the image, or to find, purchase, install and learn to use DICOM viewer software package with export capabilities. These software packages are usually not readily available or they are not economical for limited use.
  • a peripheral device for attachment with a medical imaging device provides for the encryption and conversion of a medical image into a secure and standardized image file format as well as the communication of the encrypted and/or converted image to a secure server on a remote network.
  • a system for communicating images comprises an imaging device configured to capture and image and generate a digital image file, the imaging device comprising a device identifier; a set of routines configured to label the digital image file, associated 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; a server configured to receive digital image files and process the digital image file according to at least one of a label associated with the digital image file, account information associated with the digital image file, and a device identifier associated with a device that captured the digital image file.
  • an imaging device comprises a modality configured to capture and image and generate a digital image file; a device identifier; a shared key; and a set of routines configured to label the digital image file, associated account information with the digital image file, associate the device identifier with the digital image file, encrypt the digital image file using the shared key, and communicate the digital image file to a server; wherein the label, account information and device identifier instruct the server as to how to process the digital image file.
  • Figure 1 is a diagram illustrating an example system for the automatic conversion and distribution of medical images to any of a plurality of output modalities in accordance with one embodiment
  • Figure 2 is a high level block diagram illustrating certain components of an example data conversion and delivery system that can be included in the system of figure 1 in accordance with one embodiment
  • Figure 3 is a flow chart illustrating an example automated message creation process performed by the data conversion and delivery system of figure 2 in accordance with one embodiment
  • Figure 4 is a flow chart illustrating example type of information and data that can be examined in the process of figure 3 in accordance with one embodiment
  • Figure 5 is a flow chart illustrating an example process for the use of information embedded inside of the metadata included with incoming files by the data conversion and delivery system of figure 2 in accordance with one embodiment
  • Figure 6 is a flow chart that illustrates the operation of an image converter module that can be included in the data conversion and delivery system of figure 2;
  • Figure 7 is a flow chart illustrating a typical use of a Web GUI that can be included in the data conversion and delivery system of figure 2 and its streamlined interface for finding an image by the originating modality without any identifiable patient information in accordance with one embodiment;
  • Figure 8 is a flow chart illustrating a variation of the typical use of the Web
  • GUI and its streamlined interface for finding an image by using a piece of identifiable patient data in accordance with one embodiment
  • Figure 9 is a diagram illustrating an example system for the automatic conversion and distribution of medical images to any of a plurality of output modalities in accordance with another embodiment.
  • Figure 10 is an illustration of a peripheral device connected with 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 invention.
  • Figure 11 is an illustration of a network device connected with 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 invention.
  • Figure 12 is a flowchart diagram of the signal flow through the network.
  • Figure 13 is an illustration of a system for converting and encrypting a medical image with an encryption and conversion unit, a medical imaging device and a remote server, according to one embodiment of the invention
  • Figures 14 and 15 illustrate traditional workflows for medical image sharing in a primary care and emergency room setting
  • Figure 16 is a flow chart of one embodiment of a system for real-time remote interactive collaboration for medical diagnoses
  • Figure 17 illustrates a user interfaces which users of the real-time remote interaction system will view
  • Figure 18 illustrates a user interfaces which users of the real-time remote interaction system will view
  • Figure 19 illustrates a user interfaces which users of the real-time remote interaction system will view
  • Figure 20 illustrates a user interfaces which users of the real-time remote interaction system will view
  • Figure 21 illustrates a user interfaces which users of the real-time remote interaction system will view
  • Figure 22 illustrates a user interfaces which users of the real-time remote interaction system will view
  • Figure 23 illustrates a user interfaces which users of the real-time remote interaction system will view
  • Figure 24 illustrates a user interfaces which users of the real-time remote interaction system will view
  • Figure 25 illustrates a user interfaces which users of the real-time remote interaction system will view
  • Figure 26 is an illustration of a mobile device connected with 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 invention
  • Figures 27 and 28 illustrate example processes that can be run on a device or computer system for communicating images to a server using IP networking
  • Figure 29 is a diagram illustrating an example system that includes the routines of figures 27 and 28.
  • FIG. 1 is a diagram illustrating an example system 100 for the automatic conversion and distribution of medical images to any of a plurality of output modalities.
  • output modality is used to refer to various types of devices, systems, and services, several examples of which are provided below.
  • system 100 can comprise a plurality of source medical imaging modalities 10, such as Ultrasound, MRI, CT and PET equipment, a local PACS 20 (typically source image archive-servers), or any other device capable of sending medical data such as DICOM data, commonly medical images.
  • Modalities 10 and PACS 20 can be connected, e.g., with a Central Computer System (CCS) 30 via the Internet 60 through a router 50 usually provided with encryption and firewall protection.
  • CCS Central Computer System
  • Central Computer System (CCS) 30 can include a data conversion and delivery system (DCDS) 32 for processing the medical data.
  • the CCS can comprise one or more servers, and include one or more a processors or CPUs, memory associated with the processor(s), a data storage module, a display means, and an input/output interface means.
  • various other peripheral devices and modules can be connected to the CCS, such as other servers, other data storage modules, or intrusion detection systems.
  • the CCS can also be a cluster of interoperating servers, each taking care of a specific task within the system. Similarly, all the modules shown in figure 2, and described below can each be a separate server in such a cluster, so as to distribute the load and increase the capacity of the system.
  • DCDS 32 can be configured to convert medical images associated with the medical data into, e.g., consumer- friendly images, video, or both. DCDS 32 can then in turn send these converted images to a number of destinations, or output modalities 40 as directed by the user/operator of DCDS 32 or as dictated by information included in the medical data.
  • destinations 40 can be, for example, a web site such as a social networking site including, e.g., Twitter, Facebook, and Google Health; cellular phones; PDAs; Email accounts; or any computer system capable of accepting data via protocols such as, e.g., SOAP and REST.
  • DCDS 32 functions in such a way that it allows source modalities (10, 20) to be protected by the most rigorous of firewall settings 50, while still allowing transfers to take place over the internet 60.
  • the original source image data may optionally be sent to the destinations 40 without any processing or conversion.
  • the ultrasound images can be sent to DCDS 32 for conversion into a set of images that can be sent the parent's social networking web page, their mobile device, their friends and families devices or web pages, etc. More specifically, a nice sequence of the fetus waving its arm can be captured and stored during the ultrasound examination by the operator.
  • the ultrasound operator usually a nurse or technician, sends the stored, e.g., DICOM file to DCDS 32.
  • the nurse, technician or any trusted employee at the patient's facility (user) can use a remote graphical user interface (GUI) interfaced with DCDS 32 to bring up the desired sequence sent by the source modality 10.
  • GUI remote graphical user interface
  • the user can then enter the cellular phone numbers, web account information, email addresses, etc., as well as any personal message that the patient indicates, and then start the delivery process.
  • The, e.g., DICOM file, now converted into a cellular phone compatible video format, e.g., 3gpp, can then be sent as a multimedia message to the mobile phones, and files converted to other appropriate formats can also be sent to the given email and web accounts.
  • the nurse or technician at the patient's facility can enter the patient's cellular phone number in the patient information field on the ultrasound machine.
  • DCDS 32 can be configured to then locate that number embedded in the DICOM data file, and automatically forward the converted image or video file after processing to the desired locations as 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 example DCDS 32 in accordance with one embodiment. It will be understood that the diagram of figure 2 is for purposes of explanation and illustration and is not intended to restrict the embodiments described herein to any particular architecture or design. Nor is figure 2 intended to provide a detail view of all components of an example DCDS 32.
  • a request from a modality 10 can be handled by an input stage, consisting of a Receiver 203 and Storage & Parser 204.
  • the Receiver 203 can be configured to authenticate the connection from the source modality 10, and to handle the network transactions necessary to complete the request.
  • Storage & Parser 204 can be configured to parse the received data and to store any image data 205 and all metadata 206 in storage system 214.
  • the image data 205 can be stored as binary data
  • the metadata can be stored as structured data allowing typical structured access to the data, such as, searches and associations between different items.
  • Storage & Parser 204 can be configured in certain implementations or under certain conditions to strip all sensitive patient information from the incoming data file.
  • GUI Graphical User Interface
  • the system can be programmed to automatically determine which fields in the meta data are sensitive. This process is called anonymization, and it is performed in order to protect the patient's privacy. Anonymization is discussed in more detail below.
  • an event signal can be triggered indicating that the newly stored data has been added.
  • Event System module 209 receives an event signal from the parser 204, it can be configured to determine what action, if any, should be taken as a result. For example, if rules for automatic delivery have been set, and the appropriate metadata values are found in the newly received data stored in structured database 206, then Event System module 209 can be configured to signal the Output Module 213 to send the converted data as instructed by the automatic delivery rules. This process is also described in more detail below.
  • Output Module 213 can be configured to accept calls from other parts of
  • DCDS 32 containing general data, information to send, and number of delivery destinations, including email addresses.
  • the data can include a text message, a reference to a, e.g., DICOM image, two cellular phone numbers, and one email address.
  • the Output Module 213 can be configured to assemble the appropriate formatted output "packages", or messages, and send the resulting messages using a modular plug-in-based architecture.
  • a plug-in (not shown) for each corresponding type of destination can be included and used by Output Module 213.
  • Output Module 213 can assemble one MMS message packet containing a jpeg version of an image and message text, all combined and encoded according to the MMS specifications. This message can then be sent twice, first to each phone number destinations requested, and secondly, to each email address destinations specified.
  • Output Module 213 can request a converted image from Image Converter 21 1, identifying the original image and specifying the requested format and dimensions.
  • Image Converter 21 1 can be configured to then look for an existing image in the Converted Image Cache 212 that matches the request. If no match is found, it can generate an image from the original image data 205.
  • the Image Converter 211 can be configured to use the metadata 206 of the original image stored in database to determine if the requested format is appropriate. If not, it can 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 (effectively video) would be proper.
  • Image Converter 21 1 can be configured to respond to an event from Parser
  • a Web GUI 208 provides, e.g., medical staff with remote access to DCDS 32 via a secured web browser connection (https) 202.
  • Such a Web GUI 208 can provide an interface to perform administrative tasks such as setting up rules for Event System module 209, as well as an optimized interface for identifying images and sending output messages. The typical operations of these interfaces are described in detail below.
  • Web GUI 208 can operate on the structured metadata 206 to find and identify images. It can be configured to request conversions from Image Converter 211 to, e.g., display thumbnails and previews of images, and to provide service request forms where output messages can be specified and send on to Output Module 213 for delivery.
  • An adaptable Garbage Collector 207 can continually evaluate the state of all data and compare that to configurations made by an administrator of the system.
  • the configuration can set certain criteria that items need to meet in order to remain in the system or be deleted from the system.
  • One basic criterion can be the age of an item. For example, if an item has been stored over a week ago or certain number of days ago could be automatically deleted.
  • Other automatic deletion criteria can be the number of times an item has been previously sent, system state information stored, and the value of any metadata. This feature is in part useful for keeping the resource usage down, and also to aid patient confidentiality by removing patent data that the system is no longer needed to maintain.
  • the images are to be used for clinical or diagnostic purposes. In such instances, it is often required that the image that is ultimately displayed on the device used for viewing the images maintain a certain resolution or image quality.
  • one or more of Parser 204, Event System module 209, and Image Converter 21 1 can be configured, either alone or in combination, to recognize that the image is being viewed in a diagnostic or clinical application. Such recognition can be based on information included in the meta data, information stored in Image System 214, or information provided via GUI 208.
  • the address or device identified in the meta data for receiving the image can be recognizable as an address or device associated with a clinical or diagnostic application, the image or series identifier can also be associated with a clinical or diagnostic application, etc.
  • an operator can indicate through GUI 208 that images to be sent are intended for clinical or diagnostic purposes.
  • Image Converter 211 can be configured to determine, e.g., based on information stored in storage system 214, the required resolution or image quality. For example, resolution, image quality, or both for various types of images, clinical applications, etc., can be stored in storage system 214. Image converter can then determine the correct image resolution and quality and covert the image in accordance therewith.
  • DCDS 32 can be configured to determine whether the identified output device or address is capable of displaying the converted image with the requisite image resolution and quality before sending the image. If the device or address is not capable, then DCDS can generate an error message or other notification indicating such. The error message can be displayed through GUI 208, on the device, or both.
  • DCDS 32 can be configured to take an incoming medical image file and automatically convert it for distribution to and viewing by any of a plurality of output modalities.
  • Figure 3 is a flow chart illustrating one example embodiment for an automated message creation operation performed by DCDS 32 in accordance with one embodiment. In the example of figure 3, it is assumed that destination information, e.g., output modality information is included in a medical image file received by DCDS 32.
  • a user can access DCDS 32, e.g., through GUI 208 and specify which files should be sent to which output modalities; however, a powerful aspect of DCDS 32, as configured in accordance with the systems and methods described herein, is its ability to automatically determine the destinations and to convert and format the data appropriately as described below.
  • step 320 a file is received and the headers associated therewith are examined to determine various information.
  • the medical image file received by input 203 will often include metadata that provides information related to the medical data or images included therewith.
  • the medical image file will include a header that comprises a plurality of fields. These fields are generally the same for each input modality 10.
  • DCDS 32 can be configured to examine the header fields to determine various information as described in detail below and with respect to figure 4.
  • an output destination type, or modality can be determined.
  • the header can include information identifying recipients of the images included in the image file.
  • the header can include information identifying output modalities associated with various recipients or services, e.g., such as an online photo album page, site, or service; a social networking page or service, a mobile device, etc.
  • Basic types of destinations can include a mobile device, such as a cellphone; an email account; a Web- Application Specific Interface (API), e.g., associated with an online site or service, etc.
  • API Web- Application Specific Interface
  • DCDS 32 can be configured to examine the header file and determine associated output devices or services, i.e., modalities.
  • DCDS 32 can be configured to then retrieve specific characteristics of each destination type as indicated in step 324. These characteristics can include capabilities and physical characteristics of the destination device and 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 modality. For example, this information can be used for adaptations of the image data based on specifications for the type of message being sent, e.g., e-mail has limitations in specification and common practice that can be adapted for; and MMS has very different limitations that can be adapt for.
  • the capabilities and characteristics determined in step 324 can include frame size, i.e., pixel dimensions of an image or video, e.g., 640 by 480 and the like; data rate or data size, e.g., MMS messages can commonly not exceed 300KB total size, e-mail attachments exceeding 10MB are often not accepted, etc.; supported encoding format, e.g. mpeg 4, jpeg, etc.; and message layout rules, i.e., how a message can be composed for the destination, e.g. MMS is made of "pages", each able to display a single image or video and a single text along with playing audio while e-mail is capable of HTML layouts and can hold attachments of any file type, etc.
  • frame size i.e., pixel dimensions of an image or video, e.g., 640 by 480 and the like
  • data rate or data size e.g., MMS messages can commonly not exceed 300KB total size, e-mail attachments exceeding 10
  • a basic compatibility check can be performed to determine whether the data included in the image file can be delivered in a format compatible with the output modality. For example, if the image data includes video data, then a determination can be made as to whether the output modality is capable of receiving and displaying video data.
  • the most suitable delivery format is then chosen in step 328 to ensure the output message that is ultimately generated includes the best quality data that the output modality can handle. This can be important for example in clinical settings or settings where the data is being used for examination or diagnostic purposes. Resolution information suitable for diagnostic purposes and the ability of DCDS 32 to provide such resolution is discussed in detail below.
  • step 330 the data can be extracted and converted as required.
  • MMS messages allow only a very limited total message size. Therefore images or video in particular often need to be adapted and optimized to let the final message meet the format and specification requirements of a particular output modality.
  • e-mail messages often have no strict limit on size and therefore can accept larger files, e.g., higher resolution images or video. But even e-mail accounts can include rules limiting extremely large files and therefore even e-mail messages can require optimization of, e.g., video files to ensure sufficient quality but also to comply with size limitations.
  • step 330 If the incoming file is already encoded in a format compatible with the output modality, then often no conversion will occur in step 330 in order to preserve the highest possible image quality.
  • the data can be anonymized as required by any applicable anonymization rules.
  • the data can be extracted and copied into a generic format so that certain data can be removed, redacted, etc.
  • the data can then be converted to the final output format.
  • Steps 330 and 332 can be performed in parallel or reverse order as required by a particular implementation.
  • the converted data can then be assembled into an output message in accordance with the applicable formats and specifications determined in the preceding steps.
  • other data can be included with the message.
  • This information can be manually entered, e.g., via GUI 208 or it can be extracted from the metadata accompanying the received file.
  • the data can be data retrieved from configuration settings based on the set of characteristics described above.
  • the data components that are to comprise an output message are assembled according to template rules for the type of message being created.
  • the various template rules can be stored in Storage System 214 and accessed by Output Module 213 in order to assemble the output message.
  • MMS messages are based on a page metaphor where each page can contain an image or video, a text element, and an audio element. Thus, sending two or more images, or including text, audio, or both with the image(s) will then require the message to be assembled into several pages.
  • e-mail messages can include any number of images, attachments, etc., depending on, e.g., the message size restrictions.
  • Output Module 213 can then be configured to elect the appropriate output gateway for transmission of the assembled output message in step 336.
  • Output Module 213 can be configured to send an e-mail message to a SMTP server (not shown) and to send an MMS message to a MMS gateway (not shown).
  • Figure 4 is a flow chart illustrating example type of information and data that can be examined in step 320.
  • the metadata or more specifically the header can be examined to identify the input modality in step 420.
  • the compatibility of the modality determined in step 420 with the system can be determined. If compatible, then in step 424, specific characteristics of the data included in the image file can be determined. For example, whether or not the file actually includes any image or video data or whether the data is simply report or measurement can be determined in step 424.
  • an incoming file does include, e.g., report or measurement data, then such information can be extracted and stored in, e.g., a generic structured format in step 426.
  • any image data can then be extracted and stored as well 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 chart illustrating an example process for the use of information embedded inside of the metadata including with incoming files by DCDS 32 in accordance with one embodiment.
  • the metadata e.g., header fields can be used to ensure safe and secure delivery of the image data included therewith.
  • a DICOM image file can include a plurality of header fields that are key -value pairs in a number of datatypes, such as strings, numbers, dates, special measurement types, etc. Fields can be embedded in the and can be hard linked to the file for which the provide metadata. In this way, there is no way to mix-up header files and the associated data, since they are not separated.
  • DCDS 32 can be configured to automatically track and record header fields for each network device sending images. In this way, DCDS 32 can identify the specific device associated with an incoming file. DCDS 32 can do this by recording which header fields are present for a particular modality 10 in step 522 and to then record the data included in device-dependent header fields for the associated modality in step 524. A particular device should always report the same values for, e.g., manufacturer, model name, model number, etc. Thus, DCDS 32 can use this information to identify a particular device.
  • DCDS can detect any changes in the data and then take appropriate action. For example, changes to header field data that should not be changed, e.g., manufacturer information, can be an indication that the file has been tampered with or someone is trying to hack into the system. In response to detection of such changes, the system can log the event, notify an operator, place the incoming data in an approval queue, quarantine the data or any further data from the associated device, reject the data, rejecting the all future data from the device, to name just a few possible actions.
  • changes to header field data that should not be changed e.g., manufacturer information
  • the system can log the event, notify an operator, place the incoming data in an approval queue, quarantine the data or any further data from the associated device, reject the data, rejecting the all future data from the device, to name just a few possible actions.
  • DCDS can be configured to search the header fields for data that can identify an intended recipient as noted above.
  • Identification can be in the form of an actual, e.g., e-mail address, mobile station International Subscriber Directory Number (ISDN), web site address, etc. In fact, such direct identification can be preferable as it takes advantage of the existence of the header fields.
  • Identification can also be indirect such as an ID that can be used to look up a direct address, e.g., in a registry stored in storage system 214.
  • each field can include more than one piece of data and data of different types. Accordingly, any identifying or address fields can include telephone numbers as well as e-mail address, etc. Further, identifying data can be included in more than one field.
  • the DCDS 32 can be configured to then determine an action to take in step
  • Such actions can include sending an appropriate message to any addresses found, formatting messages appropriately as described above, notifying an operator, adding a message to a queue, e.g., for manual approval, locating and adding other data or information to an outgoing message, to name just a few.
  • FIG 6 is a flow chart that illustrates the operation of DCDS 32 in more detail.
  • a Conversion Request 301 can be received containing, at a minimum, an internal identifier for the image, and a destination format.
  • the conversion request can be the result of information and data included in the metadata associated with an incoming file.
  • the request can also result from input received through GUI 208.
  • the request could contain new image dimensions to be scaled as output image to be sent.
  • the Image Converter 21 1 can be configured to then determine the existence of the requested image 304 by trying to locate the metadata associated with it in metadata database 303.
  • the converter can optionally return a placeholder image (305, 308) or abort the conversion attempt 306.
  • a placeholder is typically an image, video or similar media communicating that the requested image is unavailable.
  • the converter also can also be configured to determine if the requested output format is feasible or not.
  • the converter can be configured to load the, e.g., DICOM image 307 from image storage 302 into a raw binary format.
  • the Converter 211 can be configured to then determine if 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 for the Web GUI 208 could be rendered in any dimensions that are suitable to the layout of the html document, while video for MMS messages have very specific dimensions to comply with the specification.
  • the image data can be converted 311 to the requested destination format.
  • the results can be saved to an image cache 312 and metadata records can be updated 313 to indicate the existence of the converted image.
  • the converted images can be returned as a response to the request.
  • Converter 211 can then return either the converted binary data directly or return a reference to its location in the image cache 313.
  • DCDS 32 can also be operated and interfaced with through the Web
  • GUI 208 can enable both remote and local access the DCDS 32 and allows for images to be located within storage system 208. The images may need to be located or analysis or diagnosis or for sending to a specified destination or address.
  • the first way involves finding files without any identifying information. This is explained in detail with respect to figure 7; however, it should first be noted that each device sending files to DCDS 32 can be identified by recording and mapping header fields of incoming file transfers. The devices can also be at least partially identified based on their network address, AE titles used for the transfer, or both. Each device can then be given a name that is unique and preferable meaningful to operators. Files as well as their series, study, or both, can then be identified by the device they originated from, the time and date of the image capture, and header fields identifying the operator of the device used to capture the images.
  • DCDS 32 can handle anonymized data and no patient information can be gathered by the misuse of the system. Further, the most used images can be stored as the most recent images in the system. Thus, finding images can be made very efficient in this manner. Once the file, series, study, etc., had been found, GUI 208 can offer the operator direct access to features for viewing the images, sending the images, etc.
  • figure 7 is a flow chart illustrating a typical use of the Web
  • GUI 208 and its streamlined interface for finding an image by the originating modality without any identifiable patient information (401-404) in accordance with one embodiment.
  • the interface displays a service request form where the user enters output destination information and other message details. If the data validates (407,) the required conversions are requested (408) from the Image Converter (211.) For all successful requests, the data is assembled by the appropriate output plug- ins (409-411,) and the results are sent (412-414) to the appropriate destinations. Status information for each individual output is gathered (415,) and returned (416 or 417) to the form view (405) for display. At this point, the user can choose to repeat the send process or return to finding another image.
  • the Web GUI 208 allows for sending groups of images that belong to the same, e.g., DICOM Series. The operating steps are similar to those illustrated by figures 7 and 8.
  • the Web GUI 208 also present interfaces for configuring the Event System 209, organizing and storing output destination addresses and other administrative tasks necessary. It is important to note that, as a security measure, the Web GUI 208 does not handle any authorization of source modalities allowed to store images or access privileges to those images. These important settings are only available through a separate method of access either locally or remotely.
  • SSH Secure Shell
  • Both protocols are examples of secured remote access to the operating system.
  • the second way to access files is to use identifying information.
  • operators can search for files using patient information such as name, birth date, patient ID, etc.
  • patient information such as name, birth date, patient ID, etc.
  • the operator can, for example, input a search term and if there is a match, the system can present all available studies. If multiple patients are returned, then they can be presented for selection. Once the patient is selected, and the associated file, series, study, etc., had been found, GUI 208 can offer the operator direct access to features for viewing the images, sending the images, etc.
  • Figure 8 is a flow chart illustrating a variation of the typical use of the Web
  • GUI 208 and its streamlined interface for finding an image by using a piece of identifiable patient data (501-504,) such as, patient name, and birth-date, etc.
  • a piece of identifiable patient data such as, patient name, and birth-date, etc.
  • any unrelated identifying password or PIN code can be utilized to avoid using real patient information to ensure patient privacy.
  • CCS 30 can be interfaced with a server 902 that can be configured to host and support various value added services for, e.g., patients and family in relation to the images being captured by modalities 10 as illustrated in figure 9.
  • a server 902 can be configured to provide a variety of services for the parents, family, friends, etc.
  • the DCDS 32 can be configured to convert the images to a proper format or formats supported by server 902 and the related services.
  • the images can be sent to server 902 and stored in storage system 904.
  • server 902 can actually comprise a plurality of servers, computers, routers, etc., as well as the appropriate software and firmware required to carry out the functions described herein.
  • storage system 904 can comprise one or more databases, one or more storage servers, as well as other physical storage mediums as required.
  • Server 902 can then be configured for example, to host a web site on which users can create accounts. The users can then access the images on the site and purchase images, pregnancy calendars, customized mugs, key chains, T-shirts, canvases, etc. Further, the site can be configure to present pictures, illustrations, information on fetus and child development, health and nutrition tips, etc. Such a site can enable such services as a registry, e.g., for a baby shower; automatic updates to friends and family; digital and viral gifts, such as baby images with digital lullabies; invites and thank you cards; etc.
  • a registry e.g., for a baby shower; automatic updates to friends and family; digital and viral gifts, such as baby images with digital lullabies; invites and thank you cards; etc.
  • a user can be charged a fee for setting up an account, e.g., a subscription fee, either one time or periodic, the user and family and friends can also be charged for the various products and services, or both.
  • a fee for setting up an account e.g., a subscription fee, either one time or periodic
  • the user and family and friends can also be charged for the various products and services, or both.
  • kiosks 908 can be set up, e.g., in maternity wards that can provide at least some of the same services. Kiosk 908 can either be stand alone, i.e., interfaced directly with CCS 30, or can be interfaced with server 902 as illustrated. Thus, family and friends can order pictures and other goods, e.g., right in the waiting room.
  • the user can continue to use the account even after the birth of the child.
  • the site can track the child throughout its child hood, or at least through the first few months or years.
  • the site can be configured to send birthday reminders and announcements to friends and family or to inform of other special events, developmental milestones, etc.
  • the site can be configured to continue to present developmental information as well as health and nutrition tips for both mother and child.
  • server 902 can be configured to continue to send birthday reminders to friends and family.
  • the site hosted by server 902 can be affiliated with or host a "gift store" offering various products and services.
  • the site can offer discounts, coupons, etc., to various other business and stores. Since server 902 will have pertinent demographic information related to the child, e.g., residence information, sex, age, race, and possibly even parents age, profession, and other affiliations, the site can send reminders, gift recommendations, discount offers, etc., that are appropriate for the child and the family, popular with similar demographics, etc.
  • the user can access the site and customize or provide profile information, contacts, preferences, etc.
  • Algorithms running on server 902 can be configured to then use the information available to make product recommendations, etc.
  • the algorithms can be configured to use information for populations that share similar demographics, income levels, preferences, etc., to make recommendations.
  • a user can purchase items through the site, i.e., through server 902.
  • server 902 can be configured to accept credit card payment, a PayPal account, or for mobile billing.
  • server 902 can be configured to process the transaction and either deduct an appropriate fee or charge a related business, affiliate, partner, etc., a transaction fee.
  • purchase information can also be fed into the algorithms and used to make future recommendations. In fact, the purchases of an entire related population can be used to make more targeted and appropriate recommendations.
  • the algorithms can be constantly updated and honed in order to make, e.g., gift recommendations. Recommendations that can be automatically sent out to friends and family over the years. As the database grows over time and with more and more users, the algorithms can be honed to provide ever more relevant and targeted recommendations .
  • the database will necessarily include vast information about the relationships and connections between a large population. This includes direct links such as friends and family, but also more indirect links such as preferences, similar buying habits, etc. This type of interconnection information can be very valuable for targeted advertising and product recommendations as well as for simply tracking and mapping the interconnectedness of a large population.
  • a site can be built around other conditions or events, such as a cancer support site, physical therapy support site, etc. It should also be pointed out that the merging of interconnectedness data for these various other conditions and events can extend the power of the information and lead to even better algorithms for targeting information and products and services.
  • users can access the site via, e.g., the Internet using computers 914 and mobile devices 912. Further, the site can be interfaced with other social networking sites such as Twitter, Facebook, etc. In certain embodiments, the site can actually be converted to an application, or widget that can be exported to other sites.
  • a grandma can place the application on her Facebook page and receive updates and notices more easily without needing to log onto server 902. This can increase the interaction with the site, which can increase, for example, the amount of information and data available to server 902 as input to the algorithms described above.
  • a peripheral device may be attached with a medical imaging device for the encryption and conversion of a medical image into a secure and standardized image file format as well as the communication of the encrypted and/or converted image to a secure server on a remote network.
  • the peripheral device 102 may be a dongle or other type of stand alone device which can be physically attached with a medical imaging device 101, and will have its own processor and memory for executing a variety of functions relating to the conversion, encryption and transmission of medical image files from the medical imaging device to a remote server 103 on another network.
  • the peripheral device 102 may be attached with a communication port on the medical imaging device, such as a network port, serial port or other communication interface.
  • the peripheral device may act as a filter to monitor all medical image files generated on the medical imaging device and encrypt and convert selected medical image files for transmission to a remotely connected device on another network, such as a server or a mobile device.
  • the dongle may be configured with a separate network connection to a local area network (LAN) or wide area network (WAN), or it may be configured to use the network that is already connected with 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 may have network hardware to allow the dongle to communicate over a WiFi or cellular network or even accept a direct Ethernet cable connection to a local network which the medical imaging device is not connected with.
  • LAN local area network
  • WAN wide area network
  • the encryption dongle 102 may be connected with the imaging device 101 with an insecure connection, in which case the encryption dongle 102 will function to take medical images stored on the medical imaging device 101 and encrypt the images for transmission across a secure network connection to a remote device, such as a remote secure server or a mobile device that is the ultimate destination of the medical image.
  • a remote device such as a remote secure server or a mobile device that is the ultimate destination of the medical image.
  • One embodiment provides a method and technical system for encrypting and routing DICOM network connections from devices without any such encryption capabilities built-in.
  • One embodiment of the invention can listen on known ports for unprotected communication and automatically encrypt and route the connection in its encrypted form over the port's encrypted counterpart.
  • E.g. ordinary DICOM connections on TCP port 104 or 11112 can be encrypted in SSL/ TLS and routed as DICOM/TLS on TCP port 2762. This would effectively make the connection appear to the remote server as a secure TLS connection and to the client device as an unprotected connection.
  • HTTP protocol on TCP port 80 can be encrypted in SSL/TLS and routed as HTTPS on TCP port 443. This would effectively make the connection appear to the HTTP server as a secure HTTPS connection and to the HTTP client as an unprotected connection. It should be noted here that encrypting HTTP traffic is useful only with older clients and servers which are capable of secure connections. It is, however, a well-known pair of network ports that serve to illustrate a general embodiment of the invention.
  • Embodiments of the invention include a wireless network connection such as WiFi or cellular modem capabilities to not only encrypt but also to offer access to the Internet without existing network infrastructure near the imaging device. This is highly useful for portable devices that can be used on-the-go running on battery power.
  • a wireless network connection such as WiFi or cellular modem capabilities to not only encrypt but also to offer access to the Internet without existing network infrastructure near the imaging device. This is highly useful for portable devices that can be used on-the-go running on battery power.
  • Embodiments of the invention can be pre-configured to only forward protected traffic to a single remote end-point.
  • Embodiments of the invention may use any and all relevant encryption methods to secure the connection. Examples or these include the aforementioned SSL/TLS standard as well as other common encryption standards. The point being that the invention will mimic the native encryption standard for each type of connection an embodiment supports. Encryption may be encoded and decoded either by dedicated chips (electronic hardware components), software or a combination of software with hardware acceleration.
  • a network device for connection with a local network including at least one medical imaging device provides for the encryption and conversion of a medical image from the at least one medical imaging device into a secure and standardized image file format, as well as the communication of the encrypted and/or converted image to a secure server on a remote network.
  • the network device may act as a router or a gateway on the local network to monitor traffic of medical images from the medical imaging devices to destination devices outside of the local network and ensure that the medical data files are encrypted and converted into an appropriate format for delivery to a device on the remote network.
  • the network device Upon detection, the network device will encrypt and convert the selected medical image files for transmission to a remotely connected device on the remote network, such as a server or a mobile device.
  • FIG. 1 1 One embodiment of the network device is illustrated in FIG. 1 1, where the network device 104 acts as an encryption router to receive medical image files from one or more medical imaging devices 101 over a local network which may not be secure.
  • the encryption router 104 will then be configured for encryption and conversion of a medical image into a secure and standardized image file format.
  • the encryption router 104 will then be configured for communication of the encrypted and/or converted image over a secure connection to a secure server 103 on a remote network, such as the Internet.
  • 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 an encrypted DICOM image over WiFi, cellular (3G) or cable connection to a remote network.
  • the network device 104 acts as the network gate to ensure that all medical images being transmitted out of the local network are converted and encrypted.
  • FIG. 12 illustrates a flowchart of the 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) 307.
  • the network device 104 may include one or more of the components illustrated herein, including an encryption listening port 302 which monitors network traffic in the LAN for the transmission of medical image files which are not encrypted or converted into a proper format.
  • An encryption database 305 may store encryption settings that provide instructions on the type of encryption that a particular medical image file should be encrypted with, perhaps depending on the type of network or the destination device on the remote WAN network 307.
  • the medical image file is processed 303 to encrypt the file, after which a port is mapped 304 for transmission of the file.
  • the encrypted file is then transmitted through a firewall or other local router 306 to a remote WAN network 307.
  • a Vscan imaging device captures a medical image that is non- DICOM and not encrypted, but which is selected for transmission from the Vscan to a remote secure server on the remote network.
  • the medical image is then sent to the network device 104, which converts the image to a DICOM image and encrypts the image before sending it to the remote secure server.
  • the network device may be useful in a local network which is otherwise insecure or unreliable, as it creates a secure connection with the medical imaging devices and with a remotely connected server or device on another network. Additionally, the network device may be useful in highly secure networks with strict firewalls that would otherwise prevent connections to a remote secure server.
  • the network device may be configured as a network satellite which is attached with the local network but which acts as a remote secure server to that the one or more medical imaging devices sends the images to the network satellite under the impression that the network satellite is the final destination for the medical image file.
  • the network satellite will then take the medical image and encrypt or convert it (or both) and then send the encrypted and converted image to the actual remote secure server.
  • the medical imaging device does not need to be instructed to send the medical image file to a new location on the network such as the network device, as it instead transmits the file to what it believes is the final destination of the medical file - the remote secure server on a remote network.
  • One embodiment provides a method and technical system for encrypting and routing DICOM network connections from devices without any such encryption capabilities built-in.
  • One embodiment of the invention can listen on known ports for unprotected communication and automatically encrypt and route the connection in its encrypted form over the port's encrypted counterpart.
  • E.g. ordinary DICOM connections on TCP port 104 or 11112 can be encrypted in SSL/ TLS and routed as DICOM/TLS on TCP port 2762. This would effectively make the connection appear to the remote server as a secure TLS connection and to the client device as an unprotected connection.
  • By connecting the embodiment of the invention to the network port of an imaging device or as a network router on the same protected local network as the device a high level of security is maintained.
  • HTTP protocol on TCP port 80 can be encrypted in SSL/TLS and routed as HTTPS on TCP port 443. This would effectively make the connection appear to the HTTP server as a secure HTTPS connection and to the HTTP client as an unprotected connection. It should be noted here that encrypting HTTP traffic is useful only with older clients and servers which are capable of secure connections. It is, however, a well-known pair of network ports that serve to illustrate a general embodiment of the invention.
  • Embodiments of the invention include a wireless network connection such as WiFi or cellular modem capabilities to not only encrypt but also to offer access to the Internet without existing network infrastructure near the imaging device. This is highly useful for portable devices that can be used on-the-go running on battery power.
  • a wireless network connection such as WiFi or cellular modem capabilities to not only encrypt but also to offer access to the Internet without existing network infrastructure near the imaging device. This is highly useful for portable devices that can be used on-the-go running on battery power.
  • Embodiments of the invention can be pre-configured to only forward protected traffic to a single remote end-point.
  • Embodiments of the invention may use any and all relevant encryption methods to secure the connection. Examples or these include the aforementioned SSL/TLS standard as well as other common encryption standards. The point being that the invention will mimic the native encryption standard for each type of connection an embodiment supports. Encryption may be encoded and decoded either by dedicated chips (electronic hardware components), software or a combination of software with hardware acceleration.
  • An encryption and conversion unit may be incorporated within the hardware and software of a medical imaging device or another network device in order to provide the capability for encrypting a medical image for transmission to a remote network and for converting the medical image to a format that is compatible with a destination device or network.
  • the encryption and conversion unit may also be configured to package and transmit a converted and encrypted image to an appropriate destination, such as a secure server, on a remote network.
  • the encryption and conversion unit may act as a router or a gateway on the local network to monitor traffic of medical images from the medical imaging devices to destination devices outside of the local network and ensure that the medical data files are encrypted and converted into an appropriate format for delivery to a device on the remote network. Upon detection, the encryption and conversion unit will encrypt and convert the selected medical image files for transmission to a remotely connected device on the remote network, such as a server or a mobile device.
  • a remotely connected device on the remote network such as a server or a mobile device.
  • FIG. 1 One embodiment of the encryption and conversion unit is illustrated in FIG.
  • the encryption and conversion unit 104 acts as an encryption router to receive medical image files from one or more medical imaging devices 101 over a local network which may not be secure.
  • the encryption and conversion unit 104 may be incorporated within each medical imaging device 101 as software, hardware or a combination of software and hardware.
  • the encryption and conversion unit 104 may be a part of a router, gateway, firewall or other network device which monitors and regulates traffic over a network. Regardless of the type of device in which it is placed, the encryption and conversion unit 104 will then be configured for encryption and conversion of a medical image into a secure and standardized image file format.
  • the encryption and conversion unit 104 will then be configured for communication of the encrypted and/or converted image over a secure connection to a secure server 103 on a remote network, such as the Internet.
  • FIG. 12 illustrates a flowchart of the 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) 307.
  • the encryption and conversion unit 104 may include one or more of the components illustrated herein, either as software, hardware or a combination of both.
  • the encryption and conversion unit 104 includes an encryption listening port 302 which monitors network traffic in the LAN for the transmission of medical image files which are not encrypted or converted into a proper format.
  • An encryption database 305 may store encryption settings that provide instructions on the type of encryption that a particular medical image file should be encrypted with, perhaps depending on the type of network or the destination device on the remote WAN network 307.
  • the medical image file is processed 303 to encrypt the file, after which a port is mapped 304 for transmission of the file.
  • the encrypted file is then transmitted through a firewall or other local router 306 to a remote WAN network 307.
  • a Vscan imaging device captures a medical image that is non- DICOM and not encrypted, but which is selected for transmission from the Vscan to a remote secure server on the remote network.
  • the encryption and conversion unit 104 is embedded as software running on the Vscan device, and therefore converts the image to a DICOM image and encrypts the image before sending it out of the Vscan device to the remote secure server.
  • the encryption and conversion unit may be useful in a local network which is otherwise insecure or unreliable, as it creates a secure connection with the medical imaging devices and with a remotely connected server or device on another network. Additionally, the network device may be useful in highly secure networks with strict firewalls that would otherwise prevent connections to a remote secure server.
  • One embodiment provides a method and technical system for encrypting and routing DICOM network connections from devices without any such encryption capabilities built-in.
  • One embodiment of the invention can listen on known ports for unprotected communication and automatically encrypt and route the connection in its encrypted form over the port's encrypted counterpart.
  • E.g. ordinary DICOM connections on TCP port 104 or 11112 can be encrypted in SSL/ TLS and routed as DICOM/TLS on TCP port 2762. This would effectively make the connection appear to the remote server as a secure TLS connection and to the client device as an unprotected connection.
  • HTTP protocol on TCP port 80 can be encrypted in SSL/TLS and routed as HTTPS on TCP port 443. This would effectively make the connection appear to the HTTP server as a secure HTTPS connection and to the HTTP client as an unprotected connection. It should be noted here that encrypting HTTP traffic is useful only with older clients and servers which are capable of secure connections. It is, however, a well-known pair of network ports that serve to illustrate a general embodiment of the invention.
  • Embodiments of the invention include a wireless network connection such as WiFi or cellular modem capabilities to not only encrypt but also to offer access to the Internet without existing network infrastructure near the imaging device. This is highly useful for portable devices that can be used on-the-go running on battery power.
  • a wireless network connection such as WiFi or cellular modem capabilities to not only encrypt but also to offer access to the Internet without existing network infrastructure near the imaging device. This is highly useful for portable devices that can be used on-the-go running on battery power.
  • Embodiments of the invention can be pre-configured to only forward protected traffic to a single remote end-point.
  • Embodiments of the invention may use any and all relevant encryption methods to secure the connection. Examples or these include the aforementioned SSL/TLS standard as well as other common encryption standards. The point being that the invention will mimic the native encryption standard for each type of connection an embodiment supports. Encryption may be encoded and decoded either by dedicated chips (electronic hardware components), software or a combination of software with hardware acceleration.
  • the encryption and conversion functionality described above can be implemented on a mobile device such as a smartphone, tablet or other mobile device.
  • a mobile device such as a smartphone, tablet or other mobile device.
  • the encryption and conversion functionality can be integrated with the mobile device 107 by downloading an application 1 11 to device 107.
  • the application 11 1 will then include, or will allow the user to download the software 109 need to perform the required functions.
  • the software 109 can thus be compiled for the processor architecture of the device 107.
  • Software 109 can then act as a router or tcp proxy through which the data sent from devices 101, e.g., a portable ultrasound machine travels. From the ultrasound machine's point of view it will seem as if it is communicating directly with a dicom server on the device 107, but it will actually be communicating directly with hosted server 103 through the encrypted tunnel or secure connection provided by device 107.
  • the port used by device 107 will often be 104 but there is also the alternate port 11 1 12, which is used whenever there is a need to stay above port 1024, which is rarely the case.
  • the software can require payment for either one time uses or a subscription.
  • the system can be configured such that certificates a can be provided, e.g., by server 103 to software 1 11.
  • the certificates would be set to expire, thus application 109 can enable a process where the customer pays for a reissuing, e.g., extending the period during which the certificate is valid. This could be simply called "the subscription".
  • the auto expiration may be quite useful in this scenario.
  • application 109 can include an ability to fetch the new certificate and installing it, e.g., automatically.
  • Application 109 can include payment capability that can allow the user to pay, using a credit card, mobile wallet, or other account, for a subscription or one time use, e.g., an extended or new period during which the software would have valid certificates.
  • a more advanced user interface can be included in application 109 that allows the user to actually interact, monitor, troubleshoot, or all of the above, the functionality of software 1 11. This can include the ability to verify connectivity, the existence of the secure connection, upload and download speeds, etc.
  • mobile device 107 and the imaging devices 101 can communicate via wireless communication links, such as NFC, BlueToothTM , or WiFi.
  • wireless communication links such as NFC, BlueToothTM , or WiFi.
  • a communications dongle not shown, can be interfaced with the devices 101 to enable such wireless communication, or such capability can be included in the device 101.
  • the mobile device 107 can in turn communicate with, e.g., server 103 over, e.g., 3G/4G WAN systems. In other embodiments, however, device 107 is also able to use, e.g., a WiFi connection to communicate with, e.g., server 103..
  • a WiFi connection to communicate with, e.g., server 103.
  • devices 101 are using Wi-Fi
  • device 107 and device 107 is using a wireless Wan to communicate with server 103
  • tehn device 107 can act as a Wi-Fi base station and router to which the, e.g., ultrasound machine 101 connects.
  • the IP address to which the ultrasound machine connects is that of the device 107, which is the same as whatever router IP address the ultrasound machine gets when it configures itself via DHCP.
  • Systems and methods for integrating a variety of communication protocols and file types relating to medical imaging are provided.
  • the system integrates a current interface with third party software by adding software and intelligence to the current interface to provide for communication with third party image management software.
  • a medical imaging user interface such as a GE Viewpoint interface generates a plurality of medical images in a portable document format (PDF).
  • PDF portable document format
  • the systems and methods described herein will then convert the PDF documents into DICOM formatted image documents, which may then be sent to a specific destination and then converted back into a PDF for viewing on an appropriate electronic device, such as a personal computer, portable electronic device, etc.
  • an HL7 protocol device is used for medical software communication, and it includes a packet on the destination of a particular document. For example, an image created by an HL7 device needs to be sent to a doctor or patient.
  • the integration software obtains information on the image, combines it with the command information on the destination for the image, and then adds it to a DICOM message.
  • the integration software works by obtaining information needed from the third party software system and determining information needed to convert, encrypt and send the images to the appropriate destination.
  • the systems and methods described herein provide for live, or real-time, remote diagnosis of a medical problem of a patient using one or more medical images of the patient taken with a medical imaging device, such as an MRI.
  • the system may be embodied as a network with a plurality of computing and display devices which displays a graphical user interface (GUI) to each user so the users can all view the same medical images in realtime.
  • GUI graphical user interface
  • the users are also provided with options to annotate the images in real-time, chat about the images through an instant messaging program and even talk using a voice-over-internet- protocol (VOIP) or a traditional landline conferencing system.
  • VOIP voice-over-internet- protocol
  • the system provides a plurality of menus for a user to organize images, select diagnoses and other actions, and otherwise collaborate with a plurality of users in real-time to make a medical diagnosis based on one or more medical images.
  • FIG. 16 illustrates an overall workflow for the real-time remote interaction, where a user is first presented with a dashboard, or home screen, showing various options for collaborating to make a diagnosis.
  • the dashboard is further illustrated in FIG. 18.
  • Medical images from a Vscan device may be shown to the user, and an Exam Screen process may then be undertaken.
  • the images may be sent to a patient, an examination may be sent to the patient, and the resulting information may be sent for diagnosis.
  • a live, or real-time, diagnosis may then be made.
  • the flowchart illustrates that these steps may be skipped in order to make an emergency diagnosis without collaborating with remote users.
  • FIG. 17 illustrates an overall GUI which the user is presented with when 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.
  • FIG. 18 illustrates a "dashboard" GUI, which will list the medical imaging devices that are connected to the overall network or with the user's actual computing device (such as the medical imaging devices on the user's local network at a hospital or medical facility).
  • the dashboard will also list the images that have been captured by those devices, and may arrange them in order of capture, by patient, by doctor, etc. If new images arrive, they may be moved to the top of the list and highlighted so the user can easily find them. In one embodiment, when a new image or images is captured by a particular device, an alert will go out to the appropriate physician or health care provider handling that patient's case - such as an SMS or e-mail message.
  • the dashboard may also provide a search feature where the user can search through the images and a database of information related to the images and the patients.
  • FIG. 19 shows further detail of the main menu GUI, which provides: options to select DICOM images (where the main image workflows are found); and Inbox where the user will receive messages from the system or other users; a Recipients icon of patients or other users and contacts that can be easily found and contacted for sending images and messages; a Settings icon to handle setup of imaging devices, anonymization or automation of patient messages and labels to categorize studies; a Statistics icon to show traffic through the overall application over time; an Administration icon to show where administrators manage user accounts and setup branding of patient images; an Account icon where non- administrators can review their profiles and other account details; and a Sign Out icon that allows a user to sign out of the system.
  • the icons and options listed here are may be altered and are not limited to those described.
  • FIG. 20 illustrates one embodiment of an image workflow, where an image or a study of images can be selected from a list for further review.
  • the study information may include the number of files and labels assigned to each study, as well as the number of comments made on particular studies and images by other users. Different icons for still images, videos, comments, etc. may be provided.
  • the labels may pertain to suggested diagnoses or to a particular type of image or images contained within the study.
  • FIG. 21 illustrates a series of images as thumbnails that can be quickly reviewed before selecting one or more of them for further review.
  • a list of actions is provided at the top of the GUI, and other icons on the thumbnails provide indications as to whether the thumbnail represents a video and whether it is of a particular image format (such as DICOM). The user may click or select one of the thumbnails to open the full image or video.
  • FIG. 22 is an illustration of a real-time remote interactive collaboration GUI, where a medical image is displayed along with annotations that are made on the image by one or more users.
  • a chat screen is shown where the users can type instant messages to each other in the process of discussing the diagnosis of the patient, and a list of thumbnails of other images in the study may be provided at the top. The thumbnails may be updated as new images arrive.
  • This "Live Diagnosis Screen” is a real-time collaboration tool that updates all information in real-time and synchronizes edits between users, including the annotations, chats, actions, selected images, pins and other changes.
  • the live diagnosis screen may be particularly advantageous for an emergency room situation where a diagnosis is needed immediately.
  • the users have the option of inviting additional participants and taking one or more other actions related to the case.
  • FIG. 23 illustrates one embodiment of the Actions that may be selected in the chat screen, and may be a way to provide unambiguous instructions to another user - such as a doctor or nurse who is providing care to the patient.
  • the Actions tab may also provide tracking of the selected actions and who executed and suggested the actions so that the treatment of the patient can be properly documented.
  • a user can invite more users to participate in a live diagnosis process.
  • the invited users may receive a text message, email or phone call asking them to join in the live chat session.
  • the user interface may be adopted for any type of computing device, including mobile phones and tablets, to allow other users to participate from any location and with any type of portable electronic device.
  • FIG. 24 illustrates a GUI where a diagnosis can be requested for a particular patient based on a set of images.
  • the user can select different options for concerns and possible diagnoses to be investigated.
  • one or more users may be informed via email, text or phone, and an inbox screen may be provided to show when replies arrive.
  • the GUI for making a diagnosis is provided, where several images and a plurality of menus are provided to select appropriate diagnoses.
  • the images may be downloaded to a computer desktop for more detailed viewing with other software tools. Options for potential diagnoses can be highlighted or selected. Once a final decision is reached, the diagnosis is sent and recorded in the record for future review and study.
  • a DNS and special ports are required.
  • standard ports can be used in order to eliminate the need for a DNS.
  • certain communications routines are applications can be loaded onto the imaging device 101 or a computing system interfaced with the device 101. These communications routines can communicate with the, e.g., DICOM imaging applications on the device to take the DICOM image, encrypt the image, provide labeling and account information, and then communicate this information to a server or servers.
  • the label and account information can be used as inputs into the calculation of a private preshared keys, which can be used for encryption as described in more detail below. This information can also be used to determine if the account is suspended to prevent any transmission when an account is suspended.
  • Figure 29 is a diagram illustrating an example system 2900 configured with communication routines, processes, etc. (routines 2906), which perform such message creation functions in accordance with one embodiment.
  • the routines 2906 can be included in a device, such as a terminal 2904 coupled with device 101, or within device 101 itself.
  • Terminal 2904 can be a computing device, including a portable computing device such as a laptop, tablet or smartphone.
  • the routines 2906 can be configured to take images from device 101, create messages that include the image data, labeling, account information, and other information that can provide information on how to handle the image data, encrypt the image data or the entire message, and communicate the message to one or more servers 2912 and storage locations 2910 via a network 2908.
  • Network 2908, storage locations 2910, and servers 2912 can be indicative of a basic cloud structure.
  • the labeling and account information can instruct, or at least provide the necessary information to allow, e.g., servers 2912 to handle the messages and the image data included therewith.
  • the labels and account information can instruct servers 2912 to store the image data and associate with the account of a particular clinician, group of clinicians, a hospital, etc., where the image data can later be accessed and viewed, e.g., with viewing applications such as those described above.
  • the labeling and account information can instruct the servers 2912 to forward the image to a clinician's or patients device or a website.
  • Routines 2906 can in certain embodiments also provide the functionality to allow the image data to be converted into a different format that can more easily be transmitted to and handled by servers 2912, or into a format associated with a destination. Moreover, routines 2906 can eliminate the need for a DNS or the use of special ports. [00166] Figures 27 and 28 illustrate example implementation of two such routines 2906 or daemon processes called image data receiver 2702 and communications 2704. The following is a description of these daemon processes. First, as illustrated in figure 27, routines 2906 can comprise an image data receiver 2702 (Dcmtk: :storescp).
  • a sub process 2704 (Trice: :sendFile) can be linked in and these processes together can be configured to send an image file, such as a DICOM image file to a receiver routine 2710 (Trice: receiver) in the cloud.
  • Transport Layer Security can be achieved in certain embodiments using private preshared key that is device specific.
  • the keys are encryption keys where both the sender and receiver need to successfully calculate the same key in order for transmission to succeed. Account information and labeling can be two of the inputs into this calculation.
  • the configuration depicted should provide robust file copy functionality that will succeed 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 result in a failed response to the device 101, which can cause device 101 to attempt to resend the image data.
  • the communications routine 2704 can also be configured to communicate with the receiver 2710 as illustrated in figure 28. Communications routine 2704 can be responsible for initialization, sending "heartbeats" to the cloud, failure reporting, configuration updates, and software updates if allowed.
  • a local directory 2706 with read/write access can be included to store the configuration information.
  • the location of this directory 2706 can be passed in as an argument to both daemon processes 2702 and 2704. In most embodiments, there are no requirements regarding it's disk location for directory 2706.
  • the directory 2706 can store information such as port#, local-ip address, DICOM dictionary, error logs, etc. If device 101 is a DICOM imaging device, then a DICOM service can load the DICOM dictionary for example from this directory 2706. Heartbeat messages, as described herein, can be sent to the cloud Receiver that include port# and local-ip address, which can be read from this directory 2706. Logging information can also be stored in this directory 2706.
  • a unique name can be calculated for the device 101. If there is a device id associated with device 101, then it should be used instead of the calculated name. If there is a device id, the file name containing the device id can be passed into communications routine 2704. This device id can be the primary key for everything related to the Uplink/device in the cloud database. The cloud services can then lookup things like: when was the last heartbeat from the device; when did the device first came online; what version of the software is loaded on the device; what account is associated with the device; etc.? The Uplink depicted in figures 27 and 28 sends periodic state information, which can be termed a heartbeat and which can be persisted in the cloud using the device-id as it's primary key. It should also again be noted that standard ports are used (e.g., 443) for all communications.

Abstract

L'invention concerne un système pour communiquer des images, qui comprend un dispositif d'imagerie conçu pour capturer et former des images et générer un fichier d'images numériques, le dispositif d'imagerie comprenant un identifiant de dispositif, un ensemble de routines conçu pour étiqueter le fichier d'images numériques, des informations de compte associées au fichier d'images numériques, pour associer l'identifiant de dispositif avec le fichier d'images numériques, et pour communiquer le fichier d'images numériques à un serveur, un serveur conçu pour recevoir des fichiers d'images numériques et pour traiter le fichier d'images numériques selon une étiquette associée au fichier d'images numériques et/ou des informations de compte associées au fichier d'images numériques et/ou un identifiant de dispositif associé à un dispositif qui a capturé le fichier d'images numériques.
PCT/US2015/055832 2014-10-15 2015-10-15 Systèmes et procédés permettant de chiffrer des images médicales, de les convertir et d'interagir avec elles WO2016061415A2 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
KR1020177012383A KR102571307B1 (ko) 2014-10-15 2015-10-15 의료 이미지에 대한 암호화, 변환 및 상호작용을 위한 시스템 및 방법
CA2964779A CA2964779A1 (fr) 2014-10-15 2015-10-15 Systemes et procedes permettant de chiffrer des images medicales, de les convertir et d'interagir avec elles
CN201580067622.9A CN107004059A (zh) 2014-10-15 2015-10-15 用于加密、转换和交互医学图像的系统和方法
KR1020237028526A KR20230125352A (ko) 2014-10-15 2015-10-15 의료 이미지에 대한 암호화, 변환 및 상호작용을 위한 시스템 및 방법
EP15850895.2A EP3207480A4 (fr) 2014-10-15 2015-10-15 Systèmes et procédés permettant de chiffrer des images médicales, de les convertir et d'interagir avec elles

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201462064404P 2014-10-15 2014-10-15
US62/064,404 2014-10-15
US14/614,405 US10476848B2 (en) 2009-10-14 2015-02-04 Systems and devices for encrypting, converting and interacting with medical images using a mobile device
US14/614,405 2015-02-04

Publications (2)

Publication Number Publication Date
WO2016061415A2 true WO2016061415A2 (fr) 2016-04-21
WO2016061415A3 WO2016061415A3 (fr) 2017-05-18

Family

ID=55747554

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2015/055832 WO2016061415A2 (fr) 2014-10-15 2015-10-15 Systèmes et procédés permettant de chiffrer des images médicales, de les convertir et d'interagir avec elles

Country Status (5)

Country Link
EP (1) EP3207480A4 (fr)
KR (2) KR20230125352A (fr)
CN (1) CN107004059A (fr)
CA (1) CA2964779A1 (fr)
WO (1) WO2016061415A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111243712A (zh) * 2019-12-16 2020-06-05 创业慧康科技股份有限公司 一种文件处理方法及装置

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109828949A (zh) * 2017-10-12 2019-05-31 贵阳朗玛信息技术股份有限公司 Dicom文件格式转换方法、装置及系统
CN109360664A (zh) * 2018-08-24 2019-02-19 湘南学院 一种基于数据挖掘算法的临床护理管理系统及方法
CN112655049A (zh) * 2018-09-07 2021-04-13 文塔纳医疗系统公司 用于缓存生物图像数据的系统和方法
CN109360632A (zh) * 2018-09-12 2019-02-19 北京东软医疗设备有限公司 临床信息的共享方法、装置及系统
CN109474498B (zh) * 2018-12-28 2022-04-05 苏州承泽医疗科技有限公司 一种监测医疗影像设备使用的方法
CN109859825A (zh) * 2018-12-28 2019-06-07 杭州英放生物科技有限公司 一种匿名化数据传输系统
CN112241735A (zh) * 2019-07-18 2021-01-19 杭州海康威视数字技术股份有限公司 一种图像处理方法、装置及系统
CN111048185B (zh) * 2019-12-25 2023-03-28 长春理工大学 基于机器学习的感兴趣区域参数博弈分析方法
CN113223654B (zh) * 2021-06-04 2022-09-02 杭州云呼网络科技有限公司 一种医学检验报告单的智能解读管理平台
CN113378224B (zh) * 2021-06-22 2023-07-04 平安好医投资管理有限公司 医学影像存储方法、装置、设备及存储介质

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7302164B2 (en) * 2000-02-11 2007-11-27 Datcard Systems, Inc. System and method for producing medical image data onto portable digital recording media
US20020091659A1 (en) * 2000-09-12 2002-07-11 Beaulieu Christopher F. Portable viewing of medical images using handheld computers
US20060149601A1 (en) * 2004-11-27 2006-07-06 Mcdonough Medical Products Corporation System and method for recording medical image data on digital recording media
US7770026B2 (en) * 2005-02-18 2010-08-03 Fuji Xerox Co., Ltd. Document management system, information processing device and method, and computer program
US8145503B2 (en) * 2005-02-25 2012-03-27 Virtual Radiologic Corporation Medical image metadata processing
KR100696708B1 (ko) 2006-02-21 2007-03-20 재단법인서울대학교산학협력재단 의료기관간 의료정보 온라인 전송 시스템
US20080021741A1 (en) * 2006-07-19 2008-01-24 Mdatalink, Llc System For Remote Review Of Clinical Data
US7974924B2 (en) * 2006-07-19 2011-07-05 Mvisum, Inc. Medical data encryption for communication over a vulnerable system
WO2010022402A1 (fr) * 2008-08-22 2010-02-25 Datcard Systems, Inc. Système et procédé de chiffrement pour des volumes dicom
WO2013188850A1 (fr) * 2012-06-14 2013-12-19 Trice Imaging, Inc. Systèmes et dispositifs servant au chiffrage, à la conversion et à l'interaction avec des images médicales
US9984203B2 (en) * 2009-10-14 2018-05-29 Trice Imaging, Inc. Systems and methods for converting and delivering medical images to mobile devices and remote communications systems
WO2012031032A1 (fr) * 2010-08-31 2012-03-08 Orthoscan, Inc. Système de courtage d'informations médicales de diagnostic et procédé correspondant
US8825680B2 (en) * 2010-10-09 2014-09-02 Codonics, Inc. Method and apparatus for displaying non-standard-compliant images
US8694600B2 (en) * 2011-03-01 2014-04-08 Covidien Lp Remote monitoring systems for monitoring medical devices via wireless communication networks

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None
See also references of EP3207480A4

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111243712A (zh) * 2019-12-16 2020-06-05 创业慧康科技股份有限公司 一种文件处理方法及装置
CN111243712B (zh) * 2019-12-16 2023-09-08 创业慧康科技股份有限公司 一种文件处理方法及装置

Also Published As

Publication number Publication date
EP3207480A4 (fr) 2018-07-04
KR20170085496A (ko) 2017-07-24
KR20230125352A (ko) 2023-08-29
KR102571307B1 (ko) 2023-08-28
WO2016061415A3 (fr) 2017-05-18
EP3207480A2 (fr) 2017-08-23
CN107004059A (zh) 2017-08-01
CA2964779A1 (fr) 2016-04-21

Similar Documents

Publication Publication Date Title
US10419405B2 (en) Systems and devices for encrypting, converting and interacting with medical images
US11462314B2 (en) Systems and devices for encrypting, converting and interacting with medical images
US11735312B2 (en) Systems and methods for converting and delivering medical images to mobile devices and remote communications systems
US11818107B2 (en) Systems and devices for encrypting, converting and interacting with medical images
EP2862327B1 (fr) Systèmes et dispositifs servant au chiffrage, à la conversion et à l'interaction avec des images médicales
KR102571307B1 (ko) 의료 이미지에 대한 암호화, 변환 및 상호작용을 위한 시스템 및 방법
US11948678B2 (en) Systems and devices for encrypting, converting and interacting with medical images

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15850895

Country of ref document: EP

Kind code of ref document: A2

ENP Entry into the national phase

Ref document number: 2964779

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2015850895

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 20177012383

Country of ref document: KR

Kind code of ref document: A