CN104956391A - Clinical dashboard user interface system and method - Google Patents

Abstract

A dashboard user interface method comprising displaying a navigable list of at least one target disease, displaying a navigable list of patient identifiers associated with a target disease selected in the target disease list, displaying a Patient-linked historical and current data in disease-linked patient lists, including clinician notes on admission, receiving, storing, and displaying reviewer comments, and displaying automatically generated intervention and treatment recommendations.

Description

Clinical dashboard user interface systems and methods

field

The present disclosure relates to a clinical dashboard user interface system and method, and in particular to the field of disease identification and monitoring.

Background technique

One of the challenges hospitals face today is identifying a patient's primary disease as early as possible so that appropriate intervention can be deployed immediately. Some diseases, such as acute myocardial infarction (AMI) and pneumonia, require immediate standard action or approach within 24 hours of diagnosis. Other diseases are less severe but still require careful adherence to intermediate and long-term care (care) programs across multiple health care facilities.

The Joint Commission, the hospital accrediting agency approved by the Centers for Medicare and Medicaid Services (CMS), has developed a clearly articulated core of treatment measures. These measures rely on criteria that can lead to CMS penalties for poor performance. For example, the measures set for acute myocardial infarction include:

Set Action ID measure short name AMI-1 Aspirin on arrival AMI-2 Prescribing aspirin upon discharge AMI-3 ACE inhibitors or ARBs for LVSD AMI-4 Adult Smoking Cessation Counseling/Counseling AMI-5 Beta-blockers prescribed at discharge AMI-7 Median Time to Fibrinolysis AMI-7a Thrombolytic therapy received within 30 minutes of arriving at the hospital AMI-8 Median Time to Primary PCI AMI-8a Primary PCI received within 90 minutes of arriving at the hospital AMI-9 In-patient mortality rate (valid search 12/31/2010) AMI-10 Statin prescription at discharge

To date, most reporting and monitoring of accountable measure activities is done after a patient is discharged from a healthcare facility. Delays in identifying and understanding specific interventions often make it impossible to correct any situation. Hospital administrators also struggle to determine how well hospitals are meeting core measures on a day-to-day basis. Clinicians will need real-time or near-real-time view of patient progress and care including clinician notes throughout the hospital stay, which will alert actions (pathway and monitoring) on the part of the medical management team and physicians towards meeting these core measures .

Case management teams have difficulty tracking patients' real-time disease status. The ability to do this with a clear picture of the clinician's notes (as they change in real time during the patient's stay as new information arrives) will increase the team's ability to apply focused interventions as early as possible, and across the patient These pathways are followed or altered as needed during hospitalization to improve the quality and safety of care, reduce unplanned readmissions and adverse events, and improve patient outcomes. The present disclosure describes software developed to identify and risk stratify patients at highest risk of readmission and other adverse clinical events, and a dashboard user interface that presents data to users in a clear and understandable manner.

Description of drawings

Figure 1 is a simplified block diagram of an exemplary embodiment of a clinical prognostic and monitoring system and method according to the present disclosure;

2 is a timeline diagram of an exemplary embodiment of a clinical prognostic and monitoring system and method according to the present disclosure;

3 is a simplified logic block diagram of an exemplary embodiment of a clinical prognostic and monitoring system and method according to the present disclosure;

4 is a simplified flowchart of an exemplary embodiment of a clinical prognostic and monitoring system and method according to the present disclosure;

Figure 5 is a simplified flowchart/block diagram of an exemplary embodiment of a clinical prognostic and monitoring system and method according to the present disclosure;

6 is a simplified flowchart of an exemplary embodiment of a dashboard user interface system and method according to the present disclosure;

7 is a simplified flowchart of an exemplary embodiment of a typical user interaction with a dashboard user interface system and method according to the present disclosure;

8 is an exemplary screenshot of a dashboard user interface system and method according to the present disclosure;

9 is an exemplary screenshot of a dashboard user interface system and method for displaying a drop comment window in accordance with the present disclosure; and

10 is an exemplary screen shot of a dashboard user interface system and method displaying a viewing commentary window in accordance with the present disclosure.

Detailed ways

FIG. 1 is a simplified block diagram of an exemplary embodiment of a clinical prediction and monitoring system 10 according to the present disclosure. The clinical prognostics and monitoring system 10 includes a computer system 12 adapted to receive various clinical and non-clinical data about a patient or individual requiring care. Various data include, for example, real-time data streams and historical or Storing data. These data are used to determine disease risk scores for selected patients, allowing them to receive more targeted interventions, treatments, and care that are better tailored and tailored to their specific circumstances and needs. The system 10 is best suited to identify specific patients who require intensive inpatient and/or outpatient care to avoid serious adverse effects of a particular disease and reduce readmission rates. It should be noted that computer system 12 may include one or more local or remote computer servers operable to transfer data and communications via wired and wireless communication links and computer networks.

Data received by the clinical prognostics and monitoring system 10 may include electronic medical records (EMRs), which include both clinical and non-clinical data. EMR clinical data may be received from entities such as hospitals, clinics, pharmacies, laboratories, and health information exchanges, including: vital signs and other physiological data; comprehensive or centralized communications with physicians, nurses, or allied health professionals; Data associated with history and physical examination; medical history; previous allergies and adverse medical reactions; family medical history; previous surgical history; emergency room notes; medication administration records; culture results; oral clinical notes and records; gynecological and obstetrical history; mental status examination ; vaccination records; radiographic examinations; invasive visualization procedures; history of psychiatric treatment; previous tissue specimens; laboratory data; Supplement intake information; and centralized genotype testing.

EMR nonclinical data can include, for example, social, behavioral, lifestyle, and economic data; type and nature of occupation; work history; health insurance information; hospital utilization patterns; exercise information; addictive substance use; occupational chemical exposure; physician frequency of contact or health system; location and frequency of residence changes; predictive screening health questionnaires (such as Patient Health Questionnaire (PHQ)); personality tests; census and demographic data; surrounding environment; diet; gender; marital status; education ; distance and number of family members or care assistants; address; housing status; social media data; and education level. Non-clinical patient data may further include data entered by the patient, such as data entered or uploaded to a social media website.

Additional sources or devices of EMR data may provide, for example, lab results, medication dispensations and changes, EKG results, radiology notes, daily weight readings, and daily blood glucose test results, for example. These data sources can come from different areas of the hospital, clinic, patient care facility, patient home monitoring equipment, and other available clinical or healthcare sources.

As shown in FIG. 1 , patient data sources may include non-healthcare entities 15 . These are entities or organizations that are not considered traditional health care providers. These entities 15 may provide non-clinical data including, for example, gender; marital status; education; community and religious organization involvement; Socioeconomic data reported by borough's census; housing status; number of housing address changes; frequency of housing address changes; claims for government assistance; ability to make and keep medical appointments; independence in activities of daily living; seeking medical assistance hours; location of seeking medical care; sensory impairment; cognitive impairment; mobility impairment; education level; occupation; and economic status in absolute and relative terms for local and national income distribution; climate data; and health registration. Such data sources can further provide insightful information about a patient's lifestyle, such as the number of family members, relationship status, individuals who can help care for the patient, and health and lifestyle preferences that can affect health outcomes.

The clinical prognostics and monitoring system 10 may further receive data from a health information exchange (HIE) 16 . A HIE is an organization that electronically mobilizes health information across organizations within a region, community, or hospital system. HIEs are increasingly being developed to share clinical and non-clinical patient data among healthcare entities within city, national, regional or umbrella health systems. Data can originate from many sources such as hospitals, clinics, consumers, payers, physicians, laboratories, outpatient pharmacies, outpatient centers, nursing homes, and state or public health agencies.

A subset of the HIE connects healthcare entities to community organizations that do not specifically provide healthcare services, such as non-governmental charitable organizations, social service agencies, and city agencies. The clinical prognostics and monitoring system 10 may receive data from these social service organizations and the social-to-health information exchange 17, which data may include, for example, information on skills of daily living, transportation to medical appointments, employment assistance, training, substance abuse rehabilitation , counseling or detoxification, rent and utility assistance, homelessness status and access to services, medical follow-up, mental health services, meals and nutrition, pantry services, housing assistance, temporary shelter, home health visits , domestic violence, appointment compliance, discharge instructions, medical prescriptions, medication instructions, neighborhood status, and the ability to track referrals and appointments.

Another source of data includes social media or social networking services 18, such as FACEBOOK and GOOGLE+ web sites. Such sources may provide information such as number of family members, relationship status, identification of individuals who may assist in patient care, and health and lifestyle preferences that may affect health outcomes. For example, with the individual's permission, such social media data may be received from a web site, and some data may come directly from the user's computing device as the user enters status updates.

These non-clinical patient data provide a more realistic and accurate picture of the patient's overall holistic health care environment. Augmented with such non-clinical patient data, the analysis and predictive modeling performed by the present system to identify patients at high risk of readmission or disease recurrence becomes more robust and accurate.

The system 10 is further adapted to receive user preferences and system configuration data from a clinician's computing device (mobile device, tablet computer, laptop computer, desktop computer, server, etc.) 19 in a wired or wireless manner. The computing device is equipped to display a system dashboard and/or another graphical user interface to present system data and reports. For example, a clinician (health care provider) can immediately generate a list of patients with the highest heart failure risk scores (eg, top n or top x%). The graphical user interface is further adapted to receive user (health care provider) input of preferences and configurations. Data may be transmitted, presented, and displayed to clinicians/users in the form of web pages, web-based messages, text files, video messages, multimedia messages, text messages, emails, and in any suitable manner and format.

As shown in FIG. 1 , the clinical prediction and monitoring system 10 may receive data streamed in real time or from history, or in batches from various data sources. Furthermore, system 10 may store received data in data store 20 or process the data without first storing the data. Real-time and stored data can be in a variety of formats according to various protocols including CCD, XDS, HL7, SSO, HTTPS, EDI, CSV, etc. Data may be encrypted or otherwise suitably protected. Data can be obtained (polled) from various data sources by the system 10 or data can be pushed to the system 10 by the data sources. Alternatively or additionally, data may be received in batches according to a predetermined schedule or on demand. Data store 20 may include one or more local servers, memory, drives, and other suitable storage devices. Alternatively or additionally, data may be stored in cloud data centers.

Computer system 12 may include a number of computing devices, including servers, which may be located locally or in a cloud computing farm. The data path between computer system 12 and data storage 20 may be encrypted or otherwise secured using now known or later developed security measures or transmission protocols.

2 is a timeline diagram of an exemplary embodiment of a clinical prognostic and monitoring system and method according to the present disclosure. As an example, a timeline diagram is used to illustrate how the clinical prediction and monitoring system and method 10 can be applied to reduce readmission rates related to congestive heart failure. Most US hospitals struggle to contain readmission rates associated with congestive heart failure. While many studies have found that some combination of careful discharge planning, care provider coordination, and intensive counseling prevents subsequent readmission, it has been difficult to successfully achieve and maintain in typical US hospitals. Uniform registration of all heart failure patients, high-intensity care transition programs require a depth of case management resources that many systems (especially safety net hospitals) cannot match. The clinical prediction and monitoring system and method 10 is suitable for precise risk stratification for specific diseases and conditions, such as 30-day readmission in congestive heart failure patients.

Within 24 hours of a patient's admission, stored historical and real-time data on the patient is analyzed by the clinical prognostics and monitoring system and method 10 to identify specific diseases and conditions associated with the patient, such as congestive heart failure. Further, the system 10 calculates a congestive heart failure risk score for that particular patient within 24 hours of admission. If that particular patient's risk score for congestive heart failure exceeds a particular risk threshold, that patient is identified on the list of high risk patients presented to the intervention coordination team. The process for disease identification and risk score calculation is described in more detail below.

The clinical prediction and monitoring system and method 10 is operable to display, transmit, and otherwise present a list of high-risk patients to an intervention coordination team including physicians, physician assistants, case managers, patient advisors, nurses, social Workers, family members, and other persons or individuals involved in patient care. Presentation means may include emails, text messages, multimedia messages, voice messages, web pages, facsimiles, audible and visual alerts, etc. delivered by any number of suitable electronic or portable computing devices. The intervention coordination team can then prioritize interventions for the highest risk patients and provide targeted inpatient care and treatment. The clinical prediction and monitoring system and method 10 can further automatically present plans to include suggested intervention and treatment options. Some intervention plans may include a detailed inpatient clinical assessment as well as patient nutrition, medication, case manager, and heart failure education counseling initiated early in the patient's hospital stay. An intervention coordination team is available for immediate and orderly inpatient clinical and social interventions. In addition, the plan may include clinical and social outpatient interventions and deploy post-discharge care and support programs.

High-risk patients were also assigned a cohort of high-intensity outpatient interventions. Once the target patient is discharged, outpatient intervention and care begins. Such interventions may include a follow-up telephone call within 48 hours from the patient's case manager (such as a nurse); appointment reminders and medication updates from the physician; 30-day outpatient case management; a follow-up clinic appointment within 7 days of discharge; Cardiology appointments (if required); and follow-up primary care visits. Successful interventions have been found to be based on well-known readmission reduction programs and policies designed to significantly reduce 30-day readmissions associated with congestive heart failure.

The clinical prognostics and monitoring system and method 10 continues to receive clinical and non-clinical data pertaining to patients identified as high risk during hospitalization and after patients are discharged from the hospital to further improve diagnosis and modify or enhance treatment and intervention plans, if necessary if.

After the patient is discharged from the hospital, the clinical prognostics and monitoring system and method 10 continues to monitor the patient's intervention status based on electronic medical records, case management systems, social service entities, and other data sources as described above. The clinical prediction and monitoring system and method 10 can also interact directly with caregivers, case managers, and patients to obtain additional information and prompt action. For example, the clinical prediction and monitoring system and method 10 may notify a physician that one of his or her patients has returned to the hospital, and the physician may then send a pre-formatted message to the system directing the system to notify a specific case management management team. In another example, the clinical prediction and monitoring system and method 10 may learn that a patient missed a physician's appointment and did not reschedule. The system can send a text message to the patient reminding the patient to reschedule the appointment.

FIG. 3 is a simplified logic block diagram of an exemplary embodiment of a clinical prognostic and monitoring system and method 10 according to the present disclosure. Because system 10 receives and extracts data from many disparate sources in myriad formats according to different protocols, incoming data must first undergo multi-step processing before they can be properly analyzed and used. The clinical prediction and monitoring system and method 10 includes a data integration logic module 22 that further includes a data extraction process 24 , a data cleaning process 26 , and a data manipulation process 28 . It should be noted that although the data integration logic module 22 is shown with different processes 24-28, these are done for illustration purposes only and these processes can be performed in parallel, iteratively, and interactively.

The data extraction process 24 extracts real-time clinical and non-clinical data directly or from data sources in real-time over the Internet or in historical batch files using various techniques and protocols. Preferably in real-time, the data cleansing process 26 "cleans" or preprocesses the data such that the structured data is in a standard format and prepares the unstructured text for natural language processing (NLP) to be performed in the disease/risk logic module 30 . The system can also receive "cleaned" data and convert them to the desired format (eg, text data fields converted to numeric values for calculation purposes).

Data manipulation process 28 may analyze the representation of a particular data feed against the metadata dictionary and determine whether the particular data feed should be reconfigured or replaced by an alternate data feed. For example, a given hospital EMR may store the concept of "maximum creatinine" differently. The data manipulation process 28 may make inferences to determine which particular data from the EMR will best represent the concept of "creatinine" as defined in the metadata dictionary and determine whether the feedback will require specific reconfiguration to achieve the maximum value (e.g., select the highest value).

The data integration logic module 22 then transmits the pre-processed data to the disease/risk logic module 30 . Disease risk logic module 30 is operable to calculate for each patient a risk score associated with the identified disease or condition and identify those patients who should receive targeted interventions and care. The disease/risk logic module 30 includes a de-identification/re-identification process 32 adapted to remove all protected health information in accordance with HIPAA standards prior to transmission of the data over the Internet. It is also suitable for re-identifying data. Protected health information that may be removed and added back may include, for example, name, telephone number, fax number, email address, social security number, medical record number, health plan beneficiary number, account number, certificate or license number, License plate numbers, device numbers, URLs, all geographic subdivisions smaller than a state including street addresses, cities, counties, districts, zip codes, and their equivalent geocodes (except the first 3 digits of a zip code, If based on currently publicly available data from the Census Bureau), Internet Protocol numbers, biometric data, and any other unique identification numbers, characteristics, or codes.

The disease/risk logic module 30 further includes a disease identification process 34 . Disease identification process 34 is adapted to identify one or more diseases or conditions of interest for each patient. The disease identification process 34 considers data such as lab orders, lab values, clinical text and narrative notes, and other clinical and historical information to determine the probability that a patient has a particular disease. In addition, during disease identification, natural language processing is performed on unstructured clinical and non-clinical data to identify a disease or diseases that a physician considers to be prevalent, the process 34 may be performed iteratively over a number of days to as the physician is diagnosing Become more confident in developing a higher confidence in disease identification. New or updated patient data may not support a previously identified disease, and the system will automatically remove the patient from the disease list. Natural language processing combines rule-based and statistical learning-based models.

The disease identification process 34 utilizes a hybrid model of natural language processing that combines rule-based and statistical learning-based models. During natural language processing, raw unstructured data (eg, physician notes and reports) first undergoes a process called tokenization. Tokenization divides text into basic units of information in the form of individual words or phrases by using defined separators such as punctuation marks, spaces, or capital letters. Using a rule-based model, these basic units of information are identified and evaluated in a metadata dictionary according to predetermined rules that determine meaning. Using a statistical-based learning model, the disease identification process 34 quantifies the relationship and frequency of word and phrase forms, and then uses statistical algorithms to process them. Using machine learning, statistical learning models generate inferences based on repeated patterns and relationships. Disease identification processing 34 performs multiple complex natural language processing functions, including text preprocessing, lexical analysis, syntactic analysis, semantic analysis, processing multi-word expressions, word sense disambiguation, and other functions.

For example, if the physician's notes include the following: "55yo m c h/o dm, cri. now with adib rvr, chfexac, and rle cellulitis on 10W, tele". The data integration logic 22 operable program then translates these notes as: Fifty-five-year-old male with history of diabetes mellitus, chronic renal insufficiency, presently with atrial fibrillation with rapid ventricular response, exacerbated congestive heart failure and right lower extremity For cellulitis, 10 Wests will be performed with continuous cardiac monitoring.

Continuing with the previous example, the disease identification process 34 is adapted to further determine the following: 1) the patient is specifically admitted due to atrial fibrillation and congestive heart failure; 2) atrial fibrillation is serious due to the presence of a rapid ventricular rate; 3) Cellulitis was in the right lower extremity; 4) Patient was on continuous cardiac monitoring or telemetry; and 5) Patient appeared to have diabetes and chronic renal insufficiency.

