Patent Publication Number: US-2023157811-A1

Title: Systems and methods for vitreous disease severity measurement

Description:
BACKGROUND 
     The vitreous body is a hydrophilic gel located between the crystalline lens and the retina, constituting the largest volumetric component of the human eye. Healthy vitreous is optically transparent, composed mostly of water, with a low concentration of macromolecules (collagen, soluble proteins, and hyaluronan) that provide structural support to the globe and stability during rapid eye movements and strenuous physical activity. The optical transparency of the vitreous body is the result of the organization of these molecular components. In addition to providing structural support for the eye and facilitating light transmission, vitreous is important in ocular physiology as a repository for anti-oxidants and a pathway for nutrients utilized by the crystalline lens, ciliary body, and the retina. 
     With age, the vitreous undergoes fibrous degeneration and gel liquefaction, which in certain cases may lead to detachment of the vitreous from the retina in a process known as posterior vitreous detachment (PVD). Fibrous vitreous liquefaction results from molecular changes causing dissociation of collagen from hyaluronan, forming liquid vitreous and causing cross-linking of collagen fibrils into visible fibers. Other conditions that may quicken the onset of such molecular changes include myopia (nearsightedness), eye trauma, and previous cataract surgeries. 
     The formation of liquefied pockets, aggregation of collagen fibrils into larger fibers, and detachment of vitreous from the retina results in opacities in the vitreous, also known as “floaters.” Vitreous opacities may scatter light entering the eye, thus appearing as spots, shadows, cobwebs, or other assorted shapes that appear to move about in the field of vision of the patient. Vitreous opacities are one of the most common, albeit least treated, ocular conditions. Although symptoms are minimal in most patients and do not require treatment, vitreous opacities can, in certain cases, cause significant disturbances in vision, thereby impairing the vision-related quality of life (QOL) for some patients. When the severity of visual disturbance is significant, vitreous opacities may be treated with, e.g., laser vitreolysis and small-gauge vitrectomy. 
     Currently, various optical techniques are utilized to clinically characterize and grade vitreous opacities, in addition to patient self-reporting. Such optical techniques include utilization of a hand-held lens in combination with, e.g., slit illumination, to optically view the vitreous opacities. However, these techniques provide marginal and variable results, and do not provide an objective quantification of the degree of visual impairment caused by vitreous opacities, leading to inconsistent characterization and grading thereof Also, patient self-reporting is subjective and, in some cases, fails to indicate the true degree of visual impairment. As a result, it is often difficult to determine whether a patient&#39;s occurrence of vitreous opacities appropriates treatment. 
     Accordingly, what is needed in the art are improved systems and methods for determining severity of vitreous disease to inform patient suitability for treatment. 
     SUMMARY 
     According to certain embodiments, a method of determining a severity of a vitreous opacity condition is provided. The method comprises generating, using one or more diagnostic devices, one or more data points associated with measurements of physical parameters of a vitreous opacity condition of a current patient; and generating, using one or more trained machine learning models, one or more diagnostic determinations including a severity score of the vitreous opacity condition based, at least in part, on the one or more data points associated with measurements of physical parameters of the vitreous opacity condition of the current patient, wherein: the one or more trained machine learning models are trained based on at least one historical dataset, wherein each entry in the historical data set includes one more data points associated with measurements of physical parameters of a vitreous opacity condition for a historical patient mapped to a diagnostic determination associated with the historical patient, wherein: the diagnostic determination associated with the historical patient includes a severity score of the vitreous opacity condition for the historical patient, and the physical parameters of the vitreous opacity condition for the historical patient comprise one or more of a number, a size, a shape, a surface area, a relative transparency, a movement, a location, and a distance to a retina and/or a crystalline lens of one or more vitreous opacities. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       So that the manner in which the above-recited features of the present disclosure can be understood in detail, a more particular description of the disclosure, briefly summarized above, may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only exemplary embodiments and are therefore not to be considered limiting of its scope, and may admit to other equally effective embodiments. 
         FIGS.  1 A- 1 C  depict an example environment in which one or more machine learning models are trained and deployed for use in determining a severity of a patient&#39;s vitreous opacity condition, in accordance with certain aspects described herein. 
         FIG.  2    illustrates example operations that may be performed by one or more computing systems to train one or more machine learning models to determine a severity of a patient&#39;s occurrence of vitreous opacities, in accordance with certain aspects described herein. 
         FIG.  3    illustrates example operations that may be performed by one or more computing systems to determine a severity of a patient&#39;s vitreous opacity condition, in accordance with certain aspects described herein. 
         FIG.  4    illustrates an example system on which embodiments of the present disclosure can be performed. 
     
    
    
     To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the Figures. It is contemplated that elements and features of one embodiment may be beneficially incorporated in other embodiments without further recitation. 
     DETAILED DESCRIPTION 
     In the following description, details are set forth by way of example to facilitate an understanding of the disclosed subject matter. It should be apparent to a person of ordinary skill in the field, however, that the disclosed implementations are exemplary and not exhaustive of all possible implementations. Thus, it should be understood that reference to the described examples is not intended to limit the scope of the disclosure. Any alterations and further modifications to the described devices, instruments, methods, and any further application of the principles of the present disclosure are fully contemplated as would normally occur to one skilled in the art to which the disclosure relates. In particular, it is fully contemplated that the features, components, and/or steps described with respect to one implementation may be combined with the features, components, and/or steps described with respect to other implementations of the present disclosure. 
     As used herein, the term “about” may refer to a +/−10% variation from the nominal value. It is to be understood that such a variation can be included in any value provided herein. 
     The present disclosure relates generally to systems and methods for determining a severity of vitreous disease, and more particularly, to systems and methods for determining a severity of vitreous opacities. 
     As discussed above, the presence of vitreous opacities is a common eye condition that is often challenging to effectively characterize the severity thereof. Vitreous opacities, also known as “floaters,” are generally caused by fibrous degeneration and gel liquefaction, which may occur naturally with age. In a healthy eye, hyaluronan (i.e., hyaluronic acid) may prevent collagen fibrils from agglomerating in the vitreous cavity, thereby maintaining the structure and transparency of the vitreous. However, as the eye ages, hyaluronan may dissociate from collagen, causing cross-linking and aggregation of collagen fibrils, and forming pockets of liquid vitreous. These structures scatter light entering the eye, and may appear as assorted shapes and shadows in the field of vision of the patient. 
     Various optical techniques are currently utilized to help characterize and grade vitreous opacities, including microscopy, ultrasound imaging, and dynamic light scattering (DLS). However, such techniques only facilitate structural characterization of vitreous opacities, and do not provide a quantification of the degree of visual impairment caused thereby. There are currently no ophthalmic systems that are capable of objectively quantifying the degree of visual impairment caused by a patient&#39;s vitreous opacities, based on imaging data or other information associated with the patient. And, as previously discussed, patient self-reporting is subjective and in some cases fails to indicate the true degree of visual impairment. As a result, it is often difficult to determine whether a patient&#39;s vitreous opacity condition appropriates treatment. 
     Aspects presented herein provide systems and methods utilizing one or more machine learning models in determining a severity of vitreous opacities afflicting a patient to inform patient suitability for treatment. Such machine learning models are trained based on historical patient data associated with historical patients with various severities of the same or similar condition. By using these machine learning models, a large universe of historical patient data can be leveraged to determine a more accurate or objective indication of the severity of vitreous opacities afflicting a current patient. As defined herein, a current patient is generally a patient who is afflicted by the manifestation of vitreous opacities and for whom these machine learning models may be used to provide a severity measurement, e.g., a severity score, based on the current patient&#39;s information (e.g., imaging data). Using the severity measurement, a physician, e.g., ophthalmic surgeon, is able to determine whether the patient&#39;s condition is suitable for treatment, such as laser vitreolysis and small-gauge vitrectomy. Accordingly, the techniques herein improve existing ophthalmic systems, enabling them to objectively quantify the degree of visual impairment caused by a patient&#39;s vitreous opacity condition, based on imaging data and other information associated with the patient. 
     Example Computing Environment for Improving Vitreous Disease Diagnostics 
       FIGS.  1 A- 1 C  illustrate example computing environments in which one or more machine learning models are trained and used in determining a severity of a patient&#39;s vitreous opacities or vitreous opacity condition (hereinafter “opacity condition”). Generally, these machine learning models may be trained using a corpus of training data including records corresponding to historical patient data and deployed for use in determining the severity of the patient&#39;s opacity condition. Historical patient data for each historical patient may include the patient&#39;s demographic information, recorded measurements of physical parameters of the patient&#39;s opacity condition pre-treatment, pre-treatment self-reported severity data, the patient&#39;s vitreous opacity severity measurements, information about the treatment, if any, such as the type of treatment, and/or post-treatment self-reported severity data, as well as other post-treatment information, such as measurements of physical parameters of the patient&#39;s opacity condition post-treatment. 
     These machine learning models may be configured, as discussed in further detail below, to use at least measurements of physical parameters of a current patient&#39;s opacity condition, as input, and generate, as output, one or more vitreous opacity severity measurements (hereinafter “opacity severity measurements”), including a severity score of the current patient&#39;s opacity condition. Herein, severity refers to the extent or degree of visual impairment (e.g., negative impact on the patient&#39;s visual function) as caused by the opacity condition. More severe instances of vitreous opacities cause greater visual impairment as compared to less severe instances thereof, and may require more intensive forms of treatment to correct. In certain embodiments, the severity score is a scaled score corresponding with a value on a scale of 1-100, 1 being least severe (i.e., lowest severity) and 100 being most severe (i.e., highest severity). 
     As a result, the surgeon can be provided with an objective and more accurate determination of severity of the current patient&#39;s opacity condition. Using this information, the surgeon is able to determine an optimal form of treatment for the current patient. Note that, as described in further detail below, the input to these machine learning models may include additional information, such as data points associated with the current patient&#39;s demographic information, pre-treatment self-reported severity data, as well as other information about the current patient&#39;s opacity condition, etc. 
     Various techniques may be used to train and deploy machine learning models that generate an opacity severity measurement for a current patient. Various deployments are illustrated in  FIGS.  1 A- 1 C . For example,  FIG.  1 A  illustrates a deployment in which machine learning models are trained on a remote server and are deployed to a user console used by a surgeon during patient examination.  FIG.  1 B  illustrates a deployment in which the machine learning models are trained and deployed on a remote server accessible through the user console. Finally,  FIG.  1 C  illustrates a deployment in which the machine learning models are trained on a remote server and are deployed to a computing system integral with a diagnostic device, e.g., an imaging device. It should be recognized, however, that various other techniques for training and deploying machine learning models that generate opacity severity measurements for a current patient may be contemplated, and that the deployments illustrated in  FIGS.  1 A- 1 C  are non-limiting, illustrative examples. 
       FIG.  1 A  illustrates an example computing environment  100 A in which diagnostic devices  110 , server  120 , and user console  130  are connected via a network in order to train one or more machine learning models for use in generating opacity severity measurements for a current patient based, at least in part, on measurements of physical parameters of the current patient&#39;s opacity condition, as provided by the diagnostic devices  110 . For readability, the one or more machine learning models are referred to herein as an “ML model,” which covers both a single ML model and multiple ML models. 
     Diagnostic devices  110  are generally representative of any suitable devices that can generate, or facilitate generation of, information about the vitreous, such as measurements of physical parameters of vitreous opacities afflicting a current patient. Herein, physical parameters of the vitreous opacities refer to individual (e.g., of a singular opacity or of individual opacities of a plurality) or collective (e.g., of a collective plurality) parameters such as the number, size, shape (e.g., Weiss Ring, cobweb, or cloud), surface area, density or relative transparency, movement, location (e.g., along the visual axis or in the periphery thereof), distance to the retina and/or the crystalline lens, etc. The measurements may include, in some embodiments, e.g., measurement values of the corresponding physical parameters. In certain embodiments, the measurements include data points associated with one or more measurements of physical parameters of vitreous opacities afflicting a current patient. 
     In certain embodiments, diagnostic devices  110  may generate raw data from which measurements may be derived. In such a case, the raw data may include, for example, two-dimensional cross-sectional images of the eye; two-dimensional wide-angle images of the eye; three-dimensional images of the eye; two-dimensional topographic maps of the eye; or other data from which measurements of physical parameters may be derived. Generally, any number of diagnostic devices  110   1 - 110   n  may be included in computing environment  100 A and may be used to generate different types of data that may be used as input into an ML model that generates opacity severity measurements. Each diagnostic device  110  in the computing environment  100 A may generate measurements, or associated data points, of one or more physical parameters of a patient&#39;s opacity condition, and more generally, the patient&#39;s eye, and provide the measurements, or associated data points, to user console  130 , server  120 , and/or repository  140 . 
     In one example, one of diagnostic devices  110  may include an optical coherence tomography (OCT) device, such as a time or frequency domain OCT device, a Fourier OCT device, etc. For example, a diagnostic device  110  may include an OCT device that can generate one-dimensional (e.g., from a central point), two-dimensional, and/or three-dimensional data (e.g., imaging data) for the current patient&#39;s eye from which measurements of various individual or collective physical parameters of the current patient&#39;s opacity condition may be derived. From the data, the OCT device can derive various relevant measurements for characterizing the severity of the current patient&#39;s opacity condition, including number, size, shape (e.g., Weiss ring, cobweb, or cloud), surface area, density or relative transparency, movement, location (e.g., along the visual axis or in the periphery thereof), distance to the retina and/or the crystalline lens, etc. 
     Another one of diagnostic devices  110  may include a scanning laser ophthalmoscopy (SLO) device that can generate high quality and wide-angle two-dimensional images of the current patient&#39;s fundus in real-time. Similar to OCT, the SLO device can derive various relevant measurements for characterizing the severity of the current patient&#39;s opacity condition, including the number, size, shape, surface area, density or relative transparency, movement, location, and distance to the retina and/or the crystalline lens thereof. In such embodiments, the presence of vitreous opacities in the current patient&#39;s eye may be indicated by the presence of unfocused structures in the broad, two-dimensional SLO image. 
     Yet other examples of the diagnostic devices  110  may include a dark field microscope, an ultrasound device, and a multispectral imaging system, such as an 8-band or 10-band multispectral retinal imaging system. Generally, any suitable diagnostic devices  110  may be utilized, alone or in combination, to derive measurements of the various physical parameters of the current patient&#39;s opacity condition. 
     Server  120  is generally representative of a single computing device or cluster of computing devices on which training data sets can be generated and used to train an ML model for generating opacity severity measurements. Server  120  is communicatively coupled to historical patient data repository  140  (hereinafter “repository  140 ”), which stores records of historical patients. In certain embodiments, repository  140  may be or include a database server for receiving information from server  120 , user console  130 , and/or diagnostic devices  110  and for storing the information in corresponding patient records in a structured and organized manner. 
     In certain aspects, each patient record in repository  140  includes information such as the patient&#39;s demographic information, recorded measurements of physical parameters of the patient&#39;s opacity condition pre-treatment, pre-treatment self-reported severity data, the patient&#39;s opacity severity measurements, information about the treatment, if any, such as the type of treatment, and/or post-treatment self-reported severity data, as well as other post-treatment information , such as measurements of physical parameters of the patient&#39;s opacity condition post-treatment. For example, the demographic information for each patient may include patient age, gender, ethnicity, and the like. The measurements of physical parameters of the patient&#39;s opacity condition may include raw data or measurements generated by or provided by an OCT device, an SLO device, a dark field microscope, a multispectral imaging system, etc., as discussed above. Each patient record may also include pre-treatment self-reported severity data, which includes one or more data points indicative of the patient&#39;s own assessment of their visual impairment resulting from their opacity condition. For example, in certain embodiments, the self-reported severity data includes a subjective severity score on a three tier scale of “mild,” “moderate,” or “severe,” or on a scale of  1 - 100 , as described above. In certain cases, the self-reported severity data is based on responses provided by the patient in a Visual Function Questionnaire (VFQ), which may evaluate the patient&#39;s assessment of their vision-specific quality of life (QOL). Similar to pre-treatment self-reported severity data, post-treatment self-reported severity data includes one or more data points indicative of the patient&#39;s own assessment of their visual impairment after treatment. For example, in certain embodiments, the post-treatment severity data may be a subjective severity score (e.g., mild, moderate, severe), and/or may be based on VFQ responses provided by the patient after treatment of their opacity condition. Other post-treatment information in repository  140  may include measurements of physical parameters of the patient&#39;s opacity condition after treatment thereof. 
     Server  120  uses these records of historical patients to generate data sets for use in training an ML model that can provide opacity severity measurements to a surgeon for informing proper treatment strategy for a current patient. More specifically, as illustrated in  FIG.  1 A , server  120  includes a training data generator  122  (hereinafter “TDG  122 ”) and model trainer  124 . TDG  122  retrieves data from repository  140  to generate data sets for use by model trainer  124  to train ML model  125 . 
     Model trainer  124  includes or refers to one or more machine learning algorithms (referred to hereinafter as “ML algorithms”) that are configured to use training data sets to train ML model  125 . In certain embodiments, a trained ML model refers to a function, e.g., with weights and parameters, that is used to generate opacity severity measurements for a given set of inputs. Various ML algorithms may be used to generate different types of outputs for a given set of inputs. 
     The ML algorithms may generally include a supervised learning algorithm, an unsupervised learning algorithm, and/or a semi-supervised learning algorithm. Unsupervised learning is a type of machine learning algorithm used to draw inferences from data sets consisting of input data without labeled responses. Supervised learning is the machine learning task of learning a function that, for example, maps an input to an output based on example input-output pairs. Supervised learning algorithms, generally, include regression algorithms, classification algorithms, decision trees, neural networks, etc. A description of a labeled data set is provided below. 
     Once trained and deployed, based on a certain set of inputs associated with a current patient, including the measurements of physical parameters of the patient&#39;s opacity condition, demographic information, and pre-treatment self-reported severity data, ML model  125  is able to generate or predict opacity severity measurements for the current patient, as output. In certain aspects, model trainer  124  trains ML a model  125  configured to take a set of inputs associated with a current patient and provide opacity severity measurements, including an objective vitreous opacity severity score, to the surgeon. The surgeon may then utilize the severity measurements to select an appropriate treatment strategy for the current patient. To train ML model  125 , model trainer  124  may utilize a labeled data set provided by TDG  122  that includes a plurality of featurized data samples including a plurality of features associated with demographic information, measurements of physical parameters of the opacity condition generated by a number of diagnostic devices (e.g., an OCT device, an SLO device, a dark field microscope, and/or a multispectral imaging system), pre-treatment and post-treatment self-reported severity data, an improvement score (e.g., difference between pre-treatment and post-treatment self-reported severity data), etc. 
     A variety of ML models may be trained based on this labeled data set. In one example, the ML model  125  may be trained to predict an objective pre-treatment severity assessment. In such an example, to train such a model, the model trainer  124  may run certain or all features from each sample in the data set associated with historical patients through the ML model  125 . The features may include: the historical patient&#39;s demographic information (e.g., age, gender, ethnicity, race, etc.); pre-treatment information associated with the patient&#39;s opacity condition (e.g., number, size, shape, surface area, density or relative transparency, movement, location, distance to the retina and/or the crystalline lens, for individual or collective vitreous opacities of a historical patient as generated by a number of diagnostic devices, etc.); pre-treatment self-reported severity data provided by the historical patient in a Visual Function Questionnaire or a similar test, etc. Running each sample through the ML model  125  results in a prediction of an objective severity score that is then compared with the patient&#39;s self-reported severity score. After running a large number of samples through ML model  125  and continuing to adjust the weights based thereon, at a certain point in time, the ML model  125  starts predicting objective severity scores that are more in-line with subjective severity scores provided by non-outlier patients in the data set. 
     In another example, a different ML model  125  may be trained by the model trainer  124  by first selecting samples in the data set associated with patients who were treated and who saw an improvement in their visual impairment after the treatment, as indicated by their improvement score based on a comparison between each patient&#39;s pre-treatment and post-treatment self-reported severity assessment. Note that patients who were treated and who saw an improvement in their visual impairment after the treatment are likely patients whose pre-treatment self-reported assessment of their visual impairment have a higher correlation with their opacity condition. On the other hand, patients who were treated and who saw no improvement or a deterioration in their visual impairment are likely patients whose pre-treatment self-reported assessment of their visual impairment have a lower correlation with their opacity condition. Therefore, to train an ML model  125  that is able to predict a more objective severity assessment, samples associated with patients who saw an improvement (e.g., indicated by an improvement score of above a certain threshold) in their visual impairment after the treatment are selected. 
     Having selected the right samples, the model trainer  124  may then run certain features from each sample through the ML model  125 , where the features may include: the historical patient&#39;s demographic information; information associated with the patient&#39;s opacity condition; and pre-treatment self-reported severity data provided by the historical patient in a Visual Function Questionnaire or a similar test. 
     Running each sample through the ML model  125  results in a prediction of an objective severity assessment, which is then compared with the actual pre-treatment self-reported severity score provided by the historical patient. Any difference between the two would be considered an error, which model trainer  124  may work to reduce by adjusting the weights associated with the different features or variables in the ML model  125 . By running a large number of samples through ML model  125  and continuing to adjust the weights based thereon after a certain point, the ML model  125  starts making accurate determinations of an objective severity score. 
     In another example, the ML model  125  may be trained to predict an improvement score indicative of the likelihood of improving a current patient&#39;s visual impairment by performing a certain treatment. For such a model, the model trainer  124  may first select samples in the data set associated with historical patients who were treated with the selected treatment, and then run certain features from each sample through the ML model  125 , where the features may include: the historical patient&#39;s demographic information; information associated with the patient&#39;s opacity condition; pre-treatment self-reported severity data provided by the historical patient in a Visual Function Questionnaire or a similar test; an improvement score, etc. Running each sample through the ML model  125  results in a prediction of an improvement, which is then compared with the actual improvement score of the historical patient. Any difference between the two would be considered an error, which model trainer  124  may work to reduce by adjusting the weights associated with the different features or variables in the ML model  125 . 
     A variety of other ML models may also be trained and utilized. Once an ML model  125  is trained, it is ready to be deployed for taking a set of inputs about a current patient and generating opacity severity measurements (e.g., an objective severity assessment, an improvement score prediction, etc., that can be utilized to inform treatment strategy for the current patient). In the example of  FIG.  1 A , the trained ML model  125  may then be deployed for use at user console  130  for generating opacity severity measurements for a current patient, as described in further detail below. 
     In some aspects, ML model  125  may be a deep learning model that is trained to generate opacity severity measurements. Deep learning models may include, for example, convolutional neural networks (CNNs), adversarial learning algorithms, generative networks, or other deep learning algorithms that can learn relationships in datasets that may not be explicitly defined in the data used to train such models. In such a case, ML model  125  may be trained using raw data captured by diagnostic devices  110 , such as two-dimensional or three-dimensional images from which typical numerical measurements of physical parameters of vitreous opacities can be derived. ML model  125  may, for example, map an input to different neurons in one or more layers of a deep learning model (e.g., where the ML model is generated using neural networks), where each neuron in the ML model  125  represents new features in an internal representation of an input that are learned over time. These neurons may then be mapped to an output representing opacity severity measurements, as discussed above. 
     After ML model  125  is trained, model trainer  124  deploys the ML model  125  to user console  130  for use in generating opacity severity measurements for a current patient. The diagnostic devices  110  generate measurements of the physical parameters of the current patient&#39;s opacity condition, and transmit these measurements to server  120 , user console  130 , and/or repository  140 . Note that in embodiments where diagnostic devices  110  transmit the data points to server  120  or user console  130  (as opposed to directly transmitting them to repository  140 ), the data points may at some later point be committed by server  120  or user console  130  to repository  140 , which stores the measurements in the current patient&#39;s record. 
     User console  130  then retrieves the data points (from the repository  140  and/or from temporary memory at the user console  130 ) and inputs the data points and other patient information (e.g., the current patient&#39;s demographic information, self-reported severity data, etc.) into the ML model  125 . User console  130  then outputs the severity measurements generated by the ML model  125 . The record in the repository  140 , including the measurements for one or more physical parameters of the current patient&#39;s opacity condition, which is mapped to the severity measurements generated by the ML model  125 , is then converted into a new sample in a training dataset that is used to retrain the ML model  125 . More generally, each time a new (i.e., current) patient is examined, information about the new patient may be saved in repository  140  to supplement the training dataset(s), and the supplemented training dataset(s) may be used to retrain the ML model  125 . 
     Once the trained ML model  125  is deployed, as further described below, TDG  122  continues to augment the training data sets with information relating to patients for whom the deployed ML model  125  provided opacity severity measurements. For example, in the embodiments of  FIG.  1 A , a surgeon may use user console  130  to generate, using the deployed ML model  125 , opacity severity measurements (e.g., including vitreous opacity predicted objective severity assessment, a predicted improvement score, etc.), for a new patient. In that example, as described above, a new record is then added to repository  140  that may include information about the new patient, including demographic information, measurements of physical parameters of the patient&#39;s opacity condition, self-reported severity data, and/or other information related to the patient&#39;s opacity condition, such as post-treatment information. TDG  122  then augments the data set(s) for retraining the ML model  125 . In certain aspects, TDG  122  augments the data set(s) every time information about a new (i.e., current) patient becomes available. In certain other aspects, TDG  122  augments the data set(s) with a batch of new patient records, which may be more resource efficient. For example, once the number of new patient records hits  100  (or, more generally, some threshold number), TDG  122  may augment the data set(s) using information associated with the  100  new patient records. In such an example,  100  new samples are then made available to model trainer  124  to retrain ML model  125  with. 
     User console  130  is generally representative of a computing device or system that is communicatively coupled to server  120 , repository  140 , and/or diagnostic devices  110 . In certain embodiments, user console  130  may be a desktop computer, laptop computer, tablet computer, smartphone, or other computing device(s). For example, user console  130  may be a computing system used at the surgeon&#39;s office or clinic. In another example, user console  130  may be a device console used by a surgeon in an examination room to perform an examination of a current patient. For example, the user console may be a console for one or more of the diagnostic devices  110 . In yet another example, user console  130  may be a surgical console that is capable of performing laser vitreolysis and small-gauge vitrectomy. 
     In the example of  FIG.  1 A , the trained ML model  125  is deployed by server  120  to user console  130  for generating, for a current patient, opacity severity measurements that could be utilized by, e.g., the surgeon, to inform determination of a treatment strategy for the current patient. As illustrated, user console  130  includes a patient data recorder (“PDR”)  132  and a severity measurement generator (“SMG”)  134 . SMG  134  generally refers to a software module or a set of software instructions or algorithms, including ML model  125 , which take a set of inputs about a current patient and generate, as output, opacity severity measurements. In certain embodiments, SMG  134  is configured to receive the set of inputs from at least one of repository  140 , diagnostic devices  110 , a user interface or some other component of user console  130 , and other computing devices that a medical practitioner/office may use to record information about the current patient. In certain embodiments, SMG  134  outputs the opacity severity measurements to a display device communicatively coupled with user console  130 , prints the severity measurements, generates and transmits one or more electronic messages, including severity measurements, to a destination device (e.g., a connected device, such as a tablet, smartphone, wearable device, etc.), or the like. 
     User console  130  also comprises a PDR  132 , which receives or generates data regarding the opacity condition of the current patient, as well as other patient data for the current patient. As described above, patient data may include self-reported severity data for the current patient, demographic data, as well as any additional relevant information, such as post-treatment information. In the embodiments of  FIG.  1 A , PDR  132  transmits the current patient data to repository  140  and/or server  120 , where the current patient data may be converted by TDG  122  into a new sample in a training data set that is used to retrain the ML model  125 . 
       FIG.  1 B  illustrates another example computing environment  100 B in which training and use of the machine learning models to generate opacity severity measurements are performed. As illustrated, computing environment  100 B includes one or more diagnostic devices  110 , server  120 , user console  130 , and historical patient data repository  140 . In the example of  FIG.  1 B , TDG  122 , model trainer  124 , PDR  132 , and SMG  134  all execute on server  120 . All of these software modules function identically or at least substantially similar to what was described in relation to  FIG.  1 A . In the example of  FIG.  1 B , diagnostic devices  110  may transmit the measurements of physical parameters of vitreous opacities for a current patient to server  120  and/or repository  140 . SMG  134  generates the opacity severity measurements, based on a set of inputs associated with a current patient, and transmits the opacity severity measurements to user console  130 . User console  130  then transmits back patient data to PDR  132 , which processes and store the corresponding information at repository  140 . 
       FIG.  1 C  illustrates an example computing environment  100 C in which generating opacity severity measurements are performed on a diagnostic device  110 . As illustrated, computing environment  100 C includes a diagnostic device  110 , a server  120 , and a historical patient data repository  140 . In the example of  FIG.  1 C , PDR  132  and SMG  134  all execute on a diagnostic device  110 . All of these software modules function identically or at least substantially similar to what was described in relation to  FIGS.  1 A and  1 B . 
     As illustrated, diagnostic device  110  includes diagnostic hardware/software  112 , which generally refers to the hardware and software components and modules associated with either an OCT device, an SLO device, a multispectral imaging system, etc. Diagnostic device  110  may also include a user interface and/or a display device, enabling a user to input and/or view information as it relates to the functionality of PDR  132  and SMG  134 . 
     Example Methods for Generating Opacity Severity Measurements Using Machine Learning Models 
       FIG.  2    illustrates example operations  200  that may be performed by a computing system to train and use ML models to generate opacity severity measurements, including an objective vitreous opacity severity score, for a current patient&#39;s opacity condition, based at least on measurements of physical parameters of the current patient&#39;s opacity condition, in accordance with certain aspects described herein. Operations  200  may be performed by one or more of a user console  130 , server  120 , or diagnostic device  110  illustrated in  FIGS.  1 A- 1 C . 
     As illustrated, operations  200  may begin at block  210 , where the system retrieves a set of historical patient records. Each record in the set of historical patient records includes information about a specific historical patient. As discussed, for example, each record includes demographic information, measurements of physical parameters of the patient&#39;s opacity condition pre-treatment, pre-treatment self-reported severity data, other information related to the patient&#39;s opacity condition such as treatment and post-treatment information, as well as any opacity severity measurements, as recorded for the historical patient. In certain embodiments, other information related to the patient&#39;s opacity condition includes type of treatment and/or post-treatment self-reported severity data, as well as other post-treatment information such as measurements of physical parameters of the patient&#39;s opacity condition post-treatment. 
     At block  220 , the system generates a training data set by mapping, for each historical patient of a number of historical patients, the patient&#39;s demographic information, recorded measurements of physical parameters of the patient&#39;s opacity condition pre-treatment, pre-treatment self-reported severity data, information about the treatment, if any, as well as post-treatment data to the patient&#39;s opacity severity measurements. Generally, by mapping these historical patients&#39; data points and parameters to their opacity severity measurements, the training data set may allow for ML models to be trained to generate opacity severity measurements given at least an input of measurements of physical parameters of vitreous opacities for a future (i.e., current) patient. 
     At block  230 , the system trains one or more ML models based on the training data set. The trained ML models may be trained to generate one or more severity measurements, including an objective vitreous opacity severity score, for the current patient&#39;s opacity condition. The ML models may be MIMO models or may be a set of MISO models. 
     At block  240 , the system deploys the trained ML models for use. The trained ML models may be deployed to one or more server computers, a user console, a diagnostic device in which a computing device is integrated, or the like, as illustrated for example in  FIGS.  1 A- 1 C , or even a computing device not shown in  FIGS.  1 A- 1 C . 
       FIG.  3    illustrates example operations  300  that may be performed by one or more computing systems to generate opacity severity measurements, including an objective vitreous opacity severity score, for a current patient&#39;s opacity condition, based at least on measurements of physical parameters of the current patient&#39;s opacity condition, in accordance with certain aspects described herein. Operations  300  may be performed, for example, by a severity measurements generator, such as SMG  134  illustrated in  FIGS.  1 A- 1 C . 
     At block  310 , the system receives information associated with the patient, such as demographic information, measurements of physical parameters of a current patient&#39;s opacity condition, pre-treatment self-reported severity data, and other information related to the current patient&#39;s opacity condition. 
     At block  320 , the system generates, using trained ML models, one or more opacity severity measurements, including an objective severity score. The generated opacity severity measurements may be based, at least in part, on the data points above. The opacity severity measurements, along with all of the other relevant data points associated with the current patient, may then be added to the training data set described above for retraining the ML models. 
     At block  330 , the system transmits, to a specified destination device, the generated opacity severity measurements. The specified destination device may be a user console through which planning for ophthalmic treatment is performed (which may be communicatively coupled with one or more diagnostic devices via a network or a point-to-point connection or integral with a diagnostic device) or a device capable of receiving electronic messaging from another device. 
     Example System for Generating Opacity Severity Measurements Using Machine Learning Models 
       FIG.  4    illustrates an example system  400  that uses machine learning models to aid in performing ophthalmic examinations and procedures. For example, system  400  may comprise one or more of the diagnostic devices  110 , server  120 , and/or user console  130  illustrated in  FIG.  1   . 
     As shown, system  400  includes a central processing unit (CPU)  402 , one or more I/O device interfaces  404  that may allow for the connection of various I/O devices  414  (e.g., keyboards, displays, mouse devices, pen input, etc.) to the system  400 , network interface  406  through which system  400  is connected to network  490  (which may be a local network, an intranet, the internet, or any other group of computing devices communicatively connected to each other), a memory  408 , storage  410 , and an interconnect  412 . 
     CPU  402  may retrieve and execute programming instructions stored in the memory  408 . Similarly, the CPU  402  may retrieve and store application data residing in the memory  408 . The interconnect  412  transmits programming instructions and application data, among the CPU  402 , I/O device interface  404 , network interface  406 , memory  408 , and storage  410 . 
     CPU  402  is included to be representative of a single CPU, multiple CPUs, a single CPU having multiple processing cores, and the like. 
     Memory  408  is representative of a volatile memory, such as a random access memory, and/or a nonvolatile memory, such as nonvolatile random access memory, phase change random access memory, or the like. As shown, memory  408  includes diagnostic software or instructions  420 , SMG  430 , PDR  440 , TDG  450 , model trainer  460 , and repository  470 . Diagnostic software  420  is generally configured to receive raw image or reflectivity data from optical hardware that is a part of system  400  (e.g., OCT or SLO scanner, etc.) or a connected measurement device (e.g., OCT device, SLO device, dark field microscope, multispectral imaging device, etc.) and generate data points associated with measurements of one or more physical parameters of vitreous opacities therefrom. Diagnostic software  420  may output the data points associated with measurements of physical parameters to SMG  430  for use in providing severity measurements, including providing an objective severity score for a patient&#39;s opacity condition. 
     SMG  430  comprises or uses one or more trained and deployed ML models trained by model trainer  460 . SMG  430  generally processes at least one or more data point associated with a measurement of a physical parameter received from diagnostic software  420  or from an external source, as well as patient demographic data, self-reported patient parameters, and other related information, and generates, using the one or more ML models, one or more severity measurements. 
     PDR  440  generally allows for a user of system  400  to record patient data, as previously defined. PDR  440  may output the data to repository  470  for storage and future use in generating training data sets used to train the one or more ML models deployed to and used by SMG  430 . 
     As discussed, TDG  450  generally uses historical patient information (e.g., stored in historical patient data repository  470 ) to generate training data sets that may be used by model trainer  460  to train the one or more ML models deployed to and used by SMG  430 . 
     Model trainer  460  generally trains the one or more ML models used by SMG  430  in generating opacity severity measurements for a current patient. As discussed, model trainer  460  may use the training data sets generated by training data generator  450  to train the ML models and may deploy the trained ML models to SMG  430  (or a remote system) for use. 
     As described above, embodiments of the present disclosure provide systems and methods utilizing one or more machine learning models in determining a severity of vitreous opacities afflicting a current patient. By using the systems and methods herein, a physician, e.g., ophthalmic surgeon, is able to leverage a large universe of historical patient data in order to determine a more accurate severity of vitreous opacities afflicting the current patient, which may, in turn, be utilized to determine an optimized treatment strategy for the current patient. Accordingly, the techniques herein improve the medical field by increasing the accuracy of vitreous disease diagnostics, thereby leading to better-informed selection of treatment strategies. 
     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, as well as any combination with multiples of the same element (e.g., a-a, a-a-a, a-a-b, a-a-c, a-b-b, a-c-c, b-b, b-b-b, b-b-c, c-c, and c-c-c or any other ordering of a, b, and c). 
     As used herein, the term “determining” encompasses a wide variety of actions. For example, “determining” may include calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and the like. Also, “determining” may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and the like. Also, “determining” may include resolving, selecting, choosing, establishing and the like. 
     The methods disclosed herein comprise one or more steps or actions for achieving the methods. The method steps and/or actions may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of steps or actions is specified, the order and/or use of specific steps and/or actions may be modified without departing from the scope of the claims. Further, the various operations of methods described above may be performed by any suitable means capable of performing the corresponding functions. The means may include various hardware and/or software component(s) and/or module(s), including, but not limited to a circuit, an application specific integrated circuit (ASIC), or processor. Generally, where there are operations illustrated in figures, those operations may have corresponding counterpart means-plus-function components with similar numbering. 
     The various illustrative logical blocks, modules and circuits described in connection with the present disclosure may be implemented or performed with 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 (PLD), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any commercially available 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, one or more microprocessors in conjunction with a DSP core, or any other such configuration. 
     A processing system may be implemented with a bus architecture. The bus may include any number of interconnecting buses and bridges depending on the specific application of the processing system and the overall design constraints. The bus may link together various circuits including a processor, machine-readable media, and input/output devices, among others. A user interface (e.g., keypad, display, mouse, joystick, etc.) may also be connected to the bus. The bus may also link various other circuits such as timing sources, peripherals, voltage regulators, power management circuits, and the like, which are well known in the art, and therefore, will not be described any further. The processor may be implemented with one or more general-purpose and/or special-purpose processors. Examples include microprocessors, microcontrollers, DSP processors, and other circuitry that can execute software. Those skilled in the art will recognize how best to implement the described functionality for the processing system depending on the particular application and the overall design constraints imposed on the overall system. 
     If implemented in software, the functions may be stored or transmitted over as one or more instructions or code on a computer-readable medium. Software shall be construed broadly to mean instructions, data, or any combination thereof, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. Computer-readable media include both computer storage media and communication media, such as any medium that facilitates transfer of a computer program from one place to another. The processor may be responsible for managing the bus and general processing, including the execution of software modules stored on the computer-readable storage media. A computer-readable storage medium may be coupled to a processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. By way of example, the computer-readable media may include a transmission line, a carrier wave modulated by data, and/or a computer readable storage medium with instructions stored thereon separate from the wireless node, all of which may be accessed by the processor through the bus interface. Alternatively, or in addition, the computer-readable media, or any portion thereof, may be integrated into the processor, such as the case may be with cache and/or general register files. Examples of machine-readable storage media may include, by way of example, RAM (Random Access Memory), flash memory, ROM (Read Only Memory), PROM (Programmable Read-Only Memory), EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), registers, magnetic disks, optical disks, hard drives, or any other suitable storage medium, or any combination thereof. The machine-readable media may be embodied in a computer-program product. 
     A software module may comprise a single instruction, or many instructions, and may be distributed over several different code segments, among different programs, and across multiple storage media. The computer-readable media may comprise a number of software modules. The software modules include instructions that, when executed by an apparatus such as a processor, cause the processing system to perform various functions. The software modules may include a transmission module and a receiving module. Each software module may reside in a single storage device or be distributed across multiple storage devices. By way of example, a software module may be loaded into RAM from a hard drive when a triggering event occurs. During execution of the software module, the processor may load some of the instructions into cache to increase access speed. One or more cache lines may then be loaded into a general register file for execution by the processor. When referring to the functionality of a software module, it will be understood that such functionality is implemented by the processor when executing instructions from that software module. 
     The following claims are not intended to be limited to the embodiments shown herein, but are to be accorded the full scope consistent with the language of the claims. Within a claim, reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more.” Unless specifically stated otherwise, the term “some” refers to one or more. No claim element is to be construed under the provisions of 35 U.S.C. §112(f) unless the element is expressly recited using the phrase “means for” or, in the case of a method claim, the element is recited using the phrase “step for.” All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims.