Remote exam viewing system

[0001] This invention relates to optical coherence tomography (OCT) and more particularly to a remote exam viewing system involving a web-enabled engine for ophthalmic exam review.

[0002] As is well known ophthalmic devices such as OCT scanners generate large volumes of proprietary data that cannot be displayed on the web and require installation of expensive custom software on a computer in order to review the results of an exam and also to be able to exercise the OCT device to provide various segmentations or views of the data.

[0003] It is true that device manufacturers provide software to review or manipulate exam data, however, at significant cost and only operating on a local area network.

[0004] This is neither convenient nor helpful to most ophthalmologists who see patients in multiple exam rooms, in more than one office and in many cases see the same patients in multiple offices. Moreover, ophthalmologists have a need to consult with referring physicians to review patient exam data. Thus the need exists for a system that can extract raw data from ophthalmic OCT devices, upload the data to a server and provide the user with the ability to review and manipulate the exam data from any web-enabled computer with the same functionality and control as the ophthalmic device itself.

[0005] More particularly, optical coherence tomography devices are computer driven so that one can operate their software to view and quantify exam data so that an individual practitioner can do an analysis of the images on the device itself. One can measure retinal thickness and change over time and do so on three dimensional diametric scans that are remotely viewed on computers connected to the same local area network so that a person who is not in the examining room is able to do various types of analysis on the exams.

[0006] In order to accomplish such a goal, manufacturers have developed remote viewing software packages that need to be installed on each computer in order to run and have to be connected to a local area network, meaning the network that exists in the same office. Moreover, such a network is often times very crowded or segmented and no attempts are made to optimize speed or connection quality between the OCT device and the viewing computer. After software has been installed and each computer has been configured properly to communicate with the OCT device, a practitioner can go to the next exam room in the same office and pull up the exam data to view it.

[0007] Some systems are currently attempting to provide wide area network WAN access to ophthalmic OCT exams. However they are primitive in nature and are “image only” displays which are lower quality and limited representations of the raw data, and in many cases are simply scanned copies of printed paper reports. They import standard image file formats such as TIF, BMP, JPG and AVI; and they display them in a web page, which is highly inefficient and occupies far more storage space than necessary. However, OCT exams contain much more data than simple images and this limits the user's ability to manipulate or analyze the exam.

[0008] As mentioned before, many manufacturers require custom software installation on each computer in order for the user to be able to use and view the images. The problem with this type of approach is that one has to have a separate piece of software for each device, and for each manufacturer; and if one wants to view them simultaneously there is no common platform available. More particularly, there is no convenient way to review a patient exam record that incorporates exams performed on two different devices.

[0009] While recent attempts have been made to create some remote viewing functionality, these fail if a doctor has one office A and then across town there is an office B. This is because both offices are not on the same local network and one would need some sort of web-enabled remote viewing package such as Logmein or TightVNC.

[0010] The problem with remote viewing packages such as TightVNC, Logmein, and other remote viewing packages is that they provide very limited functionality and display of the data. Moreover, there are certain bottlenecks to the use of standard web-enabled viewers.

[0011] If one is simply interested in remote viewing and control via virtual control of a computer, if for instance a doctor is in Office A and wants to see an exam in Office B, he would have to make sure that no one else is using the device in Office B or else he would have to wait until the user finishes. Thus one of the problems remote viewing is multiple users.

[0012] The second problem with web-enabled remote viewers is the low quality of the images on the screen. The reason for this is that present remote viewing packages usable on the web use compression to speed up the transmission of the data in order to be able to see the changes on the screen. However, these compression techniques operate in color space due to the high color depth of graphics displays, and present a noticeable reduction in the quality of the transmitted images.

[0013] Finally, there is the question of latency. Remote viewing web-enabled programs to date repaint or refresh the screen when there is a change in any part of the data being displayed. Thus latency is very high when one is refreshing the screen and drawing images. This means that the practitioner has to wait for the screen to refresh, sometimes on the order of many seconds. As will be appreciated, the more one changes the screen the more data that has to be transmitted and therefore the slower the response of the program.