The disease/risk logic module 30 further includes a predictive model process 36 adapted to predict the risk of a particular disease or condition of interest based on one or more predictive models. For example, if a hospital desires to determine the level of risk of future readmission for all patients currently admitted with heart failure, a heart failure predictive model may be selected to process patient data. However, if a hospital wishes to determine the risk class for all medical patients due to any cause, the patient data can be processed using an all-cause readmission prediction model. As another example, if a hospital desires to identify those patients who are at risk for short-term and long-term diabetic complications, a diabetes predictive model can be used to target these patients. Other predictive models may include HIV readmission, diabetes markers, risk of cardiopulmonary arrest, renal disease progression, acute coronary syndrome, pneumonia, cirrhosis, all-cause disease-unrelated readmission, colon cancer pathway adherence, and more.

Continuing with the previous example, a predictive model for congestive heart failure may consider a set of risk factors or variables, including worst values for laboratories and vital sign variables such as: albumin, total bilirubin, creatine Kinase, creatinine, sodium, blood urea nitrogen, partial pressure of carbon dioxide, white blood cell count, troponin I, glucose, international normalized ratio, brain natriuretic peptide, pH, temperature, pulse, diastolic, and systolic blood pressure. Also, consider nonclinical factors such as number of home address changes in the previous year, risky health behaviors (eg, use of illicit drugs or substances), number of emergency room visits in the previous year, history of depression or anxiety , and other factors. A predictive model specifies how each variable or risk factor is classified and weighted, and calculates the predicted probability of readmission or risk score. In this manner, the clinical prediction and monitoring system and method 10 is capable of stratifying the risk of each patient arriving at a hospital or another healthcare facility in real time. Thus, those patients at highest risk are automatically identified so that targeted intervention and care can be instituted. One output from the disease/risk logic module 30 includes risk scores for all patients for a particular disease or condition. Additionally, module 30 may rank patients according to risk score and provide identification of those patients at the top of the list. For example, a hospital may wish to identify the top 20 patients at highest risk for congestive heart failure readmission, and the top 5% of patients at highest risk for cardiac arrest in the next 24 hours. Other diseases and conditions that can be identified using predictive models include, for example, HIV readmission, diabetes identification, renal disease progression, bowel cancer continuum screening, meningitis management, acid-base management, anticoagulation management, and the like.

