Treatment recommendation

Abstract

In one aspect, data characterizing healthcare information associated with a patient can be received. A health outcome assessment can be determined for the patient based on the received healthcare information data. A risk prediction for the patient can be determined based on the determined health outcome assessment. A treatment recommendation for the patient can be determined based on the determined risk prediction, and the treatment recommendation can be provided.

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims priority under 35 U.S.C. § 119(e) to U.S. Provisional Patent Application No. 63 / 018,493, filed Apr. 30, 2020, the entire content of which is hereby expressly incorporated by reference herein.

[0002] The subject matter described herein relates to providing recommendations for the treatment of patients, e.g., recommendations for a complete and optimal patient care plan.

Background Art

[0003] To provide comprehensive treatment information to a patient, it may be necessary to incorporate large amounts of data from many different sources. Data sources may not include the overall breadth necessary to appropriately inform the patient about the most optimal course of treatment (e.g., a care plan) for managing chronic conditions, improving health, improving well - being, etc., including up - to - date patient health data, expert clinical guidance. Treatment plan errors can include incorrect prescription writing and intake, issues with access to medications, and drug - related adverse events due to unsafe combinations of medications. In fact, the incidence and risk of sub - optimal treatment plans can increase exponentially when a patient is prescribed, for example, four or more medications, or when a patient is prescribed medications and other treatments from more than one provider. Other factors contributing to drug - related problems include inadequate information transfer between providers and lack of disclosure from the patient about other over - the - counter and herbal medications the patient is taking.

[0004] Patient interventions aimed at avoiding these negative outcomes can be provided at predetermined times as face-to-face consultations conducted by a pharmacist or physician. However, these interventions only consider the health status of each patient at a specific point in time, without considering past or future health risks. In some cases, these existing solutions do not consider the patient's past or future health risks, but instead intervene at a predetermined time independent of the patented clinical and behavioral observations, rather than at a point in time when the patient requires intervention due to increased health risks. Such limitations may restrict patients from accessing much-needed therapeutic education and counseling throughout their care process, thereby potentially exacerbating the rate of persistent medication errors. [Overview of the Initiative]

[0005] Methods and systems for treatment recommendations are provided. Related devices, techniques, and articles are also described.

[0006] In one embodiment, data characterizing healthcare information associated with a patient can be received. Health outcome assessments can be determined for the patient based on the received healthcare information data. Patient risk predictions can be determined based on the determined health outcome assessments. Treatment recommendations for the patient can be determined based on the determined risk predictions, and treatment recommendations can be provided.

[0007] One or more of the following features may be included in any feasible combination. For example, the determination of a health outcome assessment may include comparing received healthcare information data with healthcare data that characterizes a predetermined set of healthcare parameters relating to an aggregated population of patients; determining defects in the received healthcare information data based on the predetermined set of healthcare parameters; generating survey data that characterizes at least one question based on the determined defects; providing the survey data to the patient's client device; and receiving response data from the client device that characterizes at least one answer to at least one question characterized by the survey data, and the health outcome assessment may be based on the response data. For example, the generation of survey data may include querying a survey rule engine for at least one question based on the determined defects, the survey rule engine being configured to generate at least one question, the survey rule engine being modified by a survey prediction model that identifies predictor variables based on received healthcare information data and corrects the survey rule engine based on the identified predictor variables; and receiving at least one question from the survey rule engine to include in the survey data. For example, a clinical patient profile can be determined about a patient based on received healthcare information data and determined health outcome assessments, and the clinical patient profile can characterize the patient's attributes. For example, a provider profile can be determined about a healthcare server provider to a patient based on received healthcare data, and the provider profile can characterize the provider's attributes. For example, determining a patient's risk prediction may involve running a risk prediction model of risk factors that predict the likelihood of a negative health outcome, and the risk prediction model is trained to provide risk factors in response to queries based on historical patient risk data.For example, the decision on a treatment recommendation may involve querying a treatment recommendation rule engine regarding recommendation parameters based on at least one of determined risk factors, health outcome assessments, and / or received healthcare information data, wherein the query may include querying and generating a recommendation string that characterizes the recommendation parameters, and including the execution of the recommendation rule by the treatment recommendation rule engine. For example, the treatment recommendation rule engine may be modified by a predictive model that identifies predictor variables characterizing the likelihood of success of the intervention characterized by the treatment recommendation, based on received feedback data indicating the level of intervention success, determines modifications to the recommendation rule based on the identified predictor variables, and modifies the recommendation rule based on the determined modifications. For example, the provision of a treatment recommendation may include sending a recommendation string for presentation on a graphical user interface of a client device. For example, the treatment recommendation rule engine may be modified by a recommendation predictive model that identifies predictor variables characterizing patterns in adherence to the intervention proposed by the treatment recommendation, based on received healthcare information data, and modifies the rules of the treatment recommendation rule engine based on the identification. For example, determining a patient's risk prediction includes determining clinical risk parameters that characterize the level of clinical risk based on determined health outcome assessments, determining social risk parameters that characterize the level of social risk based on determined health outcome assessments, and determining behavioral risk parameters that characterize the level of behavioral risk based on determined health outcome assessments. For example, one or more of the clinical risk parameters, social risk parameters, and behavioral risk parameters can be dynamically updated based on received feedback data that characterizes the patient.

[0008] In another embodiment, a system is provided which includes at least one data processor and memory for storing instructions configured to cause at least one data processor to perform the operations described herein. The operations may include receiving data characterizing healthcare information associated with a patient; determining a health outcome assessment of the patient based on the received healthcare information data; determining a risk prediction for the patient based on the determined health outcome assessment; determining a treatment recommendation for the patient based on the determined risk prediction; and providing a treatment recommendation.

[0009] One or more of the following features may be included in any feasible combination. For example, the determination of a health outcome assessment may include comparing received healthcare information data with healthcare data that characterizes a predetermined set of healthcare parameters relating to an aggregated population of patients; determining defects in the received healthcare information data based on the predetermined set of healthcare parameters; generating survey data that characterizes at least one question based on the determined defects; providing the survey data to the patient's client device; and receiving response data from the client device that characterizes at least one answer to at least one question characterized by the survey data, and the health outcome assessment may be based on the response data. For example, the generation of survey data may include querying a survey rule engine for at least one question based on the determined defects, the survey rule engine being configured to generate at least one question, the survey rule engine being modified by a survey prediction model that identifies predictor variables based on received healthcare information data and corrects the survey rule engine based on the identified predictor variables; and receiving at least one question from the survey rule engine to include in the survey data. For example, a decision on predicting patient risk may include running a risk prediction model of risk factors that predict the likelihood of a negative health outcome, and the risk prediction model is trained to provide risk factors in response to queries based on historical patient risk data. For example, a decision on treatment recommendations may involve querying a treatment recommendation rule engine regarding recommendation parameters based on at least one of the determined risk factors, health outcome assessments, and / or received healthcare information data, and the query may include querying, which includes the execution of recommendation rules by the treatment recommendation rule engine, and generating recommendation strings that characterize the recommendation parameters.For example, a treatment recommendation rule engine can be modified by a predictive model that identifies predictive variables characterizing the likelihood of success of the interventions characterized by the treatment recommendations, based on received feedback data indicating the level of intervention success; determines modifications to the recommendation rules based on the identified predictive variables; and modifies the recommendation rules based on the determined modifications. For example, a treatment recommendation rule engine can be modified by a recommendation predictive model that identifies predictive variables characterizing patterns in adherence to the interventions proposed by the treatment recommendations, based on received healthcare information data; and modifies the rules of the treatment recommendation rule engine based on the identification.

[0010] Also described are non-temporary computer program products (i.e., physically embodied computer program products) that, when executed by one or more data processors of one or more computing systems, store instructions in at least one data processor to perform the operations described herein. Similarly, computer systems are described that may include one or more data processors and memory coupled to one or more data processors. The memory can temporarily or permanently store instructions in at least one processor to perform one or more of the operations described herein. In addition, the method may be implemented by one or more data processors within a single computing system or distributed across two or more computing systems. Such computing systems may be connected via one or more connections, including connections via a network (e.g., the Internet, a wireless wide area network, a local area network, a wide area network, a wired network, etc.), via direct connections between one or more of the computing systems, and may exchange data and / or commands or other instructions.

[0011] Details of one or more variations of the subject matter described herein are shown in the accompanying drawings and the following description. Other features and advantages of the subject matter described herein will be apparent from the description and drawings, as well as from the claims. [Brief explanation of the drawing]

[0012] The embodiments described above will be better understood from the following detailed description in conjunction with the attached drawings. The drawings are not intended to be drawn to scale. For clarity, not all components are shown in all drawings. These are the drawings below.

[0013] [Figure 1] This is a process flowchart illustrating exemplary processes of several embodiments of the subject matter, which can provide treatment recommendations. [Figure 2] This is a system diagram illustrating exemplary systems of several embodiments of the subject matter that can provide treatment recommendations. [Figure 3] Figure 2 is a data flow diagram showing the transfer of data between system components.

[0014] Similar reference numerals in various drawings indicate the same elements. [Modes for carrying out the invention]

[0015] Some current processes for providing information on patient care plans, pharmacotherapy, and administration can be overly rigid (e.g., adherence), cumbersome (e.g., call centers), have a limited scale, and may lead to minimal improvement. Patient interventions can be provided at predetermined points in time as face-to-face consultations conducted by pharmacists or physicians, and may consider each patient's health status at a cross-sectional point in time without considering past or future health risks. These issues can limit patients' access to much-needed therapeutic education and counseling throughout their care process, thereby exacerbating rates of persistent medication errors. Several existing approaches and software products for providing recommendations on the treatment of conditions and drug administration have been shown to have limited clinical impact, highlighting the need for better strategies and platforms.

[0016] Some embodiments of the subject matter can provide an improved approach to providing therapeutic information, as described herein. Some embodiments of the subject matter can favorably incorporate and analyze multiple different data sources to generate prioritized therapeutic recommendations for patients by running a dynamic rule engine, and the methodology for prioritizing therapeutic recommendations can be determined, at least by training the dynamic rule engine with historical data relating successful therapeutic outcomes to various therapeutic recommendations. Thus, robust therapeutic information and personalized therapeutic recommendations for patients can be curated and efficiently disseminated to address disparities in care and unoptimized treatment, adjust existing care plans, avoid medication and prescribing errors, prevent adverse drug events, and avoid and address healthcare and drug access challenges. Therefore, therapeutic recommendations can be delivered in the appropriate place and at the appropriate time, tailored to each patient's needs, throughout the course of each patient's care.

[0017] Figure 1 is a flowchart illustrating an exemplary process 100 for providing treatment recommendations to a patient according to the subject matter described herein. In operation 110, data characterizing healthcare information associated with the patient can be received. The received healthcare information data may include data characterizing the patient's prescription requests, health insurance claims, healthcare use, diagnoses, behavior, demographics, prior consent, electronic health records (e.g., lab data and chart data), and adherence to prescribed treatment plans. In some embodiments, the received healthcare information data may include data obtained from wearable devices used for patient monitoring, health applications or software, responses to patient questionnaires provided by the patient, responses to risk assessments provided by the patient, patient geolocation data, and lab and / or genomic data characterizing the patient's attributes. In some embodiments, the received healthcare information data may also include data characterizing insurance claim amounts, electronic health records, responses to algorithm-derived health questions, case management, patient health plans, and drug cost insurance coverage data. Additional data associated with the patient's medical status may also be included, such as medical data received from healthcare providers who interact with the patient in inpatient and / or outpatient settings.

[0018] In some embodiments, healthcare information data may be received directly from one or more client devices of the patient. One or more client devices of the patient may include a platform interface of the patient's mobile device (e.g., a web page or application executable on the mobile device), a platform interface of the patient's personal computer (e.g., a web page or application executable on the personal computer), a wearable device configured to measure the patient's health parameters and / or biomarkers and transmit data characterizing the measured health parameters and / or biomarkers to the platform, and a portable medical device configured to measure the patient's health parameters and / or biomarkers and transmit data characterizing the measured health parameters and / or biomarkers.

[0019] In some embodiments, healthcare information data may be received from devices of healthcare providers and / or clinicians. Such devices may include mobile devices, personal computers, and / or medical devices of providers and / or clinicians that have the same or similar functions as those of patients described above. For example, in some embodiments, data provided by a provider may include information about the patient, responses to recommendations sent on behalf of the patient, including whether the recommendations were implemented, and clinical evidence. Data reported by other providers may include clinical questions answered by the patient during the provider's intervention, patient history reported to the provider, laboratory data and other vitals available to the provider, patient information such as medications prescribed to suit a particular patient type and diagnosis, vital signs, date and purpose of the most recent visit, information about the patient's diagnosis or medications, or other healthcare outcome assessment data related to the patient.

[0020] In some embodiments, the received healthcare information data may also include information about healthcare providers, such as physicians. For example, the received healthcare information data may include the provider's prescribing patterns, data characterizing the provider's location, data characterizing the provider's associations with other providers, data characterizing the provider's associations with patients, demographic data characterizing the provider's demographic attributes, and data characterizing past interventions in patient health performed by the provider. In some embodiments, the received healthcare information data may also include data characterizing the provider's expertise, the provider's prescribing history, the provider's implementation of previously received treatment recommendations (described in more detail below), the provider's education level, previous healthcare interventions performed by the provider, a quality score characterizing the provider's performance, and the number of patients associated with the provider (e.g., provider panel size, provider's referral network, insurance companies planned / accepted by the provider, payment data associated with the provider, etc.).

[0021] In some embodiments, the received healthcare information data may also include drug data from external databases, such as drug information databases. Drug data may characterize manufacturing information, including drug name, dosage, origin, appearance, information on known drug interactions, and known symptoms and publicly available side effects for which the drug is used. In some embodiments, the received data may also include data from external databases, such as prescription history databases and medical history databases, which may be licensed from third parties and may include historical information about a patient's medications, medical history, and healthcare use that other data sources coupled to the software platform may not be able to access. For example, if a patient switches health plans, a third party may be able to access information about the patient from when they were a member of plan A, and the software platform may be configured to retrieve a continuing customer data feed from plan B.

[0022] In some embodiments, the received data may include healthcare data from multiple sources that characterize the health information of a patient population. Healthcare data may include medical claims data, pharmacy claims data, risk stratification data, quality of care data, electronic medical record data, laboratory value data, usage data, wearable and diagnostic device data, socioeconomic data, program eligibility data and demographic data, pharmacogenomics data, clinical trial data, social network data, electronic prescription data, electronic pre-consent data, and other digital device data from data sources coupled to the software platform described herein. Sources of healthcare data may include users or beneficiaries of the software platform, including patients, healthcare providers / clinicians, health insurance companies, pharmacy benefit management companies, local and state government agencies, care management companies, hospitals and health systems, medical groups, retail pharmacies, pharmaceutical companies, accountable care organizations or other corporate healthcare companies, and patients or members of health insurance schemes. Data from each of these sources can be combined to form a single dataset ("aggregated data"), as will be discussed in more detail below. The platform can ingest and aggregate data from an unlimited number of sources.

[0023] Data can be received from the aforementioned data sources via ongoing (real-time) or regularly scheduled data feeds, or ad-hoc. Received data can be supplemented with additional data collected directly from patients and providers over time.

[0024] All received data can be stored using schema-based data storage (e.g., RDS, PostGres), as well as document-based data storage (e.g., DynamoDB) that enables the software platform to store data structures and schemas more complex than flat relational data. This can enable the software platform to be flexible in that it can store any kind or type of data. The data structure format can enable the continuous deepening of a single clinical profile with any new data type or format, regardless of frequency or data structure / format.

[0025] At 120, based on the received healthcare information data, a patient's health outcome assessment can be determined. The data sets evaluated as part of the health outcome assessment include survey responses, medical claim data, pharmacy claim data, lab data, other questionnaire data, patient-reported data, provider-reported data, other cost data, third-party data sources (e.g., prescription data from SureScripts, risk or credit data from LexisNexis), and electronic health records. The data evaluated can include historical data regarding the patient and their care plan, treatment patterns, and past history to date.

[0026] In some embodiments, the health outcome assessment can include metrics that can be determined based on the received healthcare information data. The metrics to be determined can include utilization patterns (e.g., hospitalizations, emergency department visits, clinic visits), clinical values (e.g., A1c for diabetes patients, blood pressure for hypertension patients), healthcare expenditure patterns (e.g., pharmacy claim costs, medical claim costs, out-of-pocket costs), drug information (e.g., drug class, generic, brand, prescription), drug intake patterns, questionnaire responses (e.g., improvement in responses to a general anxiety disorder questionnaire, reasons for non-adherence), disease profiles (e.g., diagnosis, duration, utilization by disease), provider actions (e.g., prescribing actions, quality metrics, interventions), and patient demographic and engagement profiles. The metrics can be determined based on data characterizing patient demographics, medication refills, diagnoses, hospitalizations / outpatient / emergency department / clinic visits, provider demographics, laboratory demographics, and / or price information, which can be normalized, transformed, and / or aggregated from the received healthcare information data.

[0027] In some embodiments, metrics can be determined based on data characterizing provider information, such as National Provider Identifier (NPI) records. In some embodiments, metrics can be determined based on data characterizing drug information, such as drug mapping, drug symptoms, drug interactions, drug group mapping, and / or National Drug Codes (NDCs) to drug images. In some embodiments, metrics can be determined based on data characterizing diagnostic information, such as ICD-10 / CPT codes to drug group mapping and diagnostic group mapping. In some embodiments, metrics can be determined based on data characterizing patient-tailored questionnaires based on received healthcare information data (as described in more detail below). In some embodiments, metrics can be determined based on a subset of received healthcare information data reported directly by the patient via the patient's client device, wearable device, and / or medical device. Such a subset of data may include data characterizing the drugs the patient takes, the patient's drug-taking behavior, drug-related questions / needs, health status, and patient engagement. In some embodiments, metrics can be determined based on a subset of received healthcare information data that characterizes treatment decisions made by a provider associated with a patient or a population of patients with similar health characteristics.

[0028] In some embodiments, health outcome assessments can be determined based on a subset of received healthcare information data, characterizing patient data that includes demographic, geographic, socioeconomic, and healthcare engagement attributes of the patient. In some embodiments, health outcome assessments can be determined based on a subset of received healthcare information data, characterizing patient drug information such as drug images, drug groups, dosage forms, routes, dose units, symptoms, and prescribers. In some embodiments, health outcome assessments can be determined based on a subset of received healthcare information data, characterizing patient drug use (e.g., administration regimen, daily dose, monthly prescribing criteria (MPR), reasons for taking the drug, reasons for discontinuing the drug, side effects, and drug interactions). In some embodiments, health outcome assessments can be determined based on a subset of received healthcare information data, characterizing patient data that includes patient disease profiles (e.g., duration of disease, diagnostic groups, healthcare use, and abnormal laboratory values). In some embodiments, health outcome assessments can be determined based on a subset of received healthcare information data and provider data characterizing provider behavior (e.g., prescribing behavior, quality metrics, intervention type, and intervention frequency). In some embodiments, health outcome assessments can be determined based on customizable data flags, which are programmed as needed to achieve readily actionable assessments from received healthcare information data.

[0029] In some embodiments, health outcome assessments can be determined based on data from a clinical knowledge database, which may include an overview of treatment guidelines, an overview of real-world evidence and data regarding treatment regimens and their impact on clinical outcomes, an overview of quality metrics and best practices, and an overview of clinical knowledge and information related to an ideal treatment plan for a patient based on specific characteristics. Health outcome assessments can be further updated based on data from client-specific databases, which may include information on available programs and services for the client, including the client's benefits and coverage levels, the client's prescription collection, the client's patient or member management programs, the client's costs, the client's support programs, and details of the client's specific preferred treatment and care sites. In some embodiments, health outcome assessments can be further updated based on programs and databases from other third parties.

[0030] In some embodiments, health outcome assessments can output data characterizing other identified problems and potential challenges, such as a detailed understanding of the patient's adherence to their current prescribed treatment regimen, their adherence and compliance to their treatment plan, the risks of their current treatment plan, deficiencies in their treatment plan such as drugs, clinical tests, provider visits, their clinical risk profile and the likelihood of clinical events such as hospitalization, dangerous drug combinations including incorrect dosages, combinations, or unnecessary prescriptions, and other health behaviors. In some embodiments, health outcome assessments can output data characterizing the patient's healthcare use, trends in the patient's clinical status, trends in the patient's behavior, trends in provider prescribing behavior, trends in healthcare costs, and data characterizing the risks the patient faces, based on one or more of the aforementioned data sources.

[0031] Health outcome assessments and the aforementioned data outputs can be determined by a health outcome assessment algorithm that can selectively determine the content to include in the output data based on the type / attributes of the aforementioned data / metrics that form the basis of the health outcome assessment. The health outcome assessment algorithm can evaluate the data / metrics discussed above that can form the basis of the health outcome assessment in an Extractive Transform Load (ETL) process, and the ETL runs the algorithm on the data / metrics to determine the health outcome assessment. In some embodiments, one or more algorithms can be applied to the received healthcare information data and metrics described above to generate a set of tailored questions to be presented to the patient, configured to address one or more defects in the received data detected by one or more algorithms. For example, one or more algorithms can analyze the received data by using a questionnaire rule engine that evaluates the received data source and identifies defects in patient-related data that are important for driving clinical decisions. These defects can then be analyzed by the questionnaire rule engine, which can generate questionnaire data configured to address the defects, characterizing at least one question to be answered by the patient and / or their caregiver. For example, if a patient has been prescribed metformin but is not taking the medication regularly, a survey rules engine can generate personalized questions designed to determine whether the patient is experiencing any side effects from metformin. In another example, if a patient is using Medicaid or lives in a low-income zip code area, questions about social determinants of health (e.g., transportation barriers, housing barriers, cost barriers) may arise.

[0032] In some embodiments, the questionnaire data can be provided to the patient (and / or their caregiver) in person or by telephone via a web interface on the patient's / caregiver's device. The questionnaire data may include questions that can mimic best-in-class clinical interviews conducted by pharmacists, nurses, physicians, and other qualified healthcare professionals in a medical setting. In some embodiments, the questionnaire data may include questions that can comprise current and past medication use behavior, side effects, and patient-reported symptoms, outcomes, as well as challenges related to access to care, such as costs, difficulty making appointments, low literacy / health literacy, educational barriers, and transportation difficulties.

[0033] In some embodiments, the survey rules engine can determine which questions to include in the survey data based on the received healthcare information data. For example, if the received healthcare information data indicates that the patient lives in a low-income zip code, is a Medicaid beneficiary, a beneficiary of low-income subsidies, or is in another program identified through eligibility information indicating low income, the survey rules engine can analyze these attributes of the received healthcare data and determine that questions about access to care should be included in the survey data. In another example, if the received healthcare information data indicates that the patient has been diagnosed with diabetes, the survey rules engine can generate specific questions configured to elicit additional information related to the patient's management of their diabetes, such as questions intended to confirm the patient's most recent blood glucose reading, the patient's eating habits, whether the patient has experienced dizziness or lightheadedness while taking their medication, or whether the patient has experienced any difficulties in using their insulin. In yet another example, if the received healthcare information data indicates that the patient lives in a food desert and is low-income, the survey rules engine can generate specific questions configured to elicit additional information related to the patient's food security and ability to pay for their medication or doctor visits, or whether the patient needs coupons / patient support programs. In another example, if the received healthcare information data indicates that the patient has difficulty walking, the survey rules engine can generate specific questions configured to elicit additional information related to the patient's preferences, such as receiving mail-order medications, transportation assistance for medical appointments, home health support and care management, or virtual healthcare.

[0034] In some embodiments, the survey rule engine can compare the received data with aggregated healthcare data that characterizes a predetermined set of healthcare parameters, determine one or more defects in the received healthcare information data based on the comparison, and determine questions to include in the survey data based on the determined defects.

[0035] In some embodiments, one or more algorithms can analyze received healthcare information data, determine whether the received healthcare information data indicates an ongoing negative health behavior in the patient, and generate questionnaires based on the analysis to seek further insights into the patient. For example, when a patient is non-adherent to their medication, one or more algorithms can identify the occurrence of non-adherence by analyzing the received data, and based on the identified non-adherence, generate one or more questions configured to elicit from the patient the reasons for their non-adherence (e.g., side effects, cost barriers, lack of understanding of importance). The answers to these questions described above can be analyzed to provide further depth and context to the patient's health status and behavior. The questionnaire data, which provides insights into the patient's otherwise unknown behavior, can be combined with the received data to create entirely new datasets that can determine a more comprehensive healthcare assessment dataset, as will be further described below.

[0036] In some embodiments, the survey rule engine can be continuously improved by using predictive modeling techniques. For example, in some embodiments, data is collected on whether patients report side effects to a particular drug through a survey. A predictive model can be used to evaluate the data and identify significant predictors of experiencing side effects for a particular population. Based on the identified significant predictors, the predictive model can modify the rules used by the survey rule engine, thereby enabling the generation of personalized questions based on the modified rules that target populations characterized by the predictors.

[0037] In some embodiments, a patient's clinical patient profile can be determined based on received healthcare information data and determined health outcome assessments. In some embodiments, the clinical patient profile may include a graphical user interface that characterizes the patient's attributes, such as the patient's healthcare use, current and past hospitalizations and emergency department visits, current and past diagnoses, current and past medication use, and care disparities, suboptimal care plans, demographic information, contact information, laboratory and other test results, health insurance information, risk assessment information, current and past clinical questionnaire information, and preferred intervention methods. The clinical patient profile may also include the patient's current and past use of commercially available medications and supplements, the composition of the patient's care team (e.g., the identities of the patient's primary care provider, specialists, and / or pharmacies), the patient's current care and treatment plan, the patient's laboratory tests and clinical values, and any changes to the patient's recommended care plan.

