COMMUNICATION OF INFORMATION

CROSS-REFERENCE TO RELATED APPLICATION This application claims the benefit of U.S. Provisional Application No.

61/636,957 filed April 23, 2012.

FIELD OF THE INVENTION

The invention relates generally to an improved system and methods through which users may send and receive information. BACKGROUND OF THE INVENTION

Consumers often wish to obtain information about specific topics. However, especially when a consumer is not an expert in that topic, there may be challenges associated with obtaining relevant information about a topic and understanding the relevance of the information in the context of the consumer's situation. Accordingly, a consumer sometimes requests specific or personalized information from an information provider. For purposes of this application, an "information provider" means a topic expert, a person with some training related to a topic, a person with personal experience related to a topic, an information research specialist, a published source, or a program configured to provide information based on specific set of circumstances. Examples of a topic expert include a health care provider, professor, researcher, scientist, engineer, practitioner, or specialist.

Occasionally, an information request is time sensitive. For example, if a first responder has a question about a chemical spill in a certain environment, obtaining information about how to safely and efficiently neutralize the chemical within the context of the environment may be time sensitive in that a faster response may result in less harm done to the environment. In another example, if a patient has a question about a medical symptom or condition, such symptom or condition may require a time-sensitive response in that a faster response may result in a better health outcome. In yet another example, if a structure is on fire, contacting volunteer firefighters is time-sensitive in that a faster response likely means that the fire will cause less damage to the structure. For purposes of this application, the term "urgent event" will be used to describe any occurrence - e.g., chemical spill, medical symptom or condition, or fire - that will require or may require a time-sensitive response.

Certain communication systems have been developed to permit quickly sending a personalized request for information to an information provider. For example, a device such as a pager, telephone, cellular telephone, or electronic mail (email) may be used to send an information request. However, such devices are associated with a number of limitations. For example, when using a certain devices, the sender does not know whether the recipient has received the request. To address this problem, certain improvements have been made to some of the devices that permit the requester to see whether the device has received the request. Still, even if the device is capable of indicating when the recipient's device has received the request, the request may be sitting in the recipient's electronic mail inbox, cellular telephone text message inbox, cellular telephone voicemail, telephone answering machine storage, or other device storage without the recipient actually viewing it or responding to it.

Also, even after the recipient has reviewed the alert provided by the device, the first information provider often must find and access an information supplier to obtain context information about the request. Such information supplier may include, e.g., a patient's chart or medical history in the patient-health care provider example, a chemical information resource such as a Material Safety Data Sheet (MSDS) in the chemical spill example, or other published or non-published information source. The finding and accessing of an information supplier often takes valuable time, thus delaying the response time for a time-sensitive request.

Another limitation of certain known communication systems is that such systems often require free-form entry of information between the requester and the provider. For example, if a requester sends an email message or pager message to the information provider, the requester typically types out the entire request in a blank field. However, since, in many cases, the requester is not the expert, the requester may not know the full scope of information a provider needs to provide a timely response to the request. In the chemical spill example, a provider may need to know, not only what chemical was spilled, but also how much of the chemical was spilled, when the chemical was spilled, the cause of the chemical spill, what resources are available to address the chemical spill, and the ambient conditions of the environment in which the chemical was spilled. In such situations, the requester may send a first message in which a set of incomplete information is sent, then the provider may prepare and send a first response message in which the provider asks for more details regarding the event, and then the requester must prepare and send a second message to the provider. When the provider asks a series of questions, valuable time may be wasted before a response can be provided.

In other situations, the speed of the response is not critical, but just advising whether and when an information provider has accessed or reviewed the information is valuable. For example, if a consumer has a question about how to use a product, that consumer may send a request to a customer service associate for the product maker. The consumer may be satisfied to know that their request is under review and is not merely waiting in line for review.

More specifically with reference to the example in which the requester is requesting medical advice, systems and methods for facilitating communication between a health care provider and a patient have been developed. However, such systems and methods are associated with certain limitations.

For example, when there is a question for a health care professional, the patient, or a caregiver of the patient - e.g., parent, child, friend, professional caregiver, etc. - may call the office of the health care professional. If the health care professional is in an appointment with another patient or otherwise unavailable, the health care professional may not be able to come to the phone. As an alternative, the patient or the caregiver may call an emergency phone number, such as 9-1-1. In an actual medical emergency, an emergency operator will likely be able to respond with only generalized emergency guidance, but the emergency operator likely cannot provide personalized guidance regarding the patient because such operator typically has very little information about the patient's health history. In other circumstances, the patient or caregiver may choose not to use an emergency line if they do not realize that the patient's situation is an emergency or the patient's situation may be time-sensitive without being an actual emergency, and, accordingly, will not speak with any health care provider.

If the health care provider is not available, the patient may leave a recorded message for the health care provider to obtain at a later time or may leave a message with a receptionist. When a receptionist gives the message to the health care provider, certain details may be unintentionally altered or omitted, and the health care provider may not receive the entire message. Another option that a patient has for contacting the health care provider is preparing and sending an email. However, certain providers do not permit email communication with a patient because failure to respond promptly to an email communication may increase the health care provider's risk of legal liability for malpractice. In addition, regular email may not be a secure format for transmitting information and accordingly, personal health information sent via email is not protected in accordance with certain patient privacy standards.

Yet another known method for communication between patients and health care providers is talking in-person during an appointment. However, there are challenges associated with health care provider-patient communication at in-person appointments as well. For example, because health care providers are often pressured to keep appointments short to meet a certain quota of patients in a day, the health care provider may not have as much time as the patient wishes to discuss the patient's health. One source reports that, in an average appointment, a patient spends 18 minutes with a doctor, which may not be enough time for the patient to express all of his or her concerns. As another example, patients sometimes have a bias for reporting only symptoms which they are currently experiencing, rather than a comprehensive summary of what is going on with a patient over time.

