Patent Description:
The disclosure generally relates to healthcare related systems, devices, and methods.

Traditional health care systems are based on a fee-for-service model, whereby healthcare providers are compensated on a per-treatment or per-service basis. Under this model, a healthcare provider's compensation increases when the number of provided treatments or services increases. As such, there is no financial incentive for such providers to efficiently manage the number of provided services/procedures, nor is there any financial incentive related to the overall health outcome of the patient. Such traditional systems have led to spiraling healthcare costs and inefficiencies hindering the quality of overall care of the patient.

Moreover, many patients--especially patients with chronic illnesses--engage with a variety of different entities and health care professionals in the course of their diagnosis, treatment, and long-term care management, including hospitals, clinics, laboratories, pharmacies, physicians, clinicians, and/or other specialists. The patients' treatment information may be spread across several entities, repositories, and medical professionals, which can lead to lack of communication, or miscommunication, between the various involved entities, which can detrimentally affect the treatment and health of the patient, possibly even creating life-threatening treatment conditions. Further, this uncoordinated handling of data, and the patient's overall treatment, results in inefficiencies that can lead to increased total cost of care. In this regard, traditional fee-for-service healthcare models are far from ideal with respect to care quality and economics. The latter is evidenced by the untenable continued rise in healthcare costs in the United States under the fee-for-service model.

It is referred to <CIT>, to <CIT>, to <CIT> as well as to a publication "CKD-EPI CREATININE EQUATION (<NUM>)" by the National Kidney Foundation retrieved from the internet via https://www. org/content/ckd-epi-creatinine-equation-<NUM> as prior art.

This Summary is not intended to necessarily identify key features or essential features of the present disclosure. The present disclosure may include the following various aspects and embodiments.

An exemplary embodiment of a method for estimating progression of chronic kidney disease in a patient and applying clinical interventions includes determining historic values of at least one patient parameter that varies as a function of the progression of the chronic kidney disease over time, and computationally estimating a trend corresponding to the historic values. Based on the trend, at least one marker is automatically provided that identifies a clinical intervention and a time in the future when the clinical intervention is expected to be needed. Based on the at least one marker, clinical preparations are executed at a time prior to the administration of the intervention in order to improve at least one of a) timeliness of the execution of the intervention and b) effectiveness of the intervention.

According to various of the foregoing and other embodiments of the present disclosure, the method further includes calculating predicted future values of the at least one patient parameter based on the trend. The method further includes incorporating into a visual chart the at least one marker and at least one of a) the trend and b) the predicted future values of the at least one patient parameter calculated based on the trend. The executing clinical preparations may include providing treatment options to the patient and executing the intervention according to a corresponding treatment decision made by the patient. The at least one patient parameter includes an estimated glomerular filtration rate (eGFR). The trend may computationally estimated by non-linear regression. The trend may be computationally estimated by linear regression.

An exemplary embodiment of a system for estimating kidney disease progression and providing automatic treatment options based on the progression estimation includes an integrated care system. The system is configured to determine historic values of at least one patient parameter that varies as a function of the progression of the chronic kidney disease over time, and computationally estimate a trend corresponding to the historic values. Based on the trend, the system is configured to automatically provide at least one marker that identifies a clinical intervention and a time in the future when the clinical intervention is expected to be needed. The system is configured to cause clinical preparations to be conducted at a time prior to the administration of the intervention in order to improve at least one of a) timeliness of the execution of the intervention and b) effectiveness of the intervention.

The at least one patient parameter is an estimated glomerular filtration rate (eGFR). The historic values of at least one patient parameter may be determined based on information received from an outside system, the information received being at least one of a) the historic values of the at least one patient parameter, and b) data for calculating the historic values of the at least one patient parameter. The system may be configured to identify treatment options for presentation to the patient. The system is configured to calculate predicted future values of the at least one patient parameter based on the trend. The system may be configured to generate a report that may include the incorporated historic and the predicted future values of the at least one patient parameter and the one or more markers; and access the report for identifying the treatment options for presentation to the patient. The system may be configured to calculate actual values of the at least one patient parameter; compare the actual values to respective estimated future values; and adjust the treatment options for presentation to the patient in response to a deviation between the actual values and the estimated future values.

Further features and aspects are described in additional detail below with reference to the appended Figures.

By way of example, embodiments of the disclosed methods and devices will now be described, with reference to the accompanying drawings, in which:.

The present embodiments will now be described more fully hereinafter with reference to the accompanying drawings, in which several exemplary embodiments are shown. The subject matter of the present disclosure, however, may be embodied in many different forms and types of methods and devices for dialysis machines and other potential medical devices, diagnostics, and treatments for various diseases, and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and willfully convey the scope of the subject matter to those skilled in the art. In the drawings, like numbers refer to like elements throughout.

Example embodiments described herein are suitable for implementing value-based care, which is an alternative to the conventional fee-for-service healthcare model. Under a value-based healthcare system (also known as a "pay for performance" model), healthcare providers are provided with financial incentives tied to quality and efficiency of care and patient outcomes.

Some example embodiments are configured to provide coordinated care to a population of patients with a chronic disease, such as chronic kidney disease (CKD). CKD is a progressive disease marked by reduced kidney function. Once the kidney function drops below a threshold, the patient is considered to have kidney failure, or end-stage renal disease (ESRD). ESRD is the final stage of CKD and requires dialysis treatments for the remainder of the patient's life (absent a transplant).

In the United States, one model of value-based care in which example embodiments described herein may be implemented is the Comprehensive ESRD Care (CEC) Model, which is a type of accountable care organization (ACO) model developed under the authority of the U. Center for Medicare and Medicaid Innovation. In order to implement the CEC model, ESRD Seamless Care Organizations (ESCOs) are formed. An ESCO is an ACO that is formed by healthcare suppliers and providers voluntarily coming together. The resulting ESCO is a legal entity that provides coordinated care to ESRD beneficiaries through the CEC model.

Under the ESCO model, the ESCO shares savings and losses incurred by the U. Centers for Medicare and Medicaid Services (CMS) for the ESCO's beneficiaries. Savings or losses are determined by CMS based on an expenditure benchmark, which is derived from a baseline that reflects historical expenditure data for like or similar beneficiaries. The benchmark is compared to the actual Medicare Fee-For-Service (FFS) Part A and B expenditures for the aligned patient population in a performance year. The savings are also subject to an adjustment based on quality performance. Any reduction in costs directly translates to increased shared savings (profits), since the costs are measured against the predetermined benchmark. Quality of care is incentivized by the quality performance adjustment to the calculated shared savings.

The ESCO is responsible for each patient's overall care, which goes beyond dialysis treatments. For example, if a patient is admitted to the hospital for any reason (for example, infections, vascular dialysis access complications, and/or cardiac complications), the cost of the hospitalization counts against the yearly savings calculation. Since hospital admissions are especially costly, it is highly advantageous for ESCOs to keep the patients out of the hospital from a financial perspective. Example embodiments described herein implement a holistic approach to oversee and manage all aspects of the patients' well-being, which improves the quality of care while increasing efficiency of medical resources and overall cost efficiency.

Some example embodiments described herein analyze medical data of the applicable patient population in order to target high-risk patients with interventions to reduce the likelihood of hospitalization. Some examples analyze patient data to predict when a patient is likely to experience a particular health-related event or stage of disease progression and provide/adjust treatment accordingly.

In accordance with example embodiments, patient information may be sent to, managed within, and/or be accessible by, a coordinated care system, so that patients may receive high quality, efficient, coordinated health-care within a managed system that is able to intelligently manage and coordinate the patient's overall care. Incorporation of a coordinated care system may allow for better control of health care costs, e.g., by providing value-based care to patients in place of fee-for-service care. For example, as mentioned above, the population of patients diagnosed with ESRD has been increasing over time, often caused by several other diseases, including but not limited to diabetes, hypertension, and/or glomerulonephritis. Patients living with ESRD may face additional challenges due to the nature of the disease. For example, required lifestyle changes may lead to mental health deterioration. Additionally, at-home treatments may lead to increased isolation from medical professionals. As the healthcare landscape changes, opportunities to provide patients with resources for coordinating treatment may deliver additional patient health benefits beyond dialysis treatment.

Although exemplary embodiments described herein are related to renal diseases, it is understood that coordinated care systems and infrastructures described herein may be applicable to other chronic illnesses as an alternative or in addition to renal disease. Such other conditions may include, as non-limiting examples, cardiovascular related illnesses, pulmonary, gastrointestinal, neurological, urological, or gynecological conditions, diabetes, circulatory diseases, Alzheimer's or other dementias, asthma, COPD, emphysema, cancer, obesity, tobacco use, cystic fibrosis, or combinations thereof. Moreover, although some examples are described with respect to implementations in renal-related ACOs, such as ESCOs, it should be understood that the examples described herein may be analogously implemented in other ACOs with respect to other diseases or patient populations, and/or any other suitable value-based healthcare models.

An exemplary embodiment in accordance with the present disclosure may include a system for estimating and treating progression of CKD. As described below, a coordinated care system may be configured for analyzing individual patient information, comparing various patient data in a patient population, determining a treatment intervention, or projecting future treatment interventions, or combinations thereof. For example, the coordinated care system may estimate events associated with CKD and take appropriate action, including but not limited to informing patients, informing clinicians of when specific interventions may be warranted, outlining proposed treatment intervention options, and/or alerting clinicians to upcoming important dates for treatment interventions. Methods described herein may also include preparing for and/or carrying out such interventions in accordance with the coordinated care system's estimations.

