WO2011159849A1 - Medical imaging distribution system - Google Patents

Abstract

A system and method for medical imaging distribution is disclosed. The method includes receiving an image having a plurality of pixels arranged in at least one dimension; determining a number of the plurality of pixels in the at least one dimension satisfying a predetermined criteria; and outputting the number along with a location identification in the at least one dimension in a file.

Description

MEDICAL IMAGING DISTRIBUTION SYSTEM

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application Serial No.

61/355,142 entitled "MEDICAL IMAGING DELIVERY SYSTEM" which was filed on June 15, 2010. The entirety of the aforementioned application is herein incorporated by reference.

BACKGROUND

I. Field

[0002] This invention relates generally to medical information distribution systems, and more specifically, to a Medical Imaging Distribution System (MIDS).

II. Background

[0003] Digital media content such as medical images and supporting medical information/documentation are often distributed digitally via centralized servers or, in rare cases, via peer-to-peer systems. In the former instance of centralized server distribution systems, an entity such as a user-browsed website or user-based computer application actively requests medical images and records from a group of one or more servers over an open network such as the Internet or a closed network such as a Virtual Private Network (VPN). Upon receipt of the request, a server parses the request, creates a connection with the requesting entity, authenticates the entity, and delivers the requested medical imaging file(s).

[0004] Peer-to-peer systems directly connect two or more entities such as user-based computer applications over a network. Through an index of connected users and/or of connected medical content, users share medical content and distribute the medical content amongst themselves from computer to computer, e.g. from peer to peer. The index of users and content can be centrally located, as in the original music sharing system distributed under the trademark Napster(TM), or can be itself distributed among the users of the peer-to-peer network and actively updated as users join and leave regions of the ever-changing peer-to- peer network, such as the public peer to peer network commonly known as Gnutella. Some peer-to-peer networks increase efficiency of digital media distribution by permitting parallel sharing of portions of a particular media work amongst multiple users, using existing file transfer technologies such as those provided under the mark Bittorrent(TM), such that a peer- to-peer user may be downloading the last minute of a music media file while another user is obtaining the first minute of that music media file from that user simultaneously. Moreover, peer-to-peer networks are scalable in two senses: as more users join the network, more storage and more bandwidth becomes available for sharing, and as a particular media work becomes more popular, more copies of it are on the peer-to-peer network, thus reducing access time for more popular media works.

[0005] However, both centralized server and peer-to-peer server systems have distinctive drawbacks. Centralized servers can become strained and fail when under heavy and often unpredictable user demand. This is true even when a centralized server is distributed among many physical servers, or many network locations, through variable load-handling software available from vendors such as Akamai™ and the like.

[0006] Peer-to-peer networks have their own drawbacks. Because the structure of the peer- to-peer network is always changing, peer-to-peer networks can be unreliable at times. Moreover, because media files originate with individual unknown and unauthenticated users, peer-to-peer networks are often troubled by viruses, "Trojan horse" malicious software pretending to be legitimate media files, and generally inaccurate indexing that is either reliant on the availability of a centralized server or on a constantly-changing set of users. As a result, it is sometimes difficult to reliably share a particular media file on presently available peer-to-peer networks. Peer-to-peer networks, due to the frequent lack of centralized control, are also difficult to monitor for inappropriate or unauthorized content. In the same vein, it is sometimes difficult to authenticate individual users of a peer-to-peer network, either to ensure file authenticity, to track down malicious files or illegitimate files, or to permit users to communicate amongst themselves reliably.

[0007] Moreover, digital media files such as medical images are subject to a plethora of frequently incompatible file formats. Some medical imaging file formats require the user to have a proprietary player program. Others require the user to separately download one or more codecs, devices that can convert audio and/or video to a format visible to the user. Further, some medical imaging file formats create large files, or are incompatible with some computing platforms. Some medical imaging file formats are specifically implemented only for delivery as a complete file, while others are optimized or are only created for streaming of a media file to a user. Even streaming media file formats, as they apply to medical images, however, frequently have many different codecs, and even many different version incompatibilities within the same codec, creating user frustration that often prevents the viewing of patient medical images. Also, current streaming media formats typically involve a long initial delay while media is being "buffered," or transferred to a local memory cache, for pseudo-real time playback. Some medical imaging formats are only available for limited computing platforms, making some files unavailable to those with unsupported computers or operating systems. Along the same lines, streaming media frequently suffers from pauses, skips and lags that vary from format to format. The result of these incompatibilities is that a user, in order to share medical images with other medical professionals outside their network, must ensure that the file format is supported by the viewing user's computer and operating system, that the viewing user has a media player compatible with the media file format, and that the viewing user has an appropriate codec downloaded for that particular media format along with all appropriate licenses.

[0008] Neither current digital media formats, current central server systems, nor current peer-to-peer networks are optimized for the user's own control of who can access that user's media and media file format. In an age where medical professionals frequently want to share media files such medical images (DICOM and non-DICOM) and supporting medical information/documentation amongst medical professionals outside their network, current systems make it difficult for a medical professional user to (1) create a defined group of other users who have access to that user's media files, (2) authenticate the other users to grant them access to some or all of that user's media files, (3) authenticate the legitimacy of a media file and/or the right to share the file, and (4) provide the other users with a simple, universal method for obtaining access to and viewing media files that may be in a large number of different formats.

[0009] One problematic application is in bringing imaging interoperability to the medical market, which is defined to include the capability to receive and view any medical image without the need for special software. For example, medical imaging interoperability in the multi-billion organ transplants market. This market has pent-up demand due to lives being lost every day, viable organs going unrecovered, and industry revenue being capped by technological limitations. This technological limitation prevents transplant center physicians from viewing donor medical images that reside off-site at the donor hospital, which is often hundred or thousands of miles away. This technological shortfall forces transplant center physicians to rely on text-based descriptions of the donor medical images that reside at a distant donor hospital.

[0010] The current $100 million medical imaging market (separate from the organ transplant market) has a redundancy issue, where approximately 20 percent of all medical imaging studies are recreated, resulting in multiple health care facilities creating their own versions of medical imaging data because existing medical imaging information is not easily shared with off-site and/or out-of-network medical professionals, even if a patient consents. This costly problem totals somewhere between $10 and $20 billion annually in the U.S.

[0011] Throughout healthcare facilities worldwide, advanced medical images like MRIs,

CT scans and Ultrasounds lack interoperability, which means that often a physician at one hospital cannot readily view medical images residing at or captured by another hospital. The reasons for this are twofold:

[0012] 1. Huge data sets - a typical medical image study ranges between 100 MB and 500

MB, which may be too big to be digitally transmitted to another hospital, whether the hospital is across town or across the country.

[0013] 2. Hundreds of disparate, proprietary file formats - in order to view images, each individual file format requires the physician to have that format's proprietary software.

[0014] Further, specific to markets such as the organ transplantation market, a technological shortcoming is that transplant surgeons at transplant centers and/or organ procurement organizations (OPOs) cannot transmit and/or view donor medical images prior to accepting or rejecting an organ— and because of this, patients are dying unnecessarily because of inefficiencies in the evaluation process and organ wait lists are generally growing faster than the rate of organ donation. Medical images are instrumental to accurately matching donor organs with suitable recipients and it is not uncommon for transplant surgeons to reject organs that they would have otherwise accepted if only they were able to view the donor's medical images. To this point, on average, only three out of eight available organs per donor are recovered for transplantation.

[0015] Also, assuming time permits, time-sensitive medical images are sometimes couriered from one medical facility to another, both locally and nationally, because the technical implementation issues require actual digital media— including software used to view the images— to be physically transported from one location to another. This increases costs in transporting the information, negatively impacts patient care by postponing of diagnosis and treatments and may increase costs and decrease revenue in delay ed/cancelled operations.