Clearly, there is a demand for an improved system and methods for communication of information that facilitates sending a set of information that forms a request to an information provider, facilitates tracking the status of such request, and facilitates the information provider quickly providing a response to the requester. The present invention satisfies this demand. SUMMARY OF THE INVENTION

The present invention is directed to a system and methods for facilitating transfer of communication of information between a requester and an information provider. For purposes of this application, the term "user" describes a requester and/or an information provider with access to the system or conducting the methods of the present invention.

Certain embodiments of the present invention include a requester component and a provider component. A requester interface is configured to permit a requester to enter request information and send that request information to an information provider. A requester interface includes one or more requester fields configured to permit entry of information. In certain embodiments, each requester field is a type-in field associated with a prompt or a question. A requester field also may permit a user to enter information using a pull-down menu, a click-on menu, a check-box, browse and download a file, or other information entry format known in the art. In certain embodiments, the requester and the provider work together to choose which of the one or more fields are displayed in the requester interface.

In other embodiments, the requester chooses some topic or category of a request, and accordingly, one or more requester fields associated with the topic or category are displayed. The category may be submitted, for example, using one or more category prompts or category questions posed to the requester via the requester component. For example, if the requester wishes to track information about a health symptom or health event, the requester may first identify the symptom or health event. Then, based on the identification of which symptom or event, the system will illustrate one or more requester symptom fields or requester event fields. The requester also may enter identifying information in one or more identifying information fields.

Examples of symptoms include pain, cramps, swelling, soreness, inflammation, numbness, tingling, itching, rash, bleeding, lump, post-nasal drip, cough, vomiting, diarrhea, anemia, motivation, anxiety, depression, insomnia, fatigue, manic symptoms, panic attacks, unexplained sweating, appetite loss, black outs, bruises, blood glucose level, blood oxygen level, systolic blood pressure, diastolic blood pressure, fever, heartburn, toothache, cravings, contractions or other labor and delivery symptoms, cognitive delay, speech delay, obsessive compulsive actions, nightmares, fears, suicide triggers, hallucinations, vision changes, hearing changes, changes in gait, memory loss, incontinence, meeting or failing to meet developmental milestones, and any other condition of the patient's body.

Examples of a health event include eating food (e.g., in line with a diet), exercise, drinking liquids, sleeping, taking prescription medication, non-prescription medication, or illegal drugs, screen time (e.g., computer, smartphone, television, etc.), activities of daily living (ADL) including personal care events (e.g., brushing teeth, bathing, washing hair, getting dressed), getting into or out of a bed or chair, and using the toilet, instrumental activities of daily living (IADL) including activities related to independent living such as preparing meals, managing money, shopping, doing housework, and using a telephone, exercising, drinking alcohol, smoking, violent behavior, sexual intercourse, working at a job, volunteering, attending a therapy session, or other event that the patient or the provider wishes to track.

Examples of identifying information include name, gender, age, location, marital status, and other information about the patient.

In certain embodiments, a requester enters request information into one or more fields. The sum of content entered into the fields forms a "request statement". The request statement is sent to the provider. In certain embodiments, the request statement includes an express request - e.g., "Is this symptom life threatening?" or "How do I manage this symptom?". In other embodiments, the request statement includes only an implicit request that the provider review the information and possibly provide feedback if necessary or at a later date.

In some embodiments, the transmission of the request statement is made via a secure channel sufficient to meet requirements of patient privacy regulations. Securing measures may include account password protection, server password protection, password protection of other units, encrypted email authentication, encrypted email messages, digital signature on emails, use of POP, IMAP, or a proprietary exchange server rather than webmail, prohibiting access from unsecured networks, firewall, selective archiving, virus, malware, phis, spam and protection, or other security measures known in the art. In other embodiments, the transmission is made over minimally secure channels or non-secure channels.

Subsequently, the request statement may be received by the provider component. Upon receipt of the request statement in the provider component and/or upon opening of the request statement by a provider, a notification may be sent to the requester identifying such occurrence. For example, the system may detect when the provider component has received or opened the statement and automatically send the notification. In other embodiments, the system displays a notice that asks the provider whether they wish to send a notification stating that the statement has been viewed. In still other embodiments, upon detecting that the provider is building a response, the system may prepare and send a notification to the requester component updating the status of the response, e.g., "in transit to the provider component", "received by the provider component", "opened in the provider component", "not opened in the provider component", "stored in a provider storage component", "response building in progress", "or response transmitted". In certain embodiments, each notification regarding status of the request statement is sent as a discrete message, while in other embodiments, the status of the request statement is displayed a status indicator associated with the statement.

In certain embodiments, the request statement is made available to the provider only for a certain time limit. After the time limit has passed, the request statement is automatically deleted from the provider's component. An advantage of such embodiments is that, if requester does not receive a notification regarding the provider component receiving or opening the request statement after the time limit, the requester may automatically or manually resend the request statement to the first provider or send the request statement to a second provider after the time limit. Another advantage of such embodiments is that the requester may update the request statement each time it is sent or resent such that a provider is not receiving minutes-old, hours-old, or day-old information.

In other embodiments, the request statement is not deleted until the provider takes action with respect to the statement.

Other embodiments are configured for the provider to review request statement(s) only from time to time, rather than as soon as possible after receipt. Such embodiments may be configured such that the provider only reviews the request statement immediately before a meeting or appointment with a requester. In such embodiments, the system may be configurable to generate a graphical representation of one or more items from the request statement(s) received over a time period such that the provider can more quickly identify trends or summary of the request information.

Certain embodiments of the present invention include a statement labeling feature configured to label statements that are likely to be high priority, high risk, time sensitive, average priority, average risk, low priority, low risk, or non-time sensitive. Such labels may be provided based on the actual request information (e.g., a patient uses the term "suicide" or "violent" in the request information for high risk, patient rates pain at or above level 8 on scale of 1 to 10 for high risk), the requester identity (e.g., certain requester is always high risk, average risk, or low risk), or other classifications specified by the provider.

After a provider does receive the request statement, a provider may store the request statement or the request information in a provider storage element. A provider storage element may include a database, index, catalog, spreadsheet, or other analog or digital storage tool. In certain embodiments, the request statement is configured to permit automatic, one-step, or otherwise easy integration of the request information into the provider storage element. For example, if a provider is a health care provider, the request statement may be configured to be integrated, for example, automatically or upon a single approval step into a patient's electronic medical records. Advantageously, in certain embodiments, a health care professional does not need to reformat, re-enter, or convert the incoming request information before integrating the information into the electronic medical records.

In certain embodiments, the provider responds to an information request using a provider interface. The provider interface may include one or more provider fields configured to permit entry of information. In certain embodiments, each provider field is a type-in field associated with a prompt or a response. A provider field also may permit a user to enter information using a pull-down menu, a click-on menu, a checkbox, browse and download a file, or other information entry format known in the art. A provider field also may permit a provider to select, extract, and transmit certain information from the provider storage element to the requester. An advantage of such embodiments is that the provider can easily build a response and, accordingly, more quickly transmit the response to the requester. In certain embodiments, the requester and the provider work together to choose which of the one or more provider fields are displayed in the provider interface.

The collective information entered into the provider fields forms the response statement transmitted to the requester.

Upon receipt of the response statement in the requester component and/or upon opening of the response statement by a requester, a notification may be sent to the provider identifying such occurrence. For example, the system may detect when the requester component has received or opened the statement and automatically send the notification. In other embodiments, the system displays a notice that asks the requester whether they wish to send a notification stating that the statement has been viewed.

In certain embodiments, each notification regarding status of the response statement is sent as a discrete message, while in other embodiments, the status of the response statement is displayed a status indicator associated with the statement.

In the health care model, patients are spending more time and making more effort to become better educated about medical issues and more actively participate in their own medical care. Patients can now easily search the Internet to obtain information about what their symptoms might indicate and what treatment options are available. From a health care provider's perspective, this change can present many challenges because, although there are advantages to clients being invested in and educated about their healthcare, information obtained through the Internet may be inaccurate or incomplete. Therefore, it remains important that patients consult with providers, and that providers respect their client's interest in actively participating in plans to enhance their health and wellness.

To address this trend, medical professionals favor using a "patient centered care" model. This model has fueled other trends, including new emphases in accreditation standards. For example, the "Patient-centered Medical Home" movement is rapidly gaining popularity for accreditation in health care. This model emphasizes increasing the ways by which clients can work in conjunction with their providers to set goals, define and evaluate symptoms, and direct their care.

Currently, there is a gap between client care records, e.g., symptom documentation, and providers' charting systems. Today, most providers have some type of electronic medical records or electronic health records (EHR), which are not compatible with various clients' application charts that clients may wish to share with their providers. Many facilities elect not to scan in paper documents whenever possible.

Certain embodiments are configured to resolve this problem by providing a system accessible by patients and providers in which information can flow from patient to provider and provider to patient more easily. However, in certain embodiments, the health care provider may selectively approve which information is actually integrated into the patient's records and which information is directly accessible to or transmitted to the patient for viewing. In other embodiments, the patient controls what information is made available to other users or the patient and provider have joint control.

An advantage of certain embodiments of the present invention is that choosing one or more information fields in the respective statements permits the user to convey selected information tailored to the topic about which the user wishes to gain more information.

Another advantage of certain embodiments of the present invention is that choosing one or more information fields in the respective statements decreases the likelihood that the information provider will need to clarify the information request, and therefore, will likely able to respond more quickly to the request.

Another advantage of certain embodiments of the present invention is that choosing one or more information fields in the respective statements increases the likelihood that the requester and provider will be engaged in the communication process. In other words, embodiments of the invention facilitate involvement of clients in promoting their own health by fostering their persistent active participation in their own care, and by having information they provide acknowledged, captured, and considered by their healthcare professionals. The medical community now recognizes that clients are more likely to make decisions that positively impact their health when they play an active role in health care decisions, e.g., deciding which behavior changes they are willing to make. Clients having a greater sense of control typically exhibit greater compliance in choosing, adopting, and maintaining healthy lifestyle choices.

Another advantage of certain embodiments of the present invention is that the user may record information about a topic over time.

Another advantage of certain embodiments of the present invention is that a provider may review information from the requester over time, rather than only at meetings or appointments.

Another advantage of certain embodiments of the present invention is that graphical representations may be generated to easily assess requester information.

Another advantage of certain embodiments of the present invention is that easily extracting response information from the provider storage element eliminates the necessity for the provider to reformat, re-enter, or convert the outgoing response information before transmitting the information.

Another advantage of certain embodiments of the present invention is that automatically incorporating request information into the provider storage element eliminates the necessity for the provider to reformat, re-enter, or convert the incoming request information before integrating the information.

An additional advantage of certain embodiments of the present invention is that updating the status of the request statement and/or response statement may decrease certain legal liability for the provider. An additional advantage of certain embodiments of the present invention is that the exchange of information is subject to security measures in line with certain relevant privacy regulations.

An additional advantage of certain embodiments of the present invention is that a health care provider may receive more complete patient symptoms and behavior information before an appointment, and accordingly, make a more accurate diagnosis.

An additional advantage of certain embodiments of the present invention is that a health care provider may receive more complete patient symptoms and behavior information before an appointment, and accordingly, may spend more time during the appointment explaining treatment options, education, and motivational interviewing.

An additional advantage of certain embodiments of the present invention is that a health care provider may receive more complete patient symptoms and behavior information before an appointment, and accordingly, may conduct the appointment in a shorter period of time.

An additional advantage of certain embodiments of the present invention is that by receiving periodic updates more often than just at appointments, a health care provider may identify an illness, symptom, or condition sooner, and earlier treatment may provide a better health outcome for the patient.