[0038] In some embodiments, a population-level provider profile can be determined based on received healthcare data. Provider profile data includes metrics derived from health outcome assessments regarding provider demographics, such as location, provider type, and provider behaviors, including prescribing behaviors and interventions. Provider profiles may also include information about the provider's patients, such as a brief interpretation of healthcare data from a panel of patients associated with the provider, and the panel's current care disparities and healthcare service utilization. Provider profiles may also include data characterizing patient demographic information, such as contact information including the patient and / or provider's telephone number, email address, mailing address, fax number, and other telecommunications information. In some embodiments, the provider profile may also include an overview of the provider's patient panel composition by age, insurance type, location (home address), and other descriptors. In some embodiments, such data may be supplied from third-party data sources or directly from the provider or patient via telephone outreach or other communications.

[0039] In some embodiments, the provider profile may include health insurance information characterizing the insurance plans accepted by the provider and the insurance plans of patients, risk assessment information characterizing the overall panel risk profile of the provider's own patients, the provider's risk profile, and the provider's current and past clinical quality performance (such as the provider's performance on specific Healthcare Effectiveness Data and Information Set (HEDIS) quality measures or other metrics used to assess the provider's performance, the provider's prescribing patterns, the provider's treatment plan patterns, and patient panel information). In some embodiments, the provider profile may include data characterizing the number of patients used as the basis for data characterizing the provider in the provider profile, locations such as the home addresses of the provider's patient panel, the location of the provider's clinic, the type of insurance held by the provider's patients, the average distance of patients from the provider, the number of times patients have been seen by the provider during a particular period, and preferred interventions and communication methods such as the provider's preferred method of receiving information (e.g., email, text, telephone, fax). In some embodiments, patient profiles can be aggregated and assigned to providers (for example, patients A and B are both examined by physician X, recommendations 1, 2, and 3 are sent to providers, with 1 and 2 assigned to patient A and 3 assigned to patient B).

[0040] In 130, patient risk predictions can be determined based on health outcome assessments. In some embodiments, patient risk predictions can be determined based on the received data described above, which characterizes interventions generated from the platform and the outcomes resulting from those interventions. Risk predictions can be determined by a predictive multivariate model that analyzes one or more aspects of the data included in the health outcome assessment, such as diagnosis, medication history, answers to personalized questions, clinical variables, patient demographic information, provider data characterizing prescribers associated with the patient, their locations, prescribing patterns, quality scores, and patient outcome data characterizing past interventions.

[0041] Thus, risk prediction models can generate overall risk predictions for patients, as well as risk predictions for each of the clinical, social, and behavioral risk subcategories. Clinical factors may include medical diagnoses, medication regimens, healthcare use, other prescribed treatments, commercially available supplements, medical history, physical measurements, clinical and laboratory values ​​including vital signs, genomic data, and validated clinical questionnaire data. Social factors may include demographic information such as age, sex, race, zip code, occupation, occupational status, education, food security status, housing status, income, health insurance status, health literacy, access to care, air and water quality, incarceration status, family structure, caregiver status, marital status, stressors, and social support. Behavioral factors may include smoking, alcohol consumption, physical activity, obesity, diet, sexual health, sleep patterns, and medication adherence. As will be described in more detail below, the risk predictions for each risk subcategory can be used to associate risks with the recommendations most likely to reduce those risks in order to determine the correct recommendations that best address each patient's unique needs. In some embodiments, statistical methods can be used to subdivide the overall risk assessment from these trained models into subcategories based on the presence of predictor variables associated with those subcategories.

[0042] As will be described in more detail below, risk prediction models can be dynamically updated by predictive modeling techniques configured to optimize health outcome assessments based on updated information. In some embodiments, the risk model can be trained using historical data characterizing attributes of clinical patient profiles, as well as / or overall risk profiles and health outcome assessments associated with various risk subcategories, such as clinical, social, and behavioral risk factors. Some embodiments of this subject can assess and predict the overall risk of any patient and categorize the sources of that risk into the aforementioned clinical, social, and behavioral risk subcategories.

[0043] In 140, treatment recommendations for a patient can be determined based on the calculated risk. In some embodiments, treatment recommendations may include data characterizing patient education materials, drug action plans, and drug lists.

[0044] In some embodiments, a treatment recommendation algorithm can provide treatment recommendations based on each of the aforementioned risk components. For example, the social risk component, behavioral risk component, and clinical risk component of a patient's determined risk prediction can be used independently or in combination with each other to determine personalized treatment recommendations that minimize each risk component. For example, if a patient's determined risk prediction indicates a high social risk, the determined treatment recommendation for this patient may include a referral to a social worker to learn about available resources to overcome access to care barriers. Alternatively, for example, if the determined risk indicates a low social risk, the determined treatment recommendation for the patient may not include any interventions proposed to address access to care barriers.

[0045] In some embodiments, treatment recommendations can be determined based on health outcome assessments and / or received healthcare information data incorporated into the determined health outcome assessments. Treatment recommendations can be generated by a recommendation rule engine.

[0046] In some embodiments, if patients may have the same overall risk and risk components, the main drivers of the risk components (e.g., various predictors) may differ, and the treatment recommendation rule engine may take this variance of risk components into account when determining a particular treatment recommendation. The treatment recommendation rule engine considers the weights of these risk components and the predictors within each risk component along with the treatment recommendations. For example, if for one of the patients, one of the significant predictors of behavioral risk is drug non-adherence to a particular medication, the treatment recommendation algorithm may determine that one of the recommendations for this patient is to provide adherence counseling for that particular medication. If other patients with the same behavioral risk do not have non-adherence as a significant variable, but instead have a high clinical risk component, the treatment recommendation algorithm may determine a treatment recommendation to escalate treatment instead of adherence counseling.

[0047] In some embodiments, the recommendation rule engine may include a rule execution engine that executes logic (e.g., one or more rules) to generate treatment recommendations. For example, the rule execution engine of the recommendation rule engine may analyze inputs that may include metrics / data outputs generated as part of a health outcome assessment, the aforementioned risk predictions, data characterizing a patient's health plan, data characterizing clinical guidelines, and / or other patient / provider healthcare data, query a library of recommendation rules to retrieve execution rules from the library that are relevant to the analyzed input, and execute the rules on the input to determine treatment recommendations.

[0048] In some embodiments, the recommendation rule engine may also include a word search process that can query a template database containing various string templates for presenting treatment recommendations. The word search can retrieve an appropriate template from the template database based on the treatment recommendation. The recommendation rule engine can then generate recommendation strings that characterize treatment recommendations to be provided to patients and / or providers, based on the retrieved templates, as will be described in more detail below. In some embodiments, the word search process of the recommendation rule engine can transform the retrieved templates into optimized recommendation strings based on health outcome assessments, the aforementioned risk predictions, data characterizing patient health plans, data characterizing clinical guidelines, and / or other patient / provider healthcare data, based on the analysis of the inputs performed by the rule execution engine.