[0016] Further, health insurance companies are often forced to blindly approve millions of costly and potentially unnecessary procedures as an attending physician submits a text-based report (generated after viewing a patient's medical images) to the insurance company for authorization— but insurance companies do not have ready access to patient images so they can make fully informed decisions. [0017] Further still, pharmaceutical companies must aggregate and view medical images in clinical trials. The FDA, in an effort to increase new drug approvals, now allows imaging as part of the evidence in support of new drug applications. The challenge for pharmaceuticals is the time, effort and cost of collecting imaging studies from the clinical trial participants who are distributed across the country and around the world. It has been reported that the use of imaging could save a company millions per project.

[0018] As medical professionals seek to share patient medical imaging studies with physicians located outside of their facility or pre-established network infrastructure, their primary method for sharing such images is the time-consuming process of burning the medical images to a Compact Disc (CD) and then using couriers (e.g., FedEx, UPS or a local courier service) to deliver the CD. In today's Information Age, this antiquated delivery system is often the weakest link in providing high quality, lower cost patient care. And while much of medical-related information technology has advanced, the easy and immediate sharing of patient medical images over the Internet (regardless of the geographical location of the medical professionals) has fallen short of the mark. Health care organizations continue to struggle with medical imaging challenges associated with extremely large imaging studies that are often too large to digitally transmit, costly to store, and the hundreds of proprietary medical image file formats that usually require special software that is specific to the medical imaging equipment manufacturer in order to view them.

[0019] Consequently, it would be desirable to address one or more of the deficiencies described above.

SUMMARY

[0020] In an aspect of the disclosure, a method for medical imaging distribution is disclosed that includes receiving an image having a plurality of pixels arranged in at least one dimension; determining a number of the plurality of pixels in the at least one dimension satisfying a predetermined criteria; and outputting the number along with a location identification in the at least one dimension in a file.

[0021] In another aspect of the disclosure, an apparatus for medical imaging distribution is disclosed that includes a processing system having a processor and a memory configured to cause the processor to receive an image having a plurality of pixels arranged in at least one dimension; determine a number of the plurality of pixels in the at least one dimension satisfying a predetermined criteria; and output the number along with a location identification in the at least one dimension in a file. [0022] In another aspect of the disclosure, an apparatus for medical imaging distribution is disclosed that includes means for receiving an image having a plurality of pixels arranged in at least one dimension; means for determining a number of the plurality of pixels in the at least one dimension satisfying a predetermined criteria; and means for outputting the number along with a location identification in the at least one dimension in a file.

[0023] In another aspect of the disclosure, a computer program product includes a computer-readable medium having code executable by a processor to receive an image having a plurality of pixels arranged in at least one dimension; determine a number of the plurality of pixels in the at least one dimension satisfying a predetermined criteria; and output the number along with a location identification in the at least one dimension in a file.

[0024] In another aspect of the disclosure, a method for medical imaging distribution includes receiving a file having information related to a plurality of pixels arranged in at least one dimension, wherein the information includes a number of the plurality of pixels having pixel values satisfying a predetermined criteria and further includes a location identification in the at least one dimension of the number of the plurality of pixels; decoding the information to retrieve the number and the location identification; and constructing an image file based on the number and the location identification.

[0025] In another aspect of the disclosure, an apparatus for medical imaging distribution includes a processing system having a processor and a memory configured to cause the processor to receive a file having information related to a plurality of pixels arranged in at least one dimension, wherein the information includes a number of the plurality of pixels having pixel values satisfying a predetermined criteria and further includes a location identification in the at least one dimension of the number of the plurality of pixels; decode the information to retrieve the number and the location identification; and construct an image file based on the number and the location identification.

[0026] In another aspect of the disclosure, an apparatus for medical imaging distribution is disclosed that includes means for receiving a file having information related to a plurality of pixels arranged in at least one dimension, wherein the information includes a number of the plurality of pixels having pixel values satisfying a predetermined criteria and further includes a location identification in the at least one dimension of the number of the plurality of pixels; means for decoding the information to retrieve the number and the location identification; and means for constructing an image file based on the number and the location identification.

[0027] In another aspect of the disclosure, a computer program product includes a computer-readable medium having code executable by a processor to receive a file having information related to a plurality of pixels arranged in at least one dimension, wherein the information includes a number of the plurality of pixels having pixel values satisfying a predetermined criteria and further includes a location identification in the at least one dimension of the number of the plurality of pixels; decode the information to retrieve the number and the location identification; and construct an image file based on the number and the location identification.

BRIEF DESCRIPTION OF THE DRAWINGS

[0028] These and other sample aspects of the disclosure will be described in the detailed description that follow, and in the accompanying drawings, wherein

[0029] FIG. 1 is a schematic representation of a network including a plurality of users employing one embodiment of a medical imaging distribution system of the present invention.

[0030] FIG. 2 is a representational via of one embodiment of the MIDS server/node of the present invention.

[0031] FIG. 3 is a functional flow chart illustrating a medical image submission process via a MIDS server/node according to an embodiment of the present invention.

[0032] FIG. 4 is a functional flow chart illustrating a medical image file request process via a MIDS server/node according to an embodiment of the present invention.

[0033] FIG. 5 is a functional flow chart of one embodiment of medical image file streaming via a MIDS server/node in one embodiment of the present invention.

[0034] FIG. 6 is a representational flow chart of a MIDS server media key generation process in accordance with an embodiment of the present invention.

[0035] FIG. 7 is a topological representation illustrating medical image file storage and indexing using a medical image file MIDS index in accordance with an embodiment of the present invention.

[0036] FIG. 8 is a functional flow chart of one embodiment of a medical image file fingerprinting process of a MIDS server/node of the present invention.

[0037] FIG. 9 is a functional flow chart of a user e-mail address confirmation process of a

MIDS server/node in accordance with an embodiment of the present invention.

[0038] FIG. 10 is a block diagram schematically illustrating conversion of medical image files to a common or universal format in accordance with an embodiment of the present invention. [0039] FIG. 11 is a topological representation illustrating medical image file sharing in connection with a user data MIDS index in accordance with an embodiment of the present invention.

[0040] FIG. 12 is a block diagram illustrating the various steps for implementing a MIDS configured in accordance with one embodiment of the invention.

[0041] FIG. 13 is a flow diagram illustrating a process for creating a medical image object

(MlOb) file in accordance with an embodiment of the present invention.

[0042] FIG. 14 is a block diagram illustrating the various components in a MIDS in accordance with an embodiment of the present invention.

[0043] In accordance with common practice, some of the drawings may be simplified for clarity. Thus, the drawings may not depict all of the components of a given apparatus (e.g., device) or method. Finally, like reference numerals may be used to denote like features throughout the specification and figures.

DETAILED DESCRIPTION

[0044] Various aspects of a medical imaging distribution system (MIDS) are described more fully hereinafter with reference to the accompanying drawings. This disclosure may, however, be embodied in many different forms and should not be construed as limited to any specific structure or function presented throughout this disclosure. Rather, these aspects are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art. Based on the teachings herein one skilled in the art should appreciate that that the scope of the disclosure is intended to cover any aspect of the disclosure disclosed herein, whether implemented independently of or combined with any other aspect of the disclosure. For example, an apparatus may be implemented or a method may be practiced using any number of the aspects set forth herein. In addition, the scope of the disclosure is intended to cover such an apparatus or method which is practiced using other structure, functionality, or structure and functionality in addition to or other than the various aspects of the disclosure set forth herein. It should be understood that any aspect of the disclosure disclosed herein may be embodied by one or more elements of a claim.

[0045] In a network, as shown in FIG. 1, a plurality of users (hereinafter referred to as

Doctor Alice 10, Doctor Bob 20 and Doctor Carol 30), are each associated with a user computer A 15, user computer B 25 and user computer C 35. Each user computer A 15, B 25 and C 35 is coupled to a network 40 such as the Internet, a closed cable-loop network, a wireless network, a POTS (plain old telephone system) network, a satellite network, and the like. Each of the computers A 15, B 25 and C 35 are running a computer operating system such as those available from Microsoft(TM), Apple(TM), Sun(TM), IBM(TM), from multiple sources under the trademark LINUX(TM), a variant of the BSD operating system, a variant of the UNIX operating system, an embedded operating system such as is available from vendors such as Wind River Systems (TM), MonteVista (TM), and the like or any other operating system. Accessible to computers A 15, B 25 and C 35 over the network 40 is a network server (not shown). Doctor Alice 10, Doctor Bob 20, and Doctor Carol 30 may control their respective computers A 15, B 25 and C 35 directly or remotely through the network 40.

[0046] As illustrated on the user computers A 15 and B 25, the users Doctor Alice 10 and

Doctor Bob 20 have respectively installed a MIDS server/node 100. The MIDS server/node 100 includes, for example, a small software program compiled for the particular operating system on which computer A 15 and B 25 respectively operate, that incorporates a plurality of modules, i.e., sets of related instructions which are executable by a computer to perform medical image sharing, security and storage functions. These modules include at least some of, but are not limited to: a secure MIDS server/node module 100, a medical image file storage and indexing module 170, a medical image file fingerprinting module 180, a user security module 190, a medical image file conversion module 200 for a universal media format 210 and a MIDS player 230, optionally including a digital rights management encapsulation module 220, a user sharing group module 240, a global indexing module 250 resident on a remote network server for managing user and medical imaging data, a sharing user authentication module 260. These modules employ the memory, storage, network connection and processor of the computers A 15 and B 25, as controlled by the MIDS server/node, to provide distributed medical image sharing and streaming functionality. These modules typically are stored on a computer-readable recording medium such as a magnetic disk, optical disk tape, removable disk drive, solid state memory or other storage medium which can be local to the computer or can be accessed electronically from a remote computer via a network.

[0047] FIG. 2 shows a representational view of one embodiment of the MIDS server/node

100, in this case a secure, encrypted MIDS server/node module 100. In one embodiment, the MIDS server/node 100 is installed on a Linux-compatible computer system 110. The computer system may be, for example, a traditional computer, a set-top box, a portable media player having internet connectivity, a media-capable cellular phone, a personal digital assistant (PDA), or the like. Typically, although not necessarily, the computer 110 will communicate over at least one main data bus 115 and may include a processor 120, a memory 130, a non-volatile storage medium 140, a display 150, and a network interface 160. The MIDS server/node 100 may require only a small memory "footprint" on the computer 110, permissibly although not necessarily requiring less than 150 kilobytes (kB) of memory to reside, and more preferably although not necessarily requiring less than 100 kB of memory to reside. The MIDS server/node 100 includes the core functionality of a standard web server in that it can transmit and receive hypertext transfer protocol (HTTP) or similar requests and methods, most commonly GET and PUT, as well as other methods as described in the Internet Engineering Steering Group/Internet Engineering Task Force (IESG/IETF) Request For Comment Nos. 1945 (1996), 2616 (1999), and other standards related to the HTTP protocol. In particular, the MIDS server/node 100 preferably supports at least secure sockets layer (SSL) communications via HTTP port 443 or other ports, in order to support basic encryption functionality for transactions implemented through the MIDS server/node, and the MIDS server/node may support further forms of encryption such as public key encryption using Diffie-Hullman or RSA style public/private key pairs, Advanced Encryption Standard of the National Institute of Standards and Technology (AES NIST) encryption or a later officially approved encryption standard, one way hash functions and fingerprints, and the like. For example, in one embodiment, SSL transactions are replaced with RSA encrypted private key certificates associated with at least 1024 bit private RSA keys, and transactions are authenticated by sending certificate signing requests to an encryption certificate signing authority such as those currently provided by Thawte(TM) and the like.

The MIDS server/node 100 is typically stored as a software binary in the nonvolatile storage medium 140 such as a hard drive, persistent flash memory, optical disk or optical memory, or over a network memory. Alternatively, the MIDS server/node may be stored in a permanent or flashable hardware device as part of some computers such as, for example, portable media players and media-capable cell phones. In addition, persistent but volatile memory can be used, such as, for example, that used in some flashable basic input output system (BIOS) systems. Upon initialization, the MIDS server/node 100 resides in the memory 300 on the computer 110, where it monitors incoming HTTP requests, transmits outgoing HTTP requests, and implements various maintenance and security operations from the network interface 160. The MIDS server/node 100 maintains a connection to network communications via the standard network API for the particular operating system and computer on which the MIDS server/node 100 is implemented. [0049] As described previously with respect to FIG. 1, the MIDS server/node 100 may include a number of accompanying modules, including a medical image file storage and indexing module 170, a medical image file fingerprinting module 180, a user security module 190, a medical image file conversion module 200 for a universal media format 210 and an encapsulated MIDS streaming player 230, optionally including a digital rights management encapsulation module 220, a medical professionals sharing group module 240, a global indexing module 250 resident on a remote network server for managing user and media data, a sharing user authentication module 260. Although described in substantially more detail below, the MIDS server/node's basic file sharing functions come in four submodules: a medical image submission module, a medical image request module, a medical image serving module, and a local maintenance/security operations module.

[0050] For submitting medical images, the MIDS server/node 100, in the embodiment shown in FIG. 3, performs the steps of: (1) receiving a user request to submit a medical image file as part of a MIDS sharing group; (2) checking the MIDS index and, optionally, other MIDS indexes of group members for that particular file; (3) if the file is already in the MIDS sharing group, returning a link to that file; (4) if the MIDS index includes the requested medical image file as stored on another user's computer or another organization's server, returning a link to that file on the another user's computer; (5) if the file is not available, determining the file type and converting it to a universal media format; (6) indexing the file with basic file type and specific file information; and (7) adding the file to the MIDS index and, if shared, to the MIDS sharing group index and to the global index.

[0051] In one particular embodiment, a medical image submission process 300 begins with the submission of a medical image file 320. In a comparison operation at 310, the medical image file 320 is hashed and is compared to a MIDS index 330 of medical image files via the fingerprinting process further described below (see FIG. 8). If a matching medical image file 335 in the MIDS index 330 is found, then in a link receipt operation at 340 a medical image link 345 is returned to the user with a link to the medical image file 335, which is either on a MIDS computer or on a computer to which the user has access via the MIDS server/node 100, after which the submission process ends at 395.

[0052] If the comparison at 310 does not show a matching medical image file in the MIDS index 330, then in a media format determination operation at 350 the medical image file 320 is compared to a database of known file types 360, including medical image files available over a network 40, to determine whether a matching medical image file type 365 is part of a file type database 360. If not, then the process ends at 395. If the medical image file type 365 is available, then a digital rights confirmation portion 355, which is optional, is performed to determine whether sufficient rights are available for the medical image file 320 of medical image file type 365 to be converted to a universal media format. In particular, the medical image file 320 can be compared using digital rights access information 380 available over the network 40. If sufficient rights to convert the medical image file 320 are not available, the submission process again ends at 395. If sufficient rights are available for conversion, then a universal media format conversion process 370 is performed based on the known media file type 365. The universal media format conversion process is discussed in more detail below, and creates a universal media format version of the medical image file 320, and adds basic information 335 about the submitted file to the MIDS index 330, either from information submitted along with the submitted medical image 320 or obtained over the network 40 based on an identification of the submitted medical image 320 based on its fingerprint found in comparison at 310. Finally, a link to the universal media format version of the submitted medical image file 390 is returned, and the submission process ends 395.

For receiving requested medical imaging, the MIDS server/node 100, in one embodiment shown in FIG. 4, performs the steps of: (1) receiving a user request for a medical image file from a MIDS user on the computer; (2) comparing the requested medical image file to a MIDS index associated with the MIDS server/node ; (3) if the MIDS index includes the medical image file as stored on the computer, returning a link to the medical image file on the computer to the MIDS user or if the MIDS index includes the requested medical image file as stored on another computer for which the MIDS user has viewing access, returning a link to the medical image file on another computer to the MIDS user; (4) if the MIDS index does not include the requested medical image file, seeking a global index from a remote central index server, and if said global index is accessible, comparing the requested medical image file to the global index to find a set of other users hosting the requested medical image files and returning a link to the medical image file on the other users' computers to the MIDS user on the MIDS computer; (5) upon the MIDS user clicking upon a link to the requested medical image file if supplied, streaming the requested medical image file from at least one of a MIDS medical image storage and a remote medical image storage to the MIDS user at the computer. The MIDS server/node may also perform the step of authenticating the integrity of the media file, authenticating the MIDS user, authenticating the MIDS user's rights to play, stream and/or copy the medical image file, and authenticating the sharing list associated with the medical image file and/or MIDS user. [0054] In one particular embodiment, a medical image request process 400 begins with the receipt of a file request 420, either locally or over a network 40, from a user 440. In a comparison at 410, the file request 420 is compared to a MIDS index 430 of medical imaging files via the fingerprinting process further described below (see FIG. 8): if the comparison shows no matching medical image file, the medical image request process 400 ends at 470 (and may then proceed to a search of a global index of users on a network described below). If the comparison finds a matching medical image file 435 in the MIDS index 430, then in a request authorization comparison at 450, the MIDS server/node determines whether the requesting user 440 is authorized to receive the requested medical image 435. If the user 440 is not authorized, then the process ends 470. If the user 440 is authorized, then a link 460 to the requested medical image is returned to the user 440 and the process ends 470.

[0055] Alternatively, if the MIDS index comparison operation at 410 does not show a matching medical image file in the MIDS index 430, then in a global index decision operation the medical image request is compared to a global index including files available over a network 40 to determine whether a matching medical image file 365 is available over the global index. If not, then the process ends at 395. If the medical image file is available, then global user decision step determines if there are other users who have the requested medical image file via the global index. If there is no match to other users maintaining the medical image file, the decision step fails and the process ends. If a match is found to a medical image file on the global index, then a list of users maintaining that medical image file is returned from the global index. In a link receipt step, one or more links to a remote user source of the medical image file are provided to the user, and the process ends. In this embodiment, the global index only provides access to medical image files for which all users are authorized for access, but user permissions as described below may also be implemented in such a system, as may digital rights management controls on medical image distribution.

[0056] For serving and streaming requested medical image, the MIDS server/node 100, in one embodiment as shown in FIG. 5, performs the steps of: (1) receiving a request for a medical image file from a remote user on another computer via a network; (2) comparing the requested medical image file to a MIDS index associated with the MIDS server/node 100; (3) if the MIDS index includes the medical image file on the computer, serving a link to the remote user on another computer representing the requested medical image file on the computer; (4) upon execution of the link to the requested medical image file by the remote user on the another computer, streaming the requested medical image file from the computer to the remote user on the another computer. The MIDS server/node 100 may also perform the step of authenticating the integrity of the medical image file, authenticating the MIDS user, authenticating the MIDS user's rights to play, stream and/or copy the medical image file, and authenticating the sharing list associated with the medical image file and/or MIDS user.

[0057] In one embodiment, a medical image serving/streaming process 500 begins with the receipt of a medical image file request 520 from a system user 540 over a network 40 (although the user may be MIDS, in which case the network 40 only needs to use the local network loopback interface or may circumvent the network connection all together in serving medical imaging locally). In a comparison operation at 510 the medical image serving location, the medical image file request 520 is compared to a MIDS index 530 of medical image files via the fingerprinting process described below (see FIG. 8): if the comparison shows a matching medical image file 533 in the MIDS index 530, then in a media authorization comparison at 450 it is determined whether the requesting user 540 is authorized to receive the requested media stream, based on whether the requesting user 540 is a member of the MIDS group permitted access to the medical imaging database and/or whether the requesting user 540 has sufficient digital rights management rights to stream the requested medical image file. If not, then the process ends 570. If access is granted, then a link to the requested medical image file 560 is returned to the requesting user 540 over the network 40, through which the requested medical image 433 is streamed over the network 40, after which the process ends at 570.

[0058] Preferably, the MIDS server/node 100 is secured and is permanently associated with the computer on which it resides via use of a MIDS security algorithm to provide a MIDS user with a four digit key securely associated with the MIDS server/node and medical image files associated with the MIDS server/node. In one embodiment, the security algorithm employs four principal steps, as shown in FIG. 6.

[0059] First, in a MIDS server/node key generation process 600, a private key is obtained or calculated for a particular medical image file 610. During this process, the meta file data or fingerprints for the medical image file can be used to create an SSL or RSA certificate 620 and a private key associated with the computer can be obtained which are associated with the particular MIDS server/node and/or end user, in a key initiation operation at 630. Second, a cryptographic function operation at 640 using the standard UNIX(TM) crypto function as described in IETF Requests for Comment Nos. 1421 (1993) and 2045 (1996) is performed using the medical image file's information and the private key. As a SALT seed for the crypto command, a unique initial value 650 such as a GUID (globally unique identifier) associated with the end user's computer, or more preferably, a UNIX-style timestamp value, is obtained and is mathematically transformed via a conversion function that translates the timestamp value or GUID value into a format acceptable for the SALT variable in the crypto function. Then, the output of the crypto function, a string of at least 128 bits 690, is divided into 64 bit blocks in a string output division operation at 660. The first 64 bit block 670 is translated into a media access code such as a four-digit code that is presented to a MIDS user on the machine for association with medical image files to be stored in the medical image file storage. The second 64 block 680a and additional blocks 680b, 680c form a media key value (for DES, AES, and the like) that are used for encryption of the medical image files to be stored in the medical image file database associated with the MIDS server/node on the computer, as described below.

[0060] Associated with the MIDS server/node 100 is a medical image file store accessible to the computer on which the MIDS server/node 100 is operated, one embodiment of which is shown in FIG. 7. The medical image file store 700 is preferably locally part of a MIDS server/node 100 stored at an MIDS authorized network, but locality is not a requirement. For example, the MIDS medical image storage database 700 may be associated with a MIDS server/node 100 but accessible to a computer 10 only over a network 40. In the MIDS medical image storage 700, each medical image file 720a, 720b, 720c is associated with medical image file index data 725a, 725b, and 725c, respectively, one exemplary embodiment of which is described in Table 1, below, or of the various medical image file metadata types described herein or that are known in the art. Similarly, in the network medical image storage database 710 medical image files 730a-f are associated with medical image file index data 735a-f which can also be of the type shown in Table 2, or of the various medical image file metadata types described herein or that are known in the art.

[0061] Upon receipt of a medical image file for storage, streaming, sharing or playback, the medical image file is fingerprinted, indexed, and MIDS stored (unless medical image file metadata prohibits storage). Using the media key value described above, the MIDS stored medical image files are encrypted with the media key to prevent unauthorized access to the medical image files stored in the medical image file storage. A MIDS user or authorized sharing user can thus access the medical image files in the medical image storage by providing the media access code discussed previously, which, combined with the media key value, properly decrypts the medical image file for streaming, playback or sharing.

[0062] The media access code presented to users is preferably based on data associated with the computer on which the medical image file is stored, the same medical image file will have a different media access code on different machines. As such, the media access code assists in preventing unauthorized or illicit sharing of medical image files or copying of medical image files because the encryption step on each machine renders a medical image file in medical image storage useless on another computer unless it is obtained via a transaction authorized by the MIDS server/node.

[0063] Once the medical image file is stored, the metadata associated with the medical image file is indexed in a MIDS media index associated with the MIDS server/node. The MIDS medical image index provides a searchable list of medical image files and related metadata (updated in near-real time in one embodiment, or occasionally updated upon access to the medical image storage in another embodiment), to determine the content, availability, authenticity, file characteristics, authorized users, and the like associated with each particular medical image file. In some embodiments the MIDS index file is also shared with a global index stored on a remote central server, to provide a central location for managing access to and indexes of available medical image.

[0064] Upon receipt of a medical image file, the medical image file is fingerprinted to confirm its authenticity and to relate the authenticated medical image file to other copies of the same medical image file stored by other users. One embodiment of this fingerprinting process is illustrated in FIG. 8.

[0065] The fingerprinting process creates unique, verifiable medical image file fingerprints via a three step process as shown in one embodiment in FIG. 8: (1) the beginning of the media data in the medical image file is examined to determine the actual media type, (2) the media data is filtered for only a limited range of data stored therein (such as, for example, ASCII characters), (3) the limited set of filtered media data is fingerprinted via a standard hash function such as the MD5 algorithm to create a substantially unique fingerprint for the media data, and hence for the medical image file. More specifically, a medical image fingerprinting process 800 begins with the submission of a medical image file 810. In a media data examination at 820, the beginning of the data in the medical image file 810 is inspected to determine the actual medical image type 830. Then, in a medical image filtering at 840, the medical image file 810 is filtered to leave only a predetermined subset of media data 850, such as, for example, only ASCII characters using the formula of Equation 1, below. Finally, the predetermined subset of media data 850 is submitted to a hash function 860 such as, for example, MD5 or SHA1, resulting in a unique hash string 870 for the medical image file and a known actual media type 830 for the medical image file 810. The hash string 870 becomes a medical image fingerprint stored in the medical image storage described above along with the actual media type 830, and the process ends 880.

[0066] The MIDS user can also provide a self-description for the medical image file to further facilitate accurate determination of file contents in the overall system, among MIDS sharing users, and locally on the user's computer. Algorithmically, the fingerprinting module can be described as follows:

[0067] Medicallmagingfile.fp = md5(strings (Medicallmagmgfile.md)) (Eq. 1),

[0068] where Medicallmagingfile.fp is a fingerprint for a medical image file Medicallmagingfile;

Medicallmagmgfile.md is a medical image data associated with Medicallmagingfile; strings( ) function is the standard UNIX(TM) strings( ) function for extracting ASCII characters from a data stream; and md5( ) function is the practical, but collision susceptible, md5 hash algorithm as described in IETF Request for Comment No. 1321 (1992).

[0069] Individual users associated with a computer on which the MIDS server/node 100 is installed are preferably presented with security options analogous to those available to users in the UNIX(TM) security model. Thus for each local user, a password and local profile are created: the password is preferably not stored in plain text but is instead stored in a shadow file that stores one-way information sufficient to authenticate the password, such as a hash function of the password, but does not store the password itself. The MIDS profile preferably includes user name, user contact information including but not limited to contact information such as e-mail addresses, instant messaging addresses, alternative user names, pictures, telephone and mail contact information, social network information such as hobbies, media styles and preferences, user demographics, and the like. As used herein, the MIDS profile is sometimes referred to as user metadata.

[0070] Preferably the user metadata may be associated with the user's password in such a way as to protect the user's privacy. Individual MIDS users can thus be individually (or as a group associated, as described below with respect to sharing groups) associated with one or more medical image files in the media file storage for permission to access, stream, play back, or share the medical image files stored therein.

[0071] For particular user metadata additional security checks can be employed. For example, FIG. 9 provides one embodiment of a user e-mail address confirmation process 900 (for either a MIDS user or a remote user), where the e-mail address can be verified without further user interaction. The process entails (1) determining the e-mail server associated with the user e-mail address, (2) opening a connection between the MIDS server/node and the e- mail server and logging on, (3) sending a HELO command to the entered e-mail address, (4) upon receipt of a confirmation that the address exists from the e-mail server, closing the connection and verifying the e-mail address is likely to be correct, and (5) upon receipt of a failure to confirm the e-mail address from the e-mail server, or upon failure to find the e-mail server associated with the entered e-mail address, returning an error flagging the user metadata as potentially not valid.

[0072] More specifically, in one embodiment shown in FIG. 9, an e-mail confirmation process 900 begins with the submission of an e-mail address 910 at a MIDS server 905. The e-mail address is resolved over a network 40 (via a standard network resolution process such as the DNS Domain Name System of address resolution servers) to an e-mail server 915, which holds e-mail user data 930 that may be related to the submitted e-mail address 910. When the identity of the e-mail server 915 is returned to the MIDS server 905, the MIDS server moves to a server communication operation at 940, where the MIDS server 905 opens a connection with the e-mail server 915 via a standard "HELO" SMTP command 945 with the submitted e-mail address 910. The e-mail server 915 then returns a message 955 to the MIDS server 905, and at a e-mail authentication decision operation at 960, the returned message 955 from the e-mail server 915 is tested to see if the e-mail address is valid or not. If the e-mail address (or the e-mail server itself) is invalid, then the process moves to a e-mail address rejection operation at 970, and returns an e-mail authentication flag 990 stating that the e-mail address is invalid. If the e-mail server 905 returns a standard greeting or other message confirming the e-mail address is valid, then the e-mail authentication decision operation at 960 moves to an e-mail confirmation operation at 980, which returns an e-mail authentication flag 990 stating that the e-mail address is valid.

[0073] In order to maximize compatibility of medical image across many computers and operating systems, a medical image file conversion module for converting an original medical image file to a universal media format 510, optionally including a digital rights management encapsulation module 600, is provided. In one embodiment, a universal media format is an MPEG-4 Part 2 compatible video format, an MPEG-4 Part 10 compatible video format, or a non-MPEG wavelet-based codec, or another codec. As shown in FIG. 10 in one embodiment of the universal media format conversion process 1000, upon receipt of an original medical image file 1010, the medical image file 1010 is fingerprinted 1020 as described previously. Through the fingerprinting process as previously described in FIG. 8, the medical image file actual file format 1030 is identified and is converted to the universal media format via a windowing conversion process 1040 whose speed is variable based on the power of the computer on which the system resides. Either parallel with or after conversion to the universal media format, the medical image file is preferably encrypted via the user security module 1050 described above. The resulting universal media format encrypted file 1060 is forwarded to the user medical image storage library 1070 along with the medical image fingerprint 1075 and other medical image data 1080, and the process ends 1090.

[0074] The medical image file sharing module 1100 provides an interface for remote users to be authorized to share files on the MIDS server then must log in with a valid username and password. Each remote user so-authorized is provided a user password and user metadata in a manner described above for MIDS users, using standard UNIX-style user account control systems and, preferably, shadow password files. Each MIDS user and each remote authorized sharing user can be given access to all, some, one or none of the medical image files stored in the medical image storage by granting each user and the like), permissions on an individual, user-by-user basis or on a "group" basis. Applying the standard UNIX user account model such as implemented in standard UNIX commands such as chgrp( ), chmod( ), chown( ) (or Microsoft(TM) Windows(TM) analogs such as attrib, cacls, and the like), MIDS users and remote authorized sharing users can be made part of various user "groups," each group having access rights to one or more authorized medical image files in the medical image storage, and where each group has access to similar or different sets of medical image files.