An additional advantage of certain embodiments of the present invention is that by receiving periodic updates more often than just at appointments, a health care provider may identify risk factors for an illness, symptom, or condition sooner and may be able to recommend prevention steps. Prevention starts with education and subsequent lifestyle changes. Information about healthy habits and healthy choices are more widely known now than in the past. Most people know how to prevent hypertension or heart disease, or can be given more information by their healthcare providers about these preventative measures, as well as other health conditions, including obscure conditions.

The present invention and its attributes and advantages may be further understood and appreciated with reference to the detailed description below of contemplated embodiments, taken in conjunction with the accompanying drawing. DESCRIPTION OF THE DRAWING

The preferred embodiments of the invention will be described in conjunction with the appended drawings provided to illustrate and not to the limit the invention, where like designations denote like elements, and in which:

FIG. 1 A illustrates an embodiment of a system of the present invention;

FIG. 1 B illustrates an embodiment of a system of the present invention;

FIG. 2 includes a flow chart showing time-sensitive, secure transmission of select information from requester to provider;

FIG. 3A illustrates a requester interface element of certain embodiments of the present invention;

FIG. 3B illustrates a requester interface element of certain embodiments of the present invention;

FIG. 4A illustrates an embodiment of a user interface of the present invention; FIG. 4B illustrates an embodiment of a user interface of the present invention; FIG. 4C illustrates an embodiment of a user interface of the present invention; FIG. 4D illustrates an embodiment of a user interface of the present invention; FIG. 4E illustrates an embodiment of a user interface of the present invention; FIG. 4F illustrates an embodiment of a user interface of the present invention; FIG. 4G illustrates an embodiment of a user interface of the present invention; FIG. 4H illustrates an embodiment of a user interface of the present invention; FIG. 4J illustrates an embodiment of a user interface of the present invention; FIG. 4K illustrates an embodiment of a user interface of the present invention; FIG. 4L illustrates an embodiment of a user interface of the present invention; FIG. 4M illustrates an embodiment of a user interface of the present invention; FIG. 4N illustrates an embodiment of a user interface of the present invention; FIG. 4P illustrates an embodiment of a user interface of the present invention; FIG. 4Q illustrates an embodiment of a user interface of the present invention; FIG. 4R illustrates an embodiment of a user interface of the present invention; FIG. 4S illustrates an embodiment of a user interface of the present invention; FIG. 4T illustrates an embodiment of a user interface of the present invention; FIG. 4U illustrates an embodiment of a user interface of the present invention; FIG. 4V illustrates an embodiment of a user interface of the present invention; FIG. 4W illustrates an embodiment of a user interface of the present invention; FIG. 4Z illustrates an embodiment of a user interface of the present invention; FIG. 4Y illustrates an embodiment of a user interface of the present invention; FIG. 4Z illustrates an embodiment of a user interface of the present invention; FIG. 4AA illustrates an embodiment of a user interface of the present invention;

FIG. 4BB illustrates an embodiment of a user interface of the present invention;

FIG. 5A illustrates an embodiment of a graphical representation of request information;

FIG. 5B illustrates an embodiment of a graphical representation of request information;

FIG. 5C illustrates an embodiment of a graphical representation of request information;

FIG. 5D illustrates an embodiment of a graphical representation of request information;

FIG. 5E illustrates an embodiment of a graphical representation of request information;

FIG. 5F illustrates an embodiment of a graphical representation of request information;

FIG. 5G illustrates an embodiment of a graphical representation of request information;

FIG. 5H illustrates an embodiment of a graphical representation of request information;

FIG. 5J illustrates an embodiment of a graphical representation of request information;

FIG. 6 illustrates an exemplary computer of certain embodiments of the present invention;

FIG. 7 illustrates an exemplary cloud computing system of certain embodiments of the present invention; and

FIG. 8 illustrates a method embodiment of certain embodiments of the present invention. 2

DETAILED DESCRIPTION OF THE INVENTION

For purposes of this application, the present invention is discussed in reference to an embodiment configured for the health care setting, but the discussion is merely exemplary. The present invention is applicable to any information request from a requester and response from an information provider.

As illustrated in FIG. 1A, certain embodiments of the present invention include system 100 having a requester component 102 and a provider component 104. As illustrated in FIG. 1 B, the requester component 102 may include a requester interface component 102A and/or a requester storage element 102B. The provider component 104 may include a provider interface component 104A and/or a provider storage element 104B. The system 100 may be subject to certain security measures 120.

A requester interface 102A is configured to permit a requester 50 to enter request information and send that request information to an information provider 60. As illustrated at least in FIG. 2, the requester interface element 102A may be used to send information from the requester storage element 102A to the provider storage element 104B and accessible by the provider via the provider interface element 104A.

A requester interface 102A includes one or more requester fields 103 configured to permit entry of information. In certain embodiments, each requester field 103 is a type-in field associated with a prompt or a question 107. A requester field 103 also may permit a user to enter information using a pull-down menu, a click- on menu, a check-box, browse and download a file, or other information entry format known in the art. In certain embodiments, the requester 50 and the provider 60 may work together to choose which of the one or more fields 103 are displayed in the requester interface 102.

In other embodiments, the requester chooses some topic or category 106 of a request, and accordingly, one or more requester fields 103 associated with the topic or category 106 are displayed. The category 106 may be submitted, for example, using one or more category prompts or category questions posed to the requester via the requester component 102. For example, if the requester wishes to track information about a health symptom or health event, the requester may first identify the symptom or health event. Then, based on the identification of which symptom or event, the system will illustrate one or more requester symptom fields 103A or U 2013/037752 requester event fields 103B. The requester also may enter identifying information in one or more identifying information fields 103C.

Certain embodiments include a reminder function configured to display a reminder element 140 for the client to take some medication, record some symptom or condition, or perform some other activity as part of the patient's health improvement process.

