SYSTEMS AND METHODS FOR CLINICAL DECISION-MAKING

Abstract

Computer implemented methods are disclosed. The methods may include receiving historical data comprising at least one of provider data and patient data, and processing, using a processor, the historical data to identify one or more patterns. The method also may include generating one or more decision models from the historical data and the decision patterns, and providing one or more recommendations based on the one or more decision models.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This Application claims the benefit of U.S. Provisional Application No. 61/839,528, entitled “Systems and Methods for Managing Patient Conditions”, filed Jun. 26, 2013, the disclosure of which is incorporated herein by reference in its entirety.

TECHNICAL FIELD

The present disclosure relates generally to providing recommendations based on receiving and processing historical data. More specifically, the present disclosure relates to systems and methods for learning decision-making and providing recommendations based on the learned decision-making. In some embodiments, the recommendation may be made automatically.

BACKGROUND

Increased healthcare costs have limited patient access to appropriate care. At the same time, healthcare companies have increased provider workloads and limited physician-patient interactions. This in turn may lead to improper patient assessments and treatment. In an attempt to increase physician productivity and improve the accuracy of patient assessments, methods have been attempted to implement clinical rules and validated mathematical/statistical models based on patient diagnostic information. Some conventional methods provide patient assessment reports prior to a patient's next physician visit. These reports include data submitted by patients, such as daily blood glucose levels, dietary intake, etc. However, such methods do not provide an analysis of the data and/or or recommendations tailored to the patient and/or based on the healthcare provider's characteristics and preferences.

Thus, a need exists for improved systems and methods for increasing healthcare provider productivity, accurately assessing a patient, and providing patient treatment consistent with the healthcare provider's treatment style and/or decision-making characteristics.

SUMMARY

Embodiments of the present disclosure relate to, among other things, methods and systems for providing a treatment recommendation. Each of the embodiments disclosed herein may include one or more of the features described in connection with any of the other disclosed embodiments.

According to certain embodiments, computer-implemented methods are disclosed for automatically providing a treatment recommendation, the method may include receiving historical data comprising at least one of provider data and patient data; processing, using a processor, the historical data to identify one or more patterns; generating one or more decision models from the historical data and the decision patterns; and providing one or more recommendations based on the one or more decision models.

Aspects of the method may include one or more of the following: further comprising receiving electronic feedback on at least one of the one or more recommendations; further comprising storing the electronic feedback as historical data; further comprising exchanging the electronic feedback with a third party; further comprising receiving real-time data comprising at least one of provider data and patient data; wherein the historical data comprises treatment instructions and the real-time data comprises compliance with the treatment instructions; wherein the real-time data is received from a patient's electronic device; further comprising extracting metadata from the historical data; further comprising biasing the historical data based on the metadata; wherein the processor uses one or more machine learning algorithms; wherein the generating one or more decision models comprises importing models from a library of models; further comprising accessing one or more medical records and parsing the historical data from the one or more medical records; further comprising presenting the one or more identified patterns to a provider; further comprising receiving instructions to modify the one or more decision models; further comprising providing a comparison between the one or more recommendations, a recommendation based on standard guidelines, and a recommendation based on external data; and wherein one of the patient data and provider data comprises demographic information.

In another aspect, disclosed is an information processing device for providing a treatment recommendation, the device may include a processor for processing a set of instructions, and a computer-readable storage medium for storing the set of instructions, wherein the instructions, when executed by the processor, perform a method comprising receiving historical data comprising at least one of provider data and patient data; processing, using a processor, the historical data to identify one or more patterns; generating one or more decision models from the historical data and the decision patterns; and providing one or more recommendations based on the one or more decision models.

The processing device may include one or more of the following features: the method further comprising receiving electronic feedback on at least one of the one or more recommendations; and the method further comprising further comprising receiving real-time data comprising at least one of provider data and patient data.

In another aspect, disclosed is a non-transitory computer-readable medium storing a set of instructions that, when executed by a processor, may perform a method of providing a treatment recommendation, the method may include receiving historical data comprising at least one of provider data and patient data; processing, using a processor, the historical data to identify one or more patterns; generating one or more decision models from the historical data and the decision patterns; and providing one or more recommendations based on the one or more decision models.

It may be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate exemplary embodiments of the present disclosure and together with the description, serve to explain the principles of the disclosure.

FIG. 1 is flow diagram of an exemplary method for clinical decision-making, according to an exemplary embodiment of the present disclosure;

FIG. 2 is a flow diagram of an exemplary method for data collection, according to an exemplary embodiment of the present disclosure;

FIG. 3 is a flow diagram of an exemplary method for extracting and identifying metadata, according to an exemplary embodiment of the present disclosure;

FIG. 4 is a flow diagram of an exemplary method for selecting and applying algorithms to data, according to an exemplary embodiment of the present disclosure;

FIG. 5 is a flow diagram of an exemplary method for evaluating and modifying a recommendation, according to an exemplary embodiment of the present disclosure;

FIG. 6 is a flow diagram of an exemplary method for collecting data, according to an exemplary embodiment of the present disclosure;

FIG. 7A is flow diagram an exemplary method for electronically selecting a recommendation, according to an exemplary embodiment of the present disclosure;

FIG. 7B is a flow a flow diagram of an exemplary method for electronically presenting a clinical decision, model to a provider and a patient, according to an exemplary embodiment of the present disclosure;

FIG. 8 is a schematic diagram of an arrangement by which a clinical decision may be generated, according to an exemplary embodiment of the present disclosure; and

FIG. 9 is a simplified functional block diagram of a computer that may be configured as a host server, for example, to function as healthcare provider decision-making server, according to an exemplary embodiment of the present disclosure.

DESCRIPTION OF THE EMBODIMENTS

Overview

The present disclosure is drawn to systems and methods for providing recommendations based on analyzing past decisions. More specifically, the present disclosure relates to systems and methods for analyzing historical data to learn provider decision-making, applying machine learning algorithms to generate decision models, and providing (e.g. automatically) recommendations on subsequent scenarios based on the learned decision-making.

EXEMPLARY EMBODIMENTS

FIG. 1 is a flow diagram of an exemplary method for providing a treatment recommendation 100. In some embodiments, the depicted method 100 may be used for automatic clinical decision-making. As shown in FIG. 1, a healthcare provider (the provider), such as a physician, dentist, physical therapist, psychologist, and/or other healthcare professional may register with a service provider to receive automatic recommendations for treating a patient 102 in any suitable manner. For example, the healthcare provider may electronically communicate with a service providing clinical recommendations (the service) to indicate interest in receiving clinical recommendations. The electronic communication may be via an internal or external network, such as via the Internet and/or any other electronic network. In some embodiments, the electronic communication may be via a wired or a wireless network (e.g. Wi-Fi, Blue Tooth, and/or near field communication). During registration, the provider may provide relevant information to the service, such as billing information, type of healthcare practice (e.g. pediatric, psychiatry, internal medicine, and/or surgical), and/or information about the provider's practice and preferences (e.g. proponent of surgical intervention, proponent of alternative medical therapies such as yoga and meditation). In some examples, the service may provide confirmation of registration and/or request further information from the provider to complete registration in any suitable manner. The service also may provide the provider with materials to access its services, for example by providing a software application (such as a mobile application) having a graphical user interface (GUI) and/or codes to access restricted web-sites. In some examples, the software application may allow the provider to view, transmit, and receive information to and from the service via the GUI. The provider may designate any preferences to the service during the registration step 102 and/or any other time. For example, the provider may indicate, via the GUI, that the service should only be used for patients who have a blood glucose level above, e.g. 130 mg/dL. In some examples, the service may provide programming, such as software applications, that may be integrated with existing provider programming. For example, the programming (e.g. a software application) provided by the service may be integrated/compatible or otherwise able to communicate with the provider's programming for electronic medical records, electronic billing, and electronic scheduling. The provider also may instruct that the service to provide selective access to patient's. For example, during registration 102 or at any other time, the provider may allow a patient to selectively view information provided by the service and allow the patient to submit relevant patient data to the service, either selectively or automatically (e.g. via automatic updates from a patient's electronic device). In one embodiment, the provider may allow a patient to download the service's software application to the patients electronic device and allow the patient to submit data to the service via the electronic device (e.g. a mobile device which may have a built in blood glucose monitor or heart rate monitor) either through wired of wireless communication.

Historical health data may be received by the service that is relevant to the provider and the provider's patients. This data may be electronically transmitted by the provider and/or the patient and received by the service at step 104. The data may be electronically transmitted and received by the service at step 104 in any suitable manner. For example, the provider may access the software application or secure server and send or drop electronic data files via a network, e.g. the Internet so that the files may be accessed by the service. In some examples, the provider may allow the service limited access in compliance with any healthcare privacy regulations and other applicable regulations, to any electronic medical records, patient prescription records, referral records, etc., and the service may electronically retrieve healthcare data from such electronic records (e.g. automatically). In other examples, patient data may be electronically transmitted by a patient and may be electronically received by the service in any suitable manner. The patient data may be actively submitted by the patient via a software application and/or may be automatically electronically retrieved by the service from an electronic device of the patient (FIG. 2) that may measure patient health values, such as heart rate, blood glucose, blood oxygen, blood pressure, activity, stress, mood, and/or sleep either periodically or continuously.

The historical data received at step 104 may include any relevant historical data, including a clinical profile of the patient such as diseases, significant medical events (e.g. heart attack, stroke, head trauma, transplant), disease stage, lab values, patient self-reported clinical, behavioral and psycho-social data, patient's demographics, medical history, provider characteristics such as age, years of clinical practice experience, size of practice, specialty, demographics, context of a patient's visit such as date, day, time, location, duration of visit, and/or a decision which includes medication change, psycho-therapy, dose change, lifestyle modification (diet, exercise, weight loss), recommendation for lab test(s), education, and may include the reasoning behind the provider's decision(s).

The historical data received by the service at step 104 may be stored in a database at step 106 such as a server, cloud, or any other digital memory device. The data may be accessed at any time by the service and may be displayed, printed, or updated in any suitable manner. The stored data may be organized and accessed in any suitable manner. In some examples, the data may be electronically tagged with various identifiers, such as age, gender, clinical condition, etc. In another example, metadata may be extracted from the stored data (FIG. 3).

In addition, the data stored in the database at step 106 may be electronically processed in any suitable manner. In step 108, for example, various algorithms may be applied to the data to learn from/be trained by analyzing the data. In some examples, machine learning algorithms and/or other higher-level algorithms (e.g. supervised and unsupervised learning algorithms) may be applied to the data to learn and otherwise extract information from the data, such as for use in learning provider decision-making patterns and behaviors and/or patient behavioral patterns. Examples of such machine learning algorithms may include artificial neural networks, Bayesian statistics, case-based reason, decision trees, inductive logic processing, Gaussian process regression, Gene expression programming, Logistic model trees, stochastic modeling, statistical modeling (e.g. Bayesian networks, Markov models, ANOVA, etc.), and/or any other suitable algorithm or combinations of algorithms. For example, at step 108, machine-learning algorithms may be applied to the data to learn the characteristics of patients for which the provider has prescribed or modified use of a drug, provided a referral to another provider, recommended a lifestyle change (e.g. exercise, diet, and/or stress management).

The machine learning algorithms applied at step 108 may detect any patterns, idiosyncrasies, or any other significant associations that may be used in generating a decision model that mimics or attempts to understand the decision-making of the provider and/or predicted behavior of the patient. In another example, the machine-learning algorithm may identify a patient cohort for whom components of a treatment plan may be effective, ineffective, or partially effective, such as a cholesterol-lowering drug that is ineffective for patients with neuropathy. In some embodiments, any patterns identified in step 108 may be presented to the provider to improve the provider's clinical knowledge. For example, it may be determined at step 108 that 83% of the provider's diabetes patients between ages 65-75 for whom the provider prescribed dementia drug X suffered headaches, and only 3% of the provider's patients adhered to a diet change. Based on these patterns the provider may stop prescribing drug X to patients between ages 65-75 and stop recommending a diet change to patients ages 18-35. In another embodiments, the machine learning algorithm applied at step 108 may detect patient compliance with the provider's treatment plan, for example, it may be determined that 90% of the provider's patients over the age of 85 did not adhere to taking dementia drug X.

The application of the one or more machine learning algorithms at step 108 may be processed to generate clinical decision models at step 110. The models may be based on any patterns or other information learned by the machine learning algorithms. The models may be generated using one or more processors and may be tested with sample data that may be reviewed and automatically validated. In some embodiments, existing models may be imported from databases or libraries, processed, and applied to the data processed at step 108. In some embodiments, at step 110, the service may send the provider a notification that it is ready to provide clinical recommendations. The notification may be sent when it is determined sufficient data has been collected to provide an accurate recommendation. In some embodiments, the notification may be sent after a day, a week, a month, three months, or any other period of time. The notification may be in any suitable form, e.g. an electronic message, alert, and/or phone call.

The service may receive information in connection with a clinical scenario at 112, for example, from the provider, in any suitable manner (e.g. via a software application over the Internet). In some embodiments, the clinical scenario may be associated with an upcoming patient appointment, a current patient appointment, or a past patient visit. The service may process the information received in connection with the clinical scenario in any suitable manner. The clinical scenario may be submitted to the service directly by the provider or a proxy of the provider. For example, a patient may visit a physician's office and provide a nurse with information regarding the patient's reason for the visit, (e.g. onset of frequent migraines), and the nurse may record the patient's diagnostic information (e.g. weight, blood pressure, blood glucose level, and heart rate), and submit a recommendation request to the service on behalf of the physician.

Real-time data may be received at 118 after generating the decision models 110 or any time during method 100. The real-time data may include any relevant patient and/or provider information that may be used to generate the decision model or to improve the decision model. In some embodiments, real-time data may include behavioral data, demographic data, and financial data. The real-time data may be selectively collected or continuously collected from the provider and patients. The real-time data also may be obtained that is non-specific to the provider and/or the patient, such as weather conditions, current events, date, and/or season. This non-specific real-time data may be used to improve the accuracy the recommendation, for example, if the real-time data indicates that the temperatures for the last ten days where the patient lives have been below −10 degrees Fahrenheit, the service may not recommend that a patient start exercising outside as it may be too cold to exercise outside. In some examples, if the service is unable to complete a decision model, real-time data may be requested to complete or improve the decision model.

In some examples, step 114 may include automatically or upon provider selection, applying one or more of the decision models to the clinical scenario received at step 112 and/or extracting discrete data values from the clinical scenario and applying the decision models to each data value separately, and then combining the decision models. For example, the clinical scenario may include a patient who is a 67-year old male smoker that has type-2 diabetes, and has previously suffered a stroke. The patient may visit the provider complaining of shortness of breath. In addition, the patient may be receptive to lifestyle changes and the provider may indicate resistance to trying new drug therapies. One or more models may be applied to each the clinical scenario data values (e.g., patient age, diagnostic information, behavioral values, provider characteristics). In addition, or alternatively, all of the clinical scenario data values may be treated together and one or more models may be applied to all or subgroups of the data values. The results of applying the decision models may be further processed to detect any inconsistencies and/or errors and may be presented to the provider as a recommendation in any suitable manner for evaluation. For example, the recommendation may include a recommendation based on applying the machine learning data algorithms at step 108 to learn the provider's decision-making characteristics and application of the decision models. In addition, the recommendations may include recommendations based on other provider decision-making characteristics, recommendations based on standard guidelines (e.g. according to the American Diabetes Association, American Medical Association, etc.), and/or any other sources. The service may provide a comparison of each of the recommendations and also may suggest any changes in the provider's decision-making to improve patient treatment, reduce healthcare costs, etc. In some embodiments, the service may provide a rationale for each recommendation.

At step 116, the service may receive electronic feedback on the recommendation. The feedback may be in the form of an evaluation by the provider and/or the patient on the recommendation. In some examples, an evaluation form soliciting feedback on the recommendation may be sent by the service for completion by the provider and/or patient. The evaluation may include an indication of whether or not the recommendation was followed, a rating of the recommendation, an explanation of the why the recommendation was followed or why it was not followed. In this manner, the patient may receive a treatment plan that is tailored to the patient and the provider may quickly and easily provide a treatment plan that is in line with provider's standard of care and philosophy.

The provider's decision may be recorded at step 120 and may be stored as historical data for use in subsequent recommendations. At step 122, the provider's recommendation may be presented to the user in any suitable manner. In some embodiments the results of the provider's decision and/or other provider decision's may be saved and exchanged (e.g. sold and/or exchanged for other data) to a third party without including any patient identifying data. For example, a pharmaceutical company may purchase data from the service on provider decisions in order to improve marketing and research and development efforts. In another example, health insurance companies may be interested in the provider decision data to improve healthcare services and reduce costs. The provider decision data also may be provided to improve standard treatment guidelines and evaluate provider adherence to standard guidelines and recommendations.

FIG. 2 shows a flow diagram of an exemplary method 200 for data collection including automatic data collection. The method 200 may be used to gather and transmit health data from a provider and/or patient to a service, as shown in step 104 of FIG. 1. Historical health data may be retrieved that is relevant to a provider and the provider's patients (202). At step 204, historical health data that is relevant to the provider may be gathered. Such data may include various provider characteristics including, but not limited to, the provider's type of practice, specialty, age, years of experience, size of practice, location of practice, access to referrals, gender, education, type of training, access to treatments, and/or expertise. Historical health data that may be relevant to a patient also may be gathered at step 206. Such data may be retrieved or extracted by parsing patient electronic medical records using a processor. Such parsing may include parsing of clinical data and/or psychological data. A patient's personal information (e.g. age, gender, and education), social information, and or lifestyle characteristics (e.g. diet, and exercise regimen) also may be retrieved. The historical data gathered at step 204 and step 206 may be organized in any suitable manner at step 208 may be stored in a database at step 210.