[0075] In one embodiment as shown in FIG. 11, a MIDS user 10 on a MIDS computer 15 includes a MIDS server/node 100 coupled to an user authentication module 1160 and a MIDS user database 1100 including specific MIDS user permissions 1110 for the MIDS user 10, as well as remote user permissions 1120 and 1130 for users 20 and 30, on computers 25 and 35 connected to computer 15 on a network 40. The user permission information can be directed by the user 15 and/or can be digital rights management information associated with specific media works. Associated with the MIDS user database 1100 is a MIDS media storage database 1180 as previously defined, including media works, media index data, and the like.

[0076] The computer 25 includes its own MIDS server/node 100, but computer 35 in this embodiment does not, but can still access links to medical image works on computer 15 or 25's MIDS server/nodes via web links provided by users 10 and 20 respectively. Separate from the MIDS user store 1100 and MIDS media storage 1180, over the network 40 the users can also access a remote MIDS server/node 100 with its own user authentication module 1160 and remote user store 1120, including other user data 1110a, 1120a, 1130a for users 10, 20 and 30 respectively, as well as data for other users 1140a, 1150a and so on. [0077] Optionally, a global indexing module on a remote server is provided. The global indexing module receives, indexes, and provides to users three types of information: (1) a maintained index of medical image files and users associated with those medical image files, (2) a maintained correlation between each user and a network designation for the computer associated with that user on which the MIDS server/node 100 is installed, and (3) a maintained index of user demographic and user metadata information. The global indexing module can also contain (4) media files, and metadata, (5) digital rights management information associated with individual media files, groups of medical image files, individual users, groups of users, and the like, and (6) central administrative functions and modules.