In certain embodiments, the provider responds to an information request using a provider interface 104A. The provider interface 104A may include one or more provider fields 105 configured to permit entry of information. In certain embodiments, each provider field 105 is a type-in field associated with a prompt or a response. A provider field 105 also may permit a user to enter information using a pull-down menu, a click-on menu, a check-box, browse and download a file, or other information entry format known in the art. A provider field 105 also may permit a provider to select, extract, and transmit certain information from the provider storage element 104B to the requester. An advantage of such embodiments is that the provider can easily build a response and, accordingly, more quickly transmit the response to the requester.

In certain embodiments, the requester and the provider work together to choose which of the one or more provider fields 105 are displayed in the provider interface 104. The system may be customized to the needs or health concerns of each patient. The system may allow patients to choose any behavior, symptom, or side effect of concern to them. For example, a patient could keep records on goals established with a therapist, e.g., regarding how the client is managing fear surrounding interpersonal interactions, or the skills used on a particular day e.g., time spent meditating. Clients may have the option of entering free-form notes about any day's events or acute illnesses that may impact mood, behaviors, or symptoms. As additional examples, a patient also may chart depressive symptoms, isolation, sleep patterns, and side effects to a medication, e.g. , Prozac, after working with a psychiatrist to determine appropriate or relevant scales to monitor. Similarly, a patient who, in consultation with the primary care physician decides to cut back on tobacco use, could develop with a physician a scale for cravings to smoke, triggers to smoke, and number of cigarettes smoked in a day. A client may begin experiencing foot pain when running and begin documenting the severity, location, and nature of the pain, as well as any additional triggers, in advance of an T/US2013/037752 appointment with a podiatrist. The podiatrist would be able to review that information efficiently, with the patient's permission, at the time of the patient's visit or immediately before, providing for more time to discuss treatment. These complaints/symptoms could then be placed into the client's chart.

The fields of the user interface may be customized to maintain multiple types of information. The user may input a number, e.g., for blood pressure, temperature, number of cigarettes smoked, blood sugar result, provide a "yes" or "no" answer, e.g., "yes, I did experience negative self-thoughts today", or "no, I did not have abnormal vaginal bleeding", or provide rating data, e.g., on a scale of 1-100, e.g., My cravings to self-harm were 60% of 100% or my leg pain is 30% of 100% this afternoon. The system may permit notes in any area's rating field. For example, Pain is 50% of 100%. Note: I just used an ice pack for 1 hour to the affected area.

As illustrated in FIG. 3A, the requester interface element 102A may include a requester statement component 110 in which the incoming and/or outgoing communication statements 112, 118 may be displayed. In certain embodiments, each notification regarding status of the response statement 112 is sent as a discrete message 116A, 116B, while in other embodiments, the status of the response statement is displayed a status indicator 114 associated with the statement 112.

FIG. 4A - FIG. 4H, FIG. 4J - FIG. 4N, FIG. 4P - FIG. 4Z, and FIG. 4AA - FIG. BB illustrate various embodiments of a user interface 02A, 104A.

In certain embodiments, one or more components of request information and/or response information are formatted and displayed as a graphical representation 130 as illustrated in FIG. 4Z, FIG. 4BB, and FIG. 5A - FIG. 5H and FIG. 5J. Such graphical representations may be configured to facilitate evaluating the patient's progress or decline over time. The system and methods may permit a provider to discover health-impacting behaviors that were unreported or were not accurately gauged at previous appointments. Overall, a client's self-report would help to identify behaviors that may an impact symptoms or disease. For example, a client's self-report having stayed up until 4 AM several nights would identify behavior that may explain complaints of fatigue. Such correlations would become clearer more quickly to providers evaluating these charts and could lead to positive changes in patient education and treatment that otherwise might have been missed.

It is common for clients to report, on the day of a visit, symptoms which they are currently experiencing, rather than a comprehensive summary of what is going on with a client over time. It is more likely that a patient will express what the client is feeling of that day, while being unable to accurately capture and describe what the client had been feeling over time because of a subjective bias or poor memory recall. The system of the invention may permit providers to obtain a more accurate account of how the client has been doing over time, e.g., time between appointments, and to maintain a record of that information in the patient's chart.

Additional embodiments of the system and methods of the present invention are described below.

Certain preferred embodiments of the present invention permit gathering and storing patient information in a protected database. In such embodiments, the patient is also called a "client". The client information may then be transmitted to a provider for review and potential transfer to the provider storage element. So that both the client and provider know that their respective statements were sent and received by the other party, the client and the provider would need to be sending and receiving information at the same time, or the provider would need to access the information within a predetermined period from the time the information was sent. Alternatively, transmission and receipt of the information could be verified by establishing a set time frame within which the information would remain available. Should the provider fail to access the information within that time frame, the information would no longer be available and the sender would be notified that the information was not received. This time sensitivity component benefits the client and the provider. The client benefits because the client component will display whether or not the information has been received by the provider and can take further action if he or she wishes to do so. The provider benefits because they do not store information which they have not yet reviewed or to which they have not yet responded. Both the client and the provider may register with the system to obtain a username and password.

With reference to FIG. 2, the client accesses client's stored information by entering a user name and password. The stored information may include only blank forms, blank fields, filled-out forms, filled-out fields, or other. The client then enters information into the client's database and/or accesses information already in the client's database for transmission to the provider database. The provider may access the provider database using the provider's user name and password. Once the information sent by the client is accessed by the provider, a notification (e.g., an electronic message, push notification, pop-up message, telephone call by an agent 2 of the provider, an automated voice message, or email) is sent to the client confirming that the information was received. Receipt of information by the provider may lead to further communication between the client and provider, which may be by any method (e.g., email, mail, or telephone) initiated by the provider or an agent of the provider, or by client. For example, the provider may have further questions regarding the information received, or instructions for the client regarding, for example, treatment, further testing, referral to a specialist, or follow-up care. If the provider does not access the information within the predetermined period of time, a message is sent to the client indicating that the information was not accessed by the provider. The client may then take further action, e.g., the information may be resubmitted or the provider or the client may contact the provider or provider agent, e.g., by telephone, or may contact another provider (e.g., 9-1-1 operator or an on-call doctor).