The disease/risk logic module 30 may further include a natural language generation module 38 . Natural language generation module 38 is adapted to receive output from prediction module 36, such as the patient's risk score and risk variables, and "translate" the data to present evidence that the patient is at high risk for the disease or condition. This module 30 thus provides the intervention coordination team with additional information supporting why a patient has been identified as high risk for a particular disease or condition. In this way, the Intervention Coordination Team can better develop targeted inpatient and outpatient intervention and treatment plans to address the patient's specific circumstances.

The disease/risk logic module 30 further includes an artificial intelligence (AI) model adjustment process 40 . The artificial intelligence model tuning process 38 uses machine learning techniques to use adaptive self-learning capabilities. The ability to self-reconfigure enables the system and method 10 to be flexible and adaptable enough to detect and incorporate trends or differences in underlying patient data or populations that may affect the predictive accuracy of a given algorithm. The artificial intelligence model tuning process 40 may periodically retrain selected predictive models to obtain improved accuracy results, allowing selection of the most accurate statistical methods, variable counts, variable selections, interaction terms, weights, and weights for the local health system or clinic. Intercept. The artificial intelligence model tuning process 40 can automatically modify or improve the predictive model in three exemplary ways. First, it adjusts the predictive weights of clinical and nonclinical variables without human supervision. Second, it can adjust thresholds for specific variables without human supervision. Third, the artificial intelligence model tuning process 40 can evaluate new variables that are present in the data feed but not used in the predictive model without human supervision, which can lead to improved accuracy. The artificial intelligence model adjustment process 40 may compare the actual observed outcome of the event to the predicted outcome, and then individually analyze the variables within the model that contributed to the incorrect outcome. It can then reweight the variables that contributed to the incorrect result so that in the next iteration, these variables are less likely to contribute to the wrong prediction. In this way, the artificial intelligence model tuning process 40 is adapted to reconfigure or tune the predictive model based on the specific clinical setting or population to which it is applied. Also, no manual reconfiguration or modification of the predictive model is necessary. The artificial intelligence model tuning process 40 may also be useful for scaling predictive models to different health systems, populations, and geographic regions in rapid time periods.

As an example of how the artificial intelligence model adjustment process 40 works, the sodium variable coefficient may be evaluated periodically to determine or identify that the relative weight of abnormal sodium lab results for new populations should vary from 0.1 to 0.12. As time passes, the artificial intelligence model adjustment process 38 checks whether the nano threshold should be updated. It can be determined that in order for the threshold level of abnormal nano-lab results to be predictive for readmission, the abnormal nano-lab results should vary from, for example, 140 to 136 mg/dL. Finally, the artificial intelligence model tuning process 40 is adapted to check whether the prediction set (list of variables and variable interactions) should be updated to reflect changes in the patient population and clinical practice. For example, the nano variable can be replaced by the NT-por-BNP protein variable, which was not previously considered by the predictive model.

Results from the disease/risk logic module 30 are provided to hospital personnel (such as the Intervention Coordination Team) and other caretakers through the data presentation and system configuration logic module 42 . The data presentation logic module 42 includes a dashboard interface 44 adapted to provide information about the performance of the clinical prediction and monitoring system and method 10 . Users (eg, hospital personnel, managers, and intervention coordination teams) can find the specific data they are looking for through simple and clear visual navigation cues, icons, windows, and devices. For example, the interface may further respond to audible commands. Since the number of patients admitted to a hospital each day can be overwhelming, a simple graphical interface that maximizes efficiency and reduces user navigation time is desirable. Visual cues are preferably presented in case of assessment problems (eg, readmission, out-of-ICU, cardiac arrest, diabetic complications, and others).