Electronic medical records being stored by a patient's primary care physician, specialty physician, or by a third party, e.g., Acumen® Physician Solutions, may be sent to and/or accessible by an integrated care, or a care analysis and guidance, system. The integrated care system may receive, store, and/or determine relevant demographic and laboratory values for calculations, e.g., calculations of historic estimated glomerular filtration rate (eGFR), which is a patient parameter that is indicative of kidney function, which decreases as CKD progresses. The integrated care system then uses the calculated eGFR values to project future eGFR values (see <FIG>). It is understood that Glomerular Filtration Rate (GFR) may be an indicator of renal function in a patient.

In some embodiments, as patient parameter information is updated, e.g., data points are included in the system, corresponding future or estimated patient parameters may be updated and adjusted accordingly. As the patient has actual eGFR values measured or determined over time, actual eGFR values will replace the predicted future eGFR values. If the patient has made certain adjustments (e.g., lifestyle, dietary, mental health, and/or other changes), an actual eGFR value may not correspond to a future eGFR value that was estimated. As such, the actual or historic eGFR value may then be included in determining further future eGFR values, which may adjust or altogether alter a timeline and any associated actions.

As shown in <FIG>, an integrated care system (e.g., care analysis and guidance system) receives, stores, and/or calculates historic estimated glomerular filtration rate (eGFR) values <NUM> from information and data in an electronic medical record of a patient. Although eGFR values are described with respect to the chart <NUM>, it is understood that other patient parameters may be utilized in a similar manner to generate a corresponding chart for monitoring patient health and future estimations. For example, patient parameters may include any parameters related to a patient's health, e.g., laboratory values, data, other patient information, or combinations thereof.

In some embodiments, the historic eGFR values <NUM> may already be stored in the electronic medical records, while in other embodiments the historic eGFR values <NUM> may be calculatable by components of the integrated care system, based on other data and information provided in the electronic medical records. For example, the EMR may contain laboratory values, physician notes, demographic information, and other information related to a patient's condition. The information may be utilized in determining (e.g., calculating) a historic value for one or more patient parameters.

The integrated care system then uses these historic eGFR values <NUM> to project future eGFR values <NUM>, e.g., as shown with respect to y-axis <NUM>. For example, a chart <NUM> may include a marker <NUM>, e.g., a line divider, visually indicating historic, measured values <NUM> disposed on the left of the marker <NUM>, as indicated by reference numeral <NUM>. Estimated future eGFR values may be disposed on the right of the marker <NUM>, as indicated by reference numeral <NUM>. This may provide a "roadmap" of a patient's future medical treatment recommendations.

The chart <NUM> may be generated as at least a portion of a report, accessible by medical professionals treating a patient. In some embodiments, historic and future eGFR values may be for an individual patient, for generating a chart <NUM>, or report, and in some embodiments, a chart and/or report may be generated for a patient population. For example, historic and predicted future eGFR values may be aggregated for a patient population for additional analysis. Patient data may be analyzed within a specified demographic (e.g., age, race, national original, geographic location), and/or patients at a specified stage of CKD, for larger data trends, that may provide medical professionals with interventional treatment options for an individual patient having similar population characteristics.

In embodiments where the integrated care system calculates historic eGFR values <NUM>, demographic and measured standardized serum creatinine levels from the patients' electronic medical records may be provided to the integrated care system for analysis. According to the National Kidney Foundation, the Chronic Kidney Disease Epidemiology Collaboration (CKD-EPI) creatinine equation is: <MAT>
where eGFR (estimated glomerular filtration rate) = mL/min/<NUM><NUM>, SCr (standardized serum creatinine) = mg/dL, κ = <NUM> (females) or <NUM> (males), α = -<NUM> (females) or -<NUM> (males), min = indicates the minimum of SCr/κ or <NUM>, max = indicates the maximum of SCr/κ or <NUM>, and age = years.

Estimated future eGFR values <NUM> may be based on the historic eGFR values <NUM>, by performing regression on the logarithmic scale. In some embodiments, future eGFR values <NUM> may be estimated by linear or non-linear regression. For example, the historic eGFR values <NUM> may be regressed against a time, e.g., a number of days passed, to determine a trend <NUM> of the historic eGFR values <NUM>. This trend <NUM> may be relied upon to determine the predicted future eGFR values <NUM>, where the values of β<NUM> and β<NUM> are determined via least-squares regression:<MAT>.

The regression coefficients accordingly are utilized to estimate the future eGFR values <NUM>, which are represented as points along the trend line <NUM> (i.e., the regression line), as shown in the chart <NUM> of <FIG>. Additionally, the standard error may be used to determine a confidence interval <NUM> both for the historic eGFR values <NUM> and the future eGFR values <NUM>. The confidence interval <NUM> corresponds to broken lines <NUM> and <NUM> and the range of values disposed therebetween.

When the historic eGFR values <NUM> and the predicted future eGFR values <NUM> have been determined, the integrated care system may utilize this data to provide information to the patient and other medical professionals. For example, the integrated care system may interface with the chart <NUM> to include a visualization of a patient's CKD progression. For example, the marker, or line divider, <NUM> may be added to provide a quick visual reference for a medical professional to see where the historic eGFR values <NUM> end and where the future estimated eGFR values <NUM> begin. In some embodiments, the confidence interval <NUM> may be closer to the known historic eGFR values <NUM> than the future estimated eGFR values <NUM>. For example, the chart <NUM> may show the confidence interval <NUM> closer to the historic eGFR values <NUM> on the measured values side of line divider <NUM>. On the predicted/estimated values side of the line divider <NUM> the lines showing the confidence interval <NUM> may expand outward from the trendline <NUM>, indicating a change in confidence interval <NUM>.

As the predicted future eGFR values <NUM> are estimates, it may be advantageous for the medical professional to see where the estimations begin. The chart <NUM> may also be interactive with the medical professional, so that a user may click and drag a point along the trend line <NUM> to see future eGFR values <NUM>. It may be advantageous to the medical professional to plan for a patient's future treatments for scheduling, as well as to the patient for their own education and understanding of the disease trajectory, and to plan for any potential future costs associated with the treatments. It may also be advantageous to proactively anticipate intervention milestones, so that the interventions can be processed and administered efficiently and timely, perhaps affecting the timeline of the patient's CKD progression, and/or potentially reversing patient parameters.

In some embodiments, the chart <NUM> also includes one or more markers 140a, 140b,. 140n, indicating an estimate for when clinical interventions may be necessary. The one or more markers may be an event associated with a predetermined future eGFR value. It is understood that any number "n" of markers may be utilized. For example, a first marker 140a is placed along the trend line <NUM> amongst the future eGFR values <NUM>, where the first marker 140a may correspond to a future date. The first marker 140a may indicate that when a patient's eGFR may achieve a value along a trend line at a future date, an action should be performed (see <FIG>). The future estimated date may be provided to a medical professional and/or patient for scheduling the appropriate medical treatment, and/or providing immediate interventional treatment to potentially slow or reverse a patient parameter. A second marker 140b, may be further in the future estimation on the trend line <NUM> in time, e.g., when the patient's eGFR may achieve another value along the trend line <NUM> at a future estimated date. In embodiments, the second marker 140b may be an indicator or prompt for when an appointment may be made for evaluating the necessity of or creating a permanent access such as a fistula for initiating future dialysis treatment. For example, the second marker 140b may be any time in the future (e.g., weeks and/or months) from the first marker 140a, and based on the future estimated eGFR values <NUM> and the trend line <NUM>, so as to approximate when the patient may need appropriate medical care. Additionally, the estimated date may allow for a patient to receive immediate interventional treatment based on an estimated timeline. Immediate interventional treatment may benefit a patient's health, as well as provide healthcare providers with timely scheduling and/or an understanding of potential upcoming personnel needs, medications and/or other supply or inventory requirements, or combinations thereof. In some embodiments, immediate interventional treatments to a patient may slow or even reverse patient parameters.

One or more databases may be editable and/or storable in an integrated care system, and may be accessible for analysis. The database may include information associated with the one or more markers 140a, 140b. 140n, and may approximate eGFR values assigned for when they should be included in the chart <NUM>. The one or more markers 140a, 140b. 140n may be any item in which action should be taken to address a patient's CKD, including but not limited to education and interventions to slow CKD progression 140a, nutrition counseling and referral to nutritionist or dietician 140b, vaccinations 140c, referral to nephrology 140d, referral for a primary renal transplant 140e, modality choice 140f, referral for permanent access procedure <NUM>, maintaining usable permanent access <NUM>, coordination of renal replacement therapy (RRT) 140i, e.g., dialysis, an unprepared dialysis start, and a prepared start of dialysis 140j (see <FIG>).

Referring now to <FIG>, a database table illustrating exemplary markers 140a, 140b,. 140n, is shown, including approximate eGFR values for applying the selected marker 140a, 140b,. 140n, the associated stage of CKD, appropriate action to be taken by a medical professional, or combinations thereof. For example, education and intervention to slow CKD progression may be scheduled at any point when an eGFR value is calculated to be between <NUM> and <NUM>. An appointment may be made to meet with a medical professional to provide a patient with information regarding diet management, blood pressure management, mental health evaluations, or cardiovascular disease risk management recommendations, or combinations thereof, to potentially slow and/or reverse the progression of kidney disease. In some embodiments, the patient's electronic medical records may include a task that the education and intervention marker is to be completed no later than a minimum eGFR value calculation. For example, if the eGFR value is equal to or below <NUM> along the trend line <NUM>, the electronic medical record may indicate whether the patient has attended an educational appointment, and if not, may alert at least one of the patient, medical professional, primary care physician, and the like, to schedule the appointment. Alerts may be communicated, e.g., wirelessly, by email, text, voicemail, calendar appointment, app notification, or the like.