The predetermined period of time within which the provider must access the information before the information becomes unavailable and a message is sent to the client may vary according to the urgency of the information being transmitted. There may be a default setting for non-urgent information for which review within, for example, one or two business days is adequate. This default setting could be overridden by the client, for example, to request notification of the provider's failure to access the information within a shorter period of time. Alternatively, or additionally, the system may identify and flag certain types of information to require access within a relatively short period of time. The system may optionally include a warning to the client that the system should not be used to relay information of an urgent nature, especially when, for example the health care provider is unavailable. It could be an "away message".

The system and methods of the present invention are configured to promote clear and open communication and collaboration between client and provider regarding the client's care. It also creates an avenue for the client to provide feedback regarding important aspects of the client's care with direct input into the client's health record. The system could be used to promote communication and enhance care by providers in a variety of settings, including primary care, psychiatry, counseling, specialty care of any kind, physical therapy, nutrition, fitness training, and holistic medicine to facilitate health and wellness. The system and methods may be used, for example, to work on behavior change, monitor medication, monitor a T US2013/037752 disease process, and evaluate correlations between any listed symptoms or behaviors. The system and methods may be used as a motivational tool for the client and promote communication between the client and providers concerning health goals. Outputs from the system may be used as evidence by clients who feel their providers are not listening to or understanding their concerns. Further, the system and methods is configured to provide an empowering way for clients to be actively involved in their own healthcare.

Certain embodiments of the present invention include a database accessed through a user interface by which a client can document targeted symptoms routinely between visits and transfer the collected data to record to share with providers, e.g., before or between visits, or at the time of a visit with the provider.

Regarding another element of the system and methods of the present invention, the transition from analog to EHR continues, driven by Medicare and Medicaid incentive programs, accreditation incentives, the green healthcare movement, and practicality of EHR, there is a need for programs to assist this transition. These programs need to be sufficiently flexible for there to be compatible ways of adding and transmitting data securely into various EHR systems in current use.

In certain embodiments, a client's database may be password protected and encrypted to protect client privacy. The client could decide with whom to share the information. The application could be a cloud database or web-based database so that the client could retrieve information from any device using the username and password. All sensitive data in the cloud database may be encrypted. In certain embodiments, the stored information is protected to HIPAA certified standards or in compliance with other privacy regulations as this information may be subject to the same standards as all other medical records containing protected health information (PHI).

The system and methods could be distributed through a healthcare organization or through the vendor for an EHR with which certain embodiments of the system and methods are compatible. The EHR company could purchase the product and adapt their EHR to be compatible with the application. Tech support could be available as needed to accommodate this integration.

The system may be used in conjunction with a single alarm or various alarms reminding the client to take a prescribed medication, such as Prevacid. The client could track any relevant information, and would be prompted by the application to fill in information on the particular scales. The client would choose which information to provide. They would be able enter this information with simple clicks on a scale and notes as desired. The client may choose which information to share with the primary care physician, e.g., sharing or downloading information regarding sleep patterns, but maintaining privacy regarding how much the client has been isolating or watching pornography (things they may be tracking in their work with their psychotherapist).

As healthcare becomes increasingly integrated, the ability for a provider to see all of these various charts together will be a great benefit, allowing the provider to see the client as a whole person, with the collected data being aspects of that whole. The client may retain the right to choose what information they would like to share with any individual provider.

A clear compilation of symptoms may help the provider to identify high risk behaviors or disease states which would have otherwise gone undetected. In certain embodiments, the provider has access to these records only when the client is in the office, or when it would be possible to have contact with the client immediately should the information indicate that immediate intervention is required. An example of this would be a critical change in suicidal thoughts or homicidal thoughts, which a client may not recognize as being of particularly high risk. Another instance might be if a client has frequent and loose stools for more than 4 days and reports this, a provider would be concerned about critical dehydration, whereas a client may attribute it to ajninor illness. A delay in treatment of a life-threatening condition may result from a delay in the provider receiving this information. Yet if this information were to be sent to the provider by, for example, email, the provider may be held accountable for failing to review and act on this information.

An embodiment of the present invention may also include advice or warnings based on any preset measurements. For example, if a client inputs a high suicidal ideation report, the system may automatically generate a response which instructs the patient to go to an emergency room or asked to call their provider. In the case of the frequent loose stools, the patient could receive a reminder as soon as this begins that they should increase their fluid intake. Day 2 perhaps they receive notice that they should be adding electrolytes as well as the increased fluids and day 3 it may tell the patient that they should be contacting their provider or going to the emergency room. These warnings could be designed by expert medical providers or specialists in any one area to ensure accuracy of recommendations. There could also be custom limits discussed and decided on by patient and provider. These limits and warnings may be different than pre-programmed limits and warnings. An example would be a chronically suicidal patient who is told by their therapist that if the suicidal thoughts rise from their normal levels 6-7/10 they should call whereas someone who has never been suicidal may agree with the therapist that even a 1/10 be immediately reported. Or in the example of loose stools if the client is Diabetic or for a malnourished child the need for quicker interventions with these symptoms would need to set off an alert sooner than for a healthy adult.

The time sensitive sending/receiving element of the present invention is configured to provide a provider with access to the information for a controlled timeframe after which, if the provider has not used provider credentials to sign and receive the information, an automated message is sent to the client letting them know that the information has not been reviewed. The client may then need to seek out medical attention in another way, e.g., going to the emergency room or calling the provider's office, rather than assuming that the information was received and considered by the provider. The system could be set up to be sent to an on-call provider as needed so that any information could be sent, reviewed, and responded to quickly.