Dashboard user interface 44 allows interactive requests for various views, reports, and presentations of extracted data and risk score calculations from operational databases within the system, including, for example, a summary view of a list of patients in a particular care location; Detailed explanation of the components of each sub-score; graphical representation of data over time for a patient or population; comparison of incidences of predicted events to predicted rates over a specific time period; summary text clippings for specific patients, laboratory trends , and Risk Score to aid in the dictation and preparation of history and medical reports, daily notes, continuity of signatures of nursing notes, surgical notes, discharge summaries, continuity of nursing documents to outpatient physicians; order generation for automatic generation by Orders for electronic medical records for return to a hospital or practice as mandated by local care provider healthcare settings and state and national guidelines for return to physician's office, external healthcare provider network; aggregate data into common medical formulas Provided to aid in care, this data includes, but is not limited to: pH calculation, MELD score, Child-Pugh-Turcot score, TIMI risk score, CHADS score, estimated creatinine clearance, body surface area, body mass index, adjuvants , Neoadjuvant Therapy and Metastatic Cancer Survival Nomograms, MEWS Scores, APACHE Scores, SWIFT Scores, NIH Stroke Scale, PORT Scores, AJCC Pathological Stages; Publish elements of data on scanned or electronic versions of tables to create automated data sheet.

The data presentation and system configuration logic module 40 further includes a messaging interface 46 adapted to communicate with, for example, HL7 messaging, text messaging, email messaging, multimedia messaging, web pages, web portals, REST Output messaging codes are generated in the form of , XML, computer-generated speech, structured documents including graphical, numerical and textual summaries of risk assessments, reminders, and suggested actions. Interventions generated or suggested by the system and method 10 may include: risk score reports to attending physicians highlighting their patient's readmission risk; score reports entered into the EMR via new data fields for hospitals, coverage Population surveillance use for entire populations in entities, responsible care groups, or other levels of organization in a health care delivery network; comparison of aggregated risk of readmission within a single hospital or across hospitals to allow risk-normalized comparisons of hospital readmission rates; scores to Automatic incorporation of discharge summary templates, continuity of care documentation (within providers in inpatient settings or to external physician consultants and primary care physicians), HL7 messages to facilitate communication of readmission risk transitions to non-hospital physicians; and A communication subcomponent that aggregates socioenvironmental scores, clinical scores, and overall risk scores. These scores will highlight potential strategies to reduce readmissions, including: generating an optimized drug list; allowing pharmacies to identify those drugs on the formulary to reduce out of pocket costs and improve outpatient visits to drug treatment plans; (flagging) nutrition education needs; flagging transportation needs; assessing housing instability to flag need for nursing home placement, transitional housing, Part 8 HHS housing assistance; flagging poor self-monitoring behavior for additional follow-up calls; Suggested poor social network scores for home RN assessments; flagging high substance abuse scores for consultation in rehabilitation counseling for patients with high abuse problems.

This output can be transmitted wirelessly or via a LAN, WAN, Internet and delivered to a healthcare facility's electronic medical record store, consumer electronic device (e.g., pager, text messaging program, mobile phone, tablet computer, mobile computer, laptop desktop computers, and servers), health information exchanges, and other data stores, databases, devices, and users. The system and method 10 can automatically generate, transmit, and present items such as high-risk patient lists with risk scores, natural language generated text, reports, suggested actions, alerts, continuity of care documentation, flags, appointment reminders, and questionnaires information such as surveys.

The data presentation and system configuration logic module 40 further includes a system configuration interface 48 . Local clinical preferences, knowledge, and methods can be provided directly through the system configuration interface 46 as input to the predictive model. The system configuration interface 46 allows the institution or health system to directly set or reset variable thresholds, prediction weights, and other parameters in the prediction model. System configuration interface 48 preferably includes a graphical user interface designed to minimize user navigation time.

FIG. 4 is a simplified flowchart of an exemplary embodiment of a clinical prediction and monitoring method 50 according to the present disclosure. Method 50 receives structured and unstructured clinical and non-clinical data related to a particular patient from various sources and in a variety of different formats, as indicated at block 52 . These data may be encrypted or protected using now known or later developed data security methods. In block 54, the method 50 preprocesses the received data, such as data extraction, data cleaning, and data manipulation. Other data processing techniques, now known and later developed, may be used. In block 56, data processing methods such as natural language processing and other suitable techniques may be used to translate or otherwise understand the meaning of the data. In block 58, one or more diseases or conditions of interest associated with each patient are identified by analyzing the preprocessed data. In block 60, the method 50 applies one or more predictive models to further analyze the data and calculate one or more risk scores for each patient related to the identified disease or condition. In blocks 62 and 64, one or more lists showing those patients at highest risk for each identified disease or condition are generated, transmitted, and otherwise presented to hospital personnel, such as members of an intervention coordination team. These lists can be generated daily or according to another desired schedule. The Intervention Coordination Team can then prescribe and follow targeted intervention and treatment plans for inpatient and outpatient care. In block 66, the patients identified as high risk are continuously monitored while they undergo inpatient and outpatient care. Method 50 ends in box 68 .

Not explicitly shown in Figure 4 is the de-identification process, in which data becomes irrelevant to the patient's identity to comply with HIPAA regulations. Data can be decoupled from the patient's identity whenever the data is transmitted over wired or wireless network links that can be compromised and otherwise required by HIPAA. The method 50 is further adapted to rejoin patient data with the patient's identity.

FIG. 5 is a simplified flowchart/block diagram of an exemplary embodiment of a clinical prediction and monitoring method 70 according to the present disclosure. Various data are received from a plurality of disparate data sources 72 related to a particular patient admitted to a hospital or healthcare facility. Incoming data can be received in real time or data can be stored as historical data received in batches or on demand. Incoming data is stored in data storage 74 . In box 76, the received data is subjected to data integration processing (data extraction, data cleaning, data manipulation) as described above. The resulting preprocessed data is then subjected to disease logic processing 78 during which de-identification, disease identification, and predictive modeling are performed. The calculated risk score for the disease of interest for each patient is compared to a disease risk threshold in block 80 . Each disease is associated with its own risk threshold. If the risk score is less than the risk threshold, the process returns to data integration and repeats the process as new data associated with the patient becomes available. If the risk score is greater than or equal to the risk threshold, then in block 82 the identified patient with a high risk score is included in the patient list. In block 84, the patient list and other associated information may then be presented to the intervention coordination team in one or more possible ways, such as by text message, email, web page, etc., to a desktop or mobile device and display on it. In this manner, the intervention coordination team is notified and activated for evaluation and inpatient and outpatient treatment and care of the patients identified in the list of patients, as indicated at block 88 . This process may then provide feedback data to data source 72 and/or back to data integration 76 which continues to monitor the patient during his/her targeted inpatient and outpatient interventions and treatments. Continuous monitoring of patient-related data (such as prescribed medications and further laboratory results, radiology images, etc.) care plan.

FIG. 6 is a simplified flowchart of an exemplary embodiment of a dashboard user interface system and method 90 in accordance with the present disclosure. In block 92, the patient's data is evaluated as described above, and those patients associated with the target disease and surveillance condition are identified. Target diseases are those for which the patient is at risk of readmission to a healthcare facility. Conditions monitored are those patient conditions indicative of adverse events occurring in the healthcare facility, eg, injuries and injuries. As shown in block 94, further verification regarding the particular disease or surveillance condition involving the patient is performed by comparison to a predetermined probability threshold. If the probability threshold is met, the patient is classified or identified as belonging to the disease list or condition list. The display is also updated so that when the user selects a particular disease list to display, that patient is displayed in the list, as indicated by block 96 . This can be seen in the example screen in Figure 8. In this exemplary screen, a list of patients at risk of 30-day readmission due to congestive heart failure (CHF) is identified and listed in the active congestive heart failure list. Detailed descriptions of exemplary screens are provided below.

Users can print, transmit, and otherwise use the displayed information and generate standard or custom reports. The report can be primarily text in nature, or include graphical information. For example, a graphical report may plot a comparison of expected and observed readmission rates for any disease type, condition, or classification for patients enrolled or unenrolled in a centralized intervention program, as well as enrolled patients A graph of readmission rates over time for any disease type, condition, or classification relative to patients dropped. Patients with a greater than 95% probability of having heart failure, total patients versus enrolled patients over a specified time period, and the number of patients who were not readmitted within the 30-day discharge readmission window versus (by) elapsed time from discharge number of days. Additional exemplary standard follow-up reports may further identify all enrolled patients for whom: Post-Discharge Appointment Scheduled, Post-Discharge Consultation Scheduled, Patient Attended Follow-Up Appointment, Patient Received Post-Discharge Consultation, Patient Received and Completed Medical prescription, and the patient has received a transportation voucher. Also, sample reports may include a comparison of expected and observed readmission rates for any disease type, event, or classification for enrolled and unregistered patients, over a period of time for any disease type, event, or Classified Enrolled vs. Abandoned Patient Readmission Rate, Patients with >95% Probability of Having Heart Failure: Total Patient vs. Enrolled Patient Over a Specified Time Period, and Within a 30-Day Discharge Readmission Window Number of patients who were not readmitted versus (by) the number of days elapsed since discharge. If the probability threshold is not met in block 94, the patient's data is re-evaluated as new or updated data becomes available.

Another type of report available is a result optimization report. These are reports designed to help users (managers) assess the efficacy of programs, establish benchmarks, and identify the need for system and population level changes to improve care outcomes. The report can include data to help assess the effectiveness of identifying high-risk patients. Some data may indicate the effort expended, the patients enrolled, and how often those patients actually afflicted with the identified disease. Reports may include data to help assess whether an intervention is being given to the right patient at the right time, etc.

As new, updated, or additional patient data becomes available, as indicated in block 98, the data is evaluated to identify or verify a disease/condition. For example, a patient may be reclassified if the data now indicates that the patient should be classified differently. Patients can also be identified as additional diseases and included in another list. For example, during the first 24 hours of hospitalization, the system identifies patient Jane Doe as having CHF. Once more information is received, such as lab results and new physician notes, the system identifies Jane Doe as also having an AMI. Jane Doe will then be placed on the AMI list and identified as an AMI patient as soon as a new diagnosis is available. Additionally, Jane Doe will remain on the CHF list, but she will be identified on that list as an AMI patient.

If no new patient data exists, then as indicated by block 99, no changes are made to the patient classification and the display reflects the current status of the patient classification. Thus, as real-time or near-real-time patient data becomes available, patient disease and condition classifications are re-evaluated and updated as needed.

FIG. 7 is a simplified flowchart of an exemplary embodiment of a typical user interaction process 100 with a dashboard user interface system and method in accordance with the present disclosure. All users permitted to access the system must have login security information, such as usernames and passwords, on file. As shown in block 102, all access to the system requires logging into the system by providing the correct login information. As shown at block 103, the user may select parameters such as disease type, event, risk level, and eligibility for high-intensity intervention care program entry to generate a report. The user can make this choice at any time after a successful login. For example, a user may select a particular patient and review information related to that patient. As shown at block 104, the user may then review and evaluate the displayed information, including clipped physician notes. Users may also print, transmit, or otherwise use the displayed information in some form.

Target predictive readmission diseases could include: congestive heart failure, pneumonia, acute myocardial infarction, diabetes, cardiopulmonary arrest and mortality, cirrhosis readmission, HIV readmission, sepsis, and all causes. Target disease identifiers may include: chronic kidney disease, sepsis, surveillance, chronic kidney disease in outpatient, diabetes in outpatient, and sepsis. Conditions of interest for surveillance due to possible adverse events may include: sepsis, postoperative pulmonary embolism (PE) or deep vein thrombosis (DVT), postoperative sepsis, postoperative shock, unplanned return to surgery, respiratory failure , Hypertension, Accidental Injury, Insufficient, Omissions or Errors in Communication in Assessing Diagnosis, or Monitoring, Falls, Hospital Acquired Infections, Mismedicated Patients, Patient Identification Issues, ICU Out of Cardiopulmonary Arrest and Mortality, Chronic Kidney Disease, Shock , naloxone trigger, anesthesia trigger (over-sedation), hypoglycemia trigger, and accidental death.

For example, the evaluation may include entering comments about the patient. As part of the evaluation process, a user may confirm, deny, or express uncertainty about a patient's disease or condition identification or eligibility for enrollment in an intervention program. For example, as shown at block 106, the user may review the notes and recommendations associated with a particular patient and confirm that the patient is included in the congestive heart failure list. For example, a user consults a clinician's notes that draw attention to excerpts of key words and phrases, thereby helping him or her find key information about disease identities through the system. Key terms such as "shortness of breath," "elevated BNP," and "furosemide (Lasix)" help the user verify the disease identity of CHF for this patient. If the patient's classification, risk class, and eligibility class are confirmed, then as shown in block 107, there is no change in the patient's classification and displayed data (other than indicating that the classification has been confirmed). A user may provide a comment associated with the confirmation. User comments are stored and can be viewed by other users in real or near real time, allowing clear and timely communication between team members. The user may continue to select report or display parameters in box 103 or review and evaluate the patient in box 104 .

Alternatively, the user may disagree with the inclusion of the patient in the congestive heart failure list, or express uncertainty. The user may enter comments explaining his or her assessment of the patient's disease signature and disagreeing with the patient's disease signature. User comments are stored and can be viewed by other users in real or near real time, allowing clear and timely communication between team members.

If the user denies the classification, the patient is removed from the active list of the target disease or condition, as shown in block 108, and the patient is placed on a drop list. In response to the user denying the classification, the system may additionally display or flag information about patients that contributed to including that patient on a particular list. For example, if the user denies the disease ID that John Smith has heart failure, the system may further display the query: "Mr. Smith may have CHF due to: elevated BNP, shortness of breath, hospital admission due to decompensation CHF6/9. Are you sure?" Do you need to remove this patient from the active CHF list?" The user needs to respond to this query with yes and no. The system may additionally request a rationale from the user for intending to remove the patient from the active list. Rationales provided by users may be stored and displayed as reviewer comments. The user can also indicate uncertainty, and as shown at block 109, the patient is removed from the active list and placed on a watch list for further evaluation. The user may then review and evaluate additional patients on the same target disease list or review patients included on other disease and condition lists. At any point, the user can print, transmit, and otherwise use the displayed information in some form, such as generating standard or custom reports.

As an example, patient Kit Yong Chen was identified as a CHF patient on admission. After receiving more data from her hospital stay (ie, new lab results and new physician notes), the system has identified the patient as having an AMI.

Clinician's notes on admission state: 52yo female w pmh with CAD, also presenting with HTN for one month with progressively worsening SOB and edema. 1. Dyspnea: possible CHF with increased BNP afterload reduction with aCEi and furosemide with furosemide. O2 stats stable 2) Elevated troponin: EKG with strain mode follows serial enzymes to ROMI and consults cards for possible cathepsins. Thereafter, clinician's notes state: 52yo female with pmh CAD, also presenting with HTN with progressive SOB and edema for one month c CAD with LHC with stent prox LAD.1. Elevated troponin - NSTEMI despite pt denying CP - pt hx with known CAD, mild troponin leak 0.13 -> 0.15 -> 0.09 -> 0.1 - admitted pt 325, Plavix load 300 mg 1 , and heparin gtt-Metop increased 50mg q6, in the future may change Coreg-LHC to adopt PCI according to cardiology today. EP is also discussed for possible ICD placement2. Heart failure, acute on chronic - Severe diastolic dysfunction due to HTN discontinuation +/- CAD - proBNP increase on admission 3183 - Initially started furosemide 40 tid, edema greatly improved, now furosemide 40 po bid - TTE completed showing: 4-chamber dilation, RVH, nml LV thickness, severe depression LVEF, LVEF 30%, moderate MR, mild TR, AR and PR; severe diastolic dysfunction, RVSP 52-continue furosemide, lisinopril , Metop – discuss AICD evaluation with EP and initial medical management.

A reviewer may evaluate the admission note with the CHF disease ID compared to the second note with the PIECES disease ID for AMI in an effort to validate the new real-time disease identification. Admission notes indicated CHF as the major disease. Key prominent terms that indicate CHF to the user include "pmh of CAD" (past medical history of coronary artery disease), "SOB" (shortness of breath), "edema", "elevated BNP". The second note indicates to the user that although the patient Have CHF, but CAD is the main cause of CHF. Key prominent terms (such as, "elevated troponin" and "NSTEMI (non-ST segment myocardial infarction: heart attack)") give the user a system for identifying AMI A snapshot view of the key terms for major diseases. These highlighted key terms give the user a tool for verifying changes to the system for disease identification in real time or near real time. The user then confirms, denies, or expresses uncertainty with the new disease identification .In this example, the reviewer will evaluate the notes with highlighted terms and validate the change by accepting the change in the disease identification. Since the patient's primary intervention pathway will be for AMI, the patient, identified disease, and risk level will appear in the list of AMIs.

The dashboard user interface may also indicate changes in risk levels. For example, upon return of lab results (mildly elevated creatinine and positive tox screen for cocaine) and other social factors affecting risk (nonadherence to intake restrictions due to homelessness) and care pathway language cohorts, the system The patient can be identified as high risk. Users can follow these changes in real time and verify changes in risk levels.

FIG. 8 is an exemplary screenshot 120 of a dashboard user interface system and method according to the present disclosure. The exemplary screen 120 displays a plurality of patients identified as being at risk of readmission to a healthcare facility due to congestive heart failure. An exemplary screen displays a list of active congestive heart failures. On the left hand side of the screen are target diseases and surveillance conditions that the user can select for review and assessment. Target diseases are those for which a patient has been assessed and could place the patient at risk of readmission to a health care facility. Registration and monitoring conditions are those conditions that may be the result of adverse events occurring in the health care facility. Due to the space available to illustrate exemplary screens, only a selection of diseases and conditions are shown, and it should be understood that the systems and methods are capable of evaluating and analyzing patient data for any number of diseases and conditions of interest. The dashboard user interface system is operable to organize and display patients belonging to multiple lists: active list (identified disease or condition), watch list (indeterminate), and abandonment list (denied). Users can click on any tab to view and print any list. Displays a number of data items associated with each patient in the list, such as admission or arrival date, patient name, identified target disease or condition, status (enrolled in centralized intervention programming), whether identified Risk of illness, and readmission (expressed, eg, as high, medium, and low). The type of data displayed for each patient list may vary. It should be noted that other types of data associated with each patient on the list may be displayed such as each patient's bed number and medical record number (MRN) for transmission and otherwise used to identify the patient. The exemplary screen 120 may also display the user's name and title (Physician, Case Manager, RN, Nurse Practitioner, etc.) at the top of the screen. The number and sum of patients at risk of heart failure today, this week, and last week have been selected using low, medium, and high risk statistics are tabulated and further displayed on an exemplary screen.

The user can click on a particular patient displayed in the list and obtain additional detailed information about that patient. For example, an excerpt of the clinician's notes (the patient's assessment and plan) is displayed near the bottom of the screen, and keywords and phrases are highlighted or otherwise emphasized to indicate that the identified target disease list includes the patient, condition, risk grades, and suitability grades in particular contributed to those texts. The user can scroll through all of the excerpted clinician notes associated with the patient, organized chronologically so that the user can review the disease's progression, diagnosis, assessment, and pathway. As the user views these notes in real time or near real time, he or she is able to clinically verify the system's assessment of the unstructured text. The display further provides the viewer with comments associated with the confirmation or denial of the disease or condition identification.