[0014] It will also be appreciated that not only is remote viewing desirable, remote manipulation of the data is also required. For instance as one wants to pick a particular segmentation, zoom in on some particular data, change a particular parameter in the basic program or in general remotely access the original device, currently there is no way in order to provide such a service.

[0015] In short, and as mentioned above, the current systems that are attempting to provide wide area network access to ophthalmic exams are either primitive, low resolution image only displays having little or no ability to manipulate and analyze an exam, or have high latency, poor image quality and introduce bottlenecks into clinic flow. As mentioned, existing systems require custom software installation on each computer, and those systems that utilize remote viewing and applications are problematic due to the lag time of transmitting the desktop images over the web. Moreover, the images that are produced are of poor quality due to compression. These systems also create a bottleneck because the user cannot review an exam while the device is in use by someone else.

[0016] In order to provide remote viewing and manipulation of ophthalmic OCT exams, a web-enabled software engine on a global server is utilized to collect, store, retrieve, view and manipulate these exams. The web-enabled engine is an instantiation or duplicate of the functionality that the OCT machine on which the exam was performed is able to provide. Remote computers and devices can access this server to both view and manipulate the data in this server in real time with the look and feel of the OCT machine duplicated by the web-enabled engine to match that of the original OCT machine. Due to the bidirectional component of the engine, various types of data, such as patient demographics and existing OCT exams can also be sent back to the OCT machine, to eliminate data entry errors and allow further processing of existing exam data.

[0017] Exam data is extracted from each OCT device and in many cases this data is raw binary data. In the subject invention extracted data is securely uploaded to the server using a secure encrypted web-enabled client program. Thereafter the server can open the extracted data, convert and process it to web-capable formats in real time, and can serve the content to numerous web connections anywhere in the world upon request.

[0018] The user can then view and manipulate the extracted exam data using web-enabled devices such as a computer, an Ipad, an android tablet, an Iphone or other such device. The user can manipulate the exam with the exact same functionality as the ophthalmic device itself using the engine's custom designed web interface screens, that communicate with the server, download all the web available exam data, and provide similar screen controls and layouts as does the ophthalmic device itself. Note that the web interfaces are developed using web-enabled technology such as HTML 5, Microsoft Silverlight, ipad/iphone apps, android apps, and the like. Note further that both OCT and patient demographic data accessible to the server can be pushed back to the ophthalmic OCT device software, either through a client program or directly to the OCT device software if it supports such features, so that it can be processed on the original ophthalmic device.

[0019] Note for purposes of the subject invention the ophthalmic device referred to is an optical coherence tomography device which, interalia, outputs raw data in the form of core data components. Such core data components can include for instance scan location coordinates, which are the coordinates in the reference image that define the location of the OCT scan. Secondly, the core data may include a reference image which is a forward facing view of the eye surface in the image, either posterior or anterior. This can be generated by numerous methods such as SLO, LSLO, video camera, photograph, enface summation algorithms and the like. It is the purpose of the reference image to provide the user with a normal looking view so the user can see the locations of the OCT scans as they correlate to the surface of the eye.

[0020] Thirdly, a core data component is the OCT scan data itself. These are the OCT cross sectional scans that show the tissue layers of the segment of the eye being imaged, in one embodiment the retina.

[0021] The next core data components are the scale factors which are conversion factors that allow anatomical measurements to be made by counting pixels in the reference image and the OCT images.

[0022] Core data components of an exam from an OCT instrument can include segmentation data. This data is obtained from automatic image processing routines that analyze the OCT scans and outline various anatomic structures, such as the layers of the retina, the layers and surfaces of the cornea, the iris, the lens, the optic nerve head, etc. Note, each OCT device performs this type of an analysis and stores the results. The results can be extracted from the OCT device and sent to the server which stores and displays the segmented data on the remote viewing device. The routines that perform these analyses can also be incorporated into the client, server or even within the remote viewing device itself.

[0023] As will be seen, there are various types of segmentation, one of which is retina layer segmentation that allows the user to view layers of the retina that are the results of the analysis. Additionally, there is optic nerve segmentation in which the shape and cupping of the optic nerve is derived from the analysis that defines the shape and cupping of the optic nerve.

