Abstract:
A health information gathering system for gathering information from at least one user. The health information gathering system includes a database storing information relating to a user and pertaining to at least two of the areas of information selected from a group consisting of nutritional information, psychological information, occupational information, physical information and personal history information, access to the information stored in the database being controlled by the user. The user can input information pertaining to the at least two areas of information selected from the group consisting of nutritional information, psychological information, occupational information, physical information and personal history information into the database, and the user can retrieve information from the database.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS  
       [0001]    The present application claims priority to the provisional patent application identified by U.S. Ser. No. 60/335,002, filed Oct. 24, 2001, the entire content of which is hereby incorporated herein for all purposes. 
     
    
     
       BACKGROUND OF THE INVENTION  
         [0002]    With the rapid growth of the Internet and the World Wide Web, more and more individuals are searching for answers for their own health needs. According to Pew, there are 7.5 million “health seekers” on the Internet everyday looking for health answers and slightly fewer people see physicians every day. Although there is more information available than ever before, that does not necessarily mean it is relevant information, or even quality information. With this flood of information now available, individuals are trying to learn more about themselves and examine their own health issues.  
           [0003]    Most individuals are not trained medical practitioners. This leaves average individuals at a serious disadvantage when trying to learn more about their own health and health needs. They lack the true medical education and training to assist them in understanding more about their health; they often end up being drawn to a few common issues.  
           [0004]    Average individuals also lack the medical expertise to properly determine what may or may not be a relevant piece of information when trying to learn more about their own health. Important symptoms and situations that may help individuals discover they may have a medical or psychiatric condition, or lead to a better understanding of themselves, are often overlooked because the symptoms or situations may seem irrelevant to them. Most users would not think that loss of body hair is a serious symptom unless they knew that it was an important symptom for those suffering from, for example, hypothyroidism. Since most users do not know about diseases, disorders, and conditions, they often rely on being led to issues and then applying their symptoms to issues to which they are led. Unfortunately, many of these issues to which individuals are led are often irrelevant.  
           [0005]    Standard approaches are to separate psychological, physical, nutritional, etc., factors, compartmentalizing them. Symptoms overlap and are common in areas and in conditions. Rather than focusing on the disease model, health psychology focuses on health, wellness, and prevention. Health psychology is based on a biological, psychological, sociological, medical model. If people can assess themselves, capture their own health information, find patterns and habits and make changes, they can alter their health and increase the likelihood of wellness and prevention.  
           [0006]    If individuals choose to report information to their physicians, even if they are armed with information about themselves, their chances for conveying that information to their physicians are slim. The average time an individual has to spend with a physician is now between 4 and 6 minutes. That means, the individual must express everything he or she is currently feeling and thinking about, plus convey his or her medical, personal, and family history in a period of time that is only slightly longer than the average television commercial break.  
           [0007]    Physicians are well aware that most individuals lack the medical knowledge to communicate their issues meaningfully to them. Physicians are under a great deal of pressure to make a diagnosis in the shortest possible time and are also aware that there are other individuals awaiting their care. Because of this pressure, and because physicians do not expect to receive much information from individuals without being prompted, individuals will have, on average, only 12 seconds before they are interrupted by their physicians.  
           [0008]    With such factors taken into consideration, it is increasingly difficult for physicians to make accurate, timely, and cost-effective diagnoses for the individuals in their care and for their patients to “buy into” their treatment plans.  
         SUMMARY OF THE INVENTION  
         [0009]    The present invention is a health information gathering system (HIGS). HIGS is designed for people to capture their own health histories, symptoms, and situations—shifting power to the people to increase the likelihood of prevention and early detection in order to empower them with the knowledge to make changes and get healthier. The present invention meets the needs described above as an educational and preventative tool as well as a communication and reporting tool between an individual (a HIGS user) and their healthcare provider.  
           [0010]    By gathering histories, symptoms, and situations, HIGS users have a better understanding of their own health and health issues. With this understanding HIGS users can capture information about issues relevant to their health.  
           [0011]    Users who choose HIGS and share their gathered information with physicians can increase their likelihood of effectively communicating and reporting their information. With effective communication also comes effective treatment.  
           [0012]    The HIGS also enables the HIGS user not only to capture their histories, symptoms, and situations, but to also provide them to their healthcare provider through paper or electronic format. By presenting the information collected through HIGS, the HIGS user&#39;s physician has access to far more information in the 4 to 6 minutes normally available in a meeting.  
           [0013]    By assisting a user in gathering their health information, the HIGS user becomes more educated about themselves and their health in order to obtain treatment for current issues and the prevention of other items from becoming health issues at some future date.  
         DESCRIPTION OF THE EMBODIMENT  
         [0014]    The Health Information Gathering System (HIGS) is a data capturing and management system designed to assist users in communicating their histories, symptoms, and situations to their healthcare provider in a more efficient and timely fashion.  
           [0015]    For convenience, the discussion of the preferred embodiment will be broken into the following principal sections: System Overview, Assessment System, Histories System, Body Systems System, Personal Health Status Profile (PHSP) System, and Changes for Consideration System.  
           [0016]    HIGS is made up of four primary systems: an assessment system, a histories system, a body systems system, and a personal health status profile system.  
           [0017]    The assessment system is responsible for the management, transmission, and recording of assessments to the HIGS user. An assessment is a medical protocol, used to determine the relative risk of a particular issue for the user. Each assessment is developed using the appropriate criteria as set by the medical community.  
           [0018]    The histories system is responsible for the management, transmission and recording of user histories. These histories collect information about a user&#39;s health history and that of their family. This aids in providing a better historical picture of a user to a healthcare provider.  
           [0019]    The body systems system is responsible for the management, transmission and recording of a user&#39;s physical symptoms. Each body system listed in the body systems system targets a specific functional system of the human body, such as neurological or gastrointestinal. Each body system is made up of numerous physical symptoms. The body systems system collects user responses for the various physical symptoms to assist them in understanding their health and guiding them in addressing their health concerns.  
           [0020]    The Personal Health Status Profile (PHSP) System is responsible for bringing all a user&#39;s data together and generating meaningful reports and collections of information. A personal health status profile (PHSP) can be delivered to a user&#39;s healthcare provider through a hard-copy or electronically, depending upon the embodiment of the HIGS being used.  
           [0021]    In addition to the primary HIGS Systems, HIGS also contains two ancillary systems: a changes for consideration system, and a healthcare provider system.  
           [0022]    The changes for consideration system is responsible for providing additional information to a user based on their responses in the assessment, body systems, or history systems. This information is offered in forms ranging from a single line of text, a short paragraph, or all the way to full articles or white papers.  
           [0023]    The healthcare provider system is responsible for granting registered healthcare providers access to associated user&#39;s information. The information that a healthcare provider is granted is controlled by the user and only the information a user wishes to be known can be displayed to their healthcare provider.  
           [0024]    It is possible to add additional core systems and ancillary systems depending upon the requirements and a particular embodiment.  
       
    
    
     BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING  
       [0025]    [0025]FIG. 1 is a schematic diagram of the hardware forming one embodiment of a health information gathering system constructed in accordance with the present invention.  
         [0026]    [0026]FIG. 2 is a schematic diagram illustrating the logic of a typical embodiment of the health information gathering system.  
         [0027]    [0027]FIG. 3 is a block diagram illustrating the general operation of one embodiment of the health information gathering system.  
         [0028]    [0028]FIG. 4 a  is a logic flow diagram of an assessment system process constructed in accordance with the present invention.  
         [0029]    [0029]FIG. 4 b  is a logic flow diagram of an assessment engine process constructed in accordance with the present invention.  
         [0030]    [0030]FIG. 4 c  is a flow diagram of an assessment question—result relationship.  
         [0031]    [0031]FIG. 5 a  is a logic flow diagram of a history system process constructed in accordance with the present invention.  
         [0032]    [0032]FIG. 5 b  is a logic flow diagram of a history engine process constructed in accordance with the present invention.  
         [0033]    [0033]FIG. 5 c  is a flow diagram of a history—result relationship.  
         [0034]    [0034]FIG. 6 a  is a logic flow diagram of a body systems system process constructed in accordance with the present invention.  
         [0035]    [0035]FIG. 6 b  is a logic flow diagram of a body systems engine process constructed in accordance with the present invention.  
         [0036]    [0036]FIG. 6 c  is a flow diagram of a body system—physical symptom relationship.  
         [0037]    [0037]FIG. 7 is a logic flow diagram of a personal health status profile process constructed in accordance with the present invention.  
         [0038]    [0038]FIG. 8 is a logic flow diagram of a changes for consideration engine constructed in accordance with the present invention.  
         [0039]    [0039]FIG. 9 is a logic flow diagram of a physicians engine constructed in accordance with the present invention.  
         [0040]    [0040]FIG. 10 shows a typical personal health status profile report produced in accordance with the present invention.  
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0041]    System Overview  
         [0042]    Referring now to the drawings, and in particular to FIG. 1, shown therein and designated by a reference numeral  10  is a health information gathering system (HIGS) constructed in accordance with the present invention. In general, the HIGS  10  is a computer system that gathers user histories, symptoms, and situations with the purpose of aiding user diagnosis by a healthcare provider. To gather the information, the HIGS  10  uses a series of databases (see FIG. 2) where each database holds a specific array of questions or items for the user to respond to. The user&#39;s results are also captured in the databases in such a way to keep a historical record for tracking analysis.  
         [0043]    The HIGS  10  includes a host system  12 , communicating with one or more user devices  14  via a network  16 . The network  16  can be the Internet or other network. In either case, the host system  12  typically includes one or more servers  18  configured to communicate with the network  16  via one or more gateways  20 . When the network  16  is the Internet, the primary user interface of the HIGS  10  is delivered through a series of web pages, but the primary user interface can be replaced by another type of interface, such as a Windows-based application. This method is also used when deploying the HIGS  10  in a stand-alone environment such as a kiosk or as part of a healthcare provider system.  
         [0044]    The network  16  can be almost any type of network although Internet and Internet  2  networks are preferred because of the wide support of their underlying technologies. The preferred embodiment of the network  16  exists in an Internet environment, which means a TCP/IP-based network. It is conceivable that in the near future, the preferred or other embodiments, may wish to use more advanced networking topologies. The network  16  does not refer only to computer-based networks but can also represent telephone communications as is illustrated by item  124 , providing that the HIGS  10  is capable of voice recognition and the ability to verbalize content and navigation.  
         [0045]    The servers  20  can be networked with a LAN  30 . The gateway  20  is an entity responsible for providing access between the LAN  30  and the network  16 . The gateway  20  can also be used as a security means to protect the LAN  30  from attack from external networks such as the network  16 .  
         [0046]    The LAN  30  network can be based on a TCP/IP network such as the Internet, or it can be based on another underlying network transport technology. The preferred embodiment uses an Ethernet network with TCP/IP because of the availability and acceptance of underlying technologies, but other embodiments may use other types of networks such as Fibre Channel, SCSI, Gigabit Ethernet, etc.  
         [0047]    As discussed above, in one preferred embodiment, the host system  12  includes the servers  18 . The configuration of the server hardware will depend greatly upon the requirements and needs of the particular embodiment of the HIGS  10 . Typical embodiments, including the preferred embodiment, will include multiple servers  18  with load balancing to increase stability and availability. It is envisioned that the servers  18  will include database servers and application/web servers. The database servers are preferably separated from the application/web servers to improve availability and also to provide the database servers with improved hardware and storage.  
         [0048]    The user devices  14  can be any number and type of devices. The most typical scenario of the user device  14  involves a user  32 , using a computer  34  with a monitor  36 , keyboard  38 , and mouse  40 . In the preferred embodiment, the user  32  is required to use a type of software called a “browser” as designated by a reference numeral  42 . The browser  42  is used to render content that is received from a source. In the modern vernacular, a “browser” refers to a specific implementation called a Web Browser. Web Browsers are used to render HTML/XHTML content that is generated when requesting resources from a web server. In the preferred embodiment, HIGS  10  is designed to be compatible with all major Web Browser vendors (Microsoft Internet Explorer, Netscape Navigator, and Opera). Other embodiments may wish to focus on one particular browser depending upon the common user base connecting to the HIGS embodiment.  
         [0049]    The user devices  14  can also be implemented as a portable device such as a laptop computer  50  (or handheld computer); a cellular telephone  52  with a micro or embedded Web Browser; a Portable Digital Assistant  54  (PDA) capable of wireless network access; a pen-based or tablet computer  56  or a telephone  58  for a voice-enabled HIGS  10  embodiment. In another embodiment, the user device  14  can be a cable box  60  or other similar device for viewing through a monitor  62  or television. Current embodiments of HIGS  10  can also be modified to use any of these or future developed devices.  
         [0050]    The HIGS  10  is designed in this way as to provide flexibility in their deployment. Depending upon the requirements of the particular embodiment, the Engine could be designed to work in almost any environment such as a desktop application, a web application, or even simply as a series of web services designed to communicate with an external application.  
         [0051]    Throughout this document, the words individual, user, HIGS user, and patient are used interchangeably. Also, throughout this document the words healthcare provider and physician are used interchangeably.  
         [0052]    The hardware and system software are designed with two key concerns; flexibility and scalability. Although some specifics for software and hardware components may be mentioned herein, it will be understood that a wide array of different components could be substituted, such as using different database vendors or even replacing the databases with XML-based document stores.  
       Description of System Overview Drawings  
       [0053]    [0053]FIG. 2 illustrates a typical embodiment of the HIGS  10 . The HIGS  10  consists of numerous individual subsystems and processes, as well as several database components.  
         [0054]    In one embodiment, the HIGS  10  includes a user registration and login system  210 ; a physician registration and login system  212 ; a HIGS process  220 , including an assessment engine  222 , a histories engine  224 , a body systems engine  226 , a changes engine  228 , a PHSP system  230 , and a physician system  232 ; a user assessment database  240 ; a physician account database  242 ; an assessment store  244 ; a histories store  246 ; a physical symptoms store  248 ; a changes for consideration store  250 ; and a PHSP store  252 .  
         [0055]    The user registration and login system  210  can be tailored to the needs of the embodiment. The preferred embodiment of the user registration and login system  210  requires a user to have a valid email address. By having a valid email address, this helps in ensuring user identity and also assists in sending information to the user, such as how to obtain/change their password and provide an additional layer of security.  
         [0056]    The typical embodiment for the user registration and login system  210  requires certain personal identifiers to be provided by the user, such as email address, gender, language preference, and date of birth. All these items assist in securing a user&#39;s account against unauthorized access and also provide information needed to tailor Assessments, Histories, and Body Systems to match the particular user. Other embodiments may require additional information to further tailor the information provided, or may not require any additional information at all.  
         [0057]    The user registration and login system  210  accesses a user information database  240 . The preferred embodiment uses a single database for both the User Login and User Registration process of the user registration and login system  210  to avoid complications of cross-database communication. It is possible for other embodiments to use more than one database for the User Login and User Registration processes of the user registration and login system  210 . It is also possible that the User Login process could, itself, use multiple databases in other embodiments to spread access load across multiple database servers, or to separate user groups to improve or meet specific security criteria.  
         [0058]    The physician login and registration system  212  contains the Physician (or Healthcare Provider) Login and Registration processes. Both processes access the physician account database  242 . The Physician Login process can be embodied in the same ways as the User Login process of the user registration and login system  210 . The preferred embodiment for the physician login and registration system  212  does not require the additional information about the physician requested by the User Registration process of the user registration and login system  210 . That is, the Physician Registration process does not need the extra identifiers to assist in tailoring Assessments, Histories, and Body Systems to the Physician&#39;s gender or age as the physician&#39;s primary purpose is to view the associated user results and not to generate their own results. Other embodiments of the Physician Registration process may require this if it is also desired for physician to have access to the Assessments, Histories, and Body Systems for themselves.  
         [0059]    The HIGS process  220  represents the collection of the HIGS subsystems. The individual subsystems used by the preferred embodiment of HIGS  10  are discussed in the following sections.  
         [0060]    The assessment store  244  is a database containing all the HIGS Assessments as well as the user responses to these Assessments. In the preferred embodiment, this is a Relational Database Management System (RDBMS) but other embodiments could use non-relational data files, or other formats such as XML data files.  
         [0061]    The histories store  246  is a database containing all the HIGS Histories, as well as the user responses to these Histories. In the preferred embodiment, this is a Relational Database Management System (RDBMS), but other embodiments could use non-relational data files, or other formats such as XML data files.  
         [0062]    The physical symptoms store  248  is a database containing all the HIGS Body Systems and the user responses to their associated Physical Symptoms. In the preferred embodiment, this is a Relational Database Management System (RDBMS), but other embodiments could use non-relational data files, or other formats such as XML data files.  
         [0063]    The changes for consideration store  250  is a database containing all the relative Changes for Consideration for the Assessment, Body System, and History Systems. The individual Change items may also refer to external data sources such as a web page, a local or external file, or data that resides on an external system. In the preferred embodiment, this is a Relational Database Management System (RDBMS), but other embodiments could use non-relational data files, or other formats such as XML data files.  
         [0064]    The PHSP store  252  is a database and contains meta information about a user&#39;s preferences for a particular PHSP report generated. The PHSP store  252  desirably stores one or more PHSP reports. These PHSP reports contain references to Assessments, Body Systems, and Histories that the user has answered and would like to have available in a ready-to-run report, avoiding the user from having to select the same items repeatedly whenever they want to run a set report. The PHSP store  252  desirably does not contain the individual Assessments, Body Systems, and Histories that the user has taken and, instead, only references them through the unique identifier of each item they have taken in the appropriate system. In the preferred embodiment, this is a Relational Database Management System (RDBMS) but other embodiments could use non-relational data files, or other formats such as XML data files.  
         [0065]    [0065]FIG. 3 illustrates an overview of the general HIGS operation process. The typical process begins with item  272  in which input is received from one or more of the user devices  14 . As discussed above, this input can be through a web browser, a WAP-enabled device such as a cellular phone, a Portable Digital Assistant (PDA), or any device that can connect to the network that HIGS  10  is implemented on. Other embodiments can add additional methods for collecting user input, such as from an installable application on a desktop or through a third-party data interchange using web services or other industry standard interchange format.  
         [0066]    Input is passed to the HIGS process or engine  220 , which retrieves and stores data to and from item  260 , which represents the entirety of the HIGS databases.  
         [0067]    The HIGS process or engine  220  can also communicate with external storage  262 , as well as off-line data  274 . The external storage  262  can be used in embodiments that wish to store/transmit HIGS data to an external database, or to merge/retrieve external data for use within HIGS  10 . The off-line data  274  is useful for additional embodiments where HIGS  10  may be running in a disconnected environment and the need exists to store data locally.  
         [0068]    HIGS  10  is also provided with a reporting mechanism  268  for Personal Health Status Profile (PHSP) reports and additional items such as assessment risks. The reporting mechanism  268  also feeds to items  266 , which-represent output to a physician, or to item  270  representing output to the user. In the preferred embodiment, output from the reporting mechanism  268  only proceeds to item  266  at the request of the user and only contains the information that the user wants or selects to be reported. Other embodiments may take a different approach to this, but the preferred embodiment is focused on allowing the user to control who has access to their information.  
         [0069]    The reporting mechanism  268  can also communicate directly to the external storage  262  and off-line storage  274 . In the preferred embodiment, communication from the reporting mechanism  268  to the external database  262  is also controlled by the user, just as the communication between the reporting mechanism  268  and their physician in item  266 . Communication between the reporting mechanism  268  and the off-line storage  274  is required in order for HIGS  10  to also be available as a stand-alone system operating on a desktop computer or other similar device.  
         [0070]    Assessment Engine  
         [0071]    An Assessment, often called a Protocol in the psychological community, is a series of questions designed to assist a user in determining their risk for a particular condition/disease/issue. Each Assessment focuses on one primary condition/disease/issue but may also contain links to other related Assessments.  
         [0072]    Each Assessment will have at least the following items:  
         [0073]    One or more questions used to gather responses from the user; and  
         [0074]    Value fields indicating breakpoints between different risk levels (i.e.: a 6 represents the beginning of a mild risk whereas an 18 would represent the beginning of a moderate risk).  
         [0075]    Assessments can additionally have the following identifiers:  
         [0076]    A gender value that can optionally limit the Assessment to only being viewed by users who match the gender (such as only females can view assessments that deal with female-only issues);  
         [0077]    A language/cultural identifier which can optionally identify the assessment as being a variant for a particular language/culture. This gives Assessments more flexibility then simply offering translated versions of questions, and instead, can offer a different range of questions based on cultural issues that may apply only to the particular culture in question; and  
         [0078]    An age identifier which can optionally limit an Assessment from being viewed by users who do not meet the specified age requirement.  
       Description of Assessment System Drawings  
       [0079]    [0079]FIG. 4 a  illustrates a flowchart for generating a typical Assessment as well as the steps that follow the actual rendering of the assessment. This process can be abbreviated or expanded, based upon the need. For example: The generation of a graphical risk comparison in step  318  may not be appropriate for situations where the users will have limited display devices, such as wireless telephones, or other features can be added such as referring users to useful articles relevant to the assessment and their generated risk result.  
         [0080]    Step  302  illustrates the start of the Assessment process, which could be through a web page, an application such as a Windows or Linux-based program, or through other data interchange methods such as a web service. Once the process begins, the system proceeds to step  304 , the selection of an Assessment.  
         [0081]    There are various mechanisms that can be used for step  304  to present the user with suitable assessments for their viewing. This list of assessments used for step  304  could be generated as simply a list of all assessments available, a list of all assessments available but filtered based on a user&#39;s profile information (such as age, gender, culture), a list of assessments that the user has already taken, a list of assessments that the user has not taken, or more complex methods whereby an assessment can lead a user to other assessments based on their responses to the first assessment. After a user selects an assessment in step  304  the system proceeds to step  306 . Step  306  retrieves relevant information about the assessment being requested and, after obtaining this information, the system moves to step  340 , the assessment rendering engine detailed in FIG. 4 b.    
         [0082]    After completion of step  340 , the assessment rendering engine, the system proceeds to step  308 . Step  308  determines whether or not the assessment has been completed. It is possible in step  340  to begin an assessment, save an assessment, then stop taking that assessment. Step  308  determines if the user should see additional items based upon the assessment&#39;s state of completion. In situations where there are no additional features and only the assessment rendering engine from step  340  is used, then step  308  would simply direct the end state of the assessment system in step  322 .  
         [0083]    If an assessment is marked as completed, then the system will proceed to steps  310 - 320 , where applicable. Some or all of steps  310 - 320  can be executed and displayed simultaneously depending upon the visual design goals of the system. Steps  310 - 320  can also be built to be initiated by a trigger event, such as a user clicking a hyperlink or button. Step  310  determines if there are applicable assessments available for the user based on the current assessment just completed. This list could be based on responses entered by the user in step  340  for the current assessment, or could simply be a list of assessments that are a good idea to take after the current assessment. Assessment items in the list generated by step  310  that are selected by the user, will refer the user back to step  306  to begin the newly selected assessment.  
         [0084]    Step  312  begins generating a list of changes for consideration. Step  312  initiates the Changes for Consideration item  700 .  
         [0085]    Step  314  updates the user&#39;s Personal Health Status Profile (PHSP) results with the most current version of the assessment just completed. This enables the PHSP to reflect the most current version of a particular assessment that has been completed because a user can take a single assessment numerous times. There are instances where users may not want saved PHSPs to be updated, such as a case where they have multiple PHSPs generated every 3 months to demonstrate progress for a variety of assessments between subsequent PHSPs.  
         [0086]    Step  316  generates a risk assessment for the assessment taken. This risk could be almost any meaningful term so long as it clearly conveys the risk of having a particular assessment. For example: Risk could be “The High End of the Severe Range” or “The Middle End of the Moderate Range”.  
         [0087]    Step  318  demonstrates a graphical comparison to previous times a given assessment was taken. This provides users with graphical progress representations. Step  318  may also require users to select particular instances of a given assessment they have taken to prevent instances that may contain non-normal data from being included (i.e.: an assessment taken on a “bad day” may yield data that skews the user&#39;s overall progress determination).  
         [0088]    Step  320  enables users to forward individual assessment results to a physician. This step may not be applicable if a) the user has not signed up any of their physicians with access to their information; b) a physicians system  232  is not currently in place; c) there are no physicians currently participating; d) physicians/users prefer to send complete PHSP reports instead of individual assessments.  
         [0089]    Step  322  marks the end of processing the assessment. This could mean moving along to another part of the HIGS system or the user has logged off from the HIGS system.  
         [0090]    [0090]FIG. 4 b  illustrates the typical Assessment rendering engine for the HIGS system. This process can be abbreviated, or expanded upon, based on the need. For example, if users can only select an assessment one time, then step  342  may be eliminated. Some variations of the system may also forgo an individual End-User License Agreement (EULA) for each assessment which would eliminate step  362 .  
         [0091]    The assessment rendering engine begins with step  340 . Step  340  can be initiated by any number of sources including web services, web pages, and stand-alone applications. Once initialized, the system proceeds to step  342 .  
         [0092]    Step  342  checks to see if the user has a previously unfinished version of the assessment requested. This prevents the database from being clogged with half-finished attempts and avoids costly systems to manage this partially completed data. If a user has an assessment that they had begun earlier in the current session, or during a previous session, then the system proceeds to step  346 . If the system finds that there are no incomplete instances of the current assessment, then the system proceeds to step  344 .  
         [0093]    In step  344 , the system creates a new assessment taken item. This links the user to a particular assessment and also to their responses to the questions for this particular assessment instance. This assessment taken item also holds other information such as the date an assessment began, as well as their risk information and overall point score for their results. By using a separate assessment taken item for each instance of an assessment taken allows for the tracking of user progress in an assessment through a period of time. It is possible to do away with this feature, if it is deemed that assessments should only be taken once.  
         [0094]    Step  346  retrieves and displays all the questions for a particular assessment. The system will search for both unanswered and answered questions and create a union of the two results. This provides the capability to return from saved sessions easily and efficiently. Once the questions have been retrieved from the database, they are rendered in a manner appropriate for the platform being viewed upon. For example: For web-based viewing, these questions are often rendered into a table format with each question residing in its own row. This step could also generate XML based data for sending through a web service to another device as a consumer; or it could be rendered into a Windows DataGrid for PC-based applications. Once step  346  retrieves and renders the questions for the given assessment instance, it then waits for user input to store the responses. If the user should disconnect at this point, the system will resume at step  340  the next time the user enters the assessment process to take the particular assessment again.  
         [0095]    From step  346 , the user has two choices on how to store their assessment data. Users can proceed to step  348  to save their results, which stores their responses to the questions answered, but does not mark an assessment instance as having been completed, nor does it score the instance. From step  346 , users can also proceed to step  360  to submit the assessment for completion. This process is a superset of the process used by  348 . In addition to storing the user responses as in step  348 , step  360  also marks the assessment taken instance as having been completed and proceeds to step  362  to begin the process of displaying the user&#39;s results in step  362 .  
         [0096]    Step  362  requires users to first acknowledge an End-User License Agreement, thus confirming their understanding of the purpose of the results they will be viewing. If users accept this agreement, the system proceeds to step  370 . Step  370  then returns control to the calling process as displayed in FIG. 4 a.    
         [0097]    If users have saved their results in step  348  from step  346 , as opposed to submitting their results as in step  360 , the system then proceeds to step  350 . Step  350  confirms that their results have been saved and prompts the user to either continue with the current assessment and return to step  346 , or end the current assessment session and proceed to step  352 . Step  352  then re-directs the user to the system that initially launched the assessment system.  
         [0098]    [0098]FIG. 4 c , illustrates a tree-based example of how an Assessment, its Questions, and Results are related. Each Assessment has a store of Questions in a question bank. In this embodiment, the question bank resides in a separate table inside the assessment store  244 . In other embodiments, the question bank could reside in an external database or XML data store.  
         [0099]    The nature of the join between an Assessment and the Questions is such that a single question could be linked to multiple assessments. Each assessment would have its own weighted value risk factor for the occurrence of that question in the individual assessment. This plurality of associations between a single question and one or more assessments assists the Assessment System in leading a user to other assessments of potential interest. This enables a user to select a question in Assessment A, and have their response also recorded for Assessments B and C, leading the user to assessments that they may not otherwise have considered of interest or risk. In addition to each question having the ability to link to multiple assessments, a question also has the ability to link to multiple results.  
         [0100]    A Result is a textual string that generates meaningful information based on the user&#39;s response to a given question. If a user answers affirmative to a particular question, then they will receive a series of results that can be communicated to their healthcare provider that provide a meaningful breakdown of the information contained in the associated question. Although a result can also be included in multiple questions, the current embodiment only utilizes this feature as a resource-saving mechanism in order to avoid having numerous duplicate result records in the database. Other embodiments of the system may extend upon this link between questions and results.  
         [0101]    Histories Engine  
         [0102]    The histories engine  224  is used to gather historical information about a user and his/her family through a series of separate history questionnaires.  
         [0103]    The current embodiment of the histories engine  224  contains the following items:  
         [0104]    A list generator to create a list of available history questionnaires;  
         [0105]    A questionnaire generator responsible for retrieving the proper question items for a particular questionnaire; and  
         [0106]    A method for collecting user responses.  
         [0107]    Additional items include:  
         [0108]    A method for transmitting a particular history to the user;  
         [0109]    A method for making a particular history or histories viewable to a healthcare provider registered with HIGS; and  
         [0110]    A method for transmitting a history or histories to an external system or application through the use of a standard interchange mechanism such as Web Services.  
         [0111]    Histories represent an important part of a user&#39;s health information. They often provide the user and their healthcare provider with crucial information for identifying potential issues in a user&#39;s health. The preferred embodiment of the HIGS  10  uses two categories for Histories, Personal Histories, and Family Histories.  
         [0112]    Personal Histories are used to gather responses that are related to the user directly, such as types of employment at which they have worked, illnesses they may have had, places they may have lived, etc.  
         [0113]    Family Histories are used to gather responses that are related to a user&#39;s family in general, such as what illnesses may a parent have had, was the user&#39;s mother at least a certain age when the user was born, was the user&#39;s parents exposed to toxic chemicals before the user was born, etc.  
         [0114]    Both types of histories gather information that is otherwise not easily recorded by the user and not easily communicated verbally to a healthcare provider. Many History Items are also not easily recognized as being important or are easily overlooked by most individuals. By gathering these often forgotten History Items, a more precise history of the user is drawn.  
       Description of Histories Drawings  
       [0115]    [0115]FIG. 5 a  illustrates a flowchart for gathering information by the histories engine  224 .  
         [0116]    Step  400  represents the initial starting point for the histories engine  224 . In the preferred embodiment, this step represents the web page containing the initial histories information. After launch, the system proceeds to step  402 .  
         [0117]    Step  402  generates a list of histories available to the user. In the preferred embodiment, this list is filtered based on age, gender, and language/culture. Other embodiments may wish to forgo the filtering or may wish to filter available histories on additional or different criteria. Step  402  requires a user interaction to proceed. Once a user selects a choice from the list of histories generated, the system transfers control to the histories engine  224  in step  440 .  
         [0118]    As shown in FIG. 5 b , step  440  represents the initial state of the histories engine  224 . This step requires a valid ID for a History Item. Once initialized, the system proceeds to step  442 .  
         [0119]    In step  442 , the histories engine  224  retrieves all relevant History Items based on filter criteria. In the preferred embodiment, this criterion includes age and gender. The user&#39;s language is also used as a filter to return History Items in a language appropriate for the user. In other embodiments, it is possible to filter on additional criteria, or no criteria at all. Other embodiments may also forgo filtering upon the user&#39;s language if only one language is supported by the system.  
         [0120]    After all relevant History Items have been retrieved, the system proceeds to step  444 . Step  444  uses the retrieved History Items list to generate a viable display for the items. Along with each History Item, a method is included for selecting the History Item. Because of the Boolean nature of History Items, it is most feasible to represent this selector as a checkbox. Although there are other ways of selecting Boolean responses, as is the case with radio buttons, it may be simpler for many items to use a checkbox as to avoid confusion in complex history questionnaires. It is possible that some embodiments may wish to leave this open and include an attribute with each individual history or History Item on whether or not to display the item(s) as checkboxes or radio buttons. The preferred embodiment makes use of this flexibility, but other embodiments can be built using a set visualization such as, only checkboxes or a mix of other visualizations, in addition to radio buttons or checkboxes.  
         [0121]    After all the History Items for a given history have been displayed in step  444 , the system will await user interaction to proceed to step  446 . This action is usually embodied in a “submit” button on the form, as is the case in the preferred embodiment. It is possible to save a user&#39;s responses each time a user makes a change to the state of a History Item (from affirmative to negative or negative to affirmative). This method is typically unwieldy, especially in a network environment, as is the case in a web-based application, as each change in a History Item state by the user requires re-submitting and transmitting all data back to the server, then regenerating the page and transmitting the updated page back to the user. The preferred embodiment does not use this method and only updates a user&#39;s responses when they take the action of activating the “submit” button on the web page.  
         [0122]    Once the appropriate user action occurs in step  446 , the system proceeds to step  448  to store the results in the histories store  246 . To store a user&#39;s responses, all that is needed are a record(s) that contain both the user&#39;s unique ID, and the unique ID of the History Item. Other embodiments could store the responses as a single record to parse at runtime, or as XML data in a file or field in the database. The preferred embodiment uses a separate table to store the user&#39;s responses to individual History Items. This provides insurance of data integrity should a user be removed from the system in order to cascade the removal of any related data. In the current embodiment, users are not removed, only marked inactive as their information and results should not be destroyed.  
         [0123]    Once a user&#39;s responses have been stored, the system proceeds to step  448 , which is a state check to determine if the system needs to display the updated history or to proceed to the end state and return control to the history engine  224 . This step can either use a global system variable to determine whether or not the system should automatically redirect back to step  442  to show the updated History Items with the new user responses, or to require a user action such as a confirmation that the values were saved, and a prompt if the user wants to continue adding more responses to this history. The preferred embodiment uses a variable in the configuration for the History System to determine whether or not the redirection should be automatic. The current embodiment also uses automatic redirection and a message to alert the user that their responses were saved correctly. If this value is true, the system proceeds to step  442  to retrieve the updated history again. If this value is false, the system proceeds to step  450  which represents the end state of the engine and transfer is returned from the calling entity which typically results in returning to the History System.  
         [0124]    Once control returns from step  440  to the History System, any or all of steps  404 ,  406 ,  408 ,  410 , or  412  can occur, depending upon the configuration of the system. In the preferred embodiment, these steps are controlled through user action and require user intervention, except for step  408 , which is used to ensure the most recent history data is available in the PHSP.  
         [0125]    Step  404  represents a referral mechanism that can lead a user on to additional Assessments or Body Systems, if required. This referral could be arbitrary, or triggered by the answering of individual histories or groups of History Items.  
         [0126]    Step  406  will launch the Changes for Consideration engine to determine if any changes are necessary based on the user&#39;s responses to the History Items.  
         [0127]    Step  408  updates any references to a history in the PHSP. This ensures that the PHSP is retrieving the most current History Item responses for the given history.  
         [0128]    Step  410  can also forward the results of an individual history to a healthcare provider registered with HIGS, if desired by the user.  
         [0129]    State  412  represents the end of processing by the history engine  224  and can be triggered simply by leaving the history engine  224  to view another HIGS system, the logging out of the user&#39;s current session, or simply leaving HIGS altogether.  
         [0130]    Body Systems Engine  226   
         [0131]    The body systems engine  226  is used to gather information about an individual&#39;s physical symptoms grouped by body system. The preferred embodiment uses the following Body Systems: Neurology; Eye, Ear, Nose, and Throat; Endocrinology; Reproductive Male—Genital Urinary (GU); Circulatory and Cardiopulmonary; Digestion and Dietary Issues; Skin, Hair, and Nails; Muscular Skeletal; Female Reproductive—Obstetrics, Gynecology, and Urology. Other Body Systems can be added to the list, or current Body Systems used in the embodiment can be broken down further into more individual Body Systems.  
         [0132]    The current embodiment of the body systems engine  226  contains the following item:  
         [0133]    A list generator to create a relevant list of Body Systems for the user;  
         [0134]    A Physical Symptoms generator that can retrieve and render all the Physical Symptoms in a given Body System that is relevant to the user; and  
         [0135]    A method for collecting user responses.  
         [0136]    Other embodiments of the body systems engine  226  may include the following:  
         [0137]    A method for transmitting the results of a Body System(s) to the user, either electronically or physically;  
         [0138]    A method for making the user&#39;s responses to a Body System(s) available to a healthcare provider registered with the HIGS  10 ; and  
         [0139]    A method for transmitting a user&#39;s responses to a Body System(s) to an external system or application through the use of a standard interchange mechanism such as Web Services.  
         [0140]    Each Body System contains any number of Physical Symptoms. A Physical Symptom is not limited to one particular Body System and can be included in numerous Body Systems. When a user views an individual Body System, the body system engine  226  will retrieve all applicable Physical Symptoms. The list of Physical Symptoms that are retrieved may be filtered, based on criteria such as gender and user language, to provide the Physical Symptoms that are appropriate for them in the language of their choice. FIG. 6 c  shows the relationship between Body Systems and Physical Symptoms.  
         [0141]    User responses for a particular Physical Symptom should not be limited to a single instance of that Physical Symptom within a particular Body System. By linking a user&#39;s response only to the Physical Symptom to which they responded, and not the Physical Symptom combined with the Body System, assists in educating a user about their own Body Systems. This education can occur due to the fact that when a user has responded affirmatively to a Physical Symptom in one Body System, the same Physical Symptom will then be displayed as an affirmative value in any other Body Systems with which that particular Physical Symptom is associated. This assists the user in visualizing how one Physical Symptom can be affecting multiple Body Systems.  
         [0142]    The body systems engine  226  is an important tool in gathering relevant information about a user. Because of the wide range of Physical Symptoms listed, it is less likely that a user will let important symptoms go unmentioned. Most individuals will “pre-screen” their symptoms, based on what they think is important. This “pre-screening” of their symptoms is often detrimental, because the average individual lacks the medical knowledge to determine which symptoms may be important. All Physical Symptoms are important to gather as they can greatly assist both the user and/or their healthcare provider in understanding the user.  
       Description of Body Systems Drawings  
       [0143]    [0143]FIG. 6 a  illustrates the typical flow of the body systems engine  226 . The body systems engine  226  begins in step  500 . The body systems engine  226  can be launched either through the entering of a web page representing the launching point to the body systems engine  226 , as in the preferred embodiment. Other embodiments can include different starting points, such as through Web Services or through a form in a Windows application.  
         [0144]    Once initialized, the system will proceed to step  502 , the display of Body Systems. Step  502  retrieves a list of relevant Body Systems for the user, based on filtered values. The values commonly used to filter the Body Systems include gender and language. Other embodiments may include additional criteria, or even no criteria.  
         [0145]    Step  502  will also display the resulting list of Body Systems. The exact format of display is flexible, but should be some mechanism that limits the user to selecting only an individual Body System, as in the preferred embodiment, so as to ensure that the user is not given too much information to answer at once. Displaying only a single Body System also limits potential collision that may occur when a single Physical Symptom occurs in multiple Body Systems where a conflict may occur when a user answers affirmative to a Physical Symptom&#39;s occurrence in one Body System displayed, but does not answer affirmative to the same Physical Symptom displayed in another Body System. Other embodiments may provide the ability for a user to select multiple Body Systems for display. The preferred embodiment uses a drop-down list box to ensure that only one Body System can be chosen at a time. Once the user has selected a Body System from the list generated through step  502 , the system then proceeds to step  540  in FIG. 6 b.    
         [0146]    [0146]FIG. 6 b  represents the body systems engine  226 . It is the Body System Engine&#39;s responsibility to render and record the individual Physical Symptoms for each Body System. After the body system engine  226  has been initialized, the system then proceeds to step  542 .  
         [0147]    Step  542  retrieves all relevant Physical Symptom items in a given Body System, based on certain user attributes. In the preferred embodiment, these attributes include gender, to avoid any unnecessary symptoms not directly related to the user&#39;s physicality, and the user&#39;s preferred language, so as to display the Physical Symptoms in the user&#39;s own language (ie: English, Spanish, Japanese, etc.). If a user&#39;s language information is not available, the default language as set in the HIGS  10  is used. In the case of the preferred embodiment, this language is U.S. English. However, the language can be any language; such as Japanese, French, Spanish or Italian. Once the list of relevant Physical Symptoms is retrieved, the system proceeds to step  544  to display the collected Physical Symptom items.  
         [0148]    The Physical Symptom items should be displayed in a way that is easily represented as an affirmative (yes) or negative (no) value. The preferred embodiment uses a series of checkboxes to illustrate a user&#39;s response. This enables a user to check an item to represent an affirmative response, or uncheck it (if checked) or leave it unchecked to indicate a negative/neutral response. Other embodiments may prefer to use a different display method, such as radio buttons, but the checkbox is the easiest representation of a Boolean value available for most user environments.  
         [0149]    Step  544  will not progress to any additional step unless action is taken by the user to save their responses. This action is usually embodied in a “submit” button on the form, as is the case in the preferred embodiment. It is possible to save a user&#39;s responses each time a user makes a change to the state of a Physical Symptom (from affirmative to negative or negative to affirmative). This method is typically unwieldy, especially in a network environment as is the case in a web-based application, as each change in a Physical Symptoms state by the user requires re-submitting and transmitting all data back to the server  18 , then regenerating the page and transmitting the updated page back to the user device  14 . The preferred embodiment does not use this method and only updates a user&#39;s responses when they take the action of activating the “submit” button on the web page.  
         [0150]    Once the required action has been initiated in step  544 , the system proceeds to step  546 . Step  546  is a condition check to determine if the user has updated their Body System results on the current day. Capture of Physical Symptoms is extremely important in understanding a user. Also of importance is the progression of Physical Symptoms. By grouping a user&#39;s response changes together during a given calendar day, it is easier to illustrate the progression of responses. This enables the HIGS  10  to keep a progressive record of a user&#39;s Physical Symptoms as a user selects new Physical Symptoms, or removes old Physical Symptoms, to describe their current condition. Other embodiments of the system may not require the saving of this data in a progressive format.  
         [0151]    If step  546  determines that the user has already updated their Physical Symptoms on the current calendar day, then the system proceeds to step  550  to save the user&#39;s responses. If the user has not updated their Physical Symptoms on the current calendar day, then the system proceeds to step  548 . In embodiments where historical data regarding a user&#39;s Physical Symptoms is not required, this step can be removed and the system would proceed immediately to step  550  after step  546 .  
         [0152]    Step  548  adds a new record that will serve as a root record for the user&#39;s responses. This record will be referred to as the User Body System Response Record. This record contains the user&#39;s unique ID that is generated by the HIGS  10 , as well as a datetime placeholder to represent the current calendar day in which the user saved their responses, and the unique ID of the Body System being taken. Once this record has been created, the system proceeds to step  550 .  
         [0153]    After the creation of the record to hold a user&#39;s responses for a Body System by calendar day as in step  548 , or the determination that such a record already exists as in step  546 , step  550  can store the responses associated with the unique Body System results for that calendar day. The Physical Symptom responses are linked both to the unique ID of the User Body System Response Record, and the unique IDs of each Physical Symptom to which the user answered affirmatively. Only the ID of the current User Body System Response Record and the ID of the Physical Symptom record are needed to store the user response. Although it is possible to also store a Boolean value with this record, it is not required as only an affirmative response to a Physical Symptom will be saved. This greatly reduces the storage space needed in a given database. This method is used by the preferred embodiment. Other embodiments could also store a Boolean value, or may use a different database structure or similar technology, such as an XML document, to represent the saved user results.  
         [0154]    Once the user&#39;s responses are stored in step  550 , the system proceeds to step  552 . Step  552  is an optional step that will either redirect the system back to step  542 , or proceed to the end at step  554 . This step can either use a global system variable to determine whether or not the system should automatically redirect back to step  542  to show the updated Physical Symptom Items with the new user responses, or to require a user action such as a confirmation that the values were saved and a prompt if the user wants to continue adding more responses to this Body System. The preferred embodiment uses a variable in the configuration for the Body Systems System to determine whether or not the redirection should be automatic. The current embodiment also uses automatic redirection and a message to alert the user that their responses were saved correctly.  
         [0155]    Step  554  represents the logical end state and can occur linearly, or it can occur at any time simply by the user leaving the Body System, returning to the root Body System to view another system or to perform additional actions, selecting a new Body System from the list, or other similar action.  
         [0156]    If the user returns to the System that initially called the body system engine  226 , the system can then offer any of the optional components represented by steps  504 ,  506 ,  508 ,  510 , or step  512 , which effectively ends any additional processing. Any of the following could be included in a given embodiment. It is recommended that at least item  508  be included in an embodiment to ensure that the most recent User Body System Response Record is referenced in the user&#39;s PHSP properly.  
         [0157]    Step  504  represents a referral mechanism that can lead a user on to additional Assessments or Body Systems, if required. This referral could be arbitrary, or triggered by the answering of individual Physical Symptoms or groups of Physical Symptoms.  
         [0158]    Step  506  will launch the Changes for Consideration engine to determine if any changes are necessary based on the user&#39;s responses to the Physical Symptoms.  
         [0159]    Step  508  updates any references to previous User Body System Response Records in the PHSP that do not need to be linked to a given User Body System Response Record. This ensures that the PHSP is retrieving the most current Physical Symptom Responses for the given Body System.  
         [0160]    Step  510  can also forward the results of an individual User Body System Response Record to a healthcare provider registered with the HIGS  10 , if desired by the user.  
         [0161]    Step  512  represents the end of processing by the Body Systems System and can be triggered simply by leaving the Body Systems System to view another HIGS system, the logging out of the user&#39;s current session, or simply leaving HIGS altogether.  
       Description of Personal Health Status Profile System  230   
       [0162]    Personal Health Status Profile System  230   
         [0163]    [0163]FIG. 7 illustrates a flowchart for generating a typical PHSP. A typical PHSP is shown in FIG. 10. This process can be abbreviated or expanded upon, based on the need. For example: Wireless users have very limited space to view a PHSP, so they may only be shown previously saved PHSPs because of the lack of viewable screen area on typical wireless devices.  
         [0164]    Step  602  illustrates the start of the PHSP generation process, which could be through a web page, an application, or through other data interchange methods such as a web service. In step  604 , the user determines whether they wish to create a brand new PHSP instance, or view the results of an already saved PHSP.  
         [0165]    Step  606  begins the process of using an existing PHSP by presenting the user with a choice of saved PHSPs. This list could be a series of names assigned by the user, or another identifier such as a date and time combination of when the PHSP was saved. Meaningful information is preferred though, so a user-assigned name may be more helpful then a series of dates, especially when the user can save numerous PHSPs in a short period of time, presenting a confusing number of similar date-time strings.  
         [0166]    Step  608  represents the selection and retrieval of all the information needed for the saved PHSP. This information can be stored as a series of records in a database, XML data containing the unique identities of the items to be displayed and stored in a text file, or as a string in a database record.  
         [0167]    Step  610  prompts the user if they wish to add/remove items from the PHSP they have selected. Although not necessary in all instances, this process helps a user ensure that the PHSP they are generating has all the relevant information they wish. If they do not wish to add/remove any items, then the system proceeds to step  640 , which represents the final retrieval and display of the PHSP items.  
         [0168]    Step  620  begins the process for creating a new PHSP by listing the categories of items (assessments, histories, body systems, and future developed items) from which a user can choose. If they fail to select any items, they are referred back to this list until they successfully select at least one item. After the user selects at least one item, the system proceeds to step  622  to display a list of all the items that can be selected for each category selected in step  620 . This list can be displayed at one time, or step  622  can be repeated for each individual category selected by the user.  
         [0169]    During the process of step  622 , a list is built and retained in memory of each item selected. For ease of use, this list is kept in an XML-based format which can then easily be saved to permanent storage, if the user wishes to save the newly developed PHSP. Once the user selects at least one item from step  622  for each category they selected in step  620 , the system proceeds to step  640  to retrieve and display the PHSP items.  
         [0170]    Optionally, once step  640  is reached, the user can proceed to step  630  to save the PHSP by entering a name for the new PHSP, or being provided a name by the system. Once the name for the new PHSP has been entered/displayed, the system proceeds to step  632 . Step  632  saves the PHSP meta information gathered in step  622 , or retrieved and/or modified through steps  608 - 610 . Once the PHSP meta information is saved, the system acknowledges the save to the user and proceeds to step  640  to display the PHSP again.  
         [0171]    Changes for Consideration System  
         [0172]    The Changes for Consideration System is an education, lifestyle alteration, and health prevention tool. The system provides information to the HIGS user based on their Assessment, Body System, and History responses.  
         [0173]    The primary responsibility of the Changes for Consideration System is to provide information to the user. This information presents changes that a user can consider for altering their behavior and habits in an attempt to effect changes in their daily life that can make them healthier.  
         [0174]    The changes presented to a user can be determined in several ways:  
         [0175]    Through a set of standard changes associated with an Assessment, Body System, or History;  
         [0176]    By matching each response in an Assessment, Body System, or History to corresponding changes for consideration;  
         [0177]    By matching a specific series of responses in an Assessment, Body System, or History to corresponding Changes for Consideration; or  
         [0178]    Triggered through a particular risk level of an Assessment.  
         [0179]    The preferred embodiment uses all of the above methods for determining appropriate Changes for Consideration. Other embodiments may use a subset of the aforementioned methods, or even a series of completely different methods.  
         [0180]    The display methods for the Changes for Consideration can take a variety of forms:  
         [0181]    A short text block that can easily be displayed as a sentence or two;  
         [0182]    A paragraph block with a descriptive header (similar to a news tagline);  
         [0183]    A title, description, and a large body of text that can be displayed as a complete web page;  
         [0184]    A link to a file for download; and  
         [0185]    A title and hyperlink to an external web page, possibly provided by a third party.  
         [0186]    The preferred embodiment uses all of the above-mentioned display forms for the Changes for Consideration System. Other embodiments can use a subset of the aforementioned display methods for the Changes for Consideration, or a completely different series of display methods.  
       Description of Changes for Consideration Drawings  
       [0187]    [0187]FIG. 8 illustrates a typical embodiment for the Changes for Consideration Process. In the preferred embodiment, the Changes for Consideration system is always called from another system, such as the Assessment, Body System, or History System. Other embodiments may wish to make a stand-alone version available so that the Changes for Consideration System can be called from a third-party system outside of HIGS, or from new or altered functionality.  
         [0188]    The Changes for Consideration System begins processing at step  700 . In the preferred embodiment, the Changes for Consideration System is initialized and loads values passed to it from the Assessment, Body System, or History System.  
         [0189]    In the preferred embodiment, the values passed to the Changes for Consideration System in step  700 , typically include:  
         [0190]    A unique ID referencing the particular instance of an Assessment, Body System, or History System that the user has taken;  
         [0191]    The user&#39;s own unique ID;  
         [0192]    The string or integer that corresponds to the appropriate language for display; and  
         [0193]    A value indicating what type of System (Assessment, Body System, History) data is being sent.  
         [0194]    In other embodiments, it may be necessary to provide a different set of variables to initialize the system, depending upon the configuration and requirements. After the Changes for Consideration System has been initialized, the system proceeds to step  702 .  
         [0195]    Step  702  determines from what type of item the system is generating changes. In the preferred embodiment, this is done by utilizing the variable containing the type of information that is passed to the Changes for Consideration System on initialization in step  700 . Other embodiments may use different methods for determining the item type.  
         [0196]    Once the type of item for which the system is generating changes has been determined, the system can determine how best to proceed with the execution of step  704 . Step  704  retrieves the relevant Change Items. With the information determined by step  702 , step  704  can access the correct database to ensure that the system is comparing the proper responses. In the preferred embodiment, step  704  uses configuration variables held in an external data source, such as a secure file, containing the information to connect to the each of the other system databases, as needed.  
         [0197]    Once the list of Change Items is retrieved from step  704 , the system proceeds to step  706  for display. In step  706 , the system begins displaying the Change Items. In the preferred embodiment, the system determines how to display the Change Item depending upon what information is available. For example, in the preferred embodiment, if there is a text body for the Change Item, but no title, the contents of the text body is displayed. If there is a text body and a title, the preferred embodiment of step  706  displays the title as a link to a web page, which then displays the text body of the Change Item. Other embodiments may not wish to take this approach and, instead, may want to hard-code a specific means of displaying the Change Items.  
         [0198]    If a Change Item is displayed as a title with a link to display the text body, or a title and description with a link to display the text body, the system proceeds to step  708  when the user clicks on the link or button used to trigger the display of the full text body.  
         [0199]    Step  708  launches a new web page to view the Change Item. In the preferred embodiment, this will open a new browser window so as to not interfere with the user viewing their other information. Once launched, the system proceeds to step  710 .  
         [0200]    Step  710  both retrieves the appropriate Change Item needed by step  708 , and displays the title and text body. The user can close this new browser instance at any time. Once finished, the system proceeds to step  712 .  
         [0201]    Step  712  represents the end point of the Changes for Consideration System and the system then shuts down and returns control to the system that called it.  
         [0202]    Physician System  
         [0203]    The Physician System is responsible for providing access for a physician to a user&#39;s PHSP(s). The system is designed to assist a physician by granting them limited access to user information.  
         [0204]    In order for a physician to have access to a user&#39;s information, a user must grant the physician access to their information or PHSP. To protect a user&#39;s information, the user will always have control over what information is shown to a physician. By having immediate access to PHSPs, or other items selected by the user, a physician can save valuable time. This information provides an excellent pre-cursor to an office meeting between a user and their physician.  
         [0205]    The Physician System is, essentially, a simple data retrieval system enabling physicians access to associated user information. It is possible to expand upon this in additional embodiments. In other embodiments, it may be desirable to have a physician assign or prescribe specific tasks for a user, such as completing specific Assessments, Body Systems, or Histories on a one-time or recurring basis. The preferred embodiment only enables a physician to view user-selected items.  
       Description of Physician System Drawings  
       [0206]    [0206]FIG. 9 illustrates the Physician System. The system starts with step  800 . In the preferred embodiment, step  800  occurs immediately after a physician logs into the system. Once the Physician System is successfully initialized, the system proceeds to step  802 .  
         [0207]    Step  802  retrieves and displays all users associated with a particular physician. In the preferred embodiment, these users are associated with a particular physician(s) only at their request, making a user more comfortable that they are controlling their information.  
         [0208]    Once the list is retrieved and displayed in step  802 , the system waits for the physician to select a particular user to view their information. Selecting a user from the list will trigger the system to proceed to step  804 .  
         [0209]    Step  804  is responsible for displaying the user&#39;s information, as well as any PHSPs or other items that the user has enabled the physician to view. The system will then wait for the physician to select a PHSP or other item for viewing. When the physician selects a PHSP or other item, the system is triggered to proceed to step  806 .  
         [0210]    Step  806  displays the information from the PHSP or other HIGS item including the user&#39;s results. The information the physician will see is identical to the information displayed to the user. Once the physician has finished viewing the results, the system can proceed to either step  808 , which represents the end of the session and the physician logging out of HIGS, or the system can return to step  804  to view other information in the user&#39;s account, or to step  802  to view the list of users again.  
         [0211]    In the preferred embodiment, only the user&#39;s name is displayed to the physician. Other embodiments may make it available to the user to choose additional information to provide their physician(s) such as email address, telephone number, etc. Other embodiments may also wish to provide a means of communication through HIGS for a physician and a user.  
         [0212]    Changes may be made in the embodiments of the invention described herein, or in the parts or the elements of the embodiments described herein, or in the steps or sequence of steps of the methods described herein, without departing from the spirit and/or the scope of the invention as defined in the following claims.