[0049] In some embodiments, to determine treatment recommendations, the recommendation rule engine may include a rule interpreter that can translate a high-level language into a complex set of rules for analysis of the aforementioned input. Such functionality can enable the determination of a complex set of rules without receiving data characterizing the data structure of the analyzed input, which can allow for faster and more computationally efficient development of the rules used by the rule execution engine and extension of the recommendation rule library.

[0050] In some embodiments, to determine treatment recommendations, the recommendation rule engine may include a rule interpreter that can translate a high-level language into a complex set of rules for analysis of the aforementioned inputs. Such a function can enable the determination of a complex set of rules without prior knowledge of the data structure of the analyzed inputs, which can enable the rapider and more computationally efficient development of the rules used by the rule execution engine and the extension of the recommendation rule library.

[0051] In some embodiments, treatment recommendations can be determined based on responses to the questionnaire data questions described above. For example, if questionnaire responses indicate that the reason for a patient's non-adherence to a prescribed treatment plan is that the prescribed treatment causes undesirable side effects, one or more treatment recommendation algorithms may determine recommendations for alternative treatments that do not cause these side effects, based on an evaluation of the received data characterizing the expert's clinical knowledge, existing clinical guidelines, and other third-party data sources.

[0052] In some embodiments, non-clinical recommendations beyond treatment recommendations can be determined. Such recommendations may include cost-saving opportunities, opportunities to switch medications to better align with financial incentives, social or behavioral care support programs, other programs the patient can qualify for through their insurance or government, or community-based resources available to the patient that can improve the patient's health. These recommendations may be determined by non-clinical recommendation algorithms that operate substantially similarly to the treatment recommendation algorithms described above, but instead provide the aforementioned supplementary recommendations instead of treatment recommendations. The non-clinical recommendation algorithms can be trained on data characterizing opportunities available to the patient for various patients with risk and demographic profiles similar to the patient's determined risk predictions and clinical patient profile, and the algorithm's training can be periodically updated based on changes in available opportunities.

[0053] In some embodiments, treatment recommendations may include provider recommendations. Provider recommendations may include data characterizing treatment recommendations intended for use by the provider. Recommendations to providers may be determined in substantially the same way as treatment recommendations to patients are determined. However, provider recommendation algorithms may also leverage provider characteristics (demographics, specialty, prescribing patterns, site of administration) characterized by the aforementioned provider profile and clinical decisions made by the provider (which may or may not be based on previous provider treatment recommendations) when generating provider recommendations. In some embodiments, provider recommendations may include a list of all identified treatment concerns and their proposed solutions. Provider recommendations may also include data characterizing additional contextual information, such as important patient data (e.g., recent hospitalizations), treatment guidelines sourced from clinical information reference databases, and explanatory rationale for recommendations generated by the recommendation rule engine. In some embodiments, as will be described in more detail below, the treatment recommendation rule engine may be trained and / or optimized based on historical data characterizing the relative success of recommended treatments for various patients with risk profiles similar to the patient's determined risk prediction.

[0054] In 150, treatment recommendations can be provided. For example, in some embodiments where provider recommendations are determined, the provider can review the provider recommendations within a user interface provided within a web page on the web browser of the patient's client device, which can provide all the major issues identified and their proposed solutions. For example, in some embodiments, treatment recommendations and / or nonclinical recommendations can be provided in a user interface provided within a web page on the web browser of the patient's client device, so that the patient can view the treatment and / or nonclinical recommendations on their own client device. For example, in some embodiments, treatment recommendations, which may include one or more of the aforementioned treatment recommendations and nonclinical recommendations, can be made into a formatted document suitable for viewing by the patient and / or provider. This document can be sent by email, printed and mailed, and / or faxed. In some embodiments, provider treatment recommendations can also be transferred to an electronic medical record system. In some embodiments, the user interface can generate and provide a provider-level report featuring several different provider treatment recommendations to advise the provider regarding all patients requiring care adjustments. In some embodiments, additional and / or alternative recommendation documents or care plans may be provided to patients and providers based on treatment recommendations, non-clinical recommendations, and / or provider treatment recommendations.

[0055] In some embodiments, proposed treatment recommendations can drive the creation of tasks associated with the patient. These tasks can be prioritized in a list format so that platform users can view proposed actions aimed at reducing patient risk. Each recommendation can include data characterizing the relevant priority level and timeframe for the action. For example, patients with high social, clinical, and behavioral risks, as determined by each patient model and recommendation, will have higher priority tasks than patients with low clinical, social, and behavioral risks, or those with lower recommendation weightings. In some embodiments, a configurable workflow engine for performing one or more of the processes described herein can be included so that the assignment of tasks to care team members can be aligned with each unique workflow and care team configuration. The workflow engine can also extract data from health outcome assessments. The workflow engine can also analyze the history of interventions to determine the course and priority level of the next action. For example, if a provider has not responded to a treatment recommendation, such as evidenced by the lack of medication changes in health outcome assessment data, a task can be created to remind the provider.

[0056] In some embodiments, the implementation of proposed treatment recommendations by patients and / or providers can be continuously measured, recorded, and provided for use in future iterative decisions regarding one or more of the aforementioned health outcome assessments, clinical patient profiles, provider profiles, risk predictions, and / or treatment recommendations. In some embodiments, the impact of provided treatment recommendations can be quantified from both clinical and economic perspectives. For example, if a treatment recommendation indicates that a patient is prescribed statins for their diabetes, and the data received by the system includes a pharmacy billing file indicating that statins were prescribed and initiated, the system can mark the treatment recommendation as implemented. The clinical impact (e.g., lab values, improved health, etc.) and economic impact (e.g., overall cost of pre- and post-statin care) of implemented recommendations can also be measured. In some embodiments, the system can analyze responses to personalized questions across patients and the resulting clinical decisions to determine which questions lead to optimal interventions and prioritize those questions for inclusion in the aforementioned questionnaire data.

[0057] In some embodiments, after the provider completes a treatment plan review and provides instructions, ongoing changes in the patient's health status can be detected by analyzing healthcare information data contained in data streams received from patient devices, provider devices, and / or external databases, in order to determine whether treatment recommendations should be implemented. For example, changes in medication (e.g., new medications added, changes in dosage, discontinuation of medications) can be monitored and used as a basis for determining whether recommendations have been implemented. In some embodiments, events including but not limited to new medical diagnoses, new medications prescribed, new lab values, new device information, hospitalizations, and emergency hospitalizations, and provider visits can be identified, and notifications indicating such events can be forwarded directly to the provider for further follow-up of the patient. This can prevent the exacerbation of potential challenges that may drive increased healthcare service utilization, including but not limited to hospitalizations and emergency department visits, and ensure adherence to best practices. These flagged events are also data parameters considered in the questionnaire rule engine, workflow rule engine, and recommendation rule engine, as well as in predictive models for use in decisions described elsewhere in this specification.