[0024] There is also anterior segmentation which is the result of analysis that defines the anterior surfaces of the eye, such as the iris, the posterior lens surface and the cornea.

[0025] Finally there is normative data. Many OCT device manufacturers have compiled normative databases that correlate the thickness results of the retina layer segmentation around the optic nerve to a database of a wide array of patient samplings to determine if the results are normal or suggestive of disease.

[0026] While the above are examples of various segmentations available from some OCT devices, every device has its unique variation of what they can detect and present. The subject system accommodates all of the variations and can provide quality visuals for common exam parameters regardless of machine differences, with the presentations for the subject system being customizable to various different manufacturers and the OCT devices.

[0027] Thus, in order to provide remote exam viewing and manipulation, the first step is extracting all the useful information that resides within the exam within the OCT device so that one can create that functionality within the web-enabled engine. Secondly, once that data is extracted, the subject invention provides means to transport it across the web securely to a server. Then after the exam resides in the server the system provides a web service that will convert the data and process it into a web format so that it can be transmitted worldwide using a communication scheme involving web browsers or web-enabled applications that are able to display the required exam data and offer the functionality of the OCT device itself.

[0028] Rather than using remote control software, the subject system has much better resolution and much lower latency because in the subject system one is not operating the OCT device itself and transmitting a screen every time it updates.

[0029] In the subject system one is actually copying the data, namely the exam, off the OCT machine onto a server and then transmitting that data in its full quality to the web-enabled application that is trying to view the exam.

[0030] It will be appreciated most internet connections provide sufficient bandwidths to provide real time viewing and manipulation. Presently the average connection speed is more than adequate so that transmission speeds from 256 Kb/sec to 40 Mb/sec are clearly sufficient for the subject processes. Note also that one can apply various compression algorithms to the images to provide either a lossy or lossless image format, such as jpeg or jpeg2000 to balance image purity and transmission speed to fine-tune the performance based on the quality of the connection.

[0031] In the subject system the type of compression utilized does not resort to compressing a full color image, but rather is a compression scheme that is targeted towards the monochromatic data that the OCT machines output. When dealing with monochromatic data one is dealing with a much smaller data set, whereas, with color one has three times the amount of information.

[0032] Note also that the subject system is bidirectional so that bidirectional communication is established between the OCT device, the server, and the remote viewing application.

[0033] In operation, if one is looking at the OCT scans on a reference image, all the information is transferred when the exam is opened and one can simply scroll through this data and perform the viewing functionality without requiring any more data. Alternatively, the subject system can be implemented to transfer the OCT scans one at a time, as they are accessed by the user.

[0034] However, if the practitioner wishes to see some segmentation data or some thickness contour maps that are generated on the server and then transmitted to the web-enabled viewer program, the viewer permits the user to control what is displayed, for instance a thickness contour map. The user may also be provided with an icon to click on that requests the information from the server. Note that the server generates the requested information by processing image and or numerical data and sending it to the remote viewing device that the data is to be displayed on. It should also be noted that the routines that generate this information can alternatively be implemented into several other parts of the engine, such as in the client, during the importing to the server, during the exporting to the viewer, or even in the viewing application itself.

[0035] It will be noted that the subject system can handle a wide variety of machines due the fact that there is a necessary commonality between the data that the practitioners want to view and manipulate and that which is available from an OCT machine.

[0036] The core data captures this commonality which permits viewing of all types of data including reference images and location as to where on the eye the OCT data corresponds. There is also volume block capability or a different series of protocols so that the practitioner can correlate the OCT scan to the reference image.

[0037] The OCT output may be a B-scan or series of B-scans, with these B-scans corresponding to the positions marked on the retina. Note that B-scans are very common across all OCT platforms.

[0038] As mentioned above in addition to the B-scans, segmentation permits viewing and measuring of different layers of the retina. For instance OCT devices provide some sort of analysis which essentially tells the practitioner where the top of the retina is, where the bottom is, and as many layers as can be distinguished therebetween. These machines can also display individual layers on the screen and can present a B-scan that is selected along with a graphic display that presents to the practitioner the thickness of the layers so that the practitioner can see if the retina is a normal, healthy thickness or if it is thinning, thickening, or has some pathology in it.