[0078] The maintained index of medical image files is compiled from MIDS medical image indexes forwarded from MIDS server/nodes to the remote central server. The centralized index thus permits efficient access to medical image files by recognizing the same medical image file (even if differently named or with different metadata) stored in different locations by different MIDS server/nodes and by different users, such that popular files can be accessed and shared in a distributed fashion by correlating copies of a requested medical image file on the global index with particular MIDS server/nodes from which to obtain the requested medical image file upon receipt of a request from another MIDS server/node.

[0079] The maintained correlation between users and a network designation for the user's computer on which the MIDS server/node is installed permits remote users and sharing users to access the MIDS user's MIDS server/node without having to determine the MIDS user's technical network address (such as an IP address (internet protocol address) of the form a.b.c.d where each of a, b, c and d are an 8-bit value, an IP v6 address of the form a.b.c.d.e.f.g.h where each of these eight values are 16-bit hexadecimal values, a DNS (domain name system) address of the form hostname. ext where hostname is the name of the computer and .ext is the extension of the form .com, .org, and the like, or another network identifier. In one embodiment, the MIDS server/node 100 sends a predetermined packet to the central server at a known time interval, such that the technical network address from which the predetermined packet is received at the central server is associated with the user until such time as the address from which the predetermined packet is received from a particular MIDS server/node changes. In another embodiment, the MIDS server/node updates its technical network address with the central server when it performs an action related to the central server, such as, for example, sending the central server an updated MIDS index, sending the central server a MIDS user request for a medical image file, and the like. In order to prevent third parties from interfering with the authenticity of a MIDS server/node and a respective central server, in response to such a request from a MIDS server/node or a predetermined packet from a MIDS server/node, the central server returns an encoded timestamp, confirming the correctness of the network path to the MIDS server/node. Upon such a confirmation, remote users requesting access to that MIDS server/node 100 or to media files stored thereon via the central server are routed to that central server via the technical network information stored at the central server associated with that MIDS server/node.