[0058] In some embodiments, when additional data is received that can be used to correlate patient behavior with clinical, social, and economic outcomes, the predictive algorithm can further tailor patient recommendations, provider recommendations, tasks, and interventions by updating the various rule engines detailed above, using the health outcome assessment determined based on the received healthcare information data (which in some embodiments may also include data characterizing feedback on interventions implemented based on and / or suggested by the provided treatment recommendations, data characterizing decisions and / or rationales for not implementing any interventions based on and / or suggested by the provided treatment recommendations, and data characterizing the effectiveness of interventions implemented based on the provided treatment recommendations), and / or data characterizing feedback on interventions implemented based on and / or suggested by the provided treatment recommendations, data characterizing decisions for not implementing any interventions based on and / or suggested by the provided treatment recommendations, and data characterizing the effectiveness of interventions implemented based on the provided treatment recommendations. In this way, the greatest impact on clinical outcomes and the quality of patient care can be achieved. Various rule engines and algorithms described in detail elsewhere in this Specification may be updated by using predictive models that identify patterns in adherence to interventions proposed by treatment recommendations, by analyzing data characterizing healthcare benefits, data characterizing historical patterns of adherence to any pre-intervention treatments proposed by determined treatment recommendations, patient demographic data, patient geospatial data, data characterizing healthcare use and spending patterns, data characterizing drug use patterns, patient-reported data, and / or results from other predictive models described elsewhere in this Specification.Through this analysis, the predictive model can identify interventions that result in improved adherence to interventions and determine predictive variables that can be added to rules stored in various rule libraries described elsewhere in this specification, and / or modifications to one or more rules stored in rule libraries described elsewhere in this specification that can result in rule engine outputs that are more likely to be accurate and more predictive. For example, the predictive model can add predictive variables to rules stored in the recommendation rule library that can cause the recommendation rule engine to determine treatment recommendations that are more likely to result in improved interventions utilized by providers and / or patients, thereby resulting in improved health outcomes. For example, the recommendations of the recommendation rule engine may initially be based on treatment guideline parameters and then become more targeted over time as more data is considered in the predictive model. The data used to create guidelines is typically from randomized clinical trials, based on smaller sample sizes, homogeneous populations, and a limited number of data elements collected. This may limit predictors to age, race, sex, drug group, and disease group. Furthermore, in guidelines, these predictors can then be transformed into binary categories, such as age over 65 or under 65. For patients with poorly controlled type 2 diabetes and concurrent cardiovascular disease, the initial recommendation, in accordance with the American Diabetes Association, is a glucagon-like peptide-1 agonist or sodium-glucose cotransporter-2 inhibitor. For example, a machine learning model can identify other comorbid conditions or other data predictors of treatment success, such as specific demographics like age range (defined in this case as diabetes management via hemoglobin A1c measurement), and this comorbid condition and age range can be added to the logic of the recommendation rule engine to incorporate parameters beyond those considered in the treatment guidelines.

[0059] For example, in some embodiments, the system can predict an optimized therapeutic intervention and provide recommendations to the patient and / or provider for implementing that intervention. Based on feedback indicating the success of the intervention, the system can use a machine learning model to identify predictors of success. For example, a machine learning model can identify predictors of diabetes management through the measurement of hemoglobin A1c as an indicator of therapeutic success. Using the identified predictors of success, the system can generate additional logic (e.g., modifications to rules, new rules, deletion of rules) that can be inserted into the recommendation rule engine. For example, the system can generate a rule indicating that a given age range is a predictor of success, and a given therapeutic / intervention recommendation should be provided in response to the determination that the patient is within a given age threshold. For subsequent recommendations, the modified recommendation rule engine implements logic indicating that the given age range is a strong predictor of a successful intervention, thereby providing improved recommendations for the intervention.

[0060] For example, a drug adherence predictive model can be used to predict whether a patient is likely to adhere to their medication or become non-adherent. The predictive model can evaluate the patient's demographic and socioeconomic data, drug name, diagnosis, any patient's comorbidities, any side effects reported by the patient, and other relevant information including past behavior. The predictive model can analyze this data not only for a specific patient but also for many other patients determined to have similar profiles and characteristics based on data inputs and parameters. In some embodiments, the predictive model can perform this analysis by evaluating this data and determining predictive variables that are significant predictors of successful treatment outcomes. The determined predictive variables can be applied to data characterizing a broader patient population to identify other patients who are likely to achieve successful treatment outcomes. Based on this analysis, as well as the past drug adherence performance of all patients with similar profiles and characteristics, the algorithm can predict the likelihood of a patient becoming non-adherent to their medication and the expected timing of the onset of that non-adherence event.

[0061] Furthermore, in some embodiments, the aforementioned risk prediction parameters can be continuously evaluated to create a dynamic risk score consisting of a composite of all these parameters relating to how they impact patient health and well-being. The software platform can be configured to prompt interventions before patients become non-adherent (e.g., by creating “just-in-time” recommendations). These models can be further refined in terms of the timing and type of interventions needed to successfully address non-adherence, relying on a feedback loop based on the success or failure of previous and similar interventions and / or recommendation timings.

[0062] In some embodiments, the treatment recommendation rule engine can be modified based on predictive modeling techniques that can predict how to interact with patients and providers in a way that is most likely to result in improved health outcomes. For example, the system can analyze provider characteristics such as location, specialty, prescription history, and preferred treatment plans, and compare providers to other similar providers. The software platform can then determine the optimal timing (e.g., Monday mornings), format (e.g., fax to the office), and frequency (e.g., once a week) for delivering treatment recommendations to maximize the likelihood that the recommendations will be implemented based on provider characteristics and behaviors. These functions can be ported based on a data feedback loop, including past intervention successes, to further determine the optimal timing and type of recommendations to deliver as needed to ensure implementation by providers. Outcomes such as clinical response and successful implementation of interventions are tracked, the impact of the interventions is labeled, and fed back to the aforementioned model / rule engine to be included as additional features of the model. In subsequent iterations of this model, these new significant features are incorporated into the model to further refine risk prediction and future interventions.

[0063] In some embodiments, the platform may also automate outcome reporting, providing continuous visibility and transparency of patient and provider performance and success. Outcomes measured and included as part of outcome reporting may include changes in medication adherence, overall care costs, overall healthcare costs, overall pharmacy costs, number of emergency department visits and hospitalizations, percentage of resolved medication errors, engagement measures related to patient, provider, and pharmacy outreach, and whether providers implemented suggested recommendations.

[0064] The platform can additionally measure outcomes such as patient satisfaction, provider satisfaction, time to recommendation implementation, best time to deliver recommendations, best method to deliver recommendations (but not limited to, phone, email, electronic health record messages, fax, etc.), and patient and provider engagement. Calculations for other measured outcomes refer to other sections above (e.g., outpatient visits, hospitalizations, error resolution rates, etc.). Engagement measures such as phone pickup rates and fax reception rates can be measured automatically (e.g., phone is picked up, call length, call duration, recipient's time zone, etc.) or manually via the platform's logging function, through phone logging and their associated outcomes. Patient / provider satisfaction can be measured through questionnaires provided directly from the portal, where patient / provider responses are recorded on the platform and aggregated with other patient / provider responses as part of a data collection effort to understand satisfaction and generate satisfaction scores based on stakeholders. The time until a recommendation is implemented can be calculated from the time the recommendation is sent to the prescriber via fax, email, or telephone, and from the time the prescriber implements the change, when it is displayed in the data feed (e.g., the date a new drug is added based on the recommendation), or when the prescriber receives a fax / telephone notification of the recommendation's implementation directly from the provider.

[0065] In some embodiments, this functionality can be implemented by using an automated outcome analysis engine that includes one or more of the following components: an Extract-Transform-Load (ETL) process, an analysis planner, a reporting planner, an analysis plan executor, and a reporting generator. The ETL process may include data loading from multiple data sources, data extraction and normalization, and aggregation and storage of data in a data warehouse. The analysis planner may include an analysis plan loader that includes a list of analyses to be performed, an execution schedule, cohort definitions, and parameters for each analysis. The reporting planner may include a reporting plan that includes a list of analyses to be included in the report, a reporting template, a delivery method, and recipients. The analysis plan executor may include a data analysis pipeline that can load data analysis plans from the data warehouse and execute the analyses scheduled by the analysis plans, and can store the results of each analysis in the data warehouse. The reporting generator can monitor the analysis results of the analysis plans. When the results become available in the data warehouse, the reporting generator can generate a report and deliver it according to the reporting plan. Multiple reporting plans can be created for the same or a subset of analysis results. This includes different visualization templates, delivery methods, or recipients.

[0066] These measurements and member, provider, and clinical content attributes can be used to automatically adjust the weighting of parameters used automatically by the aforementioned rule engine and algorithm. Subsequent iterations of the algorithm and recommendations can be notified using 1) the content of the rule engine / algorithm, 2) the method of delivering clinical recommendations, 3) patient-related attributes and content that can be used by the rule engine / algorithm, including risk profiling as described elsewhere in this specification, 4) provider-related attributes and content that can be used by the rule engine / algorithm, and 5) outcome observations associated with impacts on clinical and economic outcomes as described elsewhere in this specification. This ensures that the relative probability and weighting of each unique data label or feature are taken into consideration for subsequent algorithms and recommendations that may be delivered. Based on this automated measurement and algorithm recalibration, each delivered recommendation will become more influential and more likely to drive target outcomes over time.