The system would allow the provider to confer with a client at a visit and decide together which symptoms, behaviors and side effects would be important to track between visits and set those up accordingly in their visit together or through the web portal. The client would then be able to add ratings/categories as any new issues might arise between appointments.

Because a patient may be seeing multiple providers with different specialties, they will be able to choose only the information relevant to the specific provider to send through the portal, while their other information remains protected in certain embodiments. This also helps to simplify the information given to any one provider for a more efficient use of clinical time.

In the EHR, the chart component could be referred to as a "client reported symptom log."

Alternately, the program could be purchased by individual groups and or providers and simply held in a system separate from the client's chart. This would be a way to work with the system if the Electronic Medical Record was not compatible, or until it becomes compatible.

This information could be presented in the EHR as graphs documenting any pertinent trends in symptoms, behaviors, or side effects, for easier single-glance interpretation. Any points on the graph could be clicked on if notes were available to describe or explain the symptom. These items with notes could appear as a different symbol or color so that they could be easily identified in the simplified graph view. The system would also allow two charts from the same time period to be superimposed using different colors, to facilitate assessment of any potential correlations that could help to determine possible causal relationships. In one example, a provider could review a chart showing the days that a client experienced headaches, superimposed with a chart of the days the client worked, which together could show the frequency of headaches as a function of work days vs. non-work days. The client and provider could then decide before the next appointment it would be important to see if these values change if client were to make changes at work, e.g., stop using a particular chemical at work, or practice relaxation exercises prior to going to work.

Certain embodiments could be set up with an in depth initial survey which could help determine what it might be most useful steps to monitor in addition to the items chosen by the provider and or the patient. This initial survey could include medical and family history, health related behaviors, potential risks in current lifestyle, etc. Once this is done the embodiment could recommend potential items to track based on information given though the survey. For example someone with a strong family history of early onset Myocardial Infarctions, the system may automatically recommend monitoring for cardiac symptoms. After this is completes the client and provider could discuss which should remain and any potential additions.

Client's goals could also be included in this initial survey. This would give patients an opportunity to share their personal goals with their providers which is something often missed in an initial assessment and something critical to understanding what a patient is motivated to engage in. This is a great opportunity to use motivational interviewing to help a client shape appropriate goals, given the provider's expertise.

The system permits both provider and client to track the client's response to medication, dose changes, or changes in disease states over time. Often, especially in psychiatry, it is difficult to determine effects to medications over time. For example, a client may report, "I am not sure if I am having fewer panic attacks." This system gives important information when tracking symptoms over time.

Time may be shown, for example, on the Y axis of the charts. The Y axis of the charts may show the date, or may represent the time of day, to provide data and allow evaluation of how events such as symptoms may change over the course of a day or days, and what daily patterns over time might be relevant to diagnosis and treatment.

When a client changes providers, the client would have the ability to take their personal history with them, although this would always need to be clear in any charting system that this is a "client kept record."

The system of the invention may be used by clients to document on a regular basis, at a frequency of their choosing (or chosen in consultation with their providers), their wellness or health related behaviors, symptoms or side effects. An alarm could be set to remind clients to complete the documentation. They would be able to choose to complete, snooze, or ignore the alarm. If the client wishes, the system could be used as a medication log and alarm clock reminder to take medications. There would be a box to check if the medication listed as "taken," a "snooze" with customizable intervals, or a "not taking" option with a space to record the reason for not taking the medication. This information could be provided in graphical form.

Before accessing the application, for example, after an alarm or when clicking on the icon, the client would need to enter username and password. This requirement insures protection of the information. Further, the information entered would be maintained in an encrypted database that is accessible from any device. Symptoms/behaviors can be chosen from a prewritten list or free texted in as needed. The way information is reported and collected could also be customized. When a visiting a provider, the client would be able to download the information the client chooses to share with the provider into the client's health record via the website on the provider's computer or from a smart phone, laptop or l-pad USB connection. The information would be reviewed with the provider who might then suggest another symptom/behavior to add to the list, or the client may discuss what was added and why or decide in the visit to add a new item for measurement.

The data selected by the client to share with the provider may be downloaded 2013/037752 by the provider into the provider record for review. The provider may choose to superimpose certain measurements to look for correlations or simply review and evaluate the information. Then provider may use clinical judgment to determine interventions as needed.

FIG. 6 illustrates an exemplary computer system 300 that may be used to implement the methods according to the invention. One or more computer systems 300 may carry out the methods presented herein as computer code.

Computer system 300 includes an input/output display interface 302 connected to communication infrastructure 304 - such as a bus -, which forwards data such as graphics, text, and information, from the communication infrastructure 304 or from a frame buffer (not shown) to other components of the computer system 300. The input/output display interface 302 may be, for example, a keyboard, touch screen, joystick, trackball, mouse, monitor, speaker, printer, any other computer peripheral device, or any combination thereof, capable of entering and/or viewing data.

Computer system 300 includes one or more processors 306, which may be a special purpose or a general-purpose digital signal processor that processes certain information. Computer system 300 also includes a main memory 308, for example random access memory ("RAM"), read-only memory ("ROM"), mass storage device, or any combination thereof. Computer system 300 may also include a secondary memory 310 such as a hard disk unit 312, a removable storage unit 314, or any combination thereof. Computer system 300 may also include a communication interface 316, for example, a modem, a network interface (such as an Ethernet card or Ethernet cable), a communication port, a PCMCIA slot and card, wired or wireless systems (such as Wi-Fi, Bluetooth, Infrared), local area networks, wide area networks, intranets, etc.