[0080] The maintained index of user demographic and user metadata information is updated from user information forwarded to the central server from respective MIDS server/nodes. Moreover, a public web interface to the central server is preferably provided at a principal web address, i.e., softmd.org, for example, from which users can register centrally as part of the central server index and database. The public web interface permits users to enter user metadata, search for media files, and the like, using SQL-web interface techniques as are well known in the art. The user e-mail address may be confirmed via the automatic e- mail server checking algorithm described above. After registration, user demographic information such as media file requests to and from the user, the types of media files stored, authorized sharing users associated with the user, and the like, can be stored demographically and used to correlate users for relevant services. The user metadata may be, but is not required to be, stored demographically so as to not uniquely identify a particular user's actual identity. Similarly, digital rights management information associated with individual media files, groups of media files, individual users, groups of users, and the like, can be stored. In some embodiments, central administrative functions and modules are provided to authorize and deauthorize access to medical images and records, authorize and deauthorize users and sharing groups, authorize and deauthorize particular MIDS server/node or central server features, and the like.

[0081] As described previously, sharing users are preferably authenticated in UNIX style accounts and groups on the computer associated with the MIDS server/node 100 to which each sharing user has access. Sharing user security can be handled MIDS on each MIDS server/node or centrally on the central server via central server login and redirection to the target MIDS server/node via correlated technical network address for that MIDS server/node, as described previously.

[0082] After an original medical image file is converted to the universal media format, the medical image metadata is modified to include a MIDS player in a standardized software format such as, for example, Javascript, a variant of the Java(TM) programming language created by Sun Laboratories(TM). Upon a successful authorized request for the medical image file from a remote user via the remote user's clicking of a link or selection of the medical image in a standard web browser such as those provided by Microsoft(TM) Corporation as Internet Explorer(TM), The Mozilla Corporation(TM) as Firefox(TM), Opera Inc. as Opera(TM), and the like, the MIDS server/node 100 transmits the medical image file in a series of standard HTTP format transactions to the remote user's computer over the network. Upon receipt of the beginning of the medical image file at the remote user's computer, the MIDS player is received and executed by the receiving standard web browser without any further installation of software, codecs, or media players by the remote user. The MIDS player then handles further communication between the remote user's web browser and the computer and MIDS server/node sending the requested medical image file over the network. In this manner, medical image files may be readily shared with authorized users over a network without requiring a multitude of media formats, media players, media codecs, and the like.

[0083] Further, the system can be adopted for health care enterprise uses, including multi- location conferencing, multi-location file sharing and file distribution with controlled user access, and via the use of customized plug-ins, specialized multi-location and multi-user file storage, sharing, group authoring, and database software uses.

[0084] In one embodiment of the present invention, the various aspects of the system described above may be adopted to create a Medical Imaging Distribution System (MIDS) that distributes medical imaging information and enables medical professionals to easily share and view any medical image, anytime, anywhere on any computer, without the need for special software. Using a proprietary method for losslessly compressing medical images, users such as physicians may view images with the visual integrity intact. The MIDS utilizes the various aspects of the above-described system to convert any medical image file format to a multitude of universal file formats that may be readily viewed on any computer without the need for special software. Thus, the MIDS can concurrently create, in real time, multiple universal file formats that vary in format, bit rate and resolution. The streamed medical image files are aided by a performance-enhancing network of nodes that are collectively optimized and geographically dispersed to swiftly deliver media files to distant users. The network of nodes assists in routing packets more efficiently by allowing for continuous connections and reconfiguration around broken or blocked paths by hopping from node to node until the destination is reached.