[0067] For example, the aforementioned algorithm / rule engine can identify patients with high behavioral risk and, via the user interface, recommend to the provider that this patient begin taking antipsychotic medication for untreated bipolar disorder. The system can track whether the medication has been added to the patient's medication regimen through an algorithmic review of the patient's data. Once prescribed, the platform analyzes the patient's risk profile, as described elsewhere in this specification, and, also identified from the patient data, alerts the provider via the user interface that the patient remains at high behavioral risk due to non-adherence. This prompts the generation of a personalized questionnaire, as described elsewhere in this specification, prompting the user to identify the reasons for non-adherence. By analyzing the patient's responses to the personalized questionnaire, it can be determined that the cause of the patient's non-adherence is likely due to a weight-gain side effect. The platform can analyze new patient datasets and determine treatment recommendations for the patient regarding alternative medications that do not have the same degree of metabolic adverse effects. The provider can deliver this treatment recommendation, and the system can monitor whether the medication has been added to the patient's regimen. When medication is added, the system assumes that the patient's behavioral health risk decreases, and the member stabilizes. All of these data points can be fed back into the rule engine / algorithm, and as the rule engine / algorithm learns and observes these patterns across patients, the system can then recommend alternatives for other patients with similar social, clinical, and behavioral characteristics and risk factors, proactively preventing non-adherence to this particular antipsychotic medication and preventing an increase in behavioral health risk.

[0068] In some embodiments, the system may include one or more modules addressing more specific drug-related challenges, such as adherence to quality metrics, drug product selection, drug administration regimens, drug-drug interactions, drug-disease interactions, adverse effects / events, contraindications, patient misuse of products, opportunities for prescription changes, adherence to treatment guidelines, adherence to chronic medications, patient education needs, social support needs, necessary laboratory tests, necessary health screenings, necessary doctor appointments, necessary pharmacy appointments, disease management needs, and utilization needs. Each module can be customized to meet the most urgent needs of the system user, such as specific programs, health conditions, disease areas, drug classes, therapeutic areas, prescriptions, or specific educational challenges. While several variations have been described in detail above, other modifications or additions are possible. For example, some embodiments of this subject matter can be used to optimize a patient's drug dosage based on the patient's clinical response to the drug and the results the drug is achieving. For example, a patient currently prescribed a low dose of statins who is adherent to their medication but continues to have high cholesterol levels may be recommended, based on their clinical profile, to increase their dose to a higher level or switch to a moderate or high-intensity statin.

[0069] Figure 2 is a system diagram 200 illustrating an exemplary system of several embodiments of the subject matter that can provide the functions described herein, and Figure 3 is a data flow diagram 300 illustrating the transfer of one or more of the data types described herein between the system components illustrated in Figure 2 and according to several embodiments of the subject matter. As shown in Figure 2, the system 200 may include a platform server 210 configured to perform one or more of the processes described herein. For example, the platform server 210 may receive data from various sources, such as various external databases 220 that store healthcare information data, a patient data recording device 230 configured to record patient physiological parameters and / or biomarkers, a patient client device 240 (e.g., a mobile device, personal computer, etc.) configured to receive input from patients related to applicable patient-related data forms described elsewhere in this specification, and a provider client device 250 (e.g., a mobile device, personal computer, etc.) configured to receive input from providers related to applicable provider-related data forms described elsewhere in this specification.

[0070] As shown in Figure 3, in the data reception process 301, the platform server 210 can receive healthcare information data, as described elsewhere in this specification (as well as feedback data characterizing interventions performed in patient care, and other forms of feedback from previous outputs of the platform server 210 and processes described elsewhere in this specification), from one or more of various external databases 220, patient data recorders 230, patient client devices 240, and / or provider client devices 250. The data received in the data reception process 301 can be provided to the health outcome assessment process 302, which performs various processes described elsewhere in this specification to determine the health outcome assessment. In some embodiments, if during the health outcome assessment process 302 it determines that the patient needs to answer several questions to address deficiencies in the received data in order for the health outcome assessment process 302 to fully formulate the health outcome assessment, the health outcome assessment process 302 can generate applicable questions to address deficiencies and provide them to the questionnaire process 303. The questionnaire process 303 can incorporate the questions into questionnaire data characterizing the questions. Once completed, the questionnaire data can be provided to the patient client device 240 for display on the patient client device 240's graphical user interface. The patient can answer the questions by interacting with the graphical user interface of the patient client device 240, and the data characterizing the answers can be provided by the patient client device 240 to the platform server 210 as input to the questionnaire process 303. The answers can then be extracted from the response data provided by the patient client device 240 and returned to the health outcome assessment process 302 for completion of the health outcome assessment determination.

[0071] The health outcome assessment, which may be the output of the health outcome assessment process 303, may be provided to the patient / provider profile generation process 304, which may generate one or more patient and / or provider profiles as described elsewhere in this specification, based on the data received by the platform server 210 in the health outcome assessment and / or data reception process 301 (which may also be provided to the patient / provider profile generation process 304), in accordance with the processes described elsewhere in this specification. The patient and / or provider profiles may be output from the patient / provider profile generation process 304 and provided to be displayed on the patient client device 240 and / or provider client device 250 for rendering on the patient client device 240 and / or provider client device 250. The health outcome assessment may also be provided to the risk prediction generation process 305, which may generate risk predictions as described elsewhere in this specification, based on the data received by the platform server 210 in the health outcome assessment and / or data reception process 301 (which may also be provided to the risk prediction generation process 305). The risk prediction generation process 305 can output data characterizing the generated risk prediction to the recommendation generation process 306, which can generate one or more recommendations as described elsewhere in this specification based on the received risk prediction and / or data received by the platform server 210 in the data reception process 301 (which may also be provided to the recommendation generation process 306). The generated one or more recommendations may be provided to the recommendation provision process 307, which can format the one or more recommendations according to the techniques described elsewhere in this specification and provide the formatted recommendations to the patient client device 240 and / or the provider client device 250.

[0072] The subject matter described herein offers numerous technical advantages. For example, some embodiments of the subject matter can enable real-time updates of treatment plans and recommendations during conversations with patients or providers. When a user of the software learns new information during patient care or conversations with patients or providers, this data can be added to the patient or provider profile, and the additional data in context can be analyzed in real time to update the treatment profile. Furthermore, by performing the operations described in detail herein, the system can rank and prioritize patients and providers who are most in need of intervention based on the patient's clinical and economic risk, thus enabling the user to most efficiently address the population, tackle care disparities, and provide recommendations to patients and providers who would benefit most from the intervention.

[0073] By generating the aforementioned recommendations and automatically creating patient and provider materials that can be based on those recommendations and distributed electronically, via fax, or printed for mailing, clinicians can work 5 to 10 times more efficiently and focus on clinical counseling. The software platform detects existing issues and provides relevant recommendations, enabling pharmacists, nurses, and other qualified healthcare professionals to work as trained medical professionals, making the most of their licenses. During patient counseling sessions, qualified healthcare professionals can focus on medical education and counseling instead of document review and investigation. This can reduce the time spent on comprehensive drug reviews with patients from one hour to 5 to 10 minutes. Furthermore, the platform is built in accordance with the Fast Healthcare Interoperability Resources (FHIR) standard for health data exchange, enabling communication with providers through integration with other electronic health record and software systems. Treatment recommendations can be automatically generated, reviewed by qualified clinical personnel, and delivered electronically or physically to patients and their care teams without the need for significant data entry or manual work, increasing the efficiency of clinical personnel, often pharmacists, by 5 to 10 times. Treatment recommendations can also be delivered directly to patients and their caregivers.

[0074] One or more aspects or features of the subject matter described herein can be realized in digital electronic circuits, integrated circuits, specially designed application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), computer hardware, firmware, software, and / or combinations thereof. These various aspects or features may include implementations in one or more computer programs executable and / or interpretable on a programmable system, which includes at least one programmable processor, which may be special or general-purpose, coupled to receive and transmit data and instructions from a storage system, at least one input device, and at least one output device. The programmable system or computing system may include clients and servers. Clients and servers are generally remote from each other and typically interact through a communication network. The client-server relationship is created by computer programs running on each computer that have a client-server relationship with each other.