In some embodiments, eGFR values may have predetermined values, such that in the event patient parameters equal or fall below the calculated values, interventional treatments, medical consultations, or other diagnostic tests, may be provided to the patient as immediate treatment.

The one or more markers 140a, 140b,. 140n may also incorporate best practices and recommendations of other medical organizations, for recommendations to patients with kidney disease, for a total health analysis. For example, another marker may be vaccinations, in that at a predetermined eGFR value, a patient should have been administered vaccinations recommended by the Center for Disease Control (CDC), which recognizes CKD as a high-risk group for infection. The recommendations by the CDC may be integrated into the chart <NUM> and associated with eGFR values to determine when a patient should have received the recommended vaccinations. In some embodiments, a patient may be scheduled to meet with a dietician or other nutritional expert, which may be incorporated into the chart <NUM> as well. Other outside systems may be accessible to the integrated care system for obtaining the recommended information so that information may be incorporated into the chart <NUM>, or into some other graph, report, table, tool, etc., or use the information in some other way, e.g., to calculate, model, estimate, and/or alert some activity relevant to the patient's care. The information may also be stored for later use, and/or aggregation for a larger patient population analysis.

In more advanced (e.g., later) stages of CKD, a patient may require input and care from other medical professionals, such as a nephrologist, and may be referred to one when a future eGFR value is estimated for example to be below <NUM>, or above <NUM> with proteinuria or uncontrolled hypertension. As the eGFR values decrease, these markers may indicate a progression of CKD in which treatment options such as transplants, care, and dialysis are anticipated and appointments with the appropriate medical professional may be scheduled based on future estimated dates according to the estimated eGFR values along the trendline <NUM>. In some embodiments, the future estimated eGFR values may provide immediate interventional treatment options for the patient, e.g., immediate treatments and/or medications that may alter CKD progression. By proactively addressing the progression of CKD, a patient may receive the appropriate treatment without delay or other disruptions, which may allow for an improvement in the patient's treatment and prognosis, and perhaps in some instances a change in the CKD progression timeline.

In some embodiments, the integrated care system, may use the chart <NUM> to determine when to send alerts to appropriate medical professionals of an upcoming date when a clinical intervention may be necessary. As described above, the integrated care system may be wirelessly connectable for communication to remote devices or a remote location, including but not limited to a mobile communication device (e.g., computer, laptop, tablet, mobile phone, and the like), doctor's office, hospital, call center, and technical support. In some embodiments, the chart <NUM> may be automatically provided to the electronic medical records or other outside systems in which data is storable, so that clinicians or other medical professionals may access a visualization of the data for ease and quick use. In some embodiments, the chart <NUM> may be a portion of a report, generatable by the integrated care system. A patient's electronic medical records may be updated with the forecasted data and dates, and in some embodiments may automatically schedule treatments, medications, or consultations, or schedule appointments for the appropriate treatment, or combinations thereof, based on the one or more markers 140a, 140b,.

Referring to <FIG>, an example in accordance with the present disclosure includes a coordinated care framework <NUM> for treating a patient or population of patients <NUM>. The overall care of the patient/population <NUM> is overseen and coordinated by a care coordination system <NUM>. The care coordination system <NUM> includes a care analysis and guidance system <NUM> (which is referred to herein interchangeably as an "integrated care system"), which receives, analyzes, and creates data used to coordinate the care of the patient/population <NUM>. The care coordination system <NUM> utilizes a care navigation unit (CNU) <NUM>, which implements the coordinated care in accordance with data received from the care analysis and guidance system <NUM>. To manage the overall health and well-being of the patient/population <NUM>, the care coordination system <NUM> communicates with numerous relevant entities and components. In <FIG>, the double-arrow lines graphically represent communication and interaction flows/channels.

In the example illustrated in <FIG>, the care coordination system <NUM> coordinates care for the patients <NUM> among entities that include chronic care centers or clinics <NUM>, physicians <NUM> (which may include nephrologists, especially for renal patients), nurses <NUM>, laboratories <NUM> (e.g., blood labs or other diagnostic labs), pharmacies <NUM>, hospitals <NUM>, medical devices <NUM> (e.g., dialysis machines or other medical treatment/monitoring devices), urgent care clinics <NUM>, specialty services <NUM>, counseling and mental health services <NUM>, nutritionists/dieticians <NUM>, transportation services <NUM>, providers of medical equipment and supplies <NUM>, ambulatory surgical centers (ASCs) <NUM>, additional services <NUM>, medical records <NUM>, financial and billing records <NUM>, and payer(s) <NUM> (e.g., CMS or private insurer).

It should be understood that some example embodiments may include other entities not shown, and/or may exclude some of the entities shown. Further, it should be understood that the illustrated communication channels are not exclusive, and the various entities may also, where appropriate, communicate directly or indirectly between each other and/or the patients <NUM>. In some examples, the communication between the care coordination system <NUM> and one or more of the other entities may be indirect, flowing through one or more intermediary entities. For example, coordination of nurses <NUM> may be conducted directly between the care coordination system <NUM> and the nurses <NUM> or via intermediary channels such as a clinic <NUM>, <NUM>, a hospital <NUM>, or any other suitable channel.

In accordance with some examples, the framework <NUM> of <FIG> may be used in treating diseases such as the progression of kidney disease, e.g., End-Stage Renal Disease (ESRD) and/or Chronic Kidney Disease (CKD). Patients with ESRD are patients undergoing long-term care for kidney disease, e.g., by dialysis treatments. As described above, coordinated care framework <NUM> may be utilized for obtaining, storing, and generating patient information, including but not limited to electronic medical records, calculated patient parameters, and/or integration with other systems, for interventional treatment options for patients. Monitoring health status trends of dialysis patients may pose challenges. For example, patients may exhibit varying and irregular degrees of functional/cognitive impairment, and may be coupled with complex clinical abnormalities that are independent of a patient's length of time on dialysis. Additionally, in diseases having advancing stages, a patient's condition may change at each medical evaluation. As a patient may interact with several medical professionals (e.g., physician, clinician, nutritionist, nephrologist, mental health professional, and the like), progression of disease may not be known until the patient returns to a particular medical professional. Patient treatments may be inadvertently missed or delayed until visiting the appropriate healthcare provider. In accordance with exemplary embodiments of the present disclosure, coordinated care framework <NUM>, including care analysis and guidance system <NUM>, patient information may be incorporated into coordinated care framework <NUM> so that disease progression may be monitorable. Additionally, in some embodiments, future patient parameter values may be estimated, based on historic patient parameter values. This may be advantageous for providing proactive and timely interventional treatment to a patient, which may slow or reverse disease progression.