[0039] Another way to provide remote viewing of the OCT scan is to actually store the data extracted from the device in the same format that is used by the OCT device itself The system therefore stores the data in a raw data file format that duplicates the raw data format file of the OCT device, with this raw data file in the server used to create the remote images.

[0040] The purpose of the subject system is to duplicate what practitioners are used to seeing on a given device and to do so on a remote web-enabled device, as well as giving the practitioner the same controls and the same data as the original machine.

[0041] Moreover, the subject system permits remote comparison of exams taken at different times. This is possible because there is a common database and imaging platform. For instance, the first item that the practitioner may see when he walks into an exam room on a remote viewing station is a list of patients. The practitioner can then select a particular patient and get a corresponding list of every imaging modality that the patient has had, namely their whole imaging history.

[0042] The practitioner then can select for instance two different OCT exam records and the system will tell the doctor whether one exam is performed on for instance a Heidelberg Spectral machine or on for instance on a Zeiss Cirrus machine. It is important to note that the subject system enables to practitioner to select each exam and view them through the same piece of software, namely that which is communicating with the server. It also permits the practitioner to align one exam with the other so that one can have a comparative multiview of OCT data for the exact same region of the eye. The multiview can for instance be one window having the current exam on the top and a previous exam on the bottom so that the practitioner can compare the scans. The difference between the two exams can be presented in multiple ways, such as a topographic display showing the change in thickness over time.

[0043] One can also compare thickness graphs from various machines and various exams by plotting the difference between the segmentation layers to end up with a chart or a plot in millimeters.

[0044] So thus, while the data may be acquired from different devices and at different times the measurements are the same so that all the data corresponds.

[0045] In summary the major advantage of the subject system is to give the user the ability to review and manipulate the dense data sets anywhere in the world with ease. One can be at a conference or in a hotel room and can even present the data and manipulate the data from an ipad. One can view and manipulate the data from home or another office.

[0046] Another advantage for instance is the ability to present the data to a general ophthalmologist who is referring a patient so a specialist can perform the exam and actually allow the general ophthalmologist the ability to log onto the system and review the exam with the specialist without the need for expensive specialized software. This introduces a telemedicine component in which doctors can share the exam data for a common patient.

[0047] Moreover the practitioner can control how the data is presented to him regardless of the manufacturer of the OCT device. If for instance a practitioner prefers the look and feel of a particular OCT machine they can select the presentation they like regardless of the machine on which the exam was actually performed. Thus, one can take the Zeiss Cirrus data to make its presentation look exactly like the Heidelberg output simply by remote commands.

[0048] Because there is no specialized proprietary software for each machine the expense of the subject system is much less than those employing a local area network and specialized software for each computer. Also there are no multiuser bottlenecks because of the utilization of the web and its multiuser capabilities.

[0069] Referring now to FIG. 1, an OCT device 10 is utilized to scan the eye of an individual 12, with OCT 10 outputting on a display 14 the results of the OCT scan. The raw data generated by the device is outputted at 16 and is then coupled via connection 18 to the web 20 where it is coupled to a server 22 that takes the raw data, stores it and stands ready to receive download requests from web-enabled devices such as a computer 23 at a separate office, a laptop 24, a Smart phone 26, a tablet 28 or a computer driven wall display 30 in a lecture room 32.

[0070] It is the purpose of the subject invention to enable a user 34 at a conference to be able to access the stored data in server 22 so as to be able to view and manipulate the results of an OCT exam, here shown at 36, which corresponds to the data shown in display 14 that is the direct output of OCT device 10.

[0071] It is also the purpose of the subject invention to provide user 34 with an input device for selecting what data in server 22 he or she wishes to see presented on his or her screen. This provides the remote user with the ability to access the results of an OCT scan in real time and to be able to control and manipulate what it is that he or she is seeing on his or her screen. It is the purpose of the subject system to be able to provide high quality OCT images and data on the remote screen in real time and to be able to manipulate the data in real time so as to provide real time renderings at the remote location, with the renderings being of extremely high resolution and quality. These renderings are also provided in real time due to the fact that the entire screen is not being transmitted across the web from another machine. Referring to FIG. 2 the OCT device 10 of FIG. 1 is shown having a display 12 in which the device 10 is populated with patient exam data 40. This exam data is presented on display 12, but more importantly is routed to a communication web service 42 in which OCT device 10 imports and exports data through a routine 44 that is incorporated into the OCT device software which passes the data in one embodiment as a native output format from device 10. There is also an ability to utilize custom developed import/export routines 46 to extract native raw data in the absence of routine 44 so that the full functionality of the ophthalmic device may be exercised.

[0072] The output of the communication web service 42 is connected in a bidirectional manner as illustrated by double ended arrow 48 over the web 50 to a web server 52 which includes import/export web services 54 that couple the incoming data to a database and binary storage unit 56 which is coupled in a bidirectional fashion as illustrated by arrow 58 to web services 64, which then processes and converts the data as necessary and distributes the output of the web server as illustrated by bidirectional web communication arrow 66 to a web enabled device 68 that may be any one of the devices 24, 26 and 28 described in connection with FIG. 1.

[0073] Each of the web enabled devices has a web enabled interface screen 70 including mobile applications and browser pages. The result is that the web enabled device is able to display on a screen 72 a duplicate of what is displayed by the ophthalmic device itself, namely screen 12. Thus in one embodiment the high quality data displayed at screen 12 is available at the web enabled device in exactly the same quality because it is pushed from a web enabled server that contains all of the OCT data.

[0074] Likewise when a user wishes to query the web server, the rendering of the result of the query is done in real time without any latency due to the fact that the screen need not be retransmitted over the web with every command. Also as noted before, since monochromatic images are output from the ophthalmic device and transmitted across the web, compressing color snapshots of the entire desktop screen is avoided.

[0075] Referring to FIG. 3, assuming that one has an OCT₁ device 74 manufactured by one manufacturer, and an OCT₂ device 76 manufactured by another manufacturer; and further assuming that each of these devices can output either raw data or web formatted raw data on respective links 78 and 80 across the web 82 to server 84, then, when queried from a remote web enabled device 86 over the internet 82 to server 84 a display 88 at the web enabled device 86 can be made to display either that which is originally presented by for instance the first OCT device, or in a different format as shown at 88¹ what would be available from a second OCT device manufactured by another manufacturer.

[0076] In short, since all of the raw data is stored at server 84 and since this data may be manipulated to provide various screens under the control of the web enabled device, then it is possible to display at the remote location either the format of the original machine, or the format of another machine.

[0077] What will be appreciated is that if an ophthalmic office has a number of different machines and a number of different doctors, then if a doctor wishes to see the results of an OCT exam remotely he can do so either by utilizing the format associated with the machine on which the exam was performed or can alternatively select the format of a different machine. Thus, the subject system can convert the raw data from one machine format to another machine format under the remote control of the practitioner so that the practitioner can view the results of the OCT exam in a format that he or she is familiar with, regardless of the type of machine that actually performed the exam.

[0078] Referring to FIG. 4, in which identical units have like reference characters, it can be seen that if the output of a particular OCT machine is not web enabled, the machine may be provided with a specialized client program 88 or 90 so that the raw data can be extracted from the machine and may be processed or converted prior to its being uploaded onto server 84.

[0079] Referring to FIG. 5, as discussed, some core data components of an OCT exam are common across all OCT device manufacturers. For instance as illustrated at 100 a reference image 102 is shown which is utilized by practitioners to be able to reference OCT data to an image of an eye that has either previously been taken, or has been constructed from the OCT scan data. As illustrated at 104 scan location coordinates may be placed on top of the reference image, with these coordinates defining the location of the OCT scans themselves.

[0080] Note that the reference image may be a forward facing view of the eye surface, being imaged either posteriorly or anteriorly, with this image having been generated conventionally to provide the user with a normal looking view so that the locations of the OCT scans can be seen as they correlate to the surface of the eye.

[0081] Display 100 can also display scan data as illustrated at 106 which shows cross-sectional scans of a retina to display tissue layers of the segment of the eye being imaged.

[0082] Referring to FIG. 6, the core data from virtually every OCT instrument or device includes segmentation data obtained from automatic image processing routines that analyze the OCT scans and outline various anatomic structures such as the layers of the retina, layers of the cornea, the iris, the lens, the optic nerve head, etc. It is the segmentation data which may be called up from the remote location.

[0083] For instance as shown in FIG. 6 a retinal layer segmentation can be called up which is the result of analysis that defines the layers of the retina.

[0084] As illustrated in FIG. 7 another view of the retina is shown, in which thickness values are derived from the segmentation layers and plotted as a topography map, using a color scale to indicate the thickness of the retina where the OCT scan was performed.

[0085] Referring to FIG. 8, another type of segmentation that may be called up from a remote location is from the anterior segmentation of the eye. These are the result of analysis that defines structures in the anterior segment of the eye, such as the iris, the anterior and posterior lens surfaces and the cornea.

[0086] Also core data which can be called up is the optic nerve segmentation as shown in FIG. 9 that is a result of an analysis that defines the shape and cupping of the optic nerve.

[0087] Finally as illustrated in FIG. 10, the core data components from an exam from an OCT device as illustrated in FIG. 10 may include normative data provided by many OCT device manufacturers who have compiled normative databases which for instance correlate the thickness results of a retina layer segmentation around the optic nerve to a database of a wide variety of patient samplings to determine if the results are normal or suggestive of a disease.

[0088] These presentations are oftentimes available on the machine display itself and by virtue of the subject invention may be called up remotely so that the practitioner may readily view that which he would normally view if he were in the same room and viewing the exam data from the original machine.

[0089] It will be appreciated that the practitioner at a remote location may wish to compare exam data from two different machines or data from the same subject taken at different times. The server data may be manipulated to present for instance the results of an exam at one time and then compare in a screen directly underneath the original screen the results for an exam at a later time. Moreover, the subject system may provide the exam results from the machine of one manufacturer and then compare the results to the results from a machine from a second manufacturer, in both instances presented to the remote user by screens that are one on top of the other or side by side so that the practitioner can make the comparison. Additionally, the results of layer segmentation can be subtracted from multiple exam dates to show the change in thickness of the tissue layer from one exam to the next. This change can be represented as a topography map showing the change values as a color overlay.

[0090] Referring now to FIG. 11, for import services a flowchart illustrates at 120 that the server receives incoming OCT data which is coupled to the ability to run any of the OCT analytical subroutines 121, followed by a decision block 122 that permits a path forward depending upon what format the incoming OCT exam is in. If it is already converted to a web-enabled format, it may store that format in a database as illustrated at 124. On the other hand if the format is a native format the option to store the native format is illustrated at 126, whereas the option to store in a web format is illustrated at 128. If the web format is selected, then the native data is converted to the web format as illustrated at 130, and the option 121 to provide any OCT Analytical subroutines is again available prior to being stored in the database 124. It should be noted that either or both formats can be stored. It should also be noted that comment 125 shows that the storage of the engine does not have to reside on the server itself, but rather can be an external archival system, such as PACS. In addition to receiving incoming OCT data, the import service can also receive incoming patient demographic data 127 and store it in the associated database and files to eliminate the need for users to type in the patient demographic data to start an exam. Comment 129 also shows that this demographic data can come from a data source internal to the engine, or from another source that can supply that information, such as a PACS system or electronic medical records.

[0091] Thus it will be appreciated that this import service is extremely flexible and can handle OCT data in any number of configurations and adapt its processing pipeline accordingly.

[0092] FIG. 13 shows the Convert Format subroutine, which is used to convert the OCT exam data to the web format as illustrated in 130. One may seek to extract a reference image from the native format and convert it to an image format as illustrated at 132, with the image format being any type that suits the application and provides the flexibility required to achieve good quality compression for short transmission times while not sacrificing image quality. Such an example would be jpeg, j2k, jp2 or other format. The conversion to the web format may also include the extraction of the OCT scans from the native format and converting to an image format as illustrated at 134, whereas the conversion to the web format may involve the extraction of numerical, demographic or analytical data and conversion to a web format such as XML as illustrated at 136.

[0093] This subroutine is available to numerous services on the client, server and viewer applications.

[0094] Referring now to FIG. 12, the exam data retrieve service is illustrated at 140 in which the server receives a request for OCT exam data. As illustrated at 142 the data is retrieved from the database and stored files, at which point there is a decision to be made as to whether preprocessing is needed, as illustrated at 144. If preprocessing is needed, OCT analytical process subroutines are performed at 146. It should be noted that Comment 141 shows that the exam data retrieved can either be from the engine's database, or from an external source, such as a PACS system.

[0095] If no preprocessing is involved then there is a decision made at 148 as to what format the OCT exam is stored in. If it is the web format then as illustrated at 150 reference image, OCT scans, analytic data and the like are transmitted to the requesting application via the web.

[0096] On the other hand if the OCT exam is stored in the native form as illustrated at 152 a decision is made whether to deliver it to the requesting application in the native form and supply it to process 150, thus delivering the native raw exam in its original format, or whether to convert it into a web format as illustrated at 154, at which point there is a preprocessing decision made as illustrated at 156. If the decision is no, then the unpreprocessed web formatted data is coupled to process 150. On the other hand, if preprocessing is required, OCT analytical process 146 is invoked that performs the preprocessing and then sends the preprocessed web data to process 150. It should be noted that both the native and web converted formats pass through the preprocessing decision 156 before being delivered and transmitted through 150.

[0097] Thus it will be appreciated that the stored data may be pushed out to the remote user in any one of a number of preprocessed, converted or native forms which have been selected by the practitioner.

[0098] Referring now to FIG. 14, a flowchart of the OCT Analytical Process subroutine is shown. In this routine, any number of analysis or processing can be performed on the OCT data. For example, image processing 161 can be used to remove noise from an OCT scan or enhance the contrast, Registration 162 can be used to correct for motion during a volume scan, or align volume scans from two different dates for the same patient for comparison. Segmentation 164 can be used to run segmentation algorithms to detect layers of the retina, Normative Analysis 168 can be used to determine the likelihood of a patient's nerve fiber layer thickness indicating glaucoma. Thickness Topography Map 170 can generate a topographic overlay for OCT data indicating the thickness of the patient's retina. 3D volume 172 can be used to generate a 3D volume for display from a cube of OCT B-scans. There are also empty place holders 174 for new algorithms to be inserted that may be specific to one device or another indicated by comment 176. It should be noted as in comment 163 that the subroutines in this pipeline can be run in any order, or as many or as few as are needed or desired.

[0099] It will be appreciated that this is a highly flexible subroutine to allow for all of the necessary processing flexibility needed for OCT exam data, and is also available to all parts of the engine, from client, server and viewer applications.

[0100] Referring now to FIG. 15, the Server Export Service flowchart is shown receiving a request for patient demographics at 180, and then retrieving the requested demographics at 182. It will be noted that comment 184 shows that the demographics can be retrieved from the engine's database, or from an external source such as a PACS system or electronic medical records. From there, the demographic data is supplied back to the requesting application. It should also be noted, there is another variant 188 of this service which can push demographics automatically, as they are available from 190 and also from the engines data or from an external source, as per comment 192.

[0101] It will be appreciated that this is a very flexible and adaptable configuration to supply the OCT devices with the demographic information for their patients so they do not have to enter the information manually, as well as avoiding potential errors with human data entry.

[0102] Referring now to FIG. 16, a flowchart is shown for the OCT Exam Extraction service, which is used to send and receive OCT exam data to the server. In the absence of any available routines to output the raw data from the OCT device software, the process begins at 196 by extracting raw data from the OCTs database and stored files. If the routines do exist, then the exported data is received by this service and enters the same pipeline into 198, which is a decision as to whether or not any OCT Analytics are required from the processing pipeline. After that, a decision 200 is made whether or not to send the exam to the server in a web converted or native format. If not, the data is sent out to the server on 206. If conversion is required, then a Convert Format subroutine 202 is called, and then another opportunity to run an OCT Analytical process 204 is available before sending it to the server on 206.