[0085] Some capabilities provided by the MIDS are as follows: [0086] - Upload every medical image on digital media such as a CD to the MIDS with a few, often one, simple operations.

[0087] - Compress giant medical images for quick delivery.

[0088] - Compress any medical images to manageable files for instantaneous viewing.

[0089] - Transcode medical image files to any universal streaming media format and/or proprietary format that may be viewed on a computer or mobile device.

[0090] - Stream medical images to anywhere in the world.

[0091] - View high-quality, time-sensitive patient medical images on-demand.

[0092] - Operates with medical image files containing such information as echocardiograms, angiograms, ultrasounds, CT scans, MRIs and X-rays.

[0093] - Readily share medical images with in-network doctors, out-of-network doctors, hospitals, insurance companies, patients and any other authorized parties.

[0094] - Ensure the accurate and consistent display of all types of medical images across various operating systems.

[0095] - Allow the exchange of medical images among different medical imaging systems and file formats, enabling the review of images acquired and processed elsewhere.

[0096] - Access on-demand medical images from anywhere, including any Internet- enabled device.

[0097] - Archive medical images for 24/7 access.

[0098] - Archive and retrieve images with easy-to-use thumbnail recognition.

[0099] - 24/7 Web-based application that includes a performance-enhancing optional thin client.

[00100] The MIDS may be used for the organ transplant market, including such organizations such as transplant centers and OPOs; hospitals with transplant-centers; hospitals without transplant centers; diagnostic imaging centers; and major health insurance companies.

[00101] In operation, the MIDS receives, as inputs, proprietary medical images and outputs

Medical Image Object (MlOb) files that may be stored in one or more databases in the MIDS. Upon receiving a user request to view images, the MlOb file is converted by the MIDS to a universal file format that is native to the requesting medical professional's computer hardware and software. This means the user can immediately view patient medical images in an Internet browser without the need for proprietary medical imaging software. As a medical professional requests the medical image, the MIDS solution delivers a medical image that has a minimum of a 3: 1 compression ratio, while maintaining the image's diagnostic usefulness. The MIDS allows the avoidance of distributing the entire, data-rich image file across the network each time a healthcare professional wants to access the image, thus resulting in a dramatic reduction in the impact to network infrastructure and the amount of bandwidth consumed. This advanced technology solution delivers diagnostic and non-diagnostic quality medical images over the Internet to thousands of concurrent users, using standard computer equipment, without compromising speed or image quality.

[00102] Five components of the MIDS that enable any medical professional to view any medical image, any time, any place on any computer, without requiring proprietary software will now be described, including:

[00103] - A lattice network

[00104] - Compression technologies

[00105] - An MlOb file format

[00106] - Database

[00107] - A transcoding engine

[00108] In order to deliver medical images across any terrain or network structure in less than a short period of time, such as 30 seconds, a smart network infrastructure referred to as a "lattice network" harnesses grid network computing's processing power and the fast delivery of a mesh network, which allows for continuous connections and reconfiguration around broken or blocked paths by "hopping" from one node to another until the destination is reached.