It is contemplated that the main memory 308, secondary memory 310, communication interface 316, or a combination thereof, function as a computer usable storage medium, otherwise referred to as a computer readable storage medium, to store and/or access computer software including computer instructions. For example, computer programs or other instructions may be loaded into the computer system 300 such as through a removable storage device, for example, a floppy disk, ZIP disks, magnetic tape, portable flash drive, optical disk such as a CD or DVD or Blu-ray, Micro-Electro-Mechanical Systems ("MEMS"), nanotechnological apparatus. Specifically, computer software including computer instructions may be transferred from the removable storage unit 314 or hard disc unit 312 to the secondary memory 3 0 or through the communication infrastructure 304 to the main memory 308 of the computer system 300.

Communication interface 316 allows software, instructions and data to be transferred between the computer system 300 and external devices or external networks. Software, instructions, and/or data transferred by the communication interface 316 are typically in the form of signals that may be electronic, electromagnetic, optical or other signals capable of being sent and received by the communication interface 316. Signals may be sent and received using wire or cable, fiber optics, a phone line, a cellular phone link, a Radio Frequency ("RF") link, wireless link, or other communication channels.

Computer programs, when executed, enable the computer system 300, particularly the processor 306, to implement the methods of the invention according to computer software including instructions.

The computer system 300 described herein may perform any one of, or any combination of, the steps of any of the methods presented herein. It is also contemplated that the methods according to the invention may be performed automatically, or may be invoked by some form of manual intervention.

The computer system 300 of FIG. 6 is provided only for purposes of illustration, such that the invention is not limited to this specific embodiment. It is appreciated that a person skilled in the relevant art knows how to program and implement the invention using any computer system.

The computer system 300 may be a handheld device and include any small- sized computer device including, for example, a personal digital assistant ("PDA"), smart hand-held computing device, cellular telephone, or a laptop or netbook computer, hand held console or MP3 player, tablet, or similar hand held computer device, such as an iPad ^® , iPad Touch ^® or iPhone ^® .

FIG. 7 illustrates an exemplary cloud computing system 400 that may be used to implement the methods according to the present invention. The cloud computing system 400 includes a plurality of interconnected computing environments. The cloud computing system 400 utilizes the resources from various networks as a collective virtual computer, where the services and applications can run independently from a particular computer or server configuration making hardware less important.

Specifically, the cloud computing system 400 includes at least one client computer 402. The client computer 402 may be any device through the use of which a distributed computing environment may be accessed to perform the methods disclosed herein, for example, a traditional computer, portable computer, mobile phone, personal digital assistant, tablet to name a few. The client computer 402 includes memory such as random access memory ("RAM"), read-only memory ("ROM"), mass storage device, or any combination thereof. The memory functions as a computer usable storage medium, otherwise referred to as a computer readable storage medium, to store and/or access computer software and/or instructions.

The client computer 402 also includes a communications interface, for example, a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, wired or wireless systems, etc. The communications interface allows communication through transferred signals between the client computer 402 and external devices including networks such as the Internet 404 and cloud data center 406. Communication may be implemented using wireless or wired capability such as cable, fiber optics, a phone line, a cellular phone link, radio waves or other communication channels.

The client computer 402 establishes communication with the Internet 404 - specifically to one or more servers - to, in turn, establish communication with one or more cloud data centers 406. A cloud data center 406 includes one or more networks 410a, 410b, 410c managed through a cloud management system 408. Each network 410a, 410b, 410c includes resource servers 412a, 412b, 412c, respectively. Servers 412a, 412b, 412c permit access to a collection of computing resources and components that can be invoked to instantiate a virtual machine, process, or other resource for a limited or defined duration. For example, one group of resource servers can host and serve an operating system or components thereof to deliver and instantiate a virtual machine. Another group of resource servers can accept requests to host computing cycles or processor time, to supply a defined level of processing power for a virtual machine. A further group of resource servers can host and serve applications to load on an instantiation of a virtual machine, such as an email client, a browser application, a messaging application, or other applications or software. The cloud management system 408 can comprise a dedicated or centralized server and/or other software, hardware, and network tools to communicate with one or more networks 410a, 410b, 410c, such as the Internet or other public or private network, with all sets of resource servers 412a, 412b, 412c. The cloud management system 408 may be configured to query and identify the computing resources and components managed by the set of resource servers 412a, 412b, 412c needed and available for use in the cloud data center 406. Specifically, the cloud management system 408 may be configured to identify the hardware resources and components such as type and amount of processing power, type and amount of memory, type and amount of storage, type and amount of network bandwidth and the like, of the set of resource servers 412a, 412b, 412c needed and available for use in the cloud data center 406. Likewise, the cloud management system 408 can be configured to identify the software resources and components, such as type of Operating System ("OS"), application programs, and the like, of the set of resource servers 412a, 412b, 412c needed and available for use in the cloud data center 406.

The present invention is also directed to computer products, otherwise referred to as computer program products, to provide software to the cloud computing system 400. Computer products store software on any computer useable medium, known now or in the future. Such software, when executed, may implement the methods according to certain embodiments of the invention. Examples of computer useable mediums include, but are not limited to, primary storage devices (e.g., any type of random access memory), secondary storage devices (e.g., hard drives, floppy disks, CD ROMS, ZIP disks, tapes, magnetic storage devices, optical storage devices, Micro-Electro-Mechanical Systems ("MEMS"), nanotechnological storage device, etc.), and communication mediums (e.g., wired and wireless communications networks, local area networks, wide area networks, intranets, etc.). It is to be appreciated that the embodiments described herein may be implemented using software, hardware, firmware, or combinations thereof.

The cloud computing system 400 of FIG. 7 is provided only for purposes of illustration and does not limit the invention to this specific embodiment. It is appreciated that a person skilled in the relevant art knows how to program and implement the invention using any computer system or network architecture. While the disclosure is susceptible to various modifications and alternative forms, specific exemplary embodiments of the present invention have been shown by way of example in the drawings and have been described in detail. It should be understood, however, that there is no intent to limit the disclosure to the particular embodiments disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the scope of the disclosure as defined by the appended claims.