A care analysis and guidance system (integrated care system) <NUM> may include and execute various healthcare-related models and/or programs. In some examples, these models and/or programs are specifically adapted to implement or carry out particular value-based care frameworks (for example, ESCO models, other ACO models, Chronic Special Needs Plans (C-SNP's), and the like), whereas other examples may include models/programs generally applicable across multiple value-based care frameworks. It is also understood that additional types of value-based care models may be provided for other chronic illnesses, including but not limited to chronic kidney disease, or one or more of the other chronic diseases and conditions mentioned above. These healthcare models may influence improvements in providing value-based care to a patient, for example, by more efficiently managing a patient's care within a specified structure, and may replace conventional fee-for-service (FFS) models. Fee-for-service models may typically focus on volume over the quality of individualized patient care, with little incentive to improve a patient's overall health, which may be less efficient and have lower effectiveness than value-based models.

Shifting patient care away from conventional fee-for-service models to value-based healthcare models may improve care received by patients, reduce total costs, and may improve management of large patient populations diagnosed with the same chronic disease. For example, as mentioned above, value-based healthcare models may pay providers based on a quality of care (e.g., clinical outcomes, meeting specific performance criteria, etc.) received by the patients, and providers and patients may benefit from a focus on addressing and improving the overall health of patients. For example, CMS may set a budget for patient care for a diagnosed illness (e.g., ESRD), thereby incentivizing healthcare providers for innovations to lower costs in providing treatment to the illness. In some embodiments, payments may be associated, or negotiated through "shared risk" contracts, in which the cost, as well as savings, associated with an illness and the coordinated care of a patient is shared by the provider as well as the payer. This arrangement is present in the ESCO model described in greater detail above.

In some embodiments, a care coordination system may identify, test, and/or evaluate innovations through the CEC/ESCO framework for improving patient care to Medicare beneficiaries diagnosed with ESRD. The care coordination system may provide a structure for dialysis clinics, nephrologists or other specialists, and/or other providers to be connected to each other for care coordination for aligned beneficiaries. Value-based healthcare models may incentivize providers based on a quality of care of services delivered. For example, the care coordination system may incorporate incentives for improved care coordination, individualized patient care, and/or improved long-term health outcomes of a patient population. The care coordination system may also coordinate outcomes, e.g., clinical quality, financial, etc., measured by Medicare Part A (e.g., hospital insurance) and B (e.g., medical insurance) spending, including spending related to dialysis services for their aligned ESRD beneficiaries. It is understood that some value-based healthcare models may also include Medicare Part D (e.g., prescription drug coverage) spending.

An integrated care system <NUM> may form a part of a clinical system for diagnosing and treating a patient in all aspects of care. The integrated care system <NUM> may be connectable to additional clinical systems, including but not limited to a pharmacy, a CKD/ESRD data registry, and the like. For example, the integrated care system may automatically send prescriptions and other patient information to a pharmacy based on information provided by a medical professional, and may be able to send and receive data and information to the CKD/ESRD data registry, for comparison to other patients and projections for future treatment. The integrated care system may determine events associated with CKD/ESRD and take appropriate action, including but not limited to informing patients, informing clinicians of when specific interventions are warranted, and/or alerting clinicians to upcoming important dates for interventions.

One or more outside, or external, systems may also be connectable to the integrated care system <NUM>. For example, the external systems may include one or more of diagnostic and/or treatment equipment such as a dialysis machine, labs, doctor's office, hospital, and/or electronic medical records. Patient information may be sent and received between the integrated care system and the external systems, so that patient care may be more efficient, standardized, and consistent across several functions. For example, the integrated care system <NUM> (see <FIG>) may receive information from a patient's electronic medical records, thereby accessing historical information. A dialysis unit, or dialysis machine, doctor's office, labs, and hospitals may send and receive information to and from the integrated care system based on patient treatment.

As described below with respect to <FIG>, in some embodiments, a care coordination system may provide information to a dialysis machine <NUM>, <NUM>, <NUM>, for use in dialysis treatment. In some embodiments, the integrated care system may send the dialysis machine <NUM>, <NUM>, <NUM>, a prescription from a medical professional for a prescribed dialysis treatment, in which case the integrated care system may receive the prescription from a doctor's office or hospital. The integrated care system may also be able to verify the prescribed treatment against the patient's lab work or medical records, and in some instances may remotely program the prescription onto the patient's dialysis machine, or forward the prescription to the machine for local set-up. In this manner, the patient may be sure to receive the necessary and correct treatment and may be prevented from administering or receiving an improper amount of dialysis treatment, thereby reducing human error and improving patient care. The integrated care system <NUM> may also be able to inform the relevant medical professional based on information received from these external systems, as well as the additional clinical systems, e.g., to provide appropriate medical treatment to the patient.

<FIG> is another illustration of a care coordination framework. Coordinated care framework <NUM>' of <FIG> shares the features described herein with respect to coordinated care framework <NUM> of <FIG> except to the extent described otherwise. The coordinated care framework <NUM>' described in this example is provided for integrating patient care in treating kidney disease, e.g., ESRD and/or CKD is shown (although it may be adapted as well for other chronic conditions similar to the framework of <FIG>). A care coordination system <NUM>' may coordinate at least some aspects of a patient's care with the integrated care system <NUM>' (which may include and execute healthcare-related models and/or programs <NUM>), to support patient care. Various components may engage within the care coordination system <NUM>' to provide complete patient care via the care framework. For example, any number of integrated care components may send and receive information to and from the integrated care system <NUM>', including but not limited to a secondary services component <NUM>, data creation and/or management component <NUM>, care provider component <NUM>, equipment and/or supplies component <NUM>, and regulatory component <NUM>. In some embodiments, the care coordination system <NUM>' may engage with third party resources, including but not limited to lab services, research, etc. In some embodiments, the care framework may encompass, or is implemented by, or is associated with, a care navigation unit <NUM>'. In the example of <FIG>, it is noted that the care navigation unit <NUM>' is indicated as a separate entity from the care coordination system <NUM>', but it should be understood that in other examples (see, e.g., <FIG>), the care navigation unit may be included as part of the care coordination system.

Each component of an integrated care system (e.g., care analysis and guidance system) <NUM>, <NUM>' may include one or more units, including internal services and support as well as external services and support, as described above. As shown in <FIG>, the secondary services component <NUM> may include any number "n" of services 605a, 605b,. 605n related to secondary patient services. For example, secondary services may include laboratory 605a, personalized care 605b, and/or pharmacy 605c. Each of the secondary services 605a, 605b,. 605n may send and receive patient information to the integrated care system <NUM>, <NUM>', for compilation and analysis. For example, a laboratory may automatically send results of patient bloodwork and other test results to the integrated care system <NUM>, <NUM>'. Additionally, the integrated care system <NUM>, <NUM>' may automatically send testing instructions to the laboratory for selected tests on patient samples, based on determinations from medical professionals, and/or other information gathered by the care coordination system <NUM>' via a care framework. Similarly, the integrated care system <NUM>, <NUM>' may automatically send prescriptions and dosage instructions to a pharmacy based on a patient's test results and other factors determined by the integrated care system <NUM>, <NUM>'. The pharmacy may also send information to the integrated care system <NUM>, <NUM>' related to other patient prescriptions for potential adverse drug interactions, how timely a prescription is refilled, and/or patient interaction with the pharmacist, etc..

In some embodiments, a patient may benefit from care by a nutritionist and/or dietician 605d, to adjust to dietary restrictions as a component to their care. For example, ESRD patients may have prescribed dietary requirements are part of receiving hemodialysis and other treatment for their kidney disease. A patient may benefit from consultation with a nutritionist and/or dietician, for moving towards a healthier eating lifestyle and other potential health-related benefits. Fluid management 605e may also be managed for a patient, to ensure a patient is receiving proper amounts and types of fluid. Patients living with CKD and/or ESRD may have fluid restrictions for better dialysis outcomes. Some patients may have difficulty in understanding liquid intake, and/or may be unable to reliably track their fluid intake. In some embodiments, fluid management may be managed by a nutritionist and/or dietician, although it is understood that in other embodiments a patient's fluid intake may be managed by another medical professional. In embodiments, a patient may benefit from care by mental health professionals 605f, for example, psychologists, psychiatrists, and/or other counseling services. As described above, a patient's mental well-being may be affected by progression of an illness, and may otherwise be missed by other medical professionals in the course of treatment. As such, scheduling and providing access to mental health professionals may improve the patient's total health.

Referring now to <FIG>, the data creation/management component <NUM> may include one or more units related to the creation and/or management of patient data, including internal services and support as well as external services and support, as described above. For example, the data creation/management component <NUM> may include any number "n" of services 705a, 705b,. As shown in <FIG>, electronic medical records (EMR) 705a, data registry 705b, and clinical information 705c, may receive, store, and/or send patient data records as determined by the care analysis and guidance system <NUM>, <NUM>'. For example, a patient's medical records may be automatically updated after receiving lab results, treatment information, and/or notes from medical professionals. The care analysis and guidance system <NUM>, <NUM>' may utilize a patient's medical records for trends or triggering events, so that the care coordination system <NUM>' may provide relevant information to a medical professional for treatment and other care option recommendations and timing and coordination of various types of possible interventions. In some embodiments, the care analysis and guidance system <NUM>, <NUM>' may analyze multiple patients as part of a data registry, for determining global trends and analyzing data from a macro-level.

<FIG> shows an exemplary care provider component <NUM>, including one or more units which provide patient care, as indicated by reference numerals 805a, 805b,. Any number "n" of units may be included in the provider component <NUM>. In some embodiments, care providers may include physicians and/or physician groups 805a (e.g., primary care physicians (PCP) and specialists such as nephrologists), practice management systems 805b, hospitals 805c, and/or clinic/centers 805d, although additional or alternative care providers may also be envisioned. The integrated care system <NUM>, <NUM>' may send and receive information to and from the care providers for patient treatment. For example, the integrated care system <NUM>, <NUM>' may receive physician notes of patient examinations, hospitalization information, and the like, and may send calculated information and other determined factors based on other patient data received. For example, the integrated care system <NUM>, <NUM>' may send estimations and treatment recommendations to identify, reduce, avoid, and/or eliminate patient risk of aspects and/or effects of renal disease or renal disease treatments for providing treatment to a patient based on all received patient data and assessments performed thereon.

<FIG> shows an exemplary equipment and/or supplies component <NUM>, for example, treatment supplies, for an individual patient, which may include any number "n" of services 905a, 905b,. In some embodiments, the integrated care system <NUM>' may send and receive information related to disposable medical equipment 905a, information technology (IT) technical support 905b, inventory control 905c, and/or dialysis units 905d. As described above, many patients receive treatment at home, such as home dialysis, requiring an ongoing supply of disposable medical supplies for each treatment. Deliveries of supplies and/or dialysis equipment may be automatically monitored, replenished, and/or inventoried by the integrated care system <NUM>, <NUM>', to ensure proper machine functioning and a steady supply of materials and resources to ensure a patient receives all prescribed treatments.

<FIG> shows an exemplary regulatory component <NUM>, which may include any number "n" of services 1005a, 1005b,. 1005n related to governmental and regulatory requirements. For example, certain state and federal regulations and regulatory authorities may be involved in insurance and/or Centers for Medicaid and Medicare Services (CMS) 1005a, product approvals for the public (e.g., the Food and Drug Administration (FDA)) 1005b, and billing 1005c. The integrated care system <NUM>, <NUM>' may send and receive information to and from each of these units to ensure correct billing coding, regulatory approvals, and/or insurance payments.

A care navigation unit <NUM>, <NUM>', as introduced above, may oversee and coordinate patient care based on analysis and calculations by the integrated care system <NUM>, <NUM>' determined from data and information from any of the components <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, as well as the care coordination system <NUM>'. For example, a care navigation unit <NUM>', may coordinate care to patients to follow through on interventional treatments to address functional and/or cognitive patient impairment over time, improve comorbidity management, and help drive high-value care options and timing of treatment decisions to patients over time. As shown in <FIG>, care navigation unit <NUM>, <NUM>' may include different aspects of health care coordination as indicated by reference numerals 1105a, 1105b,. 1105n, including but not limited to counseling, treatment transition, scheduling, patient monitoring, tracking, transportation, and/or discharge care. For example, the integrated care system <NUM>, <NUM>' may determine that a patient requires transportation to/from a treatment center, and may automatically schedule transportation, e.g., public transportation, carpool, taxi, ride share, etc., so that the patient may not miss a scheduled treatment. Additionally, the integrated care system <NUM>, <NUM>' may send patient results to the relevant care providers, e.g., medical specialists, doctors, and/or nurses, for monitoring and/or treatment recommendations. Care navigation unit <NUM>' may provide services to patients addressing their complete healthcare needs related to their kidney disease.

The care navigation unit <NUM>' may include treatment transition 1105b, for an integrated care system <NUM>, <NUM>' to coordinate patient care through progression of kidney disease. For example, a patient may initially be diagnosed with chronic kidney disease (CKD). Over time however, without interventional treatment (e.g., a kidney transplant) or improved kidney function, the patient may progress to end-stage renal disease (ESRD). As the patient's kidney disease progresses, the patient may need additional services, support, and/or health care, which may be overseen and/or managed under the care framework <NUM>' by the care navigation unit <NUM>' via the integrated care system <NUM>, <NUM>' and through a care framework of care coordination system <NUM>'. By calculating estimated future values of one or more patient parameters, a patient's disease progression may be trackable, for proactively addressing and treating conditions. For example, the care navigation unit <NUM>' may coordinate specified patient treatments, and scheduled appropriately, so the patient is unlikely to miss a treatment, or have complications from an unknown progression of disease.

Referring now to <FIG>, an integrated care system, such as integrated care system <NUM>, <NUM>', may include a controller <NUM>, a processor <NUM>, and a memory <NUM>. The controller <NUM> may automatically control signals received and sent to other systems, e.g., the additional clinical systems, the external systems, and the practice management and billing system. Communication between the controller <NUM> and other systems may be bi-directional, whereby the systems may acknowledge control signals, and/or may provide information associated with the system and/or requested operations. Additionally, a user input interface <NUM> and display <NUM> may be disposed to receive and/or display input from a user, e.g., a patient or a medical professional such as a doctor, nurse, technician, or the like. Examples of the components that may be employed within the user input interface <NUM> include keypads, buttons, microphones, touch screens, gesture recognition devices, display screens, and speakers. In some embodiments, the integrated care system <NUM>, <NUM>' may be a server, a computer, or other device for storing and processing data, and controlling signals to other systems. A power source <NUM> may allow the integrated care system <NUM>, <NUM>' to receive power, and in some embodiments may be an independent power source.

The processor <NUM> may be configured to execute an operating system, which may provide platform services to application software, e.g., for operating the integrated care system <NUM>, <NUM>'. These platform services may include inter-process and network communication, file system management and standard database manipulation. One or more of many operating systems may be used, and examples are not limited to any particular operating system or operating system characteristic. In some examples, the processor <NUM> may be configured to execute a real-time operating system (RTOS), such as RTLinux, or a non-real time operating system, such as BSD or GNU/Linux. According to a variety of examples, the processor <NUM> may be a commercially available processor such as a processor manufactured by INTEL, AMD, MOTOROLA, and FREESCALE. However, the processor <NUM> may be any type of processor, multiprocessor or controller, whether commercially available or specially manufactured. For instance, according to one example, the processor <NUM> may include an MPC823 microprocessor manufactured by MOTOROLA.

The memory <NUM> may include a computer readable and writeable nonvolatile data storage medium configured to store non-transitory instructions and data. In addition, the memory <NUM> may include a processor memory that stores data during operation of the processor <NUM>. In some examples, the processor memory includes a relatively high performance, volatile, random access memory such as dynamic random access memory (DRAM), static memory (SRAM), or synchronous DRAM. However, the processor memory may include any device for storing data, such as a non-volatile memory, with sufficient throughput and storage capacity to support the functions described herein. Further, examples are not limited to a particular memory, memory system, or data storage system.

The instructions stored on the memory <NUM> may include executable programs or other code that may be executed by the processor <NUM>. The instructions may be persistently stored as encoded signals, and the instructions may cause the processor <NUM> to perform the functions described herein. The memory <NUM> may include information that is recorded, on or in, the medium, and this information may be processed by the processor <NUM> during execution of instructions. The memory <NUM> may also include, for example, data records, timing for treatment and/or operations, historic information, statistical information, and informational databases for treatments. A database may be stored in the memory <NUM> of the integrated care system <NUM>, <NUM>', and may be accessible by the processor <NUM> and controller <NUM>. For example, historical data of patient information may be extracted from various databases in the integrated system <NUM>, <NUM>', including but not limited to patient lab results, treatment data, technician data during treatment (nurse notes), etc..

The integrated care system <NUM>, <NUM>' may include communication links <NUM>, so that other systems may be connectable to the integrated care system <NUM>, <NUM>'. For example, additional clinical systems, external systems, and practice management and billing systems, may be connectable to the integrated care system <NUM>, <NUM>' to send and receive data and information associated with providing patient care. In some embodiments, the communication links <NUM> may be wireless, so that the systems may be remote, or the integrated care system <NUM>, <NUM>' and/or one or more of the systems <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>' may reside and operate in a cloud-based architecture.

The integrated care system <NUM>, <NUM>' may also be wirelessly connectable via an antenna <NUM> for remote communication. For example, the integrated care system <NUM>, <NUM>' may determine one or more patient parameters by the controller <NUM>, processor <NUM>, and/or memory <NUM>, and may access other patient parameters being stored by an outside system, e.g., in electronic medical records stored on a server or database in a location remote from the system or machine, or from labs or hospital information. It may be advantageous for the integrated care system <NUM>, <NUM>' to access other patient parameters that may otherwise be unknown or undeterminable in order to provide a complete care analysis of the patient. As described above, patient data may be sent to and/or accessible by the integrated care system <NUM>, <NUM>'. The controller <NUM>, processor <NUM>, and memory <NUM> may receive, store, and/or determine relevant demographic and laboratory values, or other data, for calculations. For example, the table <NUM>, may be storable as a database. Historic data and information for generating chart <NUM> may also be storable as a database (see <FIG>).

Referring now to <FIG>, exemplary embodiments of an operating environment for a healthcare system (e.g., coordinated care framework <NUM>, <NUM>'), including integrated care system (care analysis and guidance system) <NUM>, <NUM>', are described. <FIG> illustrates an example of an operating environment <NUM> that may be representative of some embodiments. As shown in <FIG>, operating environment <NUM> may include a system <NUM> operative for treating patients, e.g., patients having chronic illnesses. In various embodiments, the system <NUM> may include computing device <NUM>. Computing device <NUM> may include processing circuitry <NUM>, a memory unit <NUM>, a transceiver <NUM>, and/or a display <NUM>. Processing circuitry <NUM> may be communicatively coupled to memory unit <NUM>, transceiver <NUM>, and/or display <NUM>. It is understood that in some embodiments, system <NUM> may include the coordinated care framework <NUM>, <NUM>', and in some embodiments, the system <NUM> may include other systems and/or frameworks.

In some embodiments, computing device <NUM> may be connected to network <NUM> through transceiver <NUM>. Network <NUM> may include nodes 462a-n, for example, remote computing devices, data sources <NUM>, and/or the like.

Processing circuitry <NUM> may include and/or may access various logic for performing processes according to some embodiments. Processing circuitry <NUM>, or portions thereof, may be implemented in hardware, software, or a combination thereof. As used in this application, the terms "logic, "component," "layer," "system," "circuitry," "decoder," "encoder," and/or "module" are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture <NUM> of <FIG>. For example, a logic, circuitry, or a layer may be and/or may include, but are not limited to, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, a computer, hardware circuitry, integrated circuits, application specific integrated circuits (ASIC), programmable logic devices (PLD), digital signal processors (DSP), field programmable gate array (FPGA), a system-on-a-chip (SoC), memory units, logic gates, registers, semiconductor device, chips, microchips, chip sets, software components, programs, applications, firmware, software modules, computer code, combinations of any of the foregoing, and/or the like.

It is also understood that components of the processing circuitry <NUM> may be located within an accelerator, a processor core, an interface, an individual processor die, implemented entirely as a software application and/or the like.

Memory unit <NUM> may include various types of computer-readable storage media and/or systems in the form of one or more higher speed memory units, such as read-only memory (ROM), random-access memory (RAM), dynamic RAM (DRAM), Double-Data-Rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, polymer memory such as ferroelectric polymer memory, ovonic memory, phase change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, an array of devices such as Redundant Array of Independent Disks (RAID) drives, solid state memory devices (e.g., USB memory, solid state drives (SSD) and any other type of storage media suitable for storing information. In addition, memory unit <NUM> may include various types of computer-readable storage media in the form of one or more lower speed memory units, including an internal (or external) hard disk drive (HDD), a magnetic floppy disk drive (FDD), and an optical disk drive to read from or write to a removable optical disk (e.g., a CD-ROM or DVD), a solid state drive (SSD), and/or the like.

Memory unit <NUM> may store various information, e.g., one or more programs, to perform various functions identifying and treating patients with CKD and/or ESRD. In some embodiments, the memory <NUM> may include logic having application programming interfaces (APIs) and/or graphical user interfaces (GUIs) to read, write, and/or otherwise access information, such as via display <NUM>, web interfaces, mobile application ("mobile applications," "mobile apps," or "apps"), and/or the like. In this manner, in some embodiments, an operator may search, visualize, read, add to, or otherwise access information associated with a patient population for identifying and treating CKD and/or ESRD.

In some embodiments, memory unit <NUM> may store various information associated with a patient population for identifying and treating CKD and/or ESRD. In some embodiments, information stored in memory unit <NUM> may be retrieved from and/or moved into a data source <NUM> including, without limitation, a hospital information management system (HIMS), laboratory information management system (LIMS), Health Information System (HIS), electronic medical records (EMR), a clinical trial database, and/or the like. In some embodiments, patient information analysis <NUM>, which may be one or more programs, algorithms, or combinations thereof, for identifying and/or treating chronic illness, such as kidney disease, may be implemented.

<FIG> illustrates an example of an operating environment <NUM> that may be representative of some embodiments. As shown in <FIG>, operating environment <NUM> may include a platform <NUM>, e.g., a healthcare exchange platform. In some embodiments, the platform <NUM> may be operative to provide for the exchange of clinical data and/or clinical trial information among interested entities. In various embodiments, the platform <NUM> may include an application platform operative for identifying a patient population and treating CKD and/or ESRD with services among nodes 560a-n and 570a-n. In exemplary embodiments, the platform <NUM> may be a software platform, suite, set of protocols, and/or the like provided to customers by a manufacturer and/or developer ("developer") associated with medical devices, medical care services, clinical research services, laboratory services, clinical trial services, and/or the like.

For example, a developer may provide the platform <NUM> as a data exchange interface for use by various entities, including government entities (for example, the FDA), and other stakeholders (for instance, pharmaceutical manufacturers, medical device manufacturers, and/or the like). An entity, such as a hospital, dialysis clinic, healthcare provider, government entity, regulatory entity, pharmaceutical manufacturer, medical device manufacturer, and/or the like providing and/or receiving clinical trial services via a node 570a-n provided by developer may use the platform <NUM> to implement processes according to some embodiments. Other entities, may access the platform <NUM> via a GUI, such as a client application, web interface, mobile app, and/or the like, e.g., for performing functions associated with the memory <NUM>. In some embodiments, at least a portion of the platform <NUM> may be hosted in a cloud computing environment.

Nodes 570a-n may be data producers for the memory <NUM> and nodes 560a-n may be data consumers of the memory <NUM>. For example, node 570a-n may include entities providing clinical data, model information, and/or the like used by the memory <NUM> to generate, perform, and/or evaluate a patient population. Nodes 560a-n may include third-party applications, decision makers, analysis processes, regulators, and/or other data consumers that may be interested in the results of generating, performing, and/or evaluating the patient population. An entity may be both a data producer and a data consumer.

For example, node 560a may be care provider (node 560b) to provide treatment to a patient based on analysis of a patient population including medical records, laboratory data, pharmacy, and the like. (node 570a). Data producers 570a-n may provide analytical data, according to permissions, to the platform <NUM>, for example, in the form of records in a HIMS, LIMS, EMR, and/or the like. Data consumers 560a-n may access analytical data, according to permissions, via the platform <NUM> (for example, through HIMS, LIMS, EMR, and/or the like and/or local copies of such records).

In some embodiments, the platform <NUM> may operate according to a cloud-based model and/or an "as-a-Service" model. In this manner, the platform <NUM> may provide for a service that operates as a single, central platform that allows entities to access clinical data, model information, simulation results, and/or the like.

In some embodiments, one of the recommended treatments and/or services may be to alter or change a dialysis treatment prescription for a patient. As illustrated in <FIG> and described below, a dialysis machine <NUM>, <NUM>, <NUM>, e.g., a dialysis machine such as a peritoneal dialysis machine or a hemodialysis machine, may be connected to the integrated care system <NUM>, <NUM>' for sending and receiving dialysis information to provide appropriate care to a patient. The hemodialysis machine may be located in a renal clinic, such as a kidney care clinic, dialysis clinic, or other third-party care provider. In some embodiments, the peritoneal dialysis machine and/or the hemodialysis machine may be home machines, e.g., treatment may be administered in a patient's home. As described above, an integrated care system may be applicable to other chronic illnesses, and may be connected to machines related to those illnesses, including but not limited to chronic kidney disease, or one or more of the other chronic diseases and conditions mentioned above.

Referring to <FIG>, a schematic of an exemplary embodiment of a dialysis machine <NUM>, and a controller <NUM> in accordance with the present disclosure are shown. The machine <NUM> may be a dialysis machine, e.g., a peritoneal dialysis machine or a hemodialysis machine, for performing a dialysis treatment on a patient (see <FIG>). The controller <NUM> may automatically control execution of a treatment function during a course of dialysis treatment. For example, the controller <NUM> may control dialysis treatment based on information received from the care analysis and guidance system <NUM>, <NUM>'. The controller <NUM> may be operatively connected to sensors <NUM> and deliver one or more signals to execute one or more treatment functions, or a course of treatment associated with various treatment systems. Although <FIG> illustrates the components integrated into the dialysis machine <NUM>, at least one of the controller <NUM>, processor <NUM>, and memory <NUM> may be configured to be external and wired or wirelessly connected to the dialysis machine <NUM>, as an individual component of a dialysis system. In some embodiments the controller <NUM>, processor <NUM> and memory <NUM> may be remote to the dialysis machine and configured to communicate wirelessly.

In some embodiments, the controller <NUM>, processor <NUM>, and memory <NUM> of the system or machine <NUM>, <NUM>, <NUM>, may receive signals from sensor <NUM> indicating one or more patient parameters. Communication between the controller <NUM> and the treatment system may be bi-directional, whereby the treatment system acknowledges control signals, and/or may provide state information associated with the treatment system and/or requested operations. For example, system state information may include a state associated with specific operations to be executed by the treatment system (e.g., trigger pump to deliver dialysate, trigger pumps and/or compressors to deliver filtered blood, and the like) and a status associated with specific operations (e.g., ready to execute, executing, completed, successfully completed, queued for execution, waiting for control signal, and the like).

The dialysis system or machine <NUM>, <NUM>, <NUM>, may also include at least one pump <NUM> operatively connected to the controller <NUM>. The controller <NUM> may also be operatively connected to one or more speakers <NUM> and one or more microphones <NUM> disposed in the system or machine <NUM>, <NUM>, <NUM>. The user input interface <NUM> may include a combination of hardware and software components that allow the controller <NUM> to communicate with an external entity, such as a patient or other user. These components may be configured to receive information from actions such as physical movement or gestures and verbal intonation. In embodiments, the components of the user input interface <NUM> may provide information to external entities. Examples of the components that may be employed within the user input interface <NUM> include keypads, buttons, microphones, touch screens, gesture recognition devices, display screens, and speakers.

As shown in <FIG>, sensors <NUM> may be included for detecting and monitoring one or more parameters and be operatively connected to at least the controller <NUM>, processor <NUM>, and memory <NUM>. The processor <NUM> may be configured to execute an operating system, which may provide platform services to application software, e.g., for operating the dialysis machine <NUM>. These platform services may include inter-process and network communication, file system management and standard database manipulation. One or more of many operating systems may be used, and examples are not limited to any particular operating system or operating system characteristic. In some examples, the processor <NUM> may be configured to execute a real-time operating system (RTOS), such as RTLinux, or a non-real time operating system, such as BSD or GNU/Linux. According to a variety of examples, the processor <NUM> may be a commercially available processor such as a processor manufactured by INTEL, AMD, MOTOROLA, and FREESCALE. However, the processor <NUM> may be any type of processor, multiprocessor or controller, whether commercially available or specially manufactured. For instance, according to one example, the processor <NUM> may include an MPC823 microprocessor manufactured by MOTOROLA.

The instructions stored on the memory <NUM> may include executable programs or other code that may be executed by the processor <NUM>. The instructions may be persistently stored as encoded signals, and the instructions may cause the processor <NUM> to perform the functions described herein. The memory <NUM> may include information that is recorded, on or in, the medium, and this information may be processed by the processor <NUM> during execution of instructions. The memory <NUM> may also include, for example, specification of data records for user timing requirements, timing for treatment and/or operations, historic sensor information, and other databases and the like. The medium may, for example, be optical disk, magnetic disk or flash memory, among others, and may be permanently affixed to, or removable from, the controller <NUM>.

A pressure sensor may be included for monitoring fluid pressure of the system or machine <NUM>, <NUM>, <NUM>, although the sensors <NUM> may also include any of a heart rate sensor, a respiration sensor, a temperature sensor, a weight sensor, a video sensor, a thermal imaging sensor, an electroencephalogram sensor, a motion sensor, audio sensor, an accelerometer, or capacitance sensor. It is appreciated that the sensors <NUM> may include sensors with varying sampling rates, including wireless sensors. Based on data monitored by the sensors <NUM>, patient parameters such as a heart rate and a respiration rate may be determined by the controller <NUM>.

The controller <NUM> may be disposed in the machine <NUM>, <NUM>, <NUM>, or may be coupled to the machine <NUM>, <NUM>, <NUM>, via a communication port or wireless communication links, shown schematically as communication element <NUM>. For example, the communication element <NUM> may connect the dialysis machine <NUM>, <NUM>, <NUM>, to the care analysis and guidance system <NUM>, <NUM>', or another remote system such as an outside system or other clinical system. The dialysis machine <NUM>, <NUM>, <NUM>, may be connectable to the integrated care system <NUM>, <NUM>' via the communication element <NUM> so that the controller <NUM> may send and receive information and other signals to the care analysis and guidance system <NUM>, <NUM>'. As described above, the care analysis and guidance system <NUM>, <NUM>' may direct a prescribed dialysis treatment based on information received from other systems, e.g., outside systems, clinical systems, directly to the dialysis machine to ensure a patient receives the proper treatment. The dialysis machine may also send data and other information to the care analysis and guidance system <NUM>, <NUM>' so that if dialysis treatment requires adjustment, the care analysis and guidance system <NUM>, <NUM>' may ensure any changes will not adversely affect patient health.

As a component disposed within the machine <NUM>, <NUM>, <NUM>, the controller <NUM> may be operatively connected to any one or more of the sensors <NUM>, pump <NUM>, pump heads <NUM>, <NUM>, and the like. The controller <NUM> may communicate control signals or triggering voltages to the components of the system or machine <NUM>, <NUM>, <NUM>. As discussed, exemplary embodiments of the controller <NUM> may include wireless communication interfaces. The controller <NUM> may detect remote devices to determine if any remote sensors are available to augment any sensor data being used to evaluate the patient.

<FIG> show an example of a peritoneal dialysis (PD) system <NUM>, which is configured in accordance with an exemplary embodiment of the system described herein. In some implementations, the PD system <NUM> may be a home PD system, e.g., a PD system configured for use at a patient's home. The dialysis system <NUM> may include a dialysis machine <NUM> (e.g., a peritoneal dialysis machine <NUM>, also referred to as a PD cycler) and in some embodiments the machine may be seated on a cart <NUM>.

The dialysis machine <NUM> may include a housing <NUM>, a door <NUM>, and a cartridge interface including pump heads <NUM>, <NUM> for contacting a disposable cassette, or cartridge <NUM>, where the cartridge <NUM> is located within a compartment formed between the cartridge interface and the closed door <NUM> (e.g., cavity <NUM>). Fluid lines <NUM> may be coupled to the cartridge <NUM> in a known manner, such as via a connector, and may further include valves for controlling fluid flow to and from fluid bags including fresh dialysate and warming fluid. In another embodiment, at least a portion of the fluid lines <NUM> may be integral to the cartridge <NUM>. Prior to operation, a user may open the door <NUM> to insert a fresh cartridge <NUM>, and to remove the used cartridge <NUM> after operation.

The cartridge <NUM> may be placed in the cavity <NUM> of the machine <NUM> for operation. During operation, dialysate fluid may be flowed into a patient's abdomen via the cartridge <NUM>, and spent dialysate, waste, and/or excess fluid may be removed from the patient's abdomen via the cartridge <NUM>. The door <NUM> may be securely closed to the machine <NUM>. Peritoneal dialysis for a patient may include a total treatment of approximately <NUM> to <NUM> liters of fluid, where approximately <NUM> liters of dialysate fluid are pumped into a patient's abdomen, held for a period of time, e.g., about an hour, and then pumped out of the patient. This is repeated until the full treatment volume is achieved, and usually occurs overnight while a patient sleeps.

A heater tray <NUM> may be positioned on top of the housing <NUM>. The heater tray <NUM> may be any size and shape to accommodate a bag of dialysate (e.g., a <NUM> bag of dialysate) for batch heating. The dialysis machine <NUM> may also include a user interface such as a touch screen <NUM> and control panel <NUM> operable by a user (e.g., a caregiver or a patient) to allow, for example, set up, initiation, and/or termination of a dialysis treatment. In some embodiments, the heater tray <NUM> may include a heating element <NUM>, for heating the dialysate prior to delivery into the patient.

Dialysate bags <NUM> may be suspended from hooks on the sides of the cart <NUM>, and a heater bag <NUM> may be positioned in the heater tray <NUM>. Hanging the dialysate bags <NUM> may improve air management as air content may be disposed by gravity to a top portion of the dialysate bag <NUM>. Although four dialysate bags <NUM> are illustrated in <FIG>, any number "n" of dialysate bags may be connectable to the dialysis machine <NUM> (e.g., <NUM> to <NUM> bags, or more), and reference made to first and second bags is not limiting to the total number of bags used in a dialysis system <NUM>. For example, the dialysis machine may have dialysate bags 1322a,. 1322n connectable in the system <NUM>. In some embodiments, connectors and tubing ports may connect the dialysate bags <NUM> and lines for transferring dialysate. Dialysate from the dialysate bags <NUM> may be transferred to the heater bag <NUM> in batches. For example, a batch of dialysate may be transferred from the dialysate bags <NUM> to the heater bag <NUM>, where the dialysate is heated by the heating element <NUM>. When the batch of dialysate has reached a predetermined temperature (e.g., approximately <NUM>°-<NUM>°F, <NUM>), the batch of dialysate may be flowed into the patient. The dialysate bags <NUM> and the heater bag <NUM> may be connected to the cartridge <NUM> via dialysate bag lines or tubing <NUM> and a heater bag line or tubing <NUM>, respectively. The dialysate bag lines <NUM> may be used to pass dialysate from dialysate bags <NUM> to the cartridge during use, and the heater bag line <NUM> may be used to pass dialysate back and forth between the cartridge and the heater bag <NUM> during use. In addition, a patient line <NUM> and a drain line <NUM> may be connected to the cartridge <NUM>. The patient line <NUM> may be connected to a patient's abdomen via a catheter and may be used to pass dialysate back and forth between the cartridge and the patient's peritoneal cavity by the pump heads <NUM>, <NUM> during use. The drain line <NUM> may be connected to a drain or drain receptacle and may be used to pass dialysate from the cartridge to the drain or drain receptacle during use.

Although in some embodiments, dialysate may be batch heated as described above, in other embodiments, dialysis machines may heat dialysate by in-line heating, e.g., continuously flowing dialysate through a warmer pouch positioned between heating elements prior to delivery into a patient. For example, instead of a heater bag for batch heating being positioned on a heater tray, one or more heating elements may be disposed internal to the dialysis machine. A warmer pouch may be insertable into the dialysis machine via an opening. It is also understood that the warmer pouch may be connectable to the dialysis machine via tubing (e.g., tubing <NUM>), or fluid lines, via a cartridge. The tubing may be connectable so that dialysate may flow from the dialysate bags, through the warmer pouch for heating, and to the patient.

In such in-line heating embodiments, a warmer pouch may be configured so dialysate may continually flow through the warmer pouch (instead of transferred in batches for batch heating) to achieve a predetermined temperature before flowing into the patient. For example, in some embodiments the dialysate may continually flow through the warmer pouch at a rate between approximately <NUM>-<NUM>/min. Internal heating elements (not shown) may be positioned above and/or below the opening, so that when the warmer pouch is inserted into the opening, the one or more heating elements may affect the temperature of dialysate flowing through the warmer pouch. In some embodiments, the internal warmer pouch may instead be a portion of tubing in the system that is passed by, around, or otherwise configured with respect to, a heating element(s).

The touch screen <NUM> and the control panel <NUM> may allow an operator to input various treatment parameters to the dialysis machine <NUM> and to otherwise control the dialysis machine <NUM>. In addition, the touch screen <NUM> may serve as a display. The touch screen <NUM> may function to provide information to the patient and the operator of the dialysis system <NUM>. For example, the touch screen <NUM> may display information related to a dialysis treatment to be applied to the patient, including information related to a prescription.

The dialysis machine <NUM> may include a processing module <NUM> that resides inside the dialysis machine <NUM>, the processing module <NUM> being configured to communicate with the touch screen <NUM> and the control panel <NUM>. The processing module <NUM> may be configured to receive data from the touch screen <NUM> the control panel <NUM> and sensors, e.g., weight, air, flow, temperature, and/or pressure sensors, and control the dialysis machine <NUM> based on the received data. For example, the processing module <NUM> may adjust the operating parameters of the dialysis machine <NUM>.

The dialysis machine <NUM> may be configured to connect to a network <NUM>. The connection to network <NUM> may be via a wired and/or wireless connection. The dialysis machine <NUM> may include a connection component <NUM> configured to facilitate the connection to the network <NUM>. The connection component <NUM> may be a transceiver for wireless connections and/or other signal processor for processing signals transmitted and received over a wired connection. Other medical devices (e.g., other dialysis machines) or components may be configured to connect to the network <NUM> and communicate with the dialysis machine <NUM>.

The user interface portion such as the touch screen <NUM> and/or display <NUM> may include one or more buttons for selecting and/or entering user information. The touch screen <NUM> and/or display <NUM> may be operatively connected to a controller (not shown) and disposed in the machine <NUM> for receiving and processing the inputs to operate the dialysis machine <NUM>.

In some embodiments, the machine <NUM>, <NUM>, <NUM> may wirelessly transmit (e.g., via a wireless Internet connection), alternatively or simultaneously or in coordination with sending information to the integrated care system <NUM>, <NUM>', information or alerts to a remote location, including but not limited to a doctor's office, hospital, call center, and technical support. For example, the machine <NUM>, <NUM>, <NUM> may provide real time remote monitoring of machine operation and patient parameters. The memory <NUM> of the machine <NUM>, may store data, or the machine <NUM>, <NUM>, <NUM> may transmit data to a local or remote server at scheduled intervals.

<FIG> illustrates a diagram of an exemplary embodiment of a dialysis system <NUM> in accordance with the present disclosure. The dialysis system <NUM> may be configured to provide hemodialysis treatment to a patient <NUM>. Fluid reservoir <NUM> may deliver fresh dialysate to a dialyzer <NUM> via tubing <NUM>, and reservoir <NUM> may receive spent dialysate once it has passed through the dialyzer <NUM> via tubing <NUM>. A hemodialysis operation may filter particulates and/or contaminates from a patient's blood through a patient external filtration device, for example, a dialyzer <NUM>. As the dialysate is passed through the dialyzer <NUM>, so too unfiltered patient blood is passed into the dialyzer via tubing <NUM> and filtered blood is returned to the patient via tubing <NUM>. Arterial pressure may be monitored via pressure sensor <NUM>, inflow pressure monitored via sensor <NUM>, and venous pressure monitored via pressure sensor <NUM>. An air trap and detector <NUM> may ensure that air is not introduced into patient blood as it is filtered and returned to the patient <NUM>. The flow of blood and the flow of dialysate are controlled via respective pumps, including a blood pump <NUM> and a fluid pump <NUM>. Heparin <NUM>, a blood thinner, may be used in conjunction with saline <NUM> to ensure blood clots do not form or occlude blood flow through the system.

In some embodiments, the dialysis system <NUM> may include a controller <NUM>, which may be similar to the controller <NUM> described above with respect to dialysis machines <NUM>, <NUM>. The controller <NUM> may be configured to monitor fluid pressure readings to identify fluctuations indicative of patient parameters, such as heart rate and/or respiration rate. In some embodiments, a patient heart rate and/or respiration rate may be determinable by the fluid pressure in the fluid flow lines and fluid bags. The controller <NUM> may also be operatively connected to and/or communicate with additional sensors or sensor systems, although the controller <NUM> may use any of the data available on the patient's biologic functions or other patient parameters. Dialysis systems may send and/or receive information to the integrated care system <NUM>, <NUM>' for providing appropriate medical treatment to a patient, based on an estimated disease progression.

<FIG> illustrates an embodiment of an exemplary computing architecture <NUM> suitable for implementing various embodiments as previously described. In various embodiments, the computing architecture <NUM> may comprise or be implemented as part of an electronic device. In some embodiments, the computing architecture <NUM> may be representative, for example, of computing device <NUM> and/or components of the platform <NUM> and/or integrated care system <NUM>, <NUM>'.

As used in this application, the terms "system" and "component" and "module" are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture <NUM>. For example, a component can be, but is not limited to being, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed between two or more computers. Further, components may be communicatively coupled to each other by various types of communications media to coordinate operations. The coordination may involve the uni-directional or bi-directional exchange of information. For instance, the components may communicate information in the form of signals communicated over the communications media. The information can be implemented as signals allocated to various signal lines. In such allocations, each message is a signal. Further embodiments, however, may alternatively employ data messages. Such data messages may be sent across various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

As shown in <FIG>, the computing architecture <NUM> comprises a processing unit <NUM>, a system memory <NUM> and a system bus <NUM>. The processing unit <NUM> can be any of various commercially available processors, including without limitation an AMD® Athlon®, Duron® and Opteron® processors; ARM® application, embedded and secure processors; IBM® and Motorola® DragonBall® and PowerPC® processors; IBM and Sony® Cell processors; Intel® Celeron®, Core (<NUM>) Duo®, Itanium®, Pentium®, Xeon®, and XScale® processors; and similar processors. Dual microprocessors, multi-core processors, and other multi-processor architectures may also be employed as the processing unit <NUM>.

The computer <NUM> may include various types of computer-readable storage media in the form of one or more lower speed memory units, including an internal (or external) hard disk drive (HDD) <NUM>, a magnetic floppy disk drive (FDD) <NUM> to read from or write to a removable magnetic disk <NUM>, and an optical disk drive <NUM> to read from or write to a removable optical disk <NUM> (e.g., a CD-ROM or DVD). The HDD <NUM>, FDD <NUM> and optical disk drive <NUM> can be connected to the system bus <NUM> by a HDD interface <NUM>, an FDD interface <NUM> and an optical drive interface <NUM>, respectively. The HDD interface <NUM> for external drive implementations can include at least one or both of Universal Serial Bus (USB) and IEEE <NUM> interface technologies.

The drives and associated computer-readable media provide volatile and/or nonvolatile storage of data, data structures, computer-executable instructions, and so forth. For example, a number of program modules can be stored in the drives and memory units <NUM>, <NUM>, including an operating system <NUM>, one or more application programs <NUM>, other program modules <NUM>, and program data <NUM>. In one embodiment, the one or more application programs <NUM>, other program modules <NUM>, and program data <NUM> can include, for example, the various applications and/or components of system and/or apparatus <NUM>, <NUM>', <NUM>, <NUM>', <NUM>, <NUM>.

A user can enter commands and information into the computer <NUM> through one or more wire/wireless input devices, for example, a keyboard <NUM> and a pointing device, such as a mouse <NUM>. Other input devices may include microphones, infra-red (IR) remote controls, radio-frequency (RF) remote controls, game pads, stylus pens, card readers, dongles, finger print readers, gloves, graphics tablets, joysticks, keyboards, retina readers, touch screens (e.g., capacitive, resistive, etc.), trackballs, trackpads, sensors, styluses, and the like. These and other input devices are often connected to the processing unit <NUM> through an input device interface <NUM> that is coupled to the system bus <NUM>, but can be connected by other interfaces such as a parallel port, IEEE <NUM> serial port, a game port, a USB port, an IR interface, and so forth.

When used in a WAN networking environment, the computer <NUM> can include a modem <NUM>, or is connected to a communications server on the WAN <NUM>, or has other means for establishing communications over the WAN <NUM>, such as by way of the Internet. The modem <NUM>, which can be internal or external and a wire and/or wireless device, connects to the system bus <NUM> via the input device interface <NUM>. In a networked environment, program modules depicted relative to the computer <NUM>, or portions thereof, can be stored in the remote memory/storage device <NUM>. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers can be used.

The computer <NUM> is operable to communicate with wire and wireless devices or entities using the IEEE <NUM> family of standards, such as wireless devices operatively disposed in wireless communication (e.g., IEEE <NUM> over-the-air modulation techniques). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth™ wireless technologies, among others. Thus, the communication can be a predefined structure as with a conventional network or simply an ad hoc communication between at least two devices. Wi-Fi networks use radio technologies called IEEE <NUM>. 11x (a, b, g, n, etc.) to provide secure, reliable, fast wireless connectivity. A Wi-Fi network can be used to connect computers to each other, to the Internet, and to wire networks (which use IEEE <NUM>-related media and functions).

Some embodiments of the disclosed systems may be implemented, for example, using a storage medium, a computer-readable medium or an article of manufacture which may store an instruction or a set of instructions that, if executed by a machine (i.e., processor or microcontroller), may cause the machine to perform methods and/or operations in accordance with embodiments of the disclosure. In addition, a server or database server may include machine readable media configured to store machine executable program instructions. Such a machine may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, or the like, and may be implemented using any suitable combination of hardware, software, firmware, or a combination thereof and utilized in systems, subsystems, components, or sub-components thereof. The computer-readable medium or article may include, for example, any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage article, storage medium and/or storage unit, for example, memory (including non-transitory memory), removable or non-removable media, erasable or non-erasable media, writeable or re-writeable media, digital or analog media, hard disk, floppy disk, Compact Disk Read Only Memory (CD-ROM), Compact Disk Recordable (CD-R), Compact Disk Rewriteable (CD-RW), optical disk, magnetic media, magneto-optical media, removable memory cards or disks, various types of Digital Versatile Disk (DVD), a tape, a cassette, or the like. The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, and the like, implemented using any suitable high-level, low-level, object-oriented, visual, compiled and/or interpreted programming language.

As used herein, an element or operation recited in the singular and proceeded with the word "a" or "an" should be understood as not excluding plural elements or operations, unless such exclusion is explicitly recited.

To the extent used in this description and in the claims, a recitation in the general form of "at least one of [a] and [b]" should be construed as disjunctive. For example, a recitation of "at least one of [a], [b], and [c]" would include [a] alone, [b] alone, [c] alone, or any combination of [a], [b], and [c].

Claim 1:
A method for estimating progression of chronic kidney disease in a patient (<NUM>, <NUM>) and applying clinical interventions, comprising:
determining historic values (<NUM>, <NUM>) of at least one patient parameter (eGFR) that varies as a function of the progression of the chronic kidney disease over time, wherein the at least one patient parameter (eGFR) includes an estimated glomerular filtration rate (eGFR);
computationally estimating a trend (<NUM>) corresponding to the historic values (<NUM>, <NUM>);
calculating predicted future values (<NUM>, <NUM>) of the at least one patient parameter (eGFR) based on the trend (<NUM>);
based on the trend (<NUM>), automatically providing at least one marker (140a-n) that identifies a clinical intervention and a time in the future when the clinical intervention is expected to be needed;
generating a visual chart (<NUM>) by incorporating the at least one marker (140a-n) and at least one of a) the trend (<NUM>) and b) the predicted future values (<NUM>, <NUM>) of the at least one patient parameter (eGFR) calculated based on the trend (<NUM>), wherein the trend (<NUM>) is shown as a trend line (<NUM>) in the visual chart (<NUM>) and wherein the at least one marker (140a-n) is placed along the trend line (<NUM>); and
based on the at least one marker (140a-n), executing clinical preparations at a time prior to the administration of the intervention in order to improve at least one of a) timeliness of the execution of the intervention and b) effectiveness of the intervention.