[00109] The MIDS is constructed on a technology platform that distributes medical images and records over any Wide Area Network (WAN) or Local Area Network (LAN), including Mesh and Grid Networks. A mesh network structure enables fast communication across hosts by lowering the physical and logical distance between nodes (consumers' computers) in the network. A grid network is the compilation of individual systems. In most cases these systems are often based on standard machines and operating systems. The network used in the present invention is neither a mesh network nor a grid network solely. In one embodiment of the present invention, the network utilizes various aspects of both networking technology approaches, and is herein after referred to as a "Lattice Network".

[00110] FIGs. 12 and 14 illustrates the various components and steps for implementing an

MIDS 1400, as configured in accordance with one embodiment of the present invention. In FIG. 12, medical imaging information 1212 is located at a client 1410. The medical imaging information 1212 may include such information as magnetic resonance imaging (MRI), echocardiography, angiography, computed tomography (CT), and X-ray that is generated by a medical imager 1412 and may be stored on a CD or other digital media in any one of a multitude of formats normally used to store such medical images or studies. These typically include files such as raw image files created by a medical imaging device, text files, and, if the recipient does not possess the application for viewing the raw files, application files that need to be installed on a recipient's computer.

[00111] In at 1216, the medical imaging information 1212 is uploaded. Performing a medical image upload has typically been a cumbersome and bandwidth intensive process. Most uploading mechanisms depended on binary data to be sent from a personal computer to a remote system; a process that had not changed much since the implementation of dial-up access in the 1970's. If the medical imaging information 1212 is stored on a CD or otherwise not compressed, these files are compressed using Z-modem protocol, which typically achieves a compression reduction of only 6%-8%.

[00112] In one embodiment of the present invention, a One-Click Uploader (OCU) 1414 is utilized to transfer medical images from one location to another. The OCU processes the medical image information 1212 at the client 1410 and sends a universally convertible file format, referred to as an MI Ob file 1214, to the server. The MI Ob file 1214 is used to store one or more raw images and associated files from the medical image information 1212 in a compressed format. Novel compression technologies are used to compress the medical image information 1212 to create the MlOb file 1214 to offer a more efficient approach of uploading. These compression technologies are designed to reduce a medical image's file size anywhere from a 2: 1 ratio to as much as a 80: 1 ratio, with the final output to the user being a diagnostic and non-diagnostic quality medical image that may be swiftly streamed. As a result, the MlOb file 1214 contains far less data than the original medical image information 1212 upon which it is based, yet preserves all of the details of the original. Because of the reduced file size, hard drive storage requirements are reduced by up to as much as 95%. Furthermore, as described herein, the MlOb file 1214 provides versatility in that it may be converted to and/or from any proprietary format. In another embodiment, if an MI Ob file is not generated for the medical imaging information 1212 on the client, it may be created by an application on the server once the medical image files are uploaded, as described herein.

[00113] An exemplary process 1300 for the creation of the MlOb file 1214 is illustrated in

FIG. 13, where at 1302, an image or a frame image sequence may be extracted from the medical image information 1212. In one embodiment, videos or images such as DCM, AVI, or JPG may be read into memory. In the case where the input is a video, a frame image sequence is created from the video before each single frame image from the sequence is read into memory. Further, a break code such as a unique character is added to the data in the MI Ob file 1214 to delineate each single frame image, and the coding process described herein is continued again with the next frame image until all frame images are processed. In the description that follows, it is assumed that a single image is being processed.

[00114] At 1304, data for a single image is read into memory for processing.

[00115] At 1306, the creation of the MlOb file 1214 is based on the generation of a text- based pixel map location (PML) using a PML module 1414A. The PML operation allows for faster transmission of data than the conventional data stream associated with current upload methods. For instance, a CT slice, in its DICOM formatted file size with compression, may be 614,400 kilobytes (kB). Creating a PML-formatted file, the size of the same CT slice may only be 16,384 kB without compression.

[00116] Currently, each DICOM image coming from a third-party imaging source to the network is still in an uncompressed version. When signed and countersigned, the DICOM image is compressed using predefined quantization matrices for precisely this CT. To begin with, quantization matrices for DICOM medical imaging file formats are designed to keep certain frequencies in the source to limit noticeable loss of image quality, and are used conservatively by current PACS confirming systems to ensure that medical professionals feel comfortable with the quality of the archived images. The reason that the quantization matrix for medical imaging is feasible lies in the JPEG algorithm or derivatives thereof. Once a given quantization matrix is selected, what results is a compromise between image quality loss and file compression. This compromise is required because without it the original medical imaging file sizes would be too large to store en masse on a network archive. The decision to agree to an acceptable level of image quality loss due to compression is based on the practical business limitations (costs, etc.) associated with medical image file storage. The purpose of the PML operation is to maintain the data integrity of each medical image as it was originally captured from the third-party imaging source.

[00117] In one embodiment, the PML operation is a hybrid pixel detection process specifically designed for medical image transmission (upload, download or stream). The common pixel detection in today's marketplace is a method of determining the Red, Green, Blue (RGB) values of a single pixel in an image, which is known as a Specific Pixel Key (SPK), and assigning multiple values to that SPK. The PML operation described herein is unique because it processes the RGB of a single pixel and assigns only a single value to a SPK by utilizing a Pixel Map Collision (PMC) approach. The PMC approach determines any change in RGB values as the process moves from one pixel to the next in a given medical image row, column, diagonal, or any other discernable patterns.

[00118] It should be noted that although RBG values are used in the examples, any pixel value such as color, brightness, intensity, hue, saturation, luminosity or any other measurement of a pixel may be used. Further, as described below, other patterns may be detected in the processing of the MI Ob file 14.

[00119] In one embodiment, the PMC approach is performed by overlaying a pixel grid on the single image data from the operation at 1304. In the exemplary approach, a lxl pixel grid is used. A first pixel (x) is stored. Then, the next pixel (y) is read and validated by comparing it to x. If the value of y equals the value of x then a counter variable (cnt) is increased by one (1). If the value of y is not equal to x then the cnt value is recorded with the value of x into a MlOb container, which is a flat file in one embodiment of the present invention.

[00120] For instance, if a single row of pixels in a medical image contains the RGB value of zero (0), which is the color black, the PMC is null or not a value, meaning that no pixel color collisions were detected because the entire row is one color. Traditional pixel detection reports every pixel in this row with an RGB value of zero (0,0,0) and it does so 512 times (assuming the image size is 512x512). This is the equivalent of 1,536 bytes for that specific row.

[00121] In contrast, the PML abbreviates the same data as 0:0:0:0:0:511 (row, r, g, b, start, stop) equaling 13 bytes for its SPK. Continuing the use of the color black as an example, if rows 1 - 50 are all the same color, the traditional pixel detection method reports rows 1 - 50 using a total of 76,800 bytes of data. The PML abbreviates the same data to 650 bytes, making the transmission of 50 rows of data significantly smaller and less bandwidth intensive while maintaining 1-to-l pixel quality.

[00122] Now taking the same scenario and, in another example, assigning the first 50 rows the color white, which has the RGB value of 255,255,255, traditional pixel detection reports every pixel in this row with an RGB value of 255 (255,255,255) and it does so 512 times (assuming the image size is 512x512) in each row. This is the equivalent of 4,608 bytes for that specific row.

[00123] The PML abbreviates the same data as 0:255:255:255:0:511 (row, r, g, b, start, stop) equaling 19 bytes for an SPK. Continuing to use the color white as an example, if rows 1 - 50 are all the same color, the traditional pixel detection method reports rows 1 - 50 using a total of 230,400 bytes of data. The PML abbreviates the same data to 950 bytes, making the transmission of 50 rows of data significantly smaller and less bandwidth intensive while maintaining 1-to-l pixel quality.

[00124] As stated above, under the pixel map detection process, a single CT slice generally is 512 pixels in width and 512 pixels in height (512x512). Each pixel has a specific color assigned. Each pixel value may range from one (1) bit to three (3) bits. Since there are eight (8) bits per byte, one (1) pixel of a medical image may be as large as twenty four (24) bits, which equal three (3) bytes for a single pixel. A CT slice size can be as large as 2,359,296 bytes (2.39 MB) for a 512x512 medical image. Utilizing the PML, the same CT slice's file size may be reduced to 9,728 bytes without compression while maintaining zero image quality loss within every pixel within a PML array.

[00125] Without conservative, predefined quantization matrices, it is close to impossible to store massive amounts of medical imaging data on a networked archive. The compromise found in traditional medical settings is required because without it the original medical imaging file sizes would be too large to store en masse on a network archive. The decision to agree to an acceptable level of image quality loss due to compression is based on practical business limitations associated with medical image file storage. The PML is created to maintain the data integrity of each medical image as it was originally captured from the third- party imaging source. At 1308, a Pixel Map Redundancy Extraction (PMRE) operation performed by a PMRE module 1414B is further used to reduce the file size to benefit storage capacity, speed of transmission, and transport, without compromising image quality.

[00126] Using the example from the PML operation section above where all pixels are white, the PMRE operation identifies redundancies and patterns in the PML array. Instead of having 50 rows with 512 instances of "255, 255, 255" in each row, which takes 230,500 bytes, the PML data is comprised of 50 rows of the same data; namely, "255:255:255:0:511", which is only 950 bytes.

[00127] The PMRE operation may further be used to shorten these rows into a single SPK, due to the rows all being one color, representing all 50 rows by an additional array value. In one embodiment, the additional array value includes a row counter, which for this example is 0:49:255:255:255:0:511 (row start, row end, R, G, B, start, stop), making the new PML array twenty-two (22) bytes without compression.

[00128] An array is a data type that is meant to describe a collection of elements, whether they are values or variables. Given that both results from the PML and PMRE operations are from array-type calculations, each selected by one or more indices may be computed at run time by a program. This array can be stored in a file such as the MI Ob file 1214. In one embodiment, the MI Ob file 1214 is generated by a MlOb generator 1414C and includes a structure that contains the following information for each original file:

A hash value of the original file;

A error-detecting code of the original

File name of the original file;

Metadata of the original file; and

PMRE and/or PML Array output;

[00134] where the hash value may be determined using a message-digest (MD) algorithm such as the

MD5 cryptographic hash function; and the error-detecting code may be determined using a cyclic redundancy check (CRC). The MIOB file 1214 may be transmitted to any remote computer, burned onto disk, stored on a flash drive and even stored in any database as a plain text entry.

[00135] In one embodiment, the data in the MIOB file 1214 is arranged in a maximum of 32 row arrays. These arrays typically have numeric patterns. At 1312, a MlOb Redundancy Removal Module (mbRM) 1428 is used to identify these patterns and assign the newly identified patterns a specific new value. In one embodiment, the redundancy removal operation is performed at the server 1420 because of the hardware at the server 1420 will generally be more suited for performing this operation than the hardware at the client 1410. After a first pass, in one embodiment of the present invention, the mbRM operation may be performed again. The mbRM operation may be performed multiple times, on different levels (extracting newly-created redundancies) on the MlOb data, to optimize storage and transmission.

[00136] In one embodiment, a unique identifier referred to as a generated unique identifier

(GUID) for the MIOB file 1214 may be generated by the server 1420 at the mbRM module 1428 in which the MI Ob file 1214 will be stored. The GUID may also be generated at the file ID generator 1424. The identifier is unique to the owner of the file and allows all nodes in the system to determine at which facility, what node, and other relevant identification information. The GUID generation ensures that in the event the MI Ob file 1214 is copied or moved without authority, it will not be compatible with any other system.

[00137] In one embodiment, the GUID includes information about how many times each operation (e.g., PML, PMRE, mbRM) has been performed. This information allows the system to determine how many times a particular operation needs to be reversed to obtain the original MlOb file. The information may hashed with a unique number to generate the GUID, appended as part of the GUID, or otherwise included with the GUID. Logically, the information about how many times each compression operation is performed is stored after the mbRM operation as that is the last operation to be performed on the MI Ob file 1214.

[00138] At 1222, a file receiver 1422 at the upload server 1420 determines if all files are intact upon receipt. In one embodiment of the present invention, this is achieved using any one of a plurality of standard CRC and checksum verification methods. This includes using any hash values and/or error-detecting codes placed in the MIOB file 1214 by the MI Ob generator 1414C.

[00139] At 1224, each received file is identified by the server reading each received file and then creating a proprietary fingerprint for that file using a file ID generator 1424. In one embodiment of the present invention, the fingerprinting process allows the removal of executable files, duplicate files (as described below), and any other unwanted files. Thus, the MIDS 1400 may only keep files that contain medical imaging-related information (e.g., multimedia files, and text files related to the medical imaging studies). Further, the files may be filtered by one or more predetermined criteria, which include criteria as selected by the upload facility or original file format. For example, certain hospitals may only want to keep DICOM files.

[00140] At 1226, in the case where the MlOb has not been created previously, such as at

1216, an MI Ob file is created by a server-side MlOb generator 1426, in which a first level of redundancy may be removed just as if non-MIOb files were uploaded at 1216. The MI Ob file that is created contains the same contents as if the MI Ob file 1214 was created at the up loader 1414 on the client 1410. Specifically, for example, the server-side MlOb generator 1426 performs the same operations as the PML module 1414A, the PMRE module 1414B, and the MlOb generator 1414C. If an MlOb file such as the MlOb file 1214 was uploaded originally atl216, then this operation is skipped. The server-side MlOb generator 1426 thus allows medical imaging information to be converted locally at the upload server 1420 to MlOb files to allow maximum flexibility in the source and processing of medical imaging information.

[00141] At 1228, other levels of redundancy are removed using the mbRM 1428 as described such that the data inside the MI Ob file 1214 is processed to remove further levels of redundancy in the data as described herein. This would be desirable to further compress the MIOb file 1214.

[00142] At 1250, the MlOb file 1214 is stored in one or more databases on a database server

1450. In one embodiment of the present invention, a universal link to access the medical images is also created at this step for use in accessing the medical imaging information. It should be noted that although multiple servers are described herein, as few as one server may be used to implement the MIDS 1400. Conversely, there should be no limitation as to the number of servers that may be used to implement any of the procedures, operations or functions described herein.

[00143] A user may attempt to view the medical imaging information contained in the database server 1450 at 1282 using the client 1410. As a part of the security measures to ensure no unauthorized access to the medical imaging information exists, at 1284 the MIDS 1400 will verify that an SSL connection exists. The data module 1406 retrieves information about the user and the client 1410, including location information, user identification information, and any other information necessary for security and other purposes as described herein. The MIDS 1400 will validate the user's request for resources at 1286 using an examiner 1486. In one embodiment, the MIDS 1400 will examine and confirm that the user has rights to access medical image information on any server or node available in the system using the examiner 1486. The examiner 1486 may be use whitelists/blacklists of servers, nodes, locations, users or any other suitable criteria, either individually, by groups, or by one or more other parameters. For example, multiple servers or nodes may have the requested information, but the user may only be allowed access to a subset of those servers or nodes. In one embodiment, only a single server or node is used, and thus the medical imaging information will come from one source.

[00144] On the server 1460, at 1288 the user will be authenticated via a login process using an authenticator 1488 that creates an audit trail of any access by the user or any attempted access by non-authorized users. During this login process, a catalog look-up at 1290 will be performed on a catalog using a cataloger 1490, where in one embodiment the catalog is stored on the database server 1450 and may contains permissions as to what the user is able to access as well as other rights the user has been granted or, conversely, denied.

[00145] Once the user has been authenticated and when an image is to be viewed, a re- authentication process occurs at 1262, which is a background operation performed by a re- authenticator 1462 to determine such conditions as if the SSL link is still up, and the user is still in the original location. Once this has occurred successfully, a transcoding at 1264 will occur, where the authentication server 1460 reads the MlOb file from the database server 1450 and creates a stream for the client 1410 using a streamer 1464.

[00146] To revert the MlOb file 1214 back to its original form, in one embodiment of the present invention the sequence of events described in FIG. 13 will occur in reverse on the same server the key was generated. The output into memory will be an image that may be converted or outputted into any other file format directly from memory—eliminating the need for cache or temporary files to be written. Additionally, the MlOb file 1214 will be losslessly restored to its original file format, thus maintaining image & file integrity.

[00147] A transcoder engine 1464 that may be implemented using transcoding technology described herein, converts an MlOb file to any number of universal file formats such as Flash, QuickTime, Windows Media, 3GP, and MPEG. The transcoder engine 1464 determines, on-the-fly, what universal file format will best play on the user's computer and then converts the MlOb file to the optimal universal file format as it begins to stream the medical images. During the transcoding operation, a bandwidth analysis occurs at 1266 using a bandwidth analyzer 1466 that determines how much bandwidth is available to a requestor. An operating system (OS) determination also occurs at 1268 using an OS analyzer 1468 that examines which OS the client 1410 is running. The operations at 1266 and 1268 are used by the streamer 1470 to determine how to construct the stream provided to it from the transcoder engine 1464. Then, at 1270, the streamer 1470 and creates a stream from the MI Ob file in a format and rate that is suitable for the client 1410.

[00148] Although the invention herein has been described with reference to particular embodiments, it is to be understood that these embodiments are merely illustrative of the principles and applications of the present invention. It is therefore to be understood that numerous modifications may be made to the illustrative embodiments and that other arrangements may be devised without departing from the spirit and scope of the present invention as defined by the appended claims.

[00149] While several forms of the present invention have been illustrated and described, it will also be apparent that various modifications may be made without departing from the spirit and scope of the invention.

[00150] Various aspects described herein may be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques. The term "article of manufacture" as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media. For example, computer readable media may include, but are not limited to, non-transitory media such as magnetic storage devices, optical disks, digital versatile disk, smart cards, and flash memory devices.

[00151] The disclosure is not intended to be limited to the preferred aspects. Furthermore, those skilled in the art should recognize that the method and apparatus aspects described herein may be implemented in a variety of ways, including implementations in hardware, software, firmware, or various combinations thereof. Examples of such hardware may include ASICs, Field Programmable Gate Arrays, general-purpose processors, DSPs, and/or other circuitry. Software and/or firmware implementations of the disclosure may be implemented via any combination of programming languages, including Java, C, C++, MatlabTM, Verilog, VHDL, and/or processor specific machine and assembly languages.

[00152] Those of skill would further appreciate that the various illustrative logical blocks, modules, processors, means, circuits, and algorithm steps described in connection with the aspects disclosed herein may be implemented as electronic hardware (e.g., a digital implementation, an analog implementation, or a combination of the two, which may be designed using source coding or some other technique), various forms of program or design code incorporating instructions (which may be referred to herein, for convenience, as "software" or a "software module"), or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

[00153] The various illustrative logical blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented within or performed by an integrated circuit ("IC"), a server, or a client. The IC may comprise a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, electrical components, optical components, mechanical components, or any combination thereof designed to perform the functions described herein, and may execute codes or instructions that reside within the IC, outside of the IC, or both. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, a processing system including one or more microprocessors and memory, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[00154] The method and system aspects described herein merely illustrate particular aspects of the disclosure. It should be appreciated that those skilled in the art will be able to devise various arrangements, which, although not explicitly described or shown herein, embody the principles of the disclosure and are included within its scope. Furthermore, all examples and conditional language recited herein are intended to be only for pedagogical purposes to aid the reader in understanding the principles of the disclosure. This disclosure and its associated references are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and aspects of the disclosure, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future, i.e., any elements developed that perform the same function, regardless of structure.

[00155] It should be appreciated by those skilled in the art that the block diagrams herein represent conceptual views of illustrative circuitry, algorithms, and functional steps embodying principles of the disclosure. Similarly, it should be appreciated that any flow charts, flow diagrams, signal diagrams, system diagrams, codes, and the like represent various processes that may be substantially represented in computer-readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

[00156] It is understood that any specific order or hierarchy of steps described in the context of a software module is being presented to provide an examples of one or more computing systems. Based upon design preferences, it is understood that the specific order or hierarchy of steps may be rearranged while remaining within the scope of the disclosure.

[00157] As used herein, a phrase referring to "at least one of a list of items refers to any combination of those items, including single members. As an example, "at least one of: a, b, or c" is intended to cover: a, b, c, a-b, a-c, b-c, and a-b-c.

[00158] Although various aspects of the disclosure have been described as software implementations, those skilled in the art will readily appreciate that the various software modules presented throughout this disclosure may be implemented in hardware, or any combination of software and hardware. Whether these aspects are implemented in hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the disclosure.

[00159] WHAT IS CLAIMED IS:

Claims

1. A method for medical imaging distribution comprises:

receiving an image comprising a plurality of pixels arranged in at least one dimension;

determining a number of the plurality of pixels in the at least one dimension satisfying a predetermined criteria; and

outputting the number along with a location identification in the at least one dimension in a file.

2. The method of claim 1 , wherein the predetermined criterion is that two contiguous pixels in the plurality of pixels have identical pixel values.

3. The method of claim 2, wherein the pixel values comprises at least one of a color, brightness, intensity, hue, saturation, or luminosity value.

4. The method of claim 1, wherein the plurality of pixels are arranged in at least another dimension, the method further comprising

determining a second number of the plurality of pixels in the at least one dimension or the at least another dimension satisfying the predetermined criteria;

constructing an array with the number and the second number.

5. The method of claim 4, further comprising attaching a unique identifier to the array.

6. An apparatus for medical imaging distribution comprising:

a processing system comprising a processor and a memory configured to cause the processor to:

receive an image comprising a plurality of pixels arranged in at least one dimension;

determine a number of the plurality of pixels in the at least one dimension satisfying a predetermined criteria; and

output the number along with a location identification in the at least one dimension in a file.

7. An apparatus for medical imaging distribution comprises: means for receiving an image comprising a plurality of pixels arranged in at least one dimension;

means for determining a number of the plurality of pixels in the at least one dimension satisfying a predetermined criteria; and

means for outputting the number along with a location identification in the at least one dimension in a file.

8. A computer program product comprises :

a computer-readable medium comprising code executable by a processor to:

receive an image comprising a plurality of pixels arranged in at least one dimension;

determine a number of the plurality of pixels in the at least one dimension satisfying a predetermined criteria; and

output the number along with a location identification in the at least one dimension in a file.

9. A method for medical imaging distribution comprises:

receiving a file comprising information related to a plurality of pixels arranged in at least one dimension, wherein the information comprises a number of the plurality of pixels having pixel values satisfying a predetermined criteria and further comprises a location identification in the at least one dimension of the number of the plurality of pixels;

decoding the information to retrieve the number and the location identification; and constructing an image file based on the number and the location identification.

10. The method of claim 9, wherein the predetermined criterion is that two contiguous pixels in the plurality of pixels have identical pixel values.

11. The method of claim 9, where constructing the image file comprises forming at least a portion of the image file with pixels having the pixel values satisfying the predetermined criteria at a position in the at least one dimension based on the location identification.

12. An apparatus for medical imaging distribution comprising:

a processing system comprising a processor and a memory configured to cause the processor to: receive a file comprising information related to a plurality of pixels arranged in at least one dimension, wherein the information comprises a number of the plurality of pixels having pixel values satisfying a predetermined criteria and further comprises a location identification in the at least one dimension of the number of the plurality of pixels;

decode the information to retrieve the number and the location identification; and

construct an image file based on the number and the location identification.

13. An apparatus for medical imaging distribution comprises:

means for receiving a file comprising information related to a plurality of pixels arranged in at least one dimension, wherein the information comprises a number of the plurality of pixels having pixel values satisfying a predetermined criteria and further comprises a location identification in the at least one dimension of the number of the plurality of pixels;

means for decoding the information to retrieve the number and the location identification; and

means for constructing an image file based on the number and the location identification.

14. A computer program product comprises :

a computer-readable medium comprising code executable by a processor to:

receive a file comprising information related to a plurality of pixels arranged in at least one dimension, wherein the information comprises a number of the plurality of pixels having pixel values satisfying a predetermined criteria and further comprises a location identification in the at least one dimension of the number of the plurality of pixels;

decode the information to retrieve the number and the location identification; and

construct an image file based on the number and the location identification.