Abstract:
Personalized heath care instructions are created, delivered and displayed. These instructions may be displayed on one or multiple devices. The devices are not specialized devices. They may be any one of the many devices readily available in the marketplace such as a smartphones, tablet computers, laptops or other computers. Better and effective communication between a caregiver and a patient improves patient care.

Description:
FIELD 
       [0001]    The present invention generally relates to health care and electronic communications. 
       BACKGROUND 
       [0002]    Most interactions between a doctor and a patient occur in the clinic or the hospital. Increasingly some communications now occur through electronic media such as computers, cell-phone etc. Increasing the interaction may increase the chances of accessing and receiving better health care. 
         [0003]    There have been recent efforts to use the smart phones and other electronic media to influence health care outcomes. The use of these devices is limited in many ways. As an example, these known methods are used to send emails, make appointments, log into a web server to check on messages from health care providers or to check on test results. Known methods also exist to facilitate obtaining data related to the health condition of the user. Some of these known methods are limited in that a dedicated device is needed to enable the acquisition of data. As an example in U.S. Pat. No. 8,015,030, such a method is described which facilitates the transfer of data related to the health condition of the patient. This patent teaches the use of dedicated devices to monitor the user health. 
         [0004]    Another example of a known method used to collect data from a patient can be found in US20110015496A1. In this publication essentially, a mobile communication device is attached to a sensor that is placed on the housing of the device. This sensor is used to collect data from the patient. There is no teaching related to personalized content generation or delivery. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWING FIGURES 
         [0005]      FIG. 1A  is a diagram of a personalized instruction generation and delivery system. 
           [0006]      FIG. 1B  is a diagram of a personalized instruction generation and deliver system showing a connection to an external computer system from which information about the patient may be obtained. 
           [0007]      FIG. 2  is an example of the different elements that may be utilized to create personalized instructions. 
           [0008]      FIG. 3  is a more detailed diagram of the method of creating and delivering personalized instructions by using the system described in  FIG. 1 . 
           [0009]      FIG. 4  is an example of what the Application Definition File may contain. 
           [0010]      FIG. 5  is a table describing states that an Application on a patient device in the system of  FIG. 1  goes through. 
           [0011]      FIG. 6  is a diagram illustrating a rules based software architecture that may be used in the system of  FIG. 1 . 
       
    
    
     DETAILED DESCRIPTION 
       [0012]    Terminology: 
         [0013]    Server Application: A software (SW) engine that resides in a server and manages various processes from for example, doctor/nurse entries to patient experience. 
         [0014]    Device Dependent Core Application or Device Application: A SW application that resides on a patient&#39;s local device which accepts inputs from the Server Application and from the patient. 
         [0015]    Application Definition file: A file that is created by the Server Application and transferred from the server to the patient&#39;s local device. Some contents within the Application Definition may be modified by the user. 
         [0016]    Application: A general term that signifies software that the user interacts with and that is created by the caregiver. 
         [0017]    Session: A period of interaction between the patient and the Device Application. 
         [0018]    User Device: The device used by the end user, in this case the patient. 
         [0019]    Most interactions between a caregiver such as a doctor and a patient occur in the clinic or the hospital. Often, these interactions occur in a very stressful environment. The instructions are easily forgotten or misunderstood. This leads to complications such as, for example, slow recovery or re-hospitalizations. This invention generally relates to providing methods and systems to assist caregivers in providing better healthcare. 
         [0020]    In this invention, in general, the caregiver creates personalized instructions which are sent via a server to a User Device in possession by the patient, such as smartphone or tablet or a computer. The instructions are displayed on the User Device. The instructions may have, for example, a combination of text, photographs, animations, movie clips, drawings, voice, etc. The patient then interacts with this device and may respond to questions displayed, or announced on the device. A complete description of the interaction between the patient and the User Device is sent to the server. A status or a report is then made available to the caregiver, who may then choose to take further action, such as, for example, sending a new set of instructions. 
         [0021]    The invention will now be described with the help of  FIG. 1A ,  1 B.  FIG. 2  and  FIG. 3 . Referring now to  FIG. 1A , a diagram is shown of a personalized instruction generation and delivery system, In a typical scenario, the patient receives instructions in one of many places such as for example, a doctor&#39;s office or a hospital or other care providing facility such as a medical clinic, an outpatient clinic a physical therapist clinic, a pharmacy or even a patient&#39;s home. In  FIG. 1A , box  10  and  20  show the step of a caregiver creating an Application and more specifically creating the personalized instructions. This same step is shown in box  310  in  FIG. 3 . The process of creating these instructions is described in  FIG. 2 . Here the caregiver may use various types of media such as for example, movie clips, animations etc, shown in box  210  to create personalized instructions. Visualizing the system described in  200  as a computer screen, the caregiver would use for example, simple drag and drop operations from the box  210  into the area  220 . In one embodiment the instructions are personalized according to information about the patient such as for example, demographics, disease state, language preference, gender, physical or mental abilities of the patient, etc. As an example of personalization, the caregiver may choose the language in which the instructions are displayed on the patient&#39;s device, while creating the instructions in English. As another example of personalization, the caregiver may choose to display text that appears on the patient&#39;s device with colors that can be read by a color blind person. 
         [0022]    one embodiment, the information about the patient may come, for example, from the patient himself or herself, or from an existing patient record or other means such as paper records or other electronic records.  FIG. 1B  shows the server  30  connected to another external computer  70 . The computer  70  may provide information about the patient such as for example, electronic medical records. 
         [0023]    In one embodiment the patient&#39;s device has an Application Definition File. This is shown in  FIG. 4 . In this figure, box  400  is the patient&#39;s device such as  40 ,  50  or  60  in  FIG. 1A and 1B . The Application Definition File  405  is stored in the device  400 . The function of the Application Definition File is to, for example, accept the instructions from the caregiver and control the display of these instructions on the patient&#39;s device as per information in this file such as for example, the capabilities of the patient&#39;s device, the language preference of the patient etc. The Application Definition File is created by sever  30  shown in  FIG. 1 . There are various methods by which the Application Definition File may come to exist on the patient&#39;s device, For example, it may be transferred at least once at the beginning of each session the patient initiates or may be downloaded into the patient&#39;s device by the patient himself or herself. This step generally has to be done only once for each device that will be used to display instructions. Yet another example of how the Application Definition File comes to exist on a User Device is as follows: a caregiver may change the definition subsequent to the initial deployment if this situation occurs an SMS message or an alternative push notification is sent to the patient device triggering the device to load the new application definition file automatically. 
         [0024]    In one embodiment, the Application Definition File allows the caregiver to create the personalized instructions without regard to the device the patient will use. The caregiver does not have to create a different Application for different devices such as iPhone™ or Android™ phones. The Application interprets the personalized instructions in the Application Definition File and displays information on the patient&#39;s device as per the capabilities and the type of device, the operating system and other characteristics which make each patient device unique. 
         [0025]    Referring still to  FIG. 1 , once the instruction set (i.e. the set of instructions containing specific instructions, video, other information) is created, the caregiver deploys the instruction set. This is depicted by arrow  100  and  120  in  FIG. 1A  and  FIG. 1B . A server  20  accepts the instructions, processes them and sends it to the patient&#39;s device as shown by arrows  130 ,  140  and  150 . These steps are shown in greater detail in  FIG. 3  in box  311 ,  312  and  320 . 
         [0026]    The role of server  30  of  FIG. 1  is defined in some more detail in box  320  in  FIG. 3 . For example, the server  30  enables one or multiple caregivers to interact with one or multiple patients. As an example, the server may host a website or doctor portal, where the caregivers may have individual accounts. In one embodiment, the caregiver selects a patient record or creates a new patient record or accepts a patient record from another source as shown in  FIG. 1B  by arrows  171  and  70 . The server  30  facilitates in this aspect. It also parses the instructions the caregivers send and sends the correct instructions to the correct patient device as shown in  FIG. 1  by arrows  130 ,  140  and  150 . The server  30  also plays a role in the presentation of patient information to the caregivers. This role will be discussed more below. 
         [0027]    In  FIG. 1 , multiple patient devices  40 ,  50  and  60  are shown attached to patient  43 ,  53  and  63 . The system  5  in  FIG. 1  can, for example, accommodate the following situations: one caregiver sending instructions to one patient on one device, one caregiver sending instructions to one patient on multiple devices, one caregiver sending instructions to multiple patients on one or multiple devices, or multiple caregivers sending instructions to one or multiple patients with multiple devices. The server  30  may contain a database of caregivers and patients and software to accommodate all these and other situations not mentioned specifically above. It should be understood that while  FIG. 1  shows multiple caregivers and multiple devices, the system  5  may be configured to accommodate any of situations described immediately above. 
         [0028]      FIG. 3  describes an example of how the system  5  in  FIG. 1  may be used. Here, the persons indicated by  43 ,  53  and  63  in  FIG. 1  may not all be patients. One person, for example  43  may be a patient. Persons  53  and  63  may be members of the patient&#39;s family. The caregiver in step  310  in  FIG. 3  may want to send instructions or information to the patient&#39;s family members. The caregiver may choose to send different information and instructions to different members of the patient&#39;s family according to their role in the care of the patient. For example person  53  may be the patient&#39;s mother and may be the person providing food for the patient. The instructions may state that low sodium food must be prepared. In this example, information about the patient may come from many sources including for example persons  53  and  63 . The server  30  in  FIG. 1  collects all this information from various inputs and makes it available to the caregiver. 
         [0029]    The patient devices such as  40 ,  50  and  60  may also accept responses from the patient. In one embodiment, the input may be, for example, text, numbers, alphanumeric, voice, etc., or output from another device such as a blood pressure machine such as shown in box  360  in  FIG. 3 . 
         [0030]    In one embodiment, the devices such as  40 ,  50  and  60 , may accept the response and analyze the input. For example, if after heart surgery a patient&#39;s weight seems to be increasing, the device may tell the patient to call the doctor immediately or may call the doctor automatically. This is shown in box  335  and  345  in  FIG. 3 . 
         [0031]    The server  30  updates its database as instructions from caregivers or responses are received. When the caregiver wants a summary or status of the patients, the same portal may be used as when the personalized instructions were created. The server  30  may have Server Application software that may accomplish several tasks; for example, it may order presentation of a summary to a caregiver according to the responses or non-responses from the patient. 
         [0032]    Software Engine 
         [0033]    The software engine will now be described in greater detail. This software engine may be a simple rule based engine. There are many ways a rules driven engine may be implemented. The rules are defined in the Application Definition file as shown in box  405  in  FIG. 4 . As discussed earlier, the Application Definition File is created by the Server Application which resides in the server  30 . The rules are generated by the Server Application according to the inputs provided by the caregiver. Some aspects of the rules may be modified by the user such as placement of instructions on the screen, language etc. The Application Definition File is a mechanism by which user preferences are saved and accessible on various devices such as  40 ,  50  or  60 . It should be noted that the Application Definition File may generally be different for each device. For some examples, the Application Definition File may be similar, depending on the make and model of the device. 
         [0034]    In one embodiment, the rules in the Application Definition file determine the user experience and may be the primary mechanism which determines the behavior of the Device Application including, for example: questions to be displayed to the user and/or text that is to be converted to speech; media containing information that is to be displayed to the patient such as instructions for examining a wound, dressing the wound, or other information; inputs that are expected from the user either in the form of button clicks, speech input, etc.; confirmation to the patient concerning the input received so far; actions that will be taken by the application based on input from the patient, etc. This is shown generally in box  440  in  FIG. 4 . 
         [0035]    The Application Definition file may also utilize the resources of the local device  40 ,  50  or  60 . These include, for example, alarms and calendar and other utilities found on the device. 
         [0036]    In one embodiment, the Device Application on the patient&#39;s device such as  40 ,  50  or  60  parses the Application Definition File and may create a database. The Application Definition File populates this database. The database stores information such as transcripts of user session, user responses, etc. As explained above, the Application Definition File indicates such information as the times of the day that the Device Application needs to interact with the patient. The patient has the option of modifying some behaviors such as choosing a more convenient me to interact with the Device Application. 
         [0037]    In one embodiment a database is not created on the patient&#39;s device such as  40 ,  50  or  60 . The responses are sent back directly to the server  30 . 
         [0038]    The Device Application alerts the patient at a pre-determined time. The alert mechanism follows the usual alarm mechanisms of snooze, stop, etc. Appropriate actions are taken once the user responds to the alarm. Additionally, the Device Application will alert the caregiver&#39;s office if the patient does not respond, In one embodiment, when a patient enters data, data triaging occurs. If the patient enters data that requires immediate attention then the User Device will call notify the doctor&#39;s office immediately. 
         [0039]    When a patient such as  43 ,  53  or  63  interacts with system  5  of  FIG. 1 , a Session is commenced on at least one of devices such as  40 ,  50  or  60 . The Session behavior may be controlled by the Application Definition File. A Session may comprise of one or multiple states. A “state” is simply the status of the Session at any time. A “state” may also represent a set of programming steps or logic to achieve a specific task. A Session may be in one or several states at any one time. A state may be used to classify an object such as a patient or a set of tasks (for example user interface tasks). For example, astute may present a question to the patient, or may present some information to the patient, or may ask for a response from the patient. 
         [0040]    Application Definition File 
         [0041]    The content of the Application Definition File is now described. As shown in  FIG. 3 , The Application Definition File such as  331  or  341  resides in the User Device  330  or  340 . It should be noted again that while  FIG. 3  shows two User Devices, there may be one or more than one Device. Now referring to  FIG. 4 , in one embodiment, the Application Definition File may contain: a list of possible states of the interaction (i.e. current state within a session); the interactions to be performed based on the current state; question for the patient; information for the patient; buttons corresponding to expected inputs which the patient may use to confirm/deny the symptom posed by the question; action to be taken on no response by the user, etc. It also may include, as shown in  FIG. 4 , for example, information about the device operating system, information about the hardware specifications (screen size, memory etc), patient preference (language, colors etc). Another key component of the Application definition File is the rules which define the Device Application flow. This is shown in box  440  in  FIG. 4 . In general, the Application Definition File controls the application behavior. 
         [0042]    In one embodiment as shown in box  450  in  FIG. 4 , the display of the instructions contains one or multiple display elements. A display element may be, for example, text, movie, clips, animations, pictures etc. The Application Definition File may store information about, for example, size, shape, color, position on the screen, orientation within the screen to be used for each display element. 
         [0043]    In one embodiment, depending on the state of the Device Application, such as the nature of the question, a non-response can be configured to mean either that the patient responded in the negative, or if there was a specific button to indicate a negative response, it can be construed as a timeout, and the appropriate actions can be taken such as sounding an alarm, or sending a message to the caregiver, or skipping that question. 
         [0044]    When a patient is interacting within a session, at the end of each state, if needed, a confirmation is provided. At the end of the session, a summary is presented to the patient along with any follow up actions such as automatic notification of the doctor&#39;s office for follow-up. Additionally, the patient is provided with important tips, as well as a reminder of upcoming appointments. A log of the interaction is sent to the server  30 . The caregiver can then access this log. 
         [0045]    In one embodiment, the Device Application can be implemented on multiple devices. The user can use multiple devices to interact with the server. This way the user has complete flexibility on which device he or she chooses to use. As an example, the user may choose to use an iPhone one day and may choose a laptop another day. The responses and Application behavior are consistent across the various devices. 
         [0046]    In one embodiment the user can interact with multiple devices even within a Session. 
         [0047]    Patient/Device Interaction 
         [0048]    The interaction between the patient and the patient device such  40 ,  50  or  60  is now described. As noted above, this interaction is dictated by the rules within the Application Definition File.  FIG. 5 , shows an example a section of rules within an Application Definition File. The patient starts the Device Application, for example, manually, or based on an alarm. The Device Application may also start automatically. The start behavior is defined in the Application Definition file. The patient sees the text in the column named “Question”. The Device Application goes through a number of states starting with state  1 . If the patient answers in the affirmative, then the Device Application will go to the state specified in the column “State on confirmation”. If the patient does not provide an input, the Device Application will go to state defined in the “State of Timeout” column. Thus the entire behavior of the Device Application is defined in the rules. 
         [0049]    In one embodiment, data can be entered into the patient&#39;s device such as  40 ,  50  or  60  in multiple ways. For example, the data can be typed in by the patient or the data can be entered via sensors as shown in box  360  in  FIG. 3 . The sensors may collect data continuously or when commanded by the Device Application or both. The sensors may communicate with the User Device wirelessly or through wired means. 
         [0050]    Software Architecture 
         [0051]    The Application Definition file is part of a software architecture, which will now be described in relation to  FIG. 6 . The goal of this software architecture is to create a software package that can be deployed in various hardware platforms without having to re-write the software for each hardware platform. The software architecture can be described by a state machine  600  in  FIG. 6 . This figure shows two state machines as an example. The architecture may have one or many state machines. A “state” as defined earlier, is simple the status of the Session at any time. Also as stated earlier, there may be one or multiple states. Specifically, in the context of this software architecture, it is convenient to think of a User Interface (UI) state and a patient state. A UI state may describe “what” information is to be displayed and “how” (layout and appearance of the information) it should be displayed. Referring to  FIG. 6 , a state can either be a UI state as discussed above and shown within the box  610  or a patient state shown in box  620 . A patient state may be thought of as a classification of a patient. For example, a patient may be classified as red, yellow, or green. A red classification may mean that the patient needs immediate attention. A yellow classification may mean that the patient may need attention soon. A green classification may mean that the patient is just fine and needs minimal attention. Other classifications are possible. Multiple classifications are also possible. Referring still to  FIG. 6 , an example is now described in relation to the table found in  FIG. 5 , When the patient&#39;s device starts executing the Device Application, it enters the state labeled UI- 1  in box  610 . This may relate to state  1  in  FIG. 5 . The text “Is this a good time to do a follow-up on your progress? Press the button to proceed otherwise wait for further instructions.” may be displayed on the patient&#39;s device. If the patient answers affirmatively,  FIG. 5  shows that the next state will be state  2 . If the patient does not answer, state  3  is attained. Referring again to  FIG. 6 , the patient input or lack of input determines if the next UI state will be UI- 2  or UI- 3  in box  610 . The rules determine the next UI state. This mechanism can be used to determine, for example, the next question or piece of information to provide to the patient. 
         [0052]      FIG. 6  shows the patient state (which  FIG. 5  does not). If the patient answers affirmatively for the question posed in UI- 1  in box  610 , the underlying rule for this specific UI state (UM) may classify this patient green at this stage of the application. So the value of “Patient State- 1 ” in box  620  may be green. If the patient had not responded, the same rule for this UI state (UI- 1 ) may have classified this patient red. 
         [0053]    There does not need to be one to one correspondence between a patient state and a UI state. A UI state does not have to change a patient state. 
         [0054]    A rule associated with a UI state may change the classification of a patient attained by a previous UI state. 
         [0055]    A rule may not always be associated with a specific UI state. As an example, a rule at the end of a session may analyze all the responses and make a final determination of the patient state. 
         [0056]    Box  610  in  FIG. 6  also shows inputs to the UI states. These inputs may be, for example, an input entered by the patient, an output of another machine such as a blood pressure machine, text, voice, photographs taken by the patient, etc. 
         [0057]    It will be appreciated by those of ordinary skill in the art that the present invention may be embodied in other specific forms without departing from the spirit or essential character thereof. The disclosed embodiments are therefore intended in all respects to be illustrative and not restrictive, The scope of the invention is indicated by the appended claims rather than the foregoing description, and all changes which come within the meaning and range of equivalents thereof are intended to be embraced therein. What is claimed is: