Patent Publication Number: US-2022230719-A1

Title: Clinical Laboratory-Based Disease Management Program, With Automated Patient-Specific Treatment Advice

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     This application is a continuation of U.S. patent application Ser. No. 16/403,915, filed May 6, 2019, which is a continuation of U.S. Pat. No. 10,290,369, filed Jan. 31, 2013, which is a continuation of U.S. patent application Ser. No. 12/535,287, filed Aug. 4, 2009, which claims the benefit of U.S. Provisional Application No. 61/086,023, filed Aug. 4, 2008, the entirety of each of which is hereby incorporated by reference. 
    
    
     FIELD OF THE PRESENT INVENTION 
     The present invention relates to systems and methods for providing a clinical laboratory-based disease management program with automated patient-specific treatment advice. 
     BACKGROUND 
     Treatment of diseases can be challenging. This is especially true when the disease is complex. In these cases, medical service providers such as doctors have a limited window of time in which to make critical decisions regarding patient treatment and care. When dealing with a complex medical condition, the medical provider may be faced with a voluminous amount of information from which to determine the proper course of treatment. Yet the patient&#39;s situation may be such that the medical provider does not know or does not have the time to adequately review all of the relevant information regarding the proper standard of care. 
     An example of such a complex case is Chronic Kidney Disease (CKD). CKD is the material loss of function of the kidneys and it involves a combination of several other common, complex diseases. CKD is primarily caused by diabetes and high blood pressure but it also causes or complicates high blood pressure, cardiovascular disease, bone and mineral diseases and anemia, among other conditions. CKD is currently a public health crisis affecting an estimated 26 million Americans and doing irreparable damage to vital body functions, yet most people with CKD are unaware they have the condition. 
     Other examples of poorly treated complex diseases include osteoporosis and thyroid disease. Osteoporosis is a metabolic disturbance of the skeleton characterized by low bone mass and structural deterioration of bone, leading to bone fragility and an increased susceptibility to fracture, especially of the hip, spine, and wrist. Proper treatment of osteoporosis requires access to sophisticated bone density scanning technology, blood testing to rule out secondary causes of the disease which, if present, require different treatment, evidence based interpretations of the bone density and blood tests, understanding of treatment alternatives and their efficacy. 
     Thyroid disease occurs when the thyroid gland does not supply the proper amount of hormones needed by the body. If the thyroid is overactive, it releases too much thyroid hormone into the bloodstream, resulting in hyperthyroidism. An underactive thyroid produces too little thyroid hormone, resulting in hypothyroidism. Treating thyroid disease with maximum effectiveness requires testing of different dosages of complex medications with often frustrating imbalances over time for the patient and the physician. 
     It is widely recognized that the complexity of treatment of diseases such as CKD and others as well as the growth of new treatments and of medical research into the effectiveness of existing treatments makes it a daunting task for physicians to know and practice at the state of the art. Embodiments of the present invention address this problem by, for example, making the clinical laboratory the organizer, integrator and interpreter of the primary data that is necessary for a physician to understand, treat and prevent chronic kidney disease. 
     SUMMARY 
     Embodiments of the present invention provide methods and systems that may improve the quality of care provided to an individual by integrating data relating to the individual and a proposed action to assist a caregiver providing care to the individual. Some embodiments include generating a proposed action, or proposed actions, for the caregiver in view of the integration of data relating to the individual. A program for the individual may comprise one or more proposed actions. 
     Embodiments of the present invention may be advantageously utilized in numerous environments including, but not limited to: healthcare, including primary healthcare, disease management, rehabilitation, physical therapy and the like; diet and nutrition; training and exercise; and similar environments where the quality of an action undertaken by an individual may be improved by the integration of a plurality of data points relating to the individual. Features and advantages of the present invention are described herein with reference to the healthcare environment wherein data relating to the individual may comprise diagnostic test data, for example data generated by a clinical testing laboratory, and may further comprise additional data relating to the individual that may not be generated from a test or analysis, for example ethnicity data, geographic data, economic data, prior treatment data, and the like. One or more data points from the diagnostic testing and/or additional data may be integrated with a proposed action for the individual. 
     In a healthcare environment, an embodiment of the present invention may integrate data relating to an individual with standard-of-care guidelines for a particular condition affecting the individual and/or a desired outcome for the individual. In an embodiment, data relating to the individual is compared to standard-of-care guidelines to generate a proposed action for the individual. Standard-of-care guidelines in the healthcare environment may comprise science-based guidelines generated by medical professionals and academics based on research and study of patient treatment programs and clinical outcomes. Standard-of-care guidelines for particular conditions or disease states may be promulgated by associations, foundations and or boards of healthcare professionals with experience relating to the disease state. Examples include, but are not limited to the National Kidney Foundation (the KDOQI™ guidelines), the American Diabetes Association, the American Cancer Society, Kidney Disease: Improving Global Outcomes (KDIGO®), and similar organizations. The U.S. Government, through the Health and Human Services Department has established a National Guideline Clearinghouse to provide healthcare professionals with access to information relating to standard-of-care guidelines. 
     In general, standard-of-care guidelines recommend an action, or actions, to be undertaken by an individual having a particular condition or disease state. An action may comprise taking of a pharmaceutical composition, modification of diet, modification of activity level and/or similar actions. As described herein, an embodiment of the present invention may advantageously generate an action for an individual in view of data relating to the individual and a standard of care guideline. 
     Additional description of the present invention is provided below with reference to embodiments in a healthcare environment and a particular disease state to promote understanding of the features and advantageous of the present invention. As will be apparent from the following description, the present invention is not limited to the specific embodiments herein described. 
     In one embodiment of the invention, a treatment management program (the “Litholink program”) is provided in which a laboratory, for example a medical diagnostic testing laboratory performs testing, for example standard-of-care clinical testing, relating to the detection, treatment or monitoring of a medical condition and seamlessly integrates with the testing a variety of disease management services that assist a patient and physician in achieving the best possible patient outcome based on the test results and other relevant information. Further embodiments of the invention may comprise one or more disease management services. 
     One embodiment may comprise a software system by which state of the art, patient-specific treatment recommendations are provided to physicians on the test results report based on state of the art treatment guidelines for the medical condition adjusted according to the individual patient&#39;s lab results, treatment history and demographics. 
     In one embodiment, a method is provided, the method including receiving a test result data, wherein said test result data represents a result of a test on a physical specimen, associating said test result data with a standard-of-care data, wherein said standard-of-care data represents a recommended course of action for the condition represented by the test result data, and transforming said specimen data and said standard-of-care data into a human-readable form. 
     In another embodiment, a system is provided, the system including a processor, a software adapted to be executed on said processor, said software comprising instructions for receiving a test result data, wherein said test result data represents a result of a test on a physical specimen, associating said test result data with a standard-of-care data, wherein said standard-of-care data represents a recommended course of action for the condition represented by the test result data, and transforming said specimen data and said standard-of-care data into a human-readable form. 
     In a further embodiment, a method for providing a Disease-Specific Patient Report is provided, the method including receiving a test result data, wherein said test result data represents a result of a test on a physical specimen, performing a quality control step on the test result data, processing the test result data in order to identify whether the data fits into an acceptable range, or if the data is above or below the acceptable range, associating said test result data with a standard-of-care data, wherein said standard-of-care data represents a recommended course of action for the condition represented by the test result data, and transforming said specimen data and said standard-of-care data into a human-readable form, and providing said test result data and said standard-of-care data. 
     In one embodiment of the invention, a treatment management program (the “Litholink program”) is provided in which a medical diagnostic testing laboratory performs standard-of-care clinical testing necessary to detect, treat and monitor a medical condition, as ordered by the patient&#39;s physician, and seamlessly integrates with the testing a variety of disease management services that assist the patient and physician in achieving the best possible patient outcome based on the test results and other relevant information. Examples of types of testing include blood testing, urine testing, EKG testing, stress testing, x-ray, colonoscopy, biopsy, and others. Further embodiments of the invention may comprise one or more disease management services. 
     One embodiment may comprise a software system by which state of the art, patient-specific treatment recommendations are provided to physicians on the test results report based on state of the art treatment guidelines for the medical condition adjusted according to the individual patient&#39;s lab results, treatment history and demographics. 
     In one embodiment, a method is provided, the method including receiving a test result data, wherein said test result data represents a result of a test on a physical specimen, associating said test result data with a standard-of-care data, wherein said standard-of-care data represents a recommended course of action for the condition represented by the test result data, and transforming said specimen data and said standard-of-care data into a human-readable form. 
     In another embodiment, a system is provided, the system including a processor, a software adapted to be executed on said processor, said software comprising instructions for receiving a test result data, wherein said test result data represents a result of a test on a physical specimen, associating said test result data with a standard-of-care data, wherein said standard-of-care data represents a recommended course of action for the condition represented by the test result data, and transforming said specimen data and said standard-of-care data into a human-readable form. 
     In a further embodiment, a method for providing a Disease-Specific Patient Report is provided, the method including receiving a test result data, wherein said test result data represents a result of a test on a physical specimen, performing a quality control step on the test result data, processing the test result data in order to identify whether the data fits into an acceptable range, or if the data is above or below the acceptable range, associating said test result data with a standard-of-care data, wherein said standard-of-care data represents a recommended course of action for the condition represented by the test result data, and transforming said specimen data and said standard-of-care data into a human-readable form, and providing said test result data and said standard-of-care data. 
    
    
     
       BRIEF DESCRIPTION OF THE FIGURES 
         FIGS. 1A and 1B  are test order forms according to one embodiment; 
         FIG. 2  is a patient sample shipping box according to one embodiment; 
         FIG. 3  is the Medical Director&#39;s Notes section of a Patient Results Report according to one embodiment; 
         FIG. 4  is the Laboratory Results section of a Patient Results Report according to one embodiment; 
         FIG. 5  is the portion of a Patient Results Report displaying summary eGFR, blood pressure, and proteinuria according to one embodiment; 
         FIG. 6  is a summary of co-morbidity status in a Patient Results Report according to one embodiment; 
         FIG. 7  is the Test Results and Treatments section of a Patient Results Report according to one embodiment; 
         FIG. 8  is the Laboratory Director&#39;s Notes section of a Patient Results Report according to a further embodiment; 
         FIGS. 9A and 9B  is the Laboratory Results section of a Patient Results Report according to a further embodiment; 
         FIG. 10  is the portion of a Patient Results Report displaying summary eGFR, blood pressure, and proteinuria according to a further embodiment; 
         FIG. 11  is a summary of co-morbidity status in a Patient Results Report according to a further embodiment; 
         FIG. 12  is the Test Results and Treatments section of a Patient Results Report according to a further embodiment; 
         FIGS. 12A, 12B, and 12C  depict an outcome according to one embodiment; 
         FIG. 13  depicts the functions handled by the various components of the SOAR architecture, according to one embodiment; 
         FIG. 14  depicts an ADO.NET software architecture that can be used to provide the application with access to the data stored in a database, according to one embodiment; 
         FIG. 15  depicts the interaction between software components according to one embodiment; 
         FIG. 16  depicts the Litholink application infrastructure according to one embodiment; 
         FIG. 17  depicts a patient data flow according to one embodiment. 
         FIG. 18  depicts an illustration of an example of the matrix logic according to one embodiment. 
         FIGS. 19-26  depict various protocols, domains, assessments, and lists according to one or more embodiments. 
     
    
    
     DETAILED DESCRIPTION 
     A Laboratory-Based Disease Management Program According to One Embodiment 
     In the context of treating a complex medical condition such as CKD, it is challenging for a medical provider, such as a doctor, to process the relevant information in order to provide treatment at the standard of care. There is no shortage of information regarding the treatment of such diseases and conditions, but this huge volume of information can add its own challenges. For example, the standard-of-care guidelines for CKD would comprise a set of multiple volumes. It is not reasonable to expect a doctor to read this voluminous information and apply it at the point of care in a usable way. 
     In order to assist doctors in providing proper care, there is a need for a way to direct doctors to the proper information that is relevant to the treatment of the patient&#39;s condition. Embodiments of the invention assist in meeting this and other needs. For example, in some embodiments, a computer assists the doctor at the point of care. The laboratory has access to lab data containing critical patient information resulting from tests, measurements, and procedures. Thus, it would be beneficial to provide a system and method that cross-references the lab data with standard-of-care information. 
     Because of the tremendous amount of information available to a doctor, it is important to provide patient care information in a form and manner that the doctor will read. One document that the doctor typically reads is the laboratory report. Thus, by providing information in the context of a laboratory report or as part of a laboratory report, this dramatically increases the likelihood that the doctor will read the information. One embodiment of the invention provides systems and methods for generating a laboratory report that includes information such as standard-of-care information based on the lab data. 
     One embodiment provides a method comprising receiving a test result data, wherein said test result data represents a result of a test on a physical specimen; associating said test result data with a standard-of-care data, wherein said standard-of-care data represents a recommended course of action for the condition represented by the test result data; and transforming said specimen data and said standard-of-care data into a human-readable form. 
     A further embodiment comprises providing said test result data and said standard-of-care data in the form of a laboratory report. 
     In one embodiment, the step of associating said test result data with a standard-of-care data comprises evaluating whether the test result data are below, within, or above a set of guidelines. 
     In a further embodiment, the set of guidelines comprises at least one of: KDOQI™, any other medical practices guidelines referenced by KDOQI™, JNC7, ATP III, Kidney Disease: Improving Global Outcomes (KDIGO®), or other medical practice guidelines which reflect a standard of care for complex diseases. 
     In one embodiment, the step of associating said test result data with a standard-of-care data comprises evaluating whether medication is being used. 
     One embodiment further comprises evaluating whether the test result data has changed from prior test results. 
     A further embodiment comprises providing information in human-readable form regarding any change in the test result data from prior test results. 
     In one embodiment, the step of associating said test result data with a standard-of-care data comprises using a matrix to query the relevant standard-of-care data for the test result data. 
     A further embodiment comprises determining whether an override condition exists, and transforming data representing the override condition into a human-readable form. 
     A further embodiment comprises associating at least one of demographic data, medication data, or prior test results with the standard-of-care data. 
     One embodiment provides a system comprising a processor, a software adapted to be executed on said processor, said software comprising instructions for receiving a test result data, wherein said test result data represents a result of a test on a physical specimen, associating said test result data with a standard-of-care data, wherein said standard-of-care data represents a recommended course of action for the condition represented by the test result data, and transforming said specimen data and said standard-of-care data into a human-readable form. 
     In one embodiment, the software further comprises instructions for providing said test result data and said standard-of-care data in the form of a laboratory report. 
     In a further embodiment, the instructions for associating said test result data with a standard-of-care data comprise instructions for evaluating whether the test result data are below, within, or above a set of guidelines. 
     In a further embodiment, the set of guidelines comprises either KDOQI™, any other medical practices guidelines referenced by KDOQI™, JNC7, ATP III, Kidney Disease: Improving Global Outcomes (KDIGO®), or other medical practice guidelines which reflect a standard of care for complex diseases. 
     In one embodiment, the step of associating said test result data with a standard-of-care data comprises evaluating whether medication is being used. 
     One embodiment further comprises evaluating whether the test result data has changed from prior test results. 
     A further embodiment comprises providing information in human-readable form regarding any change in the test result data from prior test results. 
     In one embodiment, the step of associating said test result data with a standard-of-care data comprises using a matrix to query the relevant standard-of-care data for the test result data. 
     A further embodiment comprises determining whether an override condition exists, and transforming data representing the override condition into a human-readable form. 
     A further embodiment comprises associating at least one of demographic data, medication data, or prior test results with the standard-of-care data. 
     On embodiment comprises a method for providing a Disease-Specific Report comprising receiving a test result data, wherein said test result data represents a result of a test on a physical specimen; performing a quality control step on the test result data; processing the test result data in order to identify whether the data fits into an acceptable range, or if the data is above or below the acceptable range; associating said test result data with a standard-of-care data, wherein said standard-of-care data represents a recommended course of action for the condition represented by the test result data; transforming said specimen data and said standard-of-care data into a human-readable form; and providing said test result data and said standard-of-care data. 
     In a further embodiment, the standard-of-care data relates to Chronic Kidney Disease. 
     One embodiment of the invention includes a new way to use the clinical laboratory for the treatment of chronic kidney disease. In one embodiment, the programmatic model consists of ten distinct yet integrated functions, only one of which is routinely provided by clinical laboratories today yet all of which are important to properly treat a complex chronic disease like kidney disease. The elements are:
         Thought leaders elucidate standard of care   Physician and patient education   Ordering guidance   High quality testing and service   Sophisticated clinical guidance   Outcomes feedback   Expert consultation   Compliance programs   Research       

     In some embodiments, the Litholink program may comprise one or more of the following steps. 
     A. Ordering the Test and Gathering Patient Information 
     In one embodiment, the Litholink program is available to a physician after the patient has been diagnosed with CKD or other condition. Using CKD as an example, but not limiting the application to CKD, a CKD test order form may be provided by Litholink to physicians.  FIGS. 1A and 1B  are test order forms according to one embodiment. The test form may ask the physician to identify a specific diagnosis, the tests of blood and urine needed for detection and treatment, the patient&#39;s existing medications and the patient&#39;s demographics (e.g., sex, age, ethnicity). On the bottom of the test form is a space for the phlebotomist who does the blood draw to report the collection times and fasting information. The tests performed at the lab may include one or more of: a standard renal panel to detect and measure CKD&#39;s progression, a standard lipid panel to detect and treat related cardiovascular disease, the common tests for anemia and tests to detect and measure bone and mineral disorders associated with CKD. The back of the test form may include descriptions of some or all of the tests in the panels. 
     In some embodiments, the patient may provide the sample to the lab via mail, courier, or other shipping service such as UPS or FedEx.  FIG. 2  is a patient sample shipping box according to one embodiment. In various embodiments, such a shipping box may include instructions regarding handling and processing the sample. 
     In some embodiments, after a physician has selected a patient for the program, ordered testing using the CKD test Request Form, and provided the other patient information requested, the order form is given to the patient who takes it to a service provider location, such as a Laboratory Corporation of America Holdings (LabCorp) Patient Service Center (PSC). In additional embodiments, the order form is faxed by a physician to a service provider such as Litholink. The patient may be given a copy of the form. The patient may then be registered. In one embodiment, the patient is registered in Litholink&#39;s proprietary software system called SOAR. 
     B. CKD Sample Processing 
     At the PSC, a phlebotomist may read the physician order and collect the appropriate patient samples in the appropriate tube. The phlebotomist may fill out draw dates and times on the Test Request Form, may place the form along with sample specimens into packaging for shipment to a LabCorp testing facility. 
     In some embodiments, the results are then sent electronically to Litholink where the patient may be registered and the test results uploaded in Litholink&#39;s proprietary software system called SOAR. In one embodiment, the patient is registered in Litholink&#39;s proprietary software system called SOAR. In one embodiment, SOAR is an N-Tier, open architecture, component-based software system using C#, Microsoft SQL Server 2005 and XML technology. In various embodiments, other architectures may be used, such as those based on Web Sphere, Java, and other platforms known in the art. 
     Within a 24 hour turnaround time, the CKD Patient Results Report may be generated in SOAR. 
     C. CKD Patient Results Report 
     In some embodiments, the CKD Patient Results Report consists of 5 sections. Additional embodiments may include a subset of these sections. Further embodiments may include additional sections. These sections are depicted in two embodiments— FIGS. 3-7 and 8-12 :
         Section 1—Medical Director&#39;s Notes. This section is depicted in  FIG. 3  according to one embodiment and  FIG. 8  according to another embodiment.   Section 2—Laboratory Results. This section is depicted in  FIG. 4  according to one embodiment and  FIGS. 9A and 9B  according to another embodiment.   Section 3—Summary eGFR, blood pressure, and proteinuria with treatment and follow-up options. This section is depicted in  FIG. 5  according to one embodiment and  FIG. 10  according to another embodiment.   Section 4—Summary of co-morbidity status. This section is depicted in  FIG. 6  according to one embodiment and  FIG. 11  according to another embodiment.   Section 5—Test Results and Treatments for co-morbidities. This section is depicted in  FIG. 7  according to one embodiment and  FIG. 12  according to another embodiment.       

     1. Section 1—Medical Director&#39;s Notes 
       FIG. 3  is the Medical Director&#39;s Notes section of a Patient Results Report according to one embodiment. In some embodiments, a Patient Results Report may include a section with some information regarding the patient (e.g., name and date of birth), the patient&#39;s physician, and any notes from a medical director. In some embodiments, this is the first page of a Patient Results Report. 
       FIG. 8  is the Laboratory Director&#39;s Notes section of a Patient Results Report according to a further embodiment. In some embodiments, a Patient Results Report may include a section with some information regarding the patient (e.g., name, date of birth, disease stage, and date of service), the patient&#39;s physician, and any notes from a laboratory director. In some embodiments, this is the first page of a Patient Results Report. 
     2. Section 2—Laboratory Results 
     In some embodiments, Section 2 ( FIGS. 4, 9A, and 9B ) may present the values of some or all tested chemistries and where they fall within the normal range.  FIG. 4  is the Laboratory Results section of a Patient Results Report according to one embodiment. In the example depicted in  FIG. 4 , the Patient Results Report depicts results from a renal panel. For results that are within a normal range, the result is depicted under the heading “Normal.” An example of this is the Albumin value  410 . 
     In one embodiment, when a value is below the normal range, the value is displayed to the left of where a “Normal” value would be displayed. For example, see the CO 2  value  420 . In a further embodiment, a below-normal value is positioned further left the further below normal it is. Thus, in such embodiments if the value is only slightly below the normal range, it will be positioned only slightly left of center. But if the value is further below normal, it will be positioned further left of center. 
     In one embodiment, when a value is above the normal range, the value is displayed to the right of where a “Normal” value would be displayed. For example, see the Creatinine value  430 . In a further embodiment, an above-normal value is positioned further right the further above normal it is. Thus, in such embodiments if the value is only slightly above the normal range, it will be positioned only slightly right of center. But if the value is further above normal, it will be positioned further right of center. 
     In a further embodiment, when a value is significantly above or below the normal range, an attention-grabbing shading is presented beside the numerical value. Such a shading may be dark, bright, red, black, or any color scheme that may serve to attract the attention of the reader. A benefit of such a feature is that it may alert the reader (such as a doctor or other medical provider) that the value is far outside the normal range. An example can be found in the Total Protein value  440 . 
       FIGS. 9A and 9B  is the Laboratory Results section of a Patient Results Report according to a further embodiment. In addition to the features described above in connection with  FIG. 4 , the Patient Results Report depicted in  FIGS. 9A and 9B  contains additional features. For example, the Report provides information regarding the patient&#39;s stage of CKD and the date of service  910 . Further, the Report provides additional data regarding the blood sample from which the results were obtained, such as blood draw date, draw time, and whether the patient was fasting  920 . Such additional data may be relevant to evaluating and providing treatment to the patient; thus providing such data to the reader of the Report can be beneficial. As will be understood by others skilled in the art, removing and/or adding other data to/from the report is within the scope of the invention. 
     3. Section 3—Summary eGFR With Treatment and Follow-up Options 
       FIG. 5  is the portion of a Patient Results Report displaying summary eGFR, blood pressure, and proteinuria according to one embodiment. The summary eGFR, blood pressure, and proteinuria depicted in  FIGS. 5 and 10  may graphically present one or more eGFR test results over time, (e.g., from the oldest recorded test to the most recent test). The Summary eGFR may present the eGFR test results in a format that also shows the stage of CKD disease for the patient over time. In one embodiment, the  10  most recent tests are highlighted in brackets. The interval of time to progression to CKD stage  5  is estimated. 
     In addition, treatment and follow-up treatment options regarding the progression of CKD, including medication dosage information, based on eGFR and blood pressure data, relevant medications and demographic data, may be presented. For example, they may be presented in short narrative sentences of treatment advice, as depicted in  FIG. 5 . All reported treatment options are specific to the particular characteristics of the individual patient. The options for treatment may be based on a highly regarded set of guidelines for CKD care, such as the KDOQI™ guidelines established through the National Kidney Foundation and are discussed in more detail herein. In some embodiments, at the bottom of the eGFR test results, spot urine albumin tests for proteinuria, and blood pressure data are recorded sequentially. Other guidelines include the Seventh Report of the Joint National Committee on Prevention, Detection, Evaluation, and Treatment of High Blood Pressure (JNC7) promulgated by the National Heart Lung and Blood Institute of the National Institutes of Health. 
     In some embodiments, an explanation of the report is provided  510 . This may be beneficial, for example, by assisting the reader (e.g., doctor or other medical provider) in using the data provided. Thus, the reader may be able to better utilize the data in providing treatment to the patient. 
     In some instances, the patient has a history of test results. In such cases, the Summary eGFR Report may also include a summary of one or more trends identified from the history of test results  520 . Such a summary may also include one or more caveats, such as limitations resulting from information that is not available. 
     In some embodiments, a report may include treatment options  530 . The treatment options may be the result of analyzing the test results in the context of a set of standard-of-care information and/or other relevant data. 
     In some embodiments, a report may include follow-up options  540 . The follow-up options may be the result of analyzing the test results in the context of a set of standard-of-care information and/or other relevant data. 
     In some embodiments, a report includes one or more sets of test results  550 . In cases where the patient has had multiple instances of a particular test, the report may show the results from these instances. In the report depicted in  FIG. 5 , ten eGFR tests are shown, with the most recent at the top, and descending chronologically. Benefits to displaying multiple test results include the ability to show trends and better understand the progression of the patient&#39;s condition. 
     In some embodiments, a report may include a graphical representation of the test results  560 . The data points on the graphical representation may include data from previous tests. Benefits include the ability to show trends and better understand the progression of the patient&#39;s condition. 
       FIG. 10  is the portion of a Patient Results Report displaying summary eGFR, blood pressure, and proteinuria according to a further embodiment. The report depicted in  FIG. 10  is based on KDOQI™ data. Various embodiments may utilize KDOQI™ or any other set of information that is beneficial. In one embodiment, the report includes information identifying the patient&#39;s stage of CKD  1010 . Further embodiments may contain other information that is helpful to the reader. 
     In the embodiment depicted in  FIG. 10 , the report is based on testing the eGFR, Blood Pressure, and Proteinuria. Such data may be used in generating the summary  1020 . 
     4. Section 4—Summary of Co-Morbidity Status 
       FIG. 6  is a summary of co-morbidity status in a Patient Results Report according to one embodiment. In some embodiments, section 4 of the test results report ( FIGS. 6 and 11 ) provides a “thumbnail” graph of the test results over time for several of the most complex co-morbidities of CKD—e.g., bone and mineral disease, lipidemia, and anemia. Section 4 may also provide options for treatment, again based on the information provided by the physician on the Test Request Form, chemistry results, and the KDOQI™ and other authoritative guidelines or expert judgment. 
     In one embodiment, as depicted in  FIG. 6 , the report includes a summary of the of historical test data  610 . This summary may be generated by methods and systems disclosed herein. For example, the summary may be generated based on historical test data as well as other sources of information, such as medical records. 
     In one embodiment, the report includes a description of the of treatment options  620 . This description may be generated by methods and systems disclosed herein. For example, the description may be generated based on current and historical test data as well as other sources of information, such as medical records. 
     In one embodiment, the report identifies one or more follow-up options  630 . These options may be generated by methods and systems disclosed herein. For example, they may be generated based on historical test data as well as other sources of information, such as medical records and/or standard-of-care data such as KDOQI™ guidelines. 
     In one embodiment, the report includes one or more graphs, which may depict information such as trends of historical test data  640 . These graphs may be generated by methods and systems disclosed herein. For example, the graphs may be generated based on historical test data as well as other sources of information. 
       FIG. 11  is a summary of co-morbidity status in a Patient Results Report according to a further embodiment. Embodiments may include additional information, such as the patient&#39;s stage of CKD, data of service and/or other information  1110 . 
     5. Section 5—Test Results and Treatments for Co-Morbidities 
       FIG. 7  is the Test Results and Treatments section of a Patient Results Report according to one embodiment. In some embodiments, section 5 of the Patient Results Report lists test results ( FIGS. 7 and 12 ) next to the related treatments prescribed by the physician. This section may allow the physician to view the results as he/she changes treatments and thus see how his/her patients are responding to therapy over time. 
     For example,  FIG. 7  depicts a report listing historical test results. For example, such a report may be broken down into sub-parts, such as “Bone &amp; Mineral,” “Lipids,” and “Anemia.” In some embodiments, a report may include historical test data. For example, the report shown in  FIG. 7  lists eight sets of test results under “Bone &amp; Mineral” dating from Jan. 8, 2008 to May 16, 2006  710 . 
     In some embodiments, a report may include information regarding the treatments prescribed to the patient  720 . For example, the report may include a set of treatments along with an indication whether the treatment was prescribed at the time the test was taken. Such a report may be generated using the methods and systems described herein. For example, one or more sets of standard-of-care information (such as KDOQI™ guidelines) may be used to identify commonly-prescribed treatments. 
       FIG. 12  is the Test Results and Treatments section of a Patient Results Report according to a further embodiment. Such further embodiments may include additional information on the report. For example, the report depicted in  FIG. 12  includes the patient&#39;s CKD stage information as well as date of service  1210 . Individuals with skill in the art will recognize that various other relevant information may be provided in various embodiments. 
     The test results report may be provided to the patient&#39;s healthcare provider (e.g., via mail or electronic transmittal). 
     D. Physician Consultation, Feedback and Patient Support 
     In some embodiments, Litholink makes its medical director and other physician experts on its advisory board available to physician users free of charge for consultation about the program. 
     In addition, outcome reports may be sent to physicians at regular intervals—e.g., monthly, quarterly, semi-annually, annually, or at any other interval. The outcome reports may compare the progress made by the receiving physician as compared to the rest of Litholink physician users in ameliorating blood and urine chemistry indicators of kidney disease and its co morbidities. In one embodiment, these reports measure the change in the key chemistries as a surrogate outcome. 
       FIGS. 12A, 12B, and 12C  depict an outcome according to one embodiment. In one embodiment, depicted in  FIG. 12A , the outcome report may provide the percent of measurements made within a range of testing intervals, such as KDOQI&#39;s minimum testing frequency intervals, based on stage of CKD for any number of values, including for example, one or more of:
         PTH   Calcium   Phosphorus   25-hydroxy vitamin D   Carbon dioxide   Hemoglobin on ESA   Hemoglobin, not on ESA   TSAT   LDL   Triglycerides   Hemoglobin A1C   Systolic blood pressure       

     Also, the outcome report may provide the percent of measurement within a standard, such as a KDOQI goal, based on stage of CKD (if necessary). In some embodiments, this information is displayed graphically. An exemplary embodiment is depicted in  FIG. 12A . A benefit is that the graphic representation shows how far each doctor and all doctors as a whole, are within, above or below KDOQI recommended goals. In some embodiments, the graphic image looks like the display on the front page of a Litholink lab results page. Such a report may include information regarding one or more of the following values:
         PTH   Calcium   Phosphorus   25-hydroxy vitamin D   Carbon dioxide   Hemoglobin on ESA   Standard deviation of hemoglobin on ESA   Hemoglobin, not on ESA   TSAT   LDL   Triglycerides   Hemoglobin A1C   Systolic blood pressure   Standard deviation of systolic blood pressure       

     In some embodiments, the outcome report may provide information related to the percentage of patients with a particular trait, such as a disease, condition, or medication. This information may be displayed graphically. Examples of how this information is displayed can be found in  FIG. 12A . For example, it may show how far each doctor (and/or all doctors as a whole) are within, above, or below one or more recommended goals (e.g., KDOQI recommended goals). In one embodiment, the graphic image looks like the display on the front of a Litholink laboratory results page. In various embodiments the report includes one or more of the following:
         Diabetics:
           on ACE/ARB   with urine protein measured   with systolic blood pressure&lt;130   
           Non-diabetics:
           on ACE/ARB   with urine protein measured   with systolic blood pressure&lt;130   
           Person on:
           active vitamin D   low phosphate diet   calcium based phosphate binder   non-calcium based phosphate binder   alkali   ESA   diuretic   statin   fibrate   niacin   
               

     In some embodiments, the outcome report includes one or more graphs. Six examples of such graphs are shown in  FIG. 12B . The graphs may display any information suitable to be displayed in graphical format. For example, the report may include one or more of the following graphs:
         Delta Systolic Blood Pressure vs. Initial Systolic Blood Pressure   Delta PTH vs. Initial PTH   Delta LDL vs. Initial LDL   Delta TSAT vs. Initial TSAT   Delta CO 2  vs. Initial CO 2      Delta Phosphorus vs. Initial Phosphorus
           closed circle: phosphate binder   open circle: no phosphate binder   square: on active vitamin D   
               

     In some embodiments, the outcome report includes a list of patients in need of follow-up tests. An example of such a list is depicted in  FIG. 12C . Some embodiments provide a list for each physician of patients in need of follow-up tests within one or more time frames (e.g., three months, six months, twelve months). Some embodiments provide an opportunity for a physician to indicate information. For example, the report may provide the opportunity for a physician to indicate one or more of the following indications regarding a patient: that the patient started dialysis, that the patient had a kidney transplant, that the patient left the care of the physician, or that the patient died. 
     The Litholink program may also include a patient compliance program in which letters are automatically sent to patients who have not complied with a physician&#39;s order, e.g., failed to get blood drawn or urine collected. In one embodiment, the Litholink program sends lists of patients to physicians that have not had follow-up after therapy has been initiated. Diet and other patient education materials from the National Kidney Foundation are also provided by Litholink to patients. 
     System Architecture According to One Embodiment 
     In some embodiments, the systems and methods described herein may be executed on a computer-based architecture. An example is SOAR, which is an N-Tier, open architecture, component-based software system using the C# programming language, Microsoft SQL Server 2005 and XML technology.  FIG. 13  depicts the functions handled by the various components of the SOAR architecture, according to one embodiment. 
     In one embodiment, the SOAR architecture includes three tiers. The first tier is the Web Layer  1305 . The Web Layer  1305  may utilize such technologies as XSLT, AJAX, ASP.Net, and/or other suitable technologies known in the art. A second tier is the Middle Tier  1310 . The Middle Tier  1310  may utilize such technologies as .Net and C#. In other embodiments, the Middle Tier  1310  may use various other platforms, such as Web Sphere. A third tier is the Data Layer  1315 . The Data Layer  1315  may utilize Microsoft SQL Server technology. In other embodiments, the Data Layer  1315  may utilize any other suitable database technology known in the art, such as Sybase, Oracle, or DB2. 
     A. Web Layer 
     In some embodiments, the Web Layer in  FIG. 15  includes a User Interface (UI) layer. The UI layer may reside on a server, such as, for example, a server running IBM Web Sphere or Microsoft&#39;s Internet Information Services. The server may communicate to the Presentation Layer through the Middle Tier gateway  1530 . The Web Layer may communicate through a web browser, such as Internet Explorer, Mozilla Firefox, or other browser technology. In some embodiments, the communication takes place using one or more of: the native XMLHttpRequest object, JavaScript, XSLT, AJAX, or any appropriate syntax technology known in the art that is capable of generating from the SOAR XML different types of output. The output may include one or more of: HTML, Silverlight objects, or any other appropriate format known in the art, such as XML, email, plain text, PDF, or others. 
     B. Middle Tier 
     Some embodiments include a Middle Tier  1310 . The Middle Tier  1305  may include a Presentation Layer (also known as a service layer). The Presentation Layer may include a Request Handler  1320 . The Presentation Layer may include a Response Builder  1325 . 
     In some embodiments the Request Handler  1320  is a software program executable on a computer. The Request Handler  1320  may receive data representing a request. The Request Handler  1320  may perform tasks including one or more of the following: exception handling, navigation, security, and role management. 
     In some embodiments, the Response Builder  1325  is a software program executable on a computer. The Response Builder  1325  may perform tasks including one or more of the following: exception handling, navigation, security, and role management. The Response Builder  1325  may provide information responsive to a request. The response may be in any appropriate format known in the art, such as XML, HTML, email, plain text, PDF, or others. 
     In some embodiments, the Middle Tier  1305  includes a Report Layer  1330 . The Report Layer  1330  may include any number of types of reporting functionality. For example, the Report Layer  1330  may include outcome reporting and/or patient reporting. In some embodiments, the Report Layer  1330  includes internal reporting. The reports provided by the Report Layer  1330  may be in any appropriate format known in the art, such as XML, HTML, email, plain text, PDF, or others. 
     The Middle Tier may include a Business Logic Layer. The Business Logic Layer may include one or more software programs executable on a computer. The components of the Middle Tier  1310  may reside on a different computer (or set of computers) as the components of the Web Layer  1305 . Or they may reside on the same set of computers. In other embodiments, there may be an overlap, such that some components of the Web Layer  1305  may reside on the same computer(s) as some components of the Middle Tier  1310 . 
     The Business Logic Layer may include a Transaction Controller  1335 . The Transaction Controller  1335  may receive data, such as request data, from the Request Handler  1320 . The Transaction Controller  1335  may perform operations on the data it receives. For example, the Transaction Controller  1335  may perform formatting on the request. In some embodiments, the Transaction Controller  1335  may route the request to a Command Processor  1340  or other system for processing. 
     In some embodiments, the Business Logic Layer includes a Command Processor  1340 . The Command Processor  1340  may receive a request from the Transaction Controller  1335 . In some embodiments, the Command Processor  1340  performs one or more operations in response to the request. In some embodiments, there are one or more custom Command Processors. These custom Command Processors may operate for processing certain types of requests and/or commands. 
     C. Data Layer 
     Some embodiments include a Data Layer  1315 . The Data Layer may include a Data Access Layer. The Data Access Layer may include one or more software programs executable on a computer. The components of the Data Layer  1315  may reside on a different computer (or set of computers) as the components of the Web Layer  1305  and/or the Middle Tier  1310 . Or they may reside on the same set of computers. In other embodiments, there may be an overlap, such that some components of the Web Layer  1305  may reside on the same computer(s) as some components of the Middle Tier  1310  and/or some of the components of the Data Layer  1315 . 
     In some embodiments, the Data Layer  1315  comprises a database, such as SQL Server provided by Microsoft, DB2 provided by IBM, or Oracle Database provided by Oracle Corporation. Some embodiments include one or more Data Entities  1345 . The Data Entities may receive commands from a Command Processor  1340 . Further, the Data Entities may communicate with one or more Data Components  1350 . The Data Components  1350  may include an auditing functionality and/or a table map. 
     In some embodiments, the Data Components  1350  may communicate with a database, such as the SOAR Database  1355 . The SOAR Database  1355  may be any database known in the art, such as those described herein. The SOAR Database  1355  may include information related to standard-of-care, such as KDOQI™ data. The SOAR Database  1355  may also include historical test data. In various embodiments, the SOAR Database  1355  includes various types of data necessary to generate laboratory reports as described herein. In some embodiments, the SOAR Database  1355  is in communication with one or more additional systems, such as a billing system  1360 . In some embodiments, the Data Component  1350  is in communication with a Machine Controller  1365 . 
     In some embodiments, the Middle Tier  1310  and Data Layer  1315  have one or more common features  1370 . These common features may include one or more of the following: performing calculations, performing translations, configuring the application, configuring the system, operations related to a domain-specific language, logging, tracing, email, FTP, fax, operations related to support tickets, or various utilities. 
     Web Software Infrastructure According to One Embodiment 
     As discussed herein, some embodiments may be executed on a computer-based architecture such as SOAR, which is an N-Tier, open architecture, component-based software system using C#, SQL server 2005 and XML technology.  FIG. 14  depicts an ADO.NET software architecture that can be used to provide the application with access to the data stored in a database, according to one embodiment. 
     In one embodiment, a set of computer components is provided to allow applications, such as those that create the laboratory reports described herein, to access data and data services. One such set of components is the ADO.NET architecture provided by Microsoft Corporation. ADO.NET provides a set of classes that allow application programmers to access data in a database such as Microsoft SQL Server or Oracle database. 
     In some embodiments, the ADO.NET framework  1410  is used to provide access to data. For example, the application containing logic for generating laboratory reports may utilize ADO.NET classes to access data necessary to make its calculations. The ADO.NET classes may pull data from the database and store it in a DataSet object, which functions similarly to a relational database. When the DataSet object is populated, the application can perform operations on data stored therein, rather than requesting it from the database. This can have benefits such as speed and efficiency. 
     The ADO.NET framework  1410  may have access to data stored in one or more tables  1420 . In addition, the ADO.NET framework  1410  may have access to one or more functions  1430 . Further, the ADO.NET framework  1410  may have access to one or more views  1440 . Also, the ADO.NET framework  1410  may have access to one or more stored procedures  1450 . Additionally, the ADO.NET framework  1410  may have access to one or more extended stored procedures  1460 . 
     In various embodiments, one or more software components are included.  FIG. 15  depicts the interaction between software components according to one embodiment. In the embodiment depicted in  FIG. 15 , a user logs into a web-based system  1505 . The user may be a patient, medical provider, insurer, or other entity. In various embodiments, the information presented to the user varies based upon who the user is. 
     Various components may be used in order to provide the information to the user in a particular form. In one embodiment, a web scripting language such as JavaScript  1510  is used to perform logical functions in connection with requests made by the user. The JavaScript code  1510  may interact with a Extensible Stylesheet Language Transformations (XSLT) filter  1515  that enables XML documents to be transformed into a different format. The XSLT filter  1515  may interact with one or more utilities  1520 , such as an XSLT template library, one or more cascading style sheets (CSS), images and other media, and a JavaScript library. In some embodiments, one or more of the components herein mentioned work together to provide information to the user. 
     The information provided to the user may take a variety of forms. For example, the information may include options from which the user may select. If a user selects an option, such as to produce a particular report, additional components may come into play. For example, the JavaScript code  1510  may interact with a web application such as an Asynchronous JavaScript and XML (AJAX) utility  1525 . In some embodiments, the JavaScript code  1510  executes an XMLHttpRequest call  1525  in order to send a request to a web server. The XMLHttpRequest call  1525  may serve to request data from the server and load the response back into the scripting language (e.g., JavaScript). 
     The XMLHttpRequest call  1525  may communicate with a web server, such as IBM Web Sphere or Microsoft&#39;s Internet Information Services (IIS). In one embodiment, an IIS server is used for the web server. In one embodiment, an ASP.NET application  1530  is running on the IIS server. The ASP.NET application  1530  may receive the request from the XMLHttpRequest call  1525 . Further, the ASP.NET application  1530  may retrieve the data requested and provide it to the XMLHttpRequest call  1525 , which provides it to the JavaScript code  1510 . In some embodiments, the XSLT filter  1515  as well as other relevant utilities  1520  are used to format and present the data. 
     In some embodiments, the ASP.NET application  1530  interacts with a Report Preview application  1535 . The Report Preview application  1535  may also be an ASP.NET application. In some embodiments, the Report Preview application  1535  is executed on the IIS server. The Report Preview application  1535  may interact with other utilities in the Report Layer  1540 . 
     The Report Layer  1540  has one or more functions in various embodiments. For example, the Report Layer  1540  may include outcome and patient reporting. In some embodiments, the Report Layer  1540  includes internal reporting. As will be apparent to those of skill in the art, various types of reporting may be provided in different embodiments. 
     Some embodiments include common features  1545  that may be shared by one or more components. These common features  1545  may include one or more of the following: performing calculations, performing translations, configuring the application, configuring the system, operations related to a domain-specific language, logging, email, FTP, fax, operations related to support tickets, or various utilities. 
     Application Infrastructure According to One Embodiment 
     In some embodiments, an application is provided. The application may leverage the SOAR framework described herein. One example of such an application is the Litholink CKD application provided by Litholink Corporation.  FIG. 16  depicts the Litholink application infrastructure according to one embodiment. 
     In some embodiments, the Litholink application utilizes one or more SOAR components. For example, the Litholink application may utilize the SOAR Intranet component  1605 . In one embodiment, the Litholink application utilizes the SOAR Web Service component  1610 . In one embodiment, the Litholink application utilizes the SOAR Windows service component  1615 . In various embodiments, the Litholink application may utilize one, both, or all three components. 
     A. SOAR Intranet 
     In one embodiment, the Litholink application utilizes the SOAR Intranet component  1605 . There may be one or more workstations  1620  capable of providing access to the SOAR Intranet  1605 . The workstations  1620  may be used to interact with components of the SOAR Intranet  1605 . The interaction may take place as described in connection with the discussion of  FIG. 15 , herein. 
     One embodiment includes a Machine Controller  1625  and one or more pieces of Lab Equipment  1630 . The Machine Controller  1625  may communicate with one or more components of the SOAR Intranet  1605 . The Machine Controller  1625  may also communicate with the Lab Equipment  1630 . The Lab Equipment  1630  may include any type of hardware used to test a specimen. In one embodiment, a component of the SOAR Intranet instructs the Machine Controller  1625  to provide data from the Lab Equipment  1630 . The Machine Controller  1625  is communicatively connected to the Lab Equipment  1630  via a wired or wireless connection in order to send and receive instructions and data. 
     In some embodiments, a billing software is also used. In the Litholink application the billing software is LithoBill  1635 . LithoBill  1635  may be communicatively connected to one or more components of the SOAR Intranet  1605 . LithoBill  1635  may have access to data collected and provided by SOAR Intranet  1605 . 
     In some embodiments, information such as reports (e.g., outcome reports), bills, or other communication, is provided to users. One way this can be done is via email delivery  1640 . Other means, such as fax, instant message, or any other known communication means may be used. Because this information is often sensitive, encryption may be used to secure the communication. In one embodiment, ZixCorp encryption  1645  is used. 
     B. SOAR Web Service 
     According to the Worldwide Web Consortium, a Web Service is “a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.” 
     In some embodiments, a SOAR Web Service  1610  is provided. The SOAR Web Service may be used to provide reports. For example, it may be used to provide LabCorp Legacy Reports  1650 . These reports may be provided to users in any way known in the art, e.g., via a HyperSend interface. 
     C. SOAR Windows Service 
     A Windows Service is a process that runs on a computer running the Microsoft Windows operating system that performs one or more specific functions and is typically designed not to require user interaction. Often Windows Services are executed upon startup and run until the computer is shut down. Windows Services are analogous in some ways to a Unix daemon process. Sometimes Windows Services are referred to as “background” processes. 
     In some embodiments, a SOAR Windows Service  1615  is provided. The SOAR Windows Service  1615  may allow various systems to interact with it. For example, an HL7 AP Gateway Interface (EDI interface to LabCorp or other electronic medical record providers)  1655  may interact with the SOAR Windows Service  1615 . Additional systems that may interface with the SOAR Windows Service  1615  include one or more of: an FTP Interface  1660 , a Fax Server  1665 ; and one or more e-Filing Scan Stations  1670 . 
     A Patient Data Flow According to One Embodiment 
     In some embodiments, a patient provides a specimen to an entity such as Litholink or LabCorp, and a report, such as a Disease-Specific Patient Report (DPR) is produced as a result.  FIG. 17  depicts a patient data flow according to one embodiment. 
     In order to produce a report, such as a DPR, the patient first provides a specimen. In one embodiment, the patient provides a specimen to a Patient Service Center (PSC)  1705 . The PSC  1705  then provides the specimen to a laboratory location, such as a LabCorp Branch  1710 . The LabCorp Branch  1710  may perform one or more tests on the specimen. In one embodiment, the LabCorp Branch provides the specimen and/or data related to the specimen to another location, such as Litholink  1715 . 
     Alternatively, the patient may be provided with a collection kit  1720  in order to collect and provide his/her own specimen. In one embodiment, a CKD kit is provided, the contents of which are listed in Table 1. A benefit to this method is that the patient is not required to visit a PSC in order to provide the specimen. The patient may then provide the specimen to a provider  1715  such as Litholink via a carrier  1725  such as Fedex, UPS, or any other entity capable of transporting a specimen. 
     
       
         
           
               
             
               
                 TABLE 1 
               
               
                   
               
               
                 CKD Kit Contents 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
               
            
               
                   
                 CKD Patient Sample Shipping Box 
               
               
                   
                 Foam cooler 
               
               
                   
                 Biohazard big 
               
               
                   
                 Absorbent pad 
               
               
                   
                 1-2 Cold packs 
               
               
                   
                 FedEx shipping label 
               
               
                   
                 Patient Test Forms 
               
               
                   
                 Phiebotomist Instructions 
               
               
                   
                 Sticker of bank to seal foam cooler 
               
               
                   
                 Lavender Top (EDTA) Tube 
               
               
                   
                 Gold Top (SST) Tube 
               
               
                   
                 White TOP (PPT) Tube 
               
               
                   
                 Orange Top Spot Urine Tube 
               
               
                   
                   
               
            
           
         
       
     
     According to one embodiment, when the provider  1715  receives the specimen it utilizes the SOAR infrastructure in order to process the specimen. In one embodiment, the specimen is accessed  1730  in order to begin processing. The specimen may take on a variety of forms, e.g., blood, urine, or others. The form of the specimen plays a role in determining how to handle the testing results from the specimen. 
     After accessioning the specimen  1730 , the specimen is tested  1735 . In various embodiments, any number and/or type of tests may be run on the specimen. Running the tests  1735  generates data related to the specimen. The data may include data such as the amount of glucose in the sample, the amount of creatinine in the sample, the red cell count, and/or any number of other values. 
     In some embodiments, quality control and/or quality analysis is performed  1740 . Due to the critical nature of the test data, it is important for the data to be accurate. 
     For various testing panels the physical testing and test result quality control may be handled by a testing facility, such as a LabCorp branch. In some embodiments, the raw outcome data is transmitted via HL7 to Litholink&#39;s SOAR servers. Disease-specific interpretation and additional quality control will take place thereafter. 
     In some embodiments, after the test data is generated  1735  (and QC/QA  1740  is performed, if necessary), a DPR is generated.  1745 . In order to create a DPR, the data is interpreted. In various embodiments, the data may be interpreted in a variety of ways. In one embodiment, a Medical Domain-Specific Language (MDSL) is used. 
     In one embodiment, a MDSL Matrix  1750  is utilized. As described herein, a matrix structure provides an effective and efficient way to evaluate the numerous conditions associated with the test results. A MDSL Interpreter  1755  may also be used. In one embodiment the MDSL Interpreter  1755  is a software program that understands the MSDL Matrix and protocol and drives the analysis of the patient related time-sequential outcome data and previous interpretations. Interpretations by the interpreter rely on the MDSL Matrix  1750  and system wide configurations  1760  about settings, such as one or more of: chemistries, cut-points, reference ranges, or other settings. Further, the MDSL Interpreter  1755  may communicate with the MDSL Matrix  1750 . In some embodiments, the MDSL Interpreter  1755  requests and receives the medical protocol data from the MDSL Matrix  1750  and time sequential test data from the patient data  1765 . Other information from KDOQI™, ATP III or other standard-of-care sources is embedded in the medical protocol of the MDSL Matrix  1750 . 
     In some embodiments, the MDSL Interpreter  1755  provides Patient Data  1765 . The Patient Data  1765  may be in XML format. It may include such information as a sample list, a result list, order information, medical history, or other relevant information. Other data provided to the MDSL Interpreter  1755  may include Chemistry Configurations  1770 . These may also be in XML format. The Patient Data  1765  and Chemistry Configurations  1770  may be used to create a DPR. 
     After the DPR is created  1745 , it may be reviewed  1775 . The review may be for quality control purposes. Due to the critical nature of the information contained in a DPR, it is important for it to be accurate. 
     After the DPR has been created  1745  and reviewed  1775 , it may be provided  1780 . In some embodiments, a system is provided for the DPR to be signed out and delivered  1780 . The DPR may be delivered in any number of ways, such as in HL7 format, via email, via fax, via postal mail, via instant messenger, or in any other way known in the art. 
     A Patient-Specific Treatment Options Software System According to One Embodiment 
     A. Options for Treatment 
     In some embodiments, the “treatment options” shown in the patient results reports at  FIGS. 5-6 and 10-11  are produced by a software system containing algorithms which are able to direct a computer&#39;s search for the correct option for treatment for the specific patient from multiple data bases, taking into account that patient&#39;s prior test results, demographic information, and treatments. The medical advice may be based on a set of guidelines, such as those established over several years in a process created and managed by the National Kidney Foundation (NKF) specifically to gather and recommend best CKD treatment practices from data in the scientific literature and from experts in CKD. The NKF&#39;s KDOQI™ convened panels of experts in CKD and related fields and produced 12 clinical practice guidelines for the five stages of chronic kidney disease, its complications and co-morbidities. The KDOQI™ guidelines are recognized by leading public health authorities and medical societies as the most comprehensive and authoritative guide to CKD treatment. 
     For its treatment recommendations on cardiovascular disease related to CKD, in one embodiment, treatment options are based on the guidelines initiated by The National Heart, Lung and Blood Institute of the National Institutes of Health and developed in the “Third Report of the National Cholesterol Education Program Expert Panel on Detection Evaluation and Treatment of High Blood Cholesterol in Adults” (ATP III). In a limited number of areas of CKD treatment where the KDOQI™ or ATP III guidelines are incomplete, experts, such as those from a national panel of experts convened by Litholink, may provide the treatment suggestion. An example of such a national panel of experts may include the National Expert Advisory Panel on CKD, which is represented by Table 2, but the experts&#39; names have been replaced by hypothetical names. 
     
       
         
           
               
             
               
                 TABLE 2 
               
               
                   
               
               
                 CKD Board Member Scientific Advisory Board 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
               
            
               
                 John Doe, MD 
                 John Public 
               
               
                 Medical Director, Litholink 
                 Chief Executive Officer, 
               
               
                 Laboratory Corporation of America 
                 Laboratory Corporation 
               
               
                 jdoe@domain.com 
                 of America 
               
               
                   
                 jpublic@domain.com 
               
               
                 Perry Mason, MD 
                 Florenz Meyer, MD 
               
               
                 Professor, Adult and Pediatric 
                 Professor, Division of 
               
               
                 Endocrinology, Diabetes, Metabolism 
                 Nephrology, St. Paul&#39;s Hospital, 
               
               
                 Department of Medicine, University 
                 University of British 
               
               
                 of Chicago Pritzker School of 
                 Columbia, Vancouver, Canada 
               
               
                 Medicine 
                 fmeyer@domain.com 
               
               
                 Chicago, IL 
               
               
                 pmason@domain.com 
               
               
                 Travis McGee, MD 
                 Della Street, MD 
               
               
                 Chief of Clinical Research, Denver 
                 Chief Executive Officer, Litholink 
               
               
                 Nephrology, Associate Clinical 
                 Vice President, Laboratory 
               
               
                 Professor Medicine, University of 
                 Corporation of America 
               
               
                 Colorado Health Sciences Center, 
                 dstreet@domain.com 
               
               
                 University of Colorado, Denver, 
               
               
                 Colorado 
               
               
                 tmcgee@domain.com 
               
               
                   
               
            
           
         
       
     
     Using an embodiment of the invention may improve the quality of care of chronic kidney stone patients. Although treatment guidelines from KDOQI™ and ATP III are posted on the official guideline site of the National Guideline Clearinghouse of the Agency for Health Research and Quality (AHRQ), they consist of hundreds of pages of lengthy and complex narratives and are not conveniently usable at the point of care for most physicians, particularly primary care physicians. Kidney disease is highly complex and each patient presents different variables affecting treatment. It has long been acknowledged that physicians need uniform evidence based guidelines for care and computerized decision support to implement them. They need their specialty&#39;s guidelines sorted out and presented in patient relevant terms at the point of care. 
     B. Summary of the Construction of the Treatment Option Software Program 
     In some embodiments, the Litholink software is able to produce patient-specific treatment recommendations through the use of linked matrix trees written in XML that simultaneously interrogates entire grids of logic for different CKD diseases, treatments and results. Test results may be evaluated by the system based on one or more of three key inputs: (1) whether test results are below, within or above KDOQI™ or ATP III guidelines, (2) whether medication is being used and (3) whether test results have changed from prior test results in a material way. In some embodiments, short, substantive medical content “tags” of narrative advice are condensed from the guidelines for the software matrix which then pulls the relevant tags for the specific patient condition. Cross-references and the testing of other conditions, made possible by this syntax, may make the tags complete, intelligent, and medically accurate. 
     In one embodiment, a logical if-then-else or switch statement arrangement is used. In another embodiment, a matrix approach is used in constructing the program. In one embodiment, the matrix approach interrogates multiple conditions at once, allows for the call of additional sub-matrixes, and uses its own short-hand language to reference conditions and tests outside the matrix. A benefit of the matrix approach is increased speed and programming efficiency. 
     In one embodiment, the entire syntax is driven by extensible markup language (XML). The medical information matrix and logic is not embedded within the software code. The software code utilizes a domain-specific language developed by Litholink for the medical community. In one embodiment, the domain-specific language is embedded in Litholink&#39;s protocol. The XML document feeds the software and can be extended without additional compilation of the program. Medical instructions may be built by tags, which represent segments within the XML document. The segments have instructions about KDOQI™ references, follow-up measurements, timeframes, and the actual representation of the text displayed in the final outcome report. 
     C. Specific Components of the Software System 
     1. Matrix Logic 
     In one embodiment, the matrix syntax uses a structured approach of interrogating conditions, responses, time-sequential data or other defined medical information.  FIG. 18  provides an illustration of an example of the matrix logic. Any matrix block allows the software to cover every possible permutation for the condition in question. It allows the system to query sub matrixes infinitely and to cross reference. The software code is completely separated from the medical instruction. The following is specific to one embodiment of the Litholink CKD matrix: 
     a. Domains 
     The CKD matrix is separated into medical domains. The domain order defines the output order. Each domain has primary chemistries, which are needed for the interpretation and are represented individually. Changes to previous testing are recorded and evaluated. 
     b. Paragraph 
     Each paragraph segment is handled like an individual object. The outcome is stored and tracked by the system. Segment order, follow-up measurements and timeframes are prioritized by the matrix. 
     c. Matrix 
     The matrix syntax is developed in C# code in conjunction with a domain specific programming language embedded into the Litholink XML matrix protocol. The domain-specific language, special tests, calculations, instructions, and short hand syntax are interpreted in the software. The matrix language and paragraph text are stored in the XML matrix. The matrix structure is defined within the matrix itself to enable self-awareness and flexible expansion at any time. The matrix query, to allow the interrogation of multiple conditions at once, is driven by XPath (XML query syntax) in conjunction with C# (Microsoft .Net framework, version 2.0, 3.0, etc.). Chemistry results, normal ranges (also known as reference intervals) and condition evaluations are based on Litholink&#39;s SOAR framework. SOAR is Litholink&#39;s proprietary software framework managing the entire IT infrastructure from patient call questionnaires, management reporting, billing, to laboratory information solutions. 
     2. Matrix Protocol 
     In one embodiment, Litholink&#39;s medical matrix protocol is defined as an XML structure. For this documentation, the structure of nested nodes is visualized with the help of Altova® XMLSpy®&#39;s grid view (see below). Litholink&#39;s medical matrix protocol may use the namespace “xmlns:LL=“http://www.litholink.com/dsl” for the CKD program. A xsd schema was defined for the protocol in one embodiment of the invention. 
     A Protocol Overview is illustrated in  FIG. 19 . 
     a. Active Domain List 
     In one embodiment, the Active Domain List (LL:ActiveDomainList) defines the domain nodes (LL:Domain) to be used actively for the medical protocol. The Active Domain List, along with the identification as described below, is shown in  FIG. 20 . The following domain nodes are defined in one embodiment of the invention: 
     1. Disease ID: The Disease ID (DiseaseID) defines for our framework the disease (condition) the patient is evaluated for. All outcome matrix results are stored separately by disease. 
     2. Active Domain: The Active Domain (ActiveDomain) lists one or more active domains by its “Type” name in the LL:Domain node. The active domain is the entry point for the protocol to investigate samples. It is the entry point of its self-awareness (see explanation above; more details under “Matrix” and “Sub Matrix” below). 
     b. Domain 
     In one embodiment, the domain is identified in the active domain list. The identification is shown in  FIG. 20 . 
     1. Type: Each domain called by the active domain list (see above) has a “Type” identifier. 
     2. Sample Type: Patients have different types of samples brought to us as a laboratory. Sample types could include (urine, serum, spot urines, etc.). Each medical domain interrogates similar chemistries, measurements, or other order information. The basic sample type is defined for each domain. Unless specified in the domain-specific language or protocol the chemistries default for each domain to this sample type. 
     3. Assessment List 
     The assessment list (AssessmentList) defines the components, which are listed and investigated in the assessment paragraph of our outcome reporting. The Assessment node lists the chemistry. Each chemistry shows a value display definition and whether the value has changed over time and is within the medical guidelines (cut points for the guideline and the guideline types are defined for each chemistry in our SOAR framework definitions.) The reported value (ReportedValue) lists information gathered from the physician office or other medical facility, which are submitted in any number of ways, such as via order form or electronic records (HL7). The reported values are used in conjunction with chemistries and determine the outcome reporting, hence reporting back these values are essential. An assessment list is shown in  FIG. 21 . 
     4. Additions (Overrides) 
     In one embodiment, “additions” are additional or overriding sentences which are unique, depend on one significant medical condition only, or are true for every situation. Each overriding or additional “Sentence” is interrogated for each paragraph types (Type). There are currently three paragraph types or parts: “Assessment”, “Treatment”, and “Follow-Up”. The “Position” may determine whether the sentence should appear at the beginning or the end of the paragraph part. The “Tag” may define additional segments to be called for the “Treatment” section (see more details and triggers handled by the segments below). The “Condition” may be the interrogating condition, which is optional. The condition has to be fulfilled in order to trigger the “Tag” to be added and/or the “Text” to be added to the paragraph part (see “Conditions &amp; Domain-specific language” for more details about the condition evaluation). Additions are shown in  FIG. 22 . 
     5. Follow Up (Definitions) 
     In one embodiment, follow-up definitions are unique for each domain. This part of the protocol may describe the time frame for individual follow-up commands, which are called in the “Segment List” or the “Additions” section. The “Tag” may identify the timeframe. In one embodiment, “Desc” describes in English the words for the outcome report, which apply to the called timeframe. “Weeks” may define for the system the exact time as a measurable value. Follow Up Definitions are shown in  FIG. 23 . 
     In one embodiment, “Measurement” describes the panel type which is called with the timeframe (ex. “M5-T1”=CBC is due now). “Tag” may identify the measurement. “KDOQI™” indicates whether this was a guideline-specific panel. “PrimaryChemistry” identifies one chemistry from the given panel. Setting the “primary chemistry” may allow the system to check whether the panel was tested completely. In one embodiment, the SOAR framework ensures through our quality assurance process that all chemistries are reported together in one panel. Checking one primary chemistry may indicate the entire panel is present. “Desc” may describe in English (or another language) the words for the outcome report. 
     6. Segment List 
     In some embodiments, the segment list contains one or many segments specific for the medical domain. A segment list and segments are shown in  FIG. 24 . 
     7. Tag Identifier 
     In some embodiments, the segment has a “Tag” identifier, which is unique within the domain. “KDOQI™” identifies whether the instruction in the “Text” node is guideline-based or not. “Measurement” may contain the domain-specific language (DSL) for Litholink&#39;s matrix protocol. Though primarily used to identify measurements and timeframes (see Follow-Up for details), the syntax could trigger other segments and condition interrogations (see “Conditions &amp; Domain-Specific Language (DSL)” for details). “Text” is the information that may be added to the outcome report paragraphs. 
     8. Matrix 
     In some embodiments, “Type” in the Matrix node uniquely identifies the matrix within the structure. A matrix is shown in  FIG. 25 . The following elements are described in accordance with one embodiment of the invention: 
     a. Structure 
     “Structure” defines the matrix layout. The structure identifies for the software language (DSL), what interrogation and condition syntax to build. The syntax is built in form of the XPath query language to select the XML nodes, which contain DSL instructions (see “Conditions &amp; Domain-Specific Language (DSL)” for more details). The “Condition List” defines the all XML elements and their condition description. Condition “types” are “SelectStatus” or “Level”. “Select Status” defines whether a order form information was selected with “Yes”, “No”, or “Missing” (=Unknown). “Level” refers to “H” (=High), “N” (=Normal), “L” (=Low), or “U” (=Unknown/not present). For example the following condition definition “&lt;Condition type=”SelectStatus“&gt;Statin&lt;/Condition&gt;” tells the system to look for a xml node “Statin_yes”, “Statin_no”, or “Statin unknown” based on what the physician or nurse told Litholink on the order form. The attributes for this XPath query, to select the correct node in the matrix, is defined in the “Interrogator List”. 
     “Interrogator List” makes the matrix protocol a powerful and flexible solution. The list contains one or many Interrogators, which define the chemistry or order form information based on its type. Current types available are “SelectStatus”, “Level”, “Evaluation”, “Delta”, and “DeltaRate”. “Select Status” and “Level” are explained above. “Evaluation” has a “condition” attribute defined in the “Interrogator” node. This allows a condition to be medically evaluated and the result could be “Yes” or “No”. “Delta” defines the difference between the current minus the last result for the given chemistry and identifies whether the result is “Increased”, “Unchanged”, or “Decreased”. “DeltaRate” interrogates the same outcome however the delta rate is defined per chemistry over a given time frame only. 
     Interrogators are concatenated by either an “or” or “and” “Evaluation Type”. 
     The Structure tells the system what chemistries to interrogate and how to build the query XPath syntax to identify the correct xml element, which contains the DSL syntax to build a outcome report. 
     b. Condition 
     “Condition” contains the actual matrix with attributes and elements, which result in additional sub matrix calls (see details below) or DSL interpretations. 
     For example: If a patient has a high CO 2  and low K (potassium) value and the physician told us, the patient currently takes “Alkali” medication, the program knows to the syntax “K4, K5”. The exact meaning of this syntax is described below. 
     The amount of conditions, attributes, and elements are absolutely flexible and depend on the way a physician was trained to investigate symptoms and other medical factors. 
     9. Sub Matrix 
     In some embodiments, the sub matrix has the identical structure as “Matrix”. It may contain the “Structure” and “Condition” element. The sub matrix may be used to interrogate further from the main matrix or other sub matrixes only. Each matrix may be self-aware of it interrogation structure. A condition matrix along with a sub matrix as described above, is shown in  FIG. 26 . In one embodiment, a sub matrix is identified as “[name@node]”. The “name” in the sub matrix name may identify the sub matrix “Type” and the “node” directs to the condition element in the condition matrix. 
     10. Conditions &amp; Domain-Specific Language (DSL) 
     In some embodiments, domain-specific language uses a combination of short-hand syntax, comma-separated segments, chemistry identifiers, special “bracket” tests, and keywords to build output sentences. 
     First and foremost, segment tags may be called in comma-separated order to build from individual tags and associated information the outcome paragraph in a sensible and logical order. 
     Second, each segment may contain specific instruction about their measurements. In one embodiment, the measurements are called and stored for each panel by its shortest time frame. If in one xml node the panel “CBC” is called in 3 months and later on another condition triggers the same panel “CBC” to be called in 1 month, “1 month” as the shorter time frame may overwrite the “3 months”. 
     Third, in one embodiment, the short hand condition may contain segments only, bracket tests only, or a combination of them along with logic if-then-else statements. 
     Some examples of Conditions and Domain-Specific Language according to one embodiment of the invention are described below: 
     a. Chemistries &amp; Bracket Tests 
     Bracket tests may look like the following: “[Chemistry!Ca!T3]” or “[eGFRSlope]”. The tests are identified by square brackets and have a multi-part syntax within separated by “!”. The first example identifies the chemistry “Ca” (calcium) for the latest result over 3 months. “T3” identifies the domain-specific timeframe for 3 months. The second example, like many others, spin off into statistical calculations and other standardized medical interrogations and return the results for display or other short-hand statements (see below). 
     b. Shorthand &amp; if-then-Else Statements 
     In some embodiments, the shorthand definitions utilized chemistry and order form definitions from an enterprise framework along with a simple elements such as “(”, “)”, “?”, “:”, “,”, “@”, or “!” to define logical statements. 
     Example: “(Ca greater than 5 ? (Ca equal 6 ? ABC1: ABC2): ABC3), ABC4” 
     In the above example, the syntax reads: If calcium is greater than 5, test if calcium is equal to 6. If this is the case, the segment “ABC1” is added to the outcome report, if not “ABC2” is added. If calcium was not greater than 5, “ABC3” is added. In all cases “ABC4” is added because the segment was outside the if-then-else statement. 
     All logical statements are separated by commas either within a statement, nested statement, or by simply separating segments. 
     c. Keywords 
     Keywords may define part of the domain-specific language (DSL) and interrogate the chemistry results in a medically sensible fashion. In form of a short-hand syntax the keywords are combined in logical structures to see whether chemistries, order form information, other conditions meet the following keyword conditions. A syntax may look like “(Ca less than 5 ? K1: K3)” or “([Chemistry!Ca!T3] normal ? B2, B3, U2: U3)”. 
     The following shows an excerpt of Litholink&#39;s keywords: firsttime (=checks whether the given condition appeared the first time for this patient), greater than, less than, equal, not, unknown (selection or a chemistry level is unknown), yes, no, high, low, normal, last, ever (used in conjunction with other keyword to see whether “ever” high, low, etc.), never, count, slope (slope from linear regression calculation), deltarate (present-last chemistry result over a given time frame, which is defined for each chemistry individually), Delta (present—last), within . . . “T . . . ” (used in conjunction with a chemistry), minus (=subtracts to chemistry values from each other before combining with other keywords), CKDStage (guideline-specific stages) 
     GENERAL 
     The foregoing description of the embodiments of the invention has been presented only for the purpose of illustration and description and is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Numerous modifications and adaptations are apparent to those skilled in the art without departing from the spirit and scope of the invention.