Additional features are not explicitly shown in FIG. 8, such as a search field to enable the user to enter one or more search criteria to find one or more specific patients. For example, a user may enter a medical record number, name, admission date, disease type, risk level, event, enrolled procedure, etc. to identify a group of patients meeting the search criteria. Search criteria may be based on other types of criteria, such as those patients who missed their post-discharge appointments.

9 and 10 are exemplary screenshots 122 and 124, respectively, of the dashboard user interface system and method illustrating abandoning a comment window and viewing a comment window. If the user clicks "No" to indicate that a particular patient should not be on the disease list, a Reason for Waiver window pops up to enable the user to select the clinical and non-clinical conditions that support the decision to deny classification of the patient on the AMI list. The user may further input a reason not already displayed. Similarly, as an example as shown in FIG. 10, a user may enter a reason expressing uncertainty about including a particular patient on the pneumonia list.

The display can optionally further include suggestions and reminders generated by the system. These recommendations and reminders may suggest evidence-based intervention options that will provide the patient with the greatest health benefit. Proposed interventions may take into account both clinical and non-clinical patient variables. In addition, previous patient registration results were factored into suggested interventions. Orders for post-discharge care, eg, nutrition, medication, etc., may be placed automatically when the patient is enrolled in the program.

The system described herein is operable to harness, simplify, select, and present patient information, predict and identify patients at highest risk, identify adverse events, coordinate and alert practitioners, and Patient outcomes are monitored spatially. The system improves care efficiency, aids in resource allocation, and presents vital information leading to better patient outcomes.

What is believed to be novel in the invention is set forth hereinafter with particularity in the appended claims. However, modifications, alterations, and changes to the exemplary embodiments described above will be apparent to those skilled in the art, and the systems and methods described herein incorporate these modifications, alterations, and changes and are not limited to the specific implementations described herein. example.

Claims (22)

1. A dashboard user interface method comprising: display a navigable list of at least one target disease; displaying a navigable list of patient identifiers associated with a target disease selected in said list of target diseases; Displays historical and current data associated with patients in the patient list identified as associated with the selected target disease, including clinician notes at the time of admission; receive, store, and display reviewer comments; and Displays automatically generated intervention and treatment recommendations. 2. The dashboard user interface method of claim 1, wherein displaying historical and current data further comprises displaying clinician notes in real time or near real time. 3. The dashboard user interface method of claim 1, wherein displaying historical and current data further comprises displaying clinician notes during the hospital stay. 4. The dashboard user interface method of claim 1, wherein displaying a patient identifier comprises displaying a patient name and a medical record number. 5. The dashboard user interface method of claim 1, further comprising displaying a navigable list of information associated with the patient, the information including patient name, admission date, identified target disease, risk Level, and whether to confirm the disease logo. 6. The dashboard user interface method of claim 1, further comprising displaying a query to the reviewer requesting confirmation or denial of the disease identification. 7. The dashboard user interface method of claim 1, wherein displaying the clinician notes comprises displaying the clinician notes with emphasized keywords that contribute to disease identification. 8. The dashboard user interface method of claim 1 , wherein displaying a navigable list of patients associated with at least one target disease comprises displaying patients with patient data, wherein the patients are analyzed by a risk logic module data, the risk logic module being operable to apply a predictive model to the patient data to determine at least one risk score associated with at least one of the target diseases and to identify at least one high-risk patient for the at least one of the target diseases, The predictive model includes a plurality of weighted risk variables and risk thresholds that consider clinical and non-clinical data to identify at least one high-risk patient associated with at least one of the target diseases. 9. The dashboard user interface method of claim 1, further comprising generating and transmitting information in the form of at least one selected from the group consisting of: reports, graphical data, text messages, multimedia messages, instant messages, voice messages, email messages, web pages, web-based messages, multiple web pages, web-based messages, and text documents. 10. The dashboard user interface method of claim 1, further comprising generating and transmitting notifications and information to at least one mobile device. 11. The dashboard user interface method of claim 1 , further comprising displaying a navigable list of at least one condition associated with the adverse event, and displaying a navigable list of patient identifiers associated with the at least one condition. Navigation list. 12. The dashboard user interface method of claim 1, further comprising displaying at least one of an active list, a waiver list, a watch list, and a discharge list associated with the target disease. 13. A dashboard user interface method comprising: display a navigable list of at least one target disease; displaying a navigable list of at least one condition associated with the adverse event; displaying a navigable list of patient identifiers associated with a target disease selected in the target disease list; displaying data associated with patients in the list of patients identified as being associated with the selected target disease, including clinical notes with prominent text contributing to the association with the selected target disease; and Reviewer comments are received, stored, and displayed, including rationale for confirming, denying, or expressing uncertainty about associations with selected target diseases. 14. The dashboard user interface method of claim 13, further comprising displaying clinician notes in real time or near real time. 15. The dashboard user interface method of claim 13, further comprising displaying historical and current clinician notes during the hospital stay. 16. The dashboard user interface method of claim 13, wherein displaying a patient identifier includes displaying a patient name. 17. The dashboard user interface method of claim 13, further comprising displaying a navigable list of information associated with the patient, the information including patient name, admission date, identified target disease, risk Level, and whether to confirm the disease logo. 18. The dashboard user interface method of claim 13, further comprising displaying to the reviewer a query requesting confirmation or denial of the disease classification. 19. The dashboard user interface method of claim 13, wherein displaying the clinician notes comprises displaying the clinician notes with emphasized keywords that contribute to the disease classification. 20. The dashboard user interface method of claim 13 , wherein displaying a navigable list of patients associated with at least one target disease comprises displaying patients with patient data, wherein the patient data is analyzed by a risk logic module, The risk logic module is operable to apply a predictive model to the patient data to determine at least one risk score associated with at least one of the target diseases and to identify at least one high-risk patient for the at least one of the target diseases, the predicted The model includes a plurality of weighted risk variables and risk thresholds that consider clinical and non-clinical data to identify at least one high-risk patient associated with at least one of the target diseases. 21. The dashboard user interface method of claim 13, further comprising generating and transmitting information in the form of at least one selected from the group consisting of: reports, graphical data, text messages, multimedia messages, instant messages, voice messages, email messages, web-pages, web-based messages, multiple web pages, web-based messages, and text documents. 22. The dashboard user interface method of claim 13, further comprising generating and transmitting notifications and information to at least one mobile device.