[0075] These computer programs, which may also be called programs, software, software applications, applications, components, or code, include machine instructions to a programmable processor and can be implemented in high-level procedural languages, object-oriented programming languages, functional programming languages, logic programming languages, and / or assembly language / machine code. As used herein, the term “machine-readable medium” means any computer program product, apparatus, and / or device, such as magnetic disks, optical disks, memory, and programmable logic devices (PLDs), which include a machine-readable medium that receives machine instructions as machine-readable signals and is used to provide machine instructions and / or data to a programmable processor. The term “machine-readable signal” means any signal used to provide machine instructions and / or data to a programmable processor. A machine-readable medium can store such machine instructions non-temporarily, for example, non-temporary solid-state memory or a magnetic hard drive or any equivalent storage medium. A machine-readable medium can store such machine instructions transiently, alternatively or additionally, for example, a processor cache or other random-access memory associated with one or more physical processor cores.

[0076] To provide user interaction, one or more aspects or features of the subject matter described herein may be implemented on a computer having, for example, a display device such as a cathode ray tube (CRT) or liquid crystal display (LCD), or a light-emitting diode (LED) monitor for displaying information to the user, and a keyboard and a pointing device such as a mouse or trackball that the user can use to provide input to the computer. User interaction may also be provided using other types of devices. For example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback, and input from the user may be received in any form, including acoustic, verbal, or tactile input. Other possible input devices include touchscreens or other touch-sensitive devices, such as single or multipoint resistors or capacitive trackpads, speech recognition hardware and software, optical scanners, optical pointers, digital image capture devices, and associated interpretation software.

[0077] In the above description and claims, phrases such as "at least one of" or "one or more of" may appear before a list of elements or features. The term "and / or" may also appear within a list of two or more elements or features. Such phrases are intended to mean any of the enumerated elements or features individually, or any of the enumerated elements or features combined with any of the other enumerated elements or features, unless implicitly or explicitly contradicts the context in which they are used. For example, the phrases "at least one of A and B," "one or more of A and B," and "A and / or B" are intended to mean "A alone, B alone, or A and B together," respectively. The same interpretation is intended for lists containing three or more items. For example, “at least one of A, B, and C,” “one or more of A, B, and C,” and “A, B, and / or C” are intended to mean “A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B, and C together,” respectively. In addition, the use of the term “based on” in the above and in the claims is intended to mean “based at least in part on,” so as to allow for features or elements that are not enumerated.

[0078] The subject matter described herein can be embodied as systems, apparatus, methods and / or articles depending on the desired configuration. The embodiments described above do not represent all embodiments that correspond to the subject matter described herein. Rather, they are merely some examples that correspond to aspects related to the subject matter described herein. While several variations have been described in detail above, other modifications or additions are possible. Specifically, further features and / or variations can be provided in addition to those described herein. For example, the embodiments described above may cover various combinations and secondary combinations of the disclosed features, and / or combinations and secondary combinations of some further features disclosed above. Furthermore, the logical flows shown in the accompanying drawings and / or described herein do not necessarily require a specific order or sequence to achieve the desired result. Other embodiments may fall within the scope of the following claims.

[0079] Certain exemplary embodiments are described herein to provide an overall understanding of the structure, function, manufacturing and use principles of the devices and methods disclosed herein. One or more examples of these embodiments are shown in the accompanying drawings. Those skilled in the art will understand that the devices and methods specifically described herein and shown in the accompanying drawings are non-limiting exemplary embodiments and that the scope of the invention is defined solely by the claims. Features illustrated or described in relation to one exemplary embodiment may be combined with features of other embodiments. Such modifications and variations are intended to fall within the scope of the invention.

[0080] Furthermore, in this disclosure, components with similar names in embodiments generally have similar characteristics, and therefore, within a particular embodiment, each characteristic of each component with similar names is not necessarily described in full detail.

Claims

1. A method to be performed by one or more computing systems, Receiving data that characterizes healthcare information associated with a patient, Based on the received healthcare information data, the patient's metrics are determined, Based on the metrics determined above, the risk prediction for the patient is determined, Determining the clinical patient profile of the patient based on the received healthcare information data and the determined metrics, wherein the clinical patient profile characterizes and determines the attributes of the patient. Based on the risk prediction determined above, a treatment recommendation for the patient is determined, A method comprising providing the aforementioned treatment recommendations.

2. A method performed by one or more computing systems, Receiving data that characterizes healthcare information associated with a patient, Based on the received healthcare information data, the patient's metrics are determined, Based on the metrics determined above, the risk prediction for the patient is determined, Based on the risk prediction determined above, a treatment recommendation for the patient is determined, To provide the aforementioned treatment recommendations, A method comprising determining a provider profile of a provider of healthcare services to a patient based on the received healthcare data, wherein the provider profile characterizes the attributes of the provider.

3. A method to be performed by one or more computing systems, Receiving data that characterizes healthcare information associated with a patient, Based on the received healthcare information data, the patient's metrics are determined, Based on the determined metrics, a risk prediction for the patient is determined, wherein the determination of the risk prediction for the patient includes running a risk prediction model of risk factors that predict the likelihood of a negative health outcome, and the risk prediction model is trained to provide the risk factors in response to inquiries based on historical patient risk data. Based on the risk prediction determined above, a treatment recommendation for the patient is determined, A method comprising providing the aforementioned treatment recommendations.

4. The aforementioned decision regarding the treatment recommendation, A query to a treatment recommendation rule engine regarding recommendation parameters based on at least one of the risk factors, metrics, and / or received healthcare information data, wherein the query includes the execution of recommendation rules by the treatment recommendation rule engine. The method according to claim 3, comprising generating a recommended string that characterizes the recommended parameters.

5. The method according to claim 4, wherein the treatment recommendation rule engine is modified by a predictive model that identifies predictive variables characterizing the likelihood of success of the intervention characterized by the treatment recommendation, based on received feedback data indicating the level of success of the intervention, determines a modification to the recommendation rule based on the identified predictive variables, and modifies the recommendation rule based on the determined modification.

6. The method according to claim 4, wherein the provision of the treatment recommendation includes transmitting the recommendation string for presentation on the graphical user interface of a client device.

7. The method according to claim 4, wherein the treatment recommendation rule engine is modified by a recommendation prediction model that identifies predictive variables characterizing patterns in adherence to interventions suggested by the treatment recommendation based on the received healthcare information data, and modifies the rules of the treatment recommendation rule engine based on the identification.

8. The method according to claim 3, wherein the determination of the patient's risk prediction includes determining a clinical risk parameter that characterizes the level of clinical risk based on the determined metrics, determining a social risk parameter that characterizes the level of social risk based on the determined metrics, and determining a behavioral risk parameter that characterizes the level of behavioral risk based on the determined metrics.

9. The method according to claim 8, wherein one or more of the clinical risk parameters, social risk parameters, and behavioral risk parameters are dynamically updated based on received feedback data characterizing the patient.

10. A system, At least one data processor, The at least one data processor, Receiving data that characterizes healthcare information associated with a patient, Based on the received healthcare information data, the patient's metrics are determined, Based on the determined metrics, a risk prediction for the patient is determined, wherein the determination of the risk prediction for the patient includes running a risk prediction model of risk factors that predict the likelihood of a negative health outcome, and the risk prediction model is trained to provide the risk factors in response to inquiries based on historical patient risk data. Based on the risk prediction determined above, a treatment recommendation for the patient is determined, To provide the aforementioned treatment recommendations, A system comprising: memory for storing instructions configured to perform an action including;

11. The aforementioned decision regarding the treatment recommendation, A query to a treatment recommendation rule engine regarding recommendation parameters based on at least one of the risk factors, metrics, and / or received healthcare information data, wherein the query includes the execution of recommendation rules by the treatment recommendation rule engine. The system according to claim 10, comprising generating a recommended string characterizing the aforementioned recommended parameters.

12. The system according to claim 11, wherein the treatment recommendation rule engine is modified by a predictive model that identifies predictive variables characterizing the likelihood of success of the intervention characterized by the treatment recommendation, based on received feedback data indicating the level of success of the intervention, determines a modification to the recommendation rule based on the identified predictive variables, and modifies the recommendation rule based on the determined modification.

13. The system according to claim 11, wherein the treatment recommendation rule engine is modified by a recommendation prediction model that identifies predictive variables characterizing patterns in adherence to interventions suggested by the treatment recommendation based on the received healthcare information data, and modifies the rules of the treatment recommendation rule engine based on the identification.

Images