[0103] It will be appreciated that this extraction service is a flexible system that can be adapted to any OCT and transmit the exam data in a wide variety of formats to meet any requirements.

[0104] Referring now to FIG. 17, a flowchart for the OCT Patient Demographics Retrieval Service is shown. This service acts as a conduit to route communication for this information across the web, rather than just the local area network. OCT systems making requests for demographics are received in 210 and then routed to the web server via 212. Responses containing the demographic information from the server are received from the web on 214, and passed to the requestor on the local network via 216. A decision block 218 provides the ability to insert the demographics directly into the OCTs database 220 if it is desired and the ability to do so exists.

[0105] It will be appreciated that this conduit provides wide area network communication for a local area network feature, thus simplifying the infrastructure and reducing the cost.

[0106] Moving on to FIG. 18, a flow chart of the OCT Patient Exam Retrieval Service is shown. This is a similar conduit to that shown in FIG. 17, but passes an OCT exam rather than patient demographics. OCT systems making requests for an existing patient exam are received on 224 and routed to the server on 226. Responses containing the data are received from the web on 228, passed on to the requestor via 230, with a decision block 232 to save it directly to the OCT machine 234 if it is desired and the ability to do so exists.

[0107] It will be appreciated that this conduit provides wide area network communication for a local area network feature, thus simplifying the infrastructure and reducing the cost.

[0108] Finally, referring to FIG. 19, for the Web Browser and Mobile Viewer Application as illustrated at 238 there is a request for OCT exam data by the mobile device. The information data that is requested is sent back to the mobile application as illustrated at 240 where the requested OCT exam data is received. Again, if there is no preprocessing involved as illustrated at decision block 242 the results of received data are displayed at 246 using the graphical user interface (GUI) of the web enabled mobile application.

[0109] Also, if the preprocessing is required, then the aforementioned OCT analytical process illustrated at 244 is used make sure that the data rendered is in conformity with the requested format from the mobile application.

[0110] As the user manipulates the GUI controls 248, the system determines if the user's request requires additional information from the server in order to be fulfilled at 254, for example, the user clicks a button indicating they want to see a thickness topography overlay. If it does not, then it proceeds to the OCT Analytical subroutine at 258 to perform the requested operation that the user asked for, before displaying the data in the GUI screen 260. In the event more data is needed from the server, then a request 256 is made to the server for the necessary information. There is also the capability of issuing a command 250 to save any altered or processed data that the user may have edited or enhanced back to the server so that it can be viewed later.

[0111] In summary what is provided is a system for inputting OCT exam data into a server residing on the web which then pushes the information out in a predetermined formatted form to a web enabled device under the control of the web enabled device. Rather than trying to remotely control the original OCT device, in the subject invention the original OCT machine having been instantiated into a global server, with the stored data accessible and manipulatable directly from the remote location without loss of quality and in real time with very little if any latency so that the experience for the practitioner at the remote location will be exactly the same as if he were operating the original OCT device.

[0112] It will be appreciated that while the aforementioned examples have been explained in terms of the World Wide Web, this invention is also applicable to any internet or TCP/IP based communication scheme.

[0113] It should also be noted that although the web services and figures are described in some specific configurations, they are described as a modular series of building blocks for an engine, and can therefore be configured and mixed and matched in a number of different ways. For example, if an OCT and the server were in the same office, and not only connected by the web, then the Exam Retrieval service or the Patient Demographics service might not be necessary, and the Server Export services might communicate directly to the OCT Import Routines. The invention is intended to be highly modular and capable of being adapted and reconfigured to any scheme desired to operate with the full desired functionality.

[0114] While the present invention has been described in connection with the preferred embodiments of the various figures, it is to be understood that other similar embodiments may be used or modifications or additions may be made to the described embodiment for performing the same function of the present invention without deviating therefrom. Therefore, the present invention should not be limited to any single embodiment, but rather construed in breadth and scope in accordance with the recitation of the appended claims.