FIG. 3 is a flow diagram of an exemplary method 300 for extracting and identifying metadata. In some examples, the metadata is extracted from the collected historical data and/or real-time data in order to rate the value of the data. The metadata may be used in step 108 of applying machine-learning algorithms. As shown in FIG. 3, metadata may be extracted in various manners. For example, descriptive statistics 302 may be used, which may include the mean, standard deviation, and/or the variance. Another type of metadata extraction method may include determining the availability of the historical data at step 304. For example, it may be determined that a patient's self-monitoring blood glucose (SMBG) levels are only available on a weekly basis; whereas a patient's continuous glucose data is available (CGM) only on Thursdays. The metadata based on the type of data may be extracted at step 306, such as location specific models, and weather specific models. In addition, metadata based on the category type may be determined at step 308, such as clinical, behavioral, and/or personal. For example, the location where a patient's blood glucose measurement was taken may be extracted and this category of metadata (location) may be used in the decision-making model. In this example, different decision models may be used to process the measurement if the measurement was taken at the patient's home versus if the measurement was taken was at a restaurant. Based on the appropriate data category (such as a patient's location) certain decision-support/recommendation may be useful. Hence an appropriate model for such a decision-making may be selected.

The source of the data also may be extracted at step 310 and the relationship/influence of the source may be determined. For example, it may be determined that the source of a first blood glucose level measurement was a highly accurate hospital device, and the source of a second blood glucose level measurement was a less accurate patient device, and therefore, the first measurement may be designated as having a greater value/be more reliable than the second measurement.

The type of metadata may be identified at step 312 in any suitable manner, such as by parsing the metadata, and/or a rules engine to the metadata. The parsing/rules engine may use appropriate algorithms, such as logic based algorithms, to match data against a reference knowledge base to identify the category of the data. For example, if the data is latitude and longitude coordinates, the parsing/rules engine may be used to match the data against a category called ‘location’. In another example, if the data is had a burger and fries at noon, the parsing/rules engine may be used to match the data against a category called ‘diet’ and/or a category called ‘time’.

FIG. 4 is a flow diagram of an exemplary method 400 for selecting and applying algorithms to data such as historical data, metadata, and/or real-time data. The method 400 may be used in any suitable method, for example, method 100. As shown in FIG. 4, metadata type may be discovered at step 402 in any suitable manner, for example, using the method 300 shown in FIG. 3. Processing rules may be imported from databases and/or libraries at step 404 in any suitable manner. For example, logic processing rules (414), which may include simple logic, algorithmic logic, machine learning models, and/or mathematical models, may be imported. At step 406, the applicable processing rules for data conversion based on the discovered metadata type may be determined. The data may be processed at step 408. Based on the processing rules, one or more models may be imported from the logic library at step 410. The logic library 416 may include various models, such as category/response models, and/or stochastic models. One or more models may be chose for application to the processed data at step 412 and model combinator rules may be imported from a database 420. For example, the database may include model combinator rules 418, which may include secondary sources and data on multiple diseases. The models may be chosen based on the model combinator 422 rules and a recommendation maybe generated from the data 424.

FIG. 5 is a flow diagram of an exemplary method 500 for evaluating and modifying an automatic recommendation. The method 500 may be used with any suitable method, for example, with method 100. In method 500, a provider may interact with a computer software application (502) to evaluate and provide electronic feedback on a recommended presented to the provider by the service at step 504. The recommendation may include a rationale for the recommendation. The provider may provider corrective adjustments of the recommendation and/or the rationale at step 508. For example, the recommendation provided to the provider at step 504 may be that the patient have hip surgery and this may be based on rationale that the patient is not a good candidate for pain medication due to a severe allergic reaction to the medication. In this example, the provider may provide corrective adjustments to the rationale, such as providing that the patient should have hip surgery because the amount of pain the patient is suffering cannot be managed by drugs alone. In some aspects, the provider may be presented with a course of action based on an external model that is not based on processing of the provider healthcare data at step 506. For example, the service may recommend that the provider prescribe a new cocktail drug therapy that a recent study showed to be effective in 90% of all patients. At step 510, the provider decision and/or corrective adjustments may be stored in memory.

FIG. 6 is a flow diagram of an exemplary method 600 for automatically electronically collecting data in real-time. The method may include health data received in real-time from the provider 602. For example, provider prescription data 604, which may include newly prescribed, changed medication, and/or halted prescription data. The real-time health data also may include data regarding the provider rationale (606) for making his/her decision, such as the provider's rationale for prescribing the medication, the provider's perception of the medication, the provider's perception of the patient's lifestyle, the provider's perception of the patient's lifestyle, the provider's perception the patient's adherence to the prescription, the provider's perception of the patient's education or understanding of the prescription, the provider's perception of the patient's demographics. At the same time or any other time, real-time health data from the patient may be received at step 610. For example, updates of medical records (612) (clinical data and prescription data) and patient lifestyle information 614 from various electronic monitoring devices, and/or the patient's psychosocial well-being data (616) such as the patient's outlook, feelings, and/or financial data. In addition, information regarding the provider patient interaction setting 608 maybe received (e.g. hospital setting or at home setting) The real-time data may be inputted and/or automatically sent via a software application via the Internet 618 and the data may be stored in digital memory 620.

FIG. 7A is a flow diagram of an exemplary method 700 for electronically receiving patient evaluations of decision models. The method 700 may be used in any suitable manner, for example, with method 100 for automatic clinical decision-making. Method 700 may be used to improve the breadth, customization, and significance of decision models, for example, the decision models generated in method 100.

As shown in FIG. 7A, a patient evaluation of one or more decision models may be received at step 702. The evaluation may be received from a patient, such as a self-help patient by the patient interacting with a computer software application presenting clinical decision models at step 704. For example in step 706, the patient may be presented with likely courses of action and a rationale for each action. Examples of such presentations may include a medication course of action and rationale for why the medication was recommended, a lifestyle course of action and rationale for why it was recommended, and an education course of action and rationale for why it was recommended. The self-help patient may then make a selection at step 708 from one of the recommendations. The selection may be electronically stored in memory at step 712 and real-time data may be received from the self-help patient at step 710. The real-time data and stored decision may be processed, for example, as shown in method 100, to improve the models and model selections. In some embodiments, a treatment plan may be generated for the self-help patient at step 714 for on-going heath-management.

FIG. 7B is a flow a flow diagram of an exemplary method 750 for electronically presenting clinical decision model to a provider and a patient. As shown in FIG. 7B, a clinical decision model may be generated at step 754 in any suitable manner, such as in the manner described in step 110. The provider may be presented with a clinical scenario at step 756 (e.g. a patient with high cholesterol). The provider may communicate the scenario, such as a clinical scenario to the service at step 758. The provider may receive a recommendation from the service at step 760 along with a rationale for the recommendation. The recommendation may be generated in any suitable manner, such as in the manner described in step 114. The provider may evaluate the recommendations at 762 and send the evaluation to the service.

In addition, or alternatively, a self-help patient may be presented with a clinical scenario or symptoms (e.g., a diabetes patient may have symptoms of fatigue and headaches) and may communicate such symptoms to the service. The self-help patient may receive a recommendation and rationales for the recommendations from the service for evaluation. The patient may select one of the recommendations and may provide an evaluation of the recommendation at step 766.

Example 1

An internal medicine physician may register with a web-based provider of clinical recommendations. During registration, the physician may provide her personal information, such as:

Age: 43        No. of patients: 150
               Ages: 18-35: 40
               36-50: 50
               51-75: 40
               75+: 20
Gender: Female Specialized Training: Fellowship in
               endocrinology; acupuncture training
Years of Practice: 18
Location: New York City
Practice type: Academic Hospital

The service provider may store this data and continuously receive physician data and the physician's patient's data over a period of time, thereby collecting and storing historical data on the provider's practice. The historical data may be continuously processed using algorithms, such as machine learning algorithms, to determine any patterns. The service may notify the provider that she has prescribed antibiotics to 40% of her patient's in the last week. This may indicate to the provider that there is a bacterial infection outbreak in her patient population and that she should recommend all her patients to take preventative measures to avoid being infected. The decision models may be generated based on the processed data and real-time data may be continuously received (e.g. the date, temperature, and physician workload). The service may indicate to the physician that it has obtained a sufficient amount of historical data to provide a clinical recommendation by sending her an email notification. The physician may then decide to receive a recommendation from the service and submit a clinical scenario to the service of a patient—

Patient A. Smith

Age: 57

Height: 5′10″

Weight: 200 pounds
Random Blood glucose levels: High

Blood Pressure: High

The service may retrieve historical data on the patient indicating that he has a family history of diabetes and heart disease, is taking cholesterol medication, suffered a stroke 4 years ago, has a high-stress lifestyle, and eats cake the first Friday of every month. The service also may receive real-time data on the patient indicating that the patient exercises regularly, eats a healthy diet, but has minimal social interaction and receives less than five hours of sleep every night, and has been late in making his credit card payments three months in a row. The service also may identify patterns in the provider's historical data indicating that she rarely prescribes blood pressure medication and often instructs patients in the patient's age range to change their diet and exercise. Data also may be received from external sources that indicates that patients who are 50-60 and who live in New York City have a 90% adherence rate to blood pressure lowering medication. The service also may receive real-time data from the provider indicating that she has recently authored a research article on the benefits of avoiding carbohydrates for diabetes patients. The service may process the historical and real-time data and provide the physician a recommendation and its rationale based on what is determined to be the physician's likely recommendation:

Recommendation:

Prescribe blood pressure medication and diabetes medication and modify diet to reduce carbohydrate intake.

Rationale:

The patient has a family history of heart disease and diabetes and already exercises and has a healthy diet, therefore lifestyle change may not be effective.
In addition, the service may provide a recommendation based on the American Medical Association, and a recommendation based on all other data sources. The physician may select the recommendation and/or provide feedback on the recommendations that may be saved by the service as historical data.

Example 2

The physician of Example 1 may receive a patient report on the patient of Example 1 prior to the patient's next visit. Prior to the visit the service may provide a report to the physician and a recommendation based on historical and real-time data:

Recommendation:

Reduce strength of prescription of medication, prescribe antibiotics, and muscle relaxers.

Rationale:

The patient's blood glucose and blood pressure levels have decreased. The patient changed his diet, increased his exercise regime, and has moved to the beach. In addition, the patient has been coughing, and sneezing and has back pain.
In addition, the service may provide a recommendation based on the American Medical Association, and a recommendation based on all other data sources. The physician may decide to follow the recommendation in part, but halt the medication and provide feedback on the recommendations that may be saved by the service as historical data.

FIG. 8 is a schematic diagram of an arrangement of a system 800 by which a clinical decision may be automatically generated, according to an exemplary embodiment of the present disclosure. For example, the system 800 may access decision models stored on a decision model database 870 via a network 805, such as the Internet. The retrieved decision models may be used for display and/or processing by one or more provider and/or patient devices 810, such as a mobile device 815 (e.g., mobile phone, personal digital assistant, tablet computer), tablet device 820, a computer (laptop, desktop) 425, kiosk 830 (e.g. kiosk at pharmacy, clinic or hospital having medical and/or prescription information), and/or any device connected to a network 805, such as the Internet, according to an exemplary embodiment of the present disclosure.

In the example shown in FIG. 8, mobile electronic device 815 may be a smartphone, a personal digital assistant (“PDA”), medical diagnostic device, or other type of mobile computing device, such as a device having a touchscreen display. Mobile device 815, tablet 820, and computer 825 each may be equipped with or include, for example, a GPS receiver for obtaining and reporting location information, e.g., GPS data, via network 805 to and from any of servers 835 and/or one or more GPS satellites 855.

However, it should be noted that each of user devices 810, including mobile device 815, tablet device 820, computer 825, and/or kiosk 830, may be implemented using any type of electronic device configured to send and receive data (e.g. clinical information) to and from a system of servers 835 over network 805. The user input device(s) may include any type or combination of input/output devices, such as a display monitor, touchpad, touchscreen, microphone, camera, keyboard, and/or mouse.

The various user devices 810 may also communicate with each other by any suitable means (e.g., via Wi-Fi, radio frequency (RF), infrared (IR), Bluetooth, Near Field Communication, or any other suitable means) to send and receive location and other information. For example, a mobile device 815 may communicate with tablet device 820 or kiosk 830.

The user device 810 may receive information, such clinical data via the network 805 from the system of servers 835, having one or more servers such as clinical data servers 840, algorithm servers 845, user interface servers 850, and/or any other suitable servers. Each server may access the decision model database 870 to retrieve decision models. Each server may include memory, a processor, and/or a database. For example, the clinical data server 840 may have a processor configured to retrieve clinical data from a provider's database and/or a patient's electronic medical record. The algorithm server 845 may have a database that includes various algorithms, and a processor configured to process the clinical data. The user interface server 850 may be configured to receive and process user input, such as clinical decision preferences. The satellite 855 may be configured to send and receive information to the server system 835 and user devices 810.

The clinical data server 840 may receive clinical data, such as data regarding the provider and the patient from the user device 810 via the network 805 or indirectly via the user interface server 850. The clinical data server 840 may save the information in memory, such as a computer readable memory.

The clinical data server 840 also may be in communication with one or more other servers, such as the algorithm server 845 and/or external servers such as servers of providers 860 and/or patients 865 (e.g. medical records servers). The servers may include data about provider preferences, and/or patient health history. In addition, the clinical data server 860 may include data from other providers and/or patients. The algorithm server 845 may include machine learning, and/or other suitable algorithms. The algorithm server 845 may be in communication with other external servers and may be updated as desired. For example, the algorithm server 845 may be updated with new algorithms, more powerful programming, and/or more data. The clinical data server 840 and/or the algorithm server 845 may process the information and transmit data to the model server 870 for processing.

Each server in the system of servers 835, including clinical data server 840, algorithm server 845, and UI server 850 may each represent any of various types of servers including, but not limited to a web server, an application server, a proxy server, a network server, or a server farm. Each server in the system of servers 835 may be implemented using, for example, any general-purpose computer capable of serving data to other computing devices including, but not limited to, user devices 810 or any other computing device (not shown) via network 805. Such a general-purpose computer can include, but is not limited to, a server device having a processor and memory for executing and storing instructions. The memory may include any type of random access memory (RAM) or read-only memory (ROM) embodied in a physical storage medium, such as magnetic storage including floppy disk, hard disk, or magnetic tape; semiconductor storage such as solid-state disk (SSD) or flash memory; optical disc storage; or magneto-optical disc storage. Software may include one or more applications and an operating system. Hardware can include, but is not limited to, a processor, memory, and graphical user interface display. Each server also may have multiple processors and multiple shared or separate memory components that are configured to function together within, for example, a clustered computing environment or server farm.

FIG. 9 is a simplified functional block diagram of a computer that may be configured as a host server, for example, to function as healthcare provider decision-making server. FIG. 9 illustrates a network or host computer platform 900, as may typically be used to implement a server like the clinical decision model server 870. It is believed that those skilled in the art are familiar with the structure, programming, and general operation of such computer equipment and as a result, the drawings should be self-explanatory.

A platform for a server 900 or the like, for example, may include a data communication interface for packet data communication 960. The platform also may include a central processing unit (CPU) 920, in the form of one or more processors, for executing program instructions. The platform typically includes an internal communication bus 910, program storage, and data storage for various data files to be processed and/or communicated by the platform such as ROM 930 and RAM 940 or the like. The hardware elements, operating systems, and programming languages of such equipment are conventional in nature, and it is presumed that those skilled in the art are adequately familiar therewith. The server 900 also may include input and output ports 950 to connect with input and output devices such as keyboards, mice, touchscreens, monitors, displays, etc., and communication ports 960. Of course, the various server functions may be implemented in a distributed fashion on a number of similar platforms to distribute the processing load. Alternatively, the servers may be implemented by appropriate programming of one computer hardware platform.

Program aspects of the technology may be thought of as “products” or “articles of manufacture” typically in the form of executable code and/or associated data that is carried on or embodied in a type of machine-readable medium. “Storage” type media include any or all of the tangible memory of the computers, processors or the like, or associated modules thereof, such as various semiconductor memories, tape drives, disk drives and the like, which may provide non-transitory storage at any time for the software programming. All or portions of the software may at times be communicated through the Internet or various other telecommunication networks. Such communications, for example, may enable loading of the software from one computer or processor into another, for example, from a management server or host computer of the mobile communication network into the computer platform of a server and/or from a server to the mobile device. Thus, another type of media that may bear the software elements includes optical, electrical and electromagnetic waves, such as used across physical interfaces between local devices, through wired and optical landline networks and over various air-links. The physical elements that carry such waves, such as wired or wireless links, optical links, or the like, also may be considered as media bearing the software. As used herein, unless restricted to non-transitory, tangible “storage” media, terms such as computer or machine “readable medium” refer to any medium that participates in providing instructions to a processor for execution.

The many features and advantages of the disclosure are apparent from the detailed specification, and thus, it is intended by the appended claims to cover all such features and advantages of the disclosure which fall within the true spirit and scope of the disclosure. Further, since numerous modifications and variations will readily occur to those skilled in the art, it is not desired to limit the disclosure to the exact construction and operation illustrated and described, and accordingly.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.

Claims

1. A computer-implemented method for automatically providing a treatment recommendation, the method comprising:

receiving historical data comprising at least one of provider data and patient data;

processing, using a processor, the historical data to identify one or more patterns;

generating one or more decision models from the historical data and the decision patterns; and

providing one or more recommendations based on the one or more decision models.

2. The computer-implemented method of claim 1, further comprising receiving electronic feedback on at least one of the one or more recommendations.

3. The computer-implemented method of 2, further comprising storing the electronic feedback as historical data.

4. The computer-implemented method of 2, further comprising exchanging the electronic feedback with a third party.

5. The computer-implemented method of claim 1, further comprising receiving real-time data comprising at least one of provider data and patient data.

6. The computer-implemented method of claim 5, wherein the historical data comprises treatment instructions and the real-time data comprises compliance with the treatment instructions.

7. The computer-implemented method of claim 5, wherein the real-time data is received from a patient's electronic device.

8. The computer-implemented method of claim 1, further comprising extracting metadata from the historical data.

9. The computer-implemented method of claim 8, further comprising biasing the historical data based on the metadata.

10. The computer-implemented method of claim 1, wherein the processor uses one or more machine learning algorithms.

11. The computer-implemented method of claim 1, wherein the generating one or more decision models comprises importing models from a library of models.

12. The computer-implemented method of claim 1, further comprising accessing one or more medical records and parsing the historical data from the one or more medical records.

13. The computer-implemented method of claim 1, further comprising presenting the one or more identified patterns to a provider.

14. The computer-implemented method of claim 1, further comprising receiving instructions to modify the one or more decision models.

15. The computer-implemented method of claim 1, further comprising providing a comparison between the one or more recommendations, a recommendation based on standard guidelines, and a recommendation based on external data.

16. The computer-implemented method of claim 1, wherein one of the patient data and provider data comprises demographic information.

17. An information processing device for providing a treatment recommendation, the device comprising:

a processor for processing a set of instructions; and

a computer-readable storage medium for storing the set of instructions, wherein the instructions, when executed by the processor, perform a method comprising:

receiving historical data comprising at least one of provider data and patient data;

processing, using a processor, the historical data to identify one or more patterns;

generating one or more decision models from the historical data and the decision patterns; and

providing one or more recommendations based on the one or more decision models.

18. The information processing device of claim 17, the method further comprising receiving electronic feedback on at least one of the one or more recommendations.

19. The information processing device of claim 17, the method further comprising further comprising receiving real-time data comprising at least one of provider data and patient data.

20. A non-transitory computer-readable medium storing a set of instructions that, when executed by a processor, perform a method of providing a treatment recommendation, the method comprising:

receiving historical data comprising at least one of provider data and patient data;

processing, using a processor, the historical data to identify one or more patterns;

generating one or more decision models from the historical data and the decision patterns; and

providing one or more recommendations based on the one or more decision models.