JP2008210399A - Disease management system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a system for an automated long-term disease management of a patient based on knowledge. <P>SOLUTION: Disease management is performed in a perfectly automated manner using a periodic interactive dialog with a patient so as to acquire health state measurements from the patient, evaluate and assess the progress of the patient's disease, review the therapy and adjust it to the optimal level, manage the treatment, and give the patient the medical advice for coping with a sudden and rapid episode of the disease. The patient's health is promoted in an automated way that reduces the intervention of medical care that requires a huge cost. The system is specially designed to accumulate and use the information unique to a patient so that the disease management can be adapted to individual cases. As a patient is managed over a long period of time, a profile is built in the form of the frequency of and the reason for the patient's contact with the system, the patient's subjective understanding of the disease, the patient's objective response to various treatments, and the patient's preference on treatments. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates generally to medical knowledge systems, and more particularly to computerized long-term management systems for patient diseases.

  Health is the basis for our lives. Medicine consists of diagnosis and treatment. The diagnostic means find the cause of the patient's problem and the treatment is the application of the best available therapy. However, not all diseases can be completely cured by treatment.

  Diseases such as asthma and diabetes may require treatment on a regular schedule called therapy throughout the life of the patient. In this case, the disease is managed rather than treated. Disease management is the management of patients with known diagnoses with the intention of educating patients to eliminate costly medical interventions and promote patient well-being, and the sudden onset of disease symptoms. It may be defined as monitoring to prevent severe onset. Because patients may respond differently to the same treatment, eg, certain drugs, the therapeutic portion of disease management must be performed individually to suit a particular patient's response.

  Because disease management creates recurrence costs for society, there is a strong desire to reduce costs. To understand why the goals deserve to be realized, you must understand an extremely uniform healthcare system. Advocates of a completely uniform fee system argue that everyone will work. Ultimately, no one will be ill and there will be no patients, so the doctor will be paid for patients who do not see. In a completely flat fee system, every person in the world pays a predetermined amount per month to a health maintenance organization whose sole purpose is to keep the person healthy. This is a commendable goal, but it is impossible to achieve. However, a feasible goal is to automate the way diseases are managed.

  The overall concept of disease management is, in the extreme case, to visualize a doctor who is spinning around a patient 24 hours a day. Of course, this is a solution that is not feasible in many cases. To reduce costs, doctors' knowledge must be disseminated to the general public. One solution would also be to not require the physical presence of a doctor where the patient is.

  Much of medicine is algorithmic. That is, the diagnosis is followed by a series of steps to isolate the cause of the problem. Advanced Cardiac Life Support Therapy (ACIS) and Advanced Trauma Life Support Therapy (ATLS) have shown how many cares can be improved by setting standards. Some standards may be translated into a pharmaceutical algorithm, which can help set care standards for the physician. The concept of telephone health check has been proven by national toxic control centers. Also, doctors, especially pediatricians, have been performing therapy over the phone since the phone was invented. In fact, the first word spoken over the phone was a call for help. On March 7, 1876, Alexander Graham Bell spilled battery fluid for the phone and shouted, "Come on, Watson, I need you." Today's so-called telemedicine remains in a one-to-one relationship. The telemedicine phenomenon depends in part on the best practice guidelines that will help to ensure a consistent practice of medicine.

  Disease management is not less than a redesign of medical practice. The medical problem was mainly one of information and how to combine that information. Advances in disease management are now possible due to the development of personal computers and standards. In the past, doctors are medical information warehouses that organize medical information so that it has clinical significance. However, now these functions can be performed in an automated manner using means of telecommunications and computer technology.

  Disease management can include coordinating care for patients throughout the entire health care sequence from birth to death. Disease management has programs available for all parts of everyone's life, including prevention, diagnosis, treatment and rehabilitation. This process includes the management of healthy patients as well as patients with certain diseases. Often, providers focus on providing intensive and costly services to patients with severe manifestations of disease symptoms. In order to improve the health of the entire population, disease management argues that it places a great focus on preventive and integrated care. In a sense, disease management takes medical practice from the doctor's hand and places it in the patient's hand.

  Almost all “knowledge-based” clinical reasoning is better performed and more reliable by computers. Technology promotes the democratization of medicine. In particular, in disease management, a system that can automate the practice of medical care and a system that encourages and trains patients to play a major and beneficial role in medical health care is highly desirable. Such a system should provide a sustainable, substantial and significant competitive advantage in the flat rate healthcare market. Such systems can automatically identify critical periods in any disease process so that interventions are best utilized clinically, economically and humanely. Should be.

Retrieving a patient's medical record corresponding to a particular patient having a known medical condition from memory, assessing the patient's health, automatically asking the patient, and health Automatically receiving an answer from the patient to obtain data; automatically storing the obtained health data in the patient's medical record; and part of the patient's medical record. Automatically selecting a corresponding specific health parameter; automatically calculating a change from a previous disease management session of the patient's health status indicated by the health parameter; and Automatically comparing disease specific changes to the medical disease, and automatically indicating data indicating adjustment of disease therapy for the specific patient based on the obtained health data and the comparison A computerized disease management method comprising assessing the health of the patient including outputting to a medical advice module capable of automatically providing medical information to a particular patient; and for each of a plurality of patients A computerized medical advice system comprising an authorization database having authorization information indicating a level of accessibility allowed for the medical information, the authorization information having an authorization database having an authorization level for the particular patient.

  In one embodiment of the present invention, there is a computerized disease management method that includes assessing the health of a patient with a disease and optimizing a therapy for the disease based on the health assessment of the patient.

  In another embodiment of the invention, comprising a subjective health measurement in an electronic medical record corresponding to a particular patient, and comprising an objective health measurement in the electronic medical record; There is a computerized correlation assessment method that includes calculating a metric based on the subjective health measurement and the objective health measurement.

  In yet another embodiment of the invention, comprising a critical curve for a particular disease, comprising a plurality of health parameters in an electronic medical record corresponding to a particular patient having the particular disease, There is a computerized critical curve assessment method that includes comparing at least one health parameter with the critical curve to obtain assessment information.

  In yet another embodiment of the present invention, a disease management module capable of automatically providing therapy information for patients with health assessment and disease, and the level of accessibility allowed for health assessment and therapy information There is a disease management system having an authorization database having authorization information indicating.

  Yet another embodiment of the present invention is a medical advice module capable of providing medical information to a patient, and a computerized medical advice system having an authorization level combined with the medical advice module.

  In yet another embodiment of the present invention, determining the availability of objective and subjective health measurements for a particular patient with a particular disease, and for said patient based on the available objective health measurements There are computerized methods of therapy optimization that include adjusting therapy or adjusting therapy for the patient based on objective health measures that are not available and subjective health measures that are available.

  In yet another embodiment of the present invention, a plurality of groups of questions indicative of assessing patient health, wherein each group is indicative of assessing patient health regarding language level understanding. Identifying an understanding of the language level of a particular patient, selecting one of the groups of questions based on the identified language level, and from the selected group There are computerized question explanation methods that involve asking the patient questions.

  In yet another embodiment of the present invention, computerized comprising encoding a patient's subjective pain perception into a pain code and diagnosing the disease by indexing a disease database with the pain code. There have been medical diagnostic methods.

  In yet another embodiment of the invention, providing a treatment change authorization level corresponding to a particular patient having a particular disease, automatically determining a therapy adjustment for the patient, and the treatment change authorization level. There is a computerized treatment modification method that includes recommending the therapy adjustment to the patient as permitted by.

  In yet another embodiment of the invention, the patient is allowed to set a preview mode for the medical script, ask questions about the patient's health, and receive information about the results of answering the questions. And a computerized preview mode method that includes resetting the medical script as if the question was not answered.

  In yet another embodiment of the invention, providing a plurality of parameters, asking a selected question from a medical script, waiting for a preset time for responding to the question, There is a computerized no response method that includes performing an action based on the parameter after a preset time has ended without response.

  In yet another embodiment of the invention, filtering critical symptoms of a particular patient with a particular disease and obtaining an initial health measurement from the patient if the patient has not been previously evaluated. There is a computerized health assessment method that includes accumulating and, if the patient has been previously evaluated, obtaining and accumulating subsequent health measurements from the patient.

  In a final embodiment of the invention, determining the severity of a critical symptom obtained from a particular patient with a particular disease and assessing the health of the patient if the severity level is sufficiently low And a computerized critical symptom filtering method that includes taking a predetermined action if the severity level is sufficiently high.

  The following detailed description of the presently preferred embodiment sets forth one specific embodiment to assist in understanding the claims. However, the invention can be embodied in a number of different ways, as defined and protected by the claims. This will be described with reference to the drawings. Like numbers refer to like parts throughout the drawings.

  The detailed explanation consists of the following items.

System Overview System Process and Database Top Level System Process Flow Disease Management Overview Disease Management Module Open Session Health Assessment Critical Symptom Filter Severity Assessment Initial Health Assessment Current Health Assessment Correlation Assessment Criticality Curve Assessment Therapy Optimization Therapy Adjustment ( Subjective)
Therapy adjustment (objective)
Patient consent level Closed session Question version Preview mode feature No response feature PQRST sequence Disease management order (DMO)
Authorization database Regulatory authorization Sharing authorization Treatment modification authorization level (TAPI)
Meta structure Meta function Benefits of disease management
System Overview With reference to FIG. 1, a computerized knowledge-based medical management system 100 will be described. A disease management module (DMM) 80 and several other high-level service modules 82 perform automated medical services for users of the medical management system 100. The service module 82 may have diagnostics, treatment tables, automated demand management, audio / visual / image libraries, and author access. DMM 80 handles tasks combined with disease management (DM). Its primary goal is to promote patient welfare, educate patients, and reduce expensive medical interventions. The user may be the patient 114 or an assistant for the patient. Throughout this specification, the terms “user” and “patient” are used interchangeably. However, it will be understood that a user may be used as a surrogate for a patient. In this case, the user is registered as an assistant for the patient. As described below, the system 100 uses an appropriate registration and login process for either the patient or the assistant.

  Modules 80 and 82 are supported by the operating system and support software 88 of embedded computer hardware platform 110, by a number of databases 84, and by computing environment 90. The entire computer hardware-software-communication complex is operated and maintained by support staff. All application tasks in DMM 80 are fully automated. Contact between the outside of the patient, doctor, clinic, pharmacy, laboratory, etc. (92 in total) and the DMM can be done using an interactive voice response (IVR), “ It is handled by an automated communication system such as direct modem-to-modem access or access via the Internet 102. Patient 114 uses computer 116 and monitor 118, telephone 124, or other components to communicate with system computer platform 110. Part of the component is described below in connection with FIG. 2a.

  With reference to FIG. 2a, a block diagram of one embodiment of the medical management system 100 will be described. The system 100 has a network 102. Network 102 may represent a local area network (LAN), a wide area network (WAN), the Internet, or other connection service.

  System programs and databases may reside on a group of servers 108 that are preferably interconnected to network 102 by LAN 106 and gateway 104. Alternatively, system programs and databases may reside on one server 110 that utilizes network interface hardware and software 112. System server 108/110 stores modules 80 and 82 (FIG. 1).

  The network 102 may be connected to the user computer 116 using, for example, a modem or using a network interface card. To remotely access system programs, a user 114 of computer 116 may utilize browser 120 using a keyboard and / or a display device such as a pointing device and monitor 118. Alternatively, when the system program is executed on the computer 116 in local mode, the browser 120 is not utilized. A video camera 122 may optionally be connected to the computer 116 to provide visual input such as visible symptoms or signs. Furthermore, clinical sounds can be captured by a video camera or another microphone (not shown).

  Various other devices may be used for communication with the system server 108/110. If the server is equipped with voice recognition or DTMF hardware, the user can use the telephone 124 to communicate with the system program. An example by phone is US patent application Ser. No. 08 / 176,041, filed Dec. 29, 1993, entitled “Computerized Medical Diagnosis and Treatment Advice System”, now US Pat. 660,176. Other connection devices for communicating with the system server 108/110 include a portable personal computer having a modem or wireless connection interface, a cable interface device 128 connected to the display device 130, or a satellite receiver 134. And a satellite receiving antenna 132 connected to the television 136. Other ways of communicating between the user 114 and the system server 108/110 are also conceivable.

  Referring to FIG. 2b, a schematic diagram of one embodiment of server computer 110 illustrates some possible interconnections with the network. In order to execute the script, a special program called a script engine is used. The script engine reads the medical diagnostic script file and uses the code to perform an interview operation that outputs a question to the patient and inputs an answer. In addition, the script may collect answers from the patient, evaluate the answers, make a diagnosis, and update the patient's medical records. The script engine may also reside on the user's computer 116 (FIG. 2a). The script engine may be stored on a hard drive or CD-ROM and loaded into main memory or cache for execution.

  The components of the presently preferred server computer 110 of the computerized medical system 100 according to the present invention are shown in FIG. 2b. Server computer 110 has a plurality of components in the enclosure. Telephone line 156 connects public telephone network 158 to computer 110 via modem 160. The telephone network 158 may be connected to the network 102, which has a connection with the system server 108/110. Alternatively, the computer 110 may connect to the network 102 using a network interface card 164.

  Hardware and system software are assembled with two basic concepts in mind: portability to other operating systems and the use of industry standard components. In this way, the system is more flexible and allows competition in the free market to continually improve the product while simultaneously reducing costs. Although specific hardware and software are referenced, it will be understood that different components may be used in the system.

  Computer 110 is preferably a personal computer having an Intel Pentium microprocessor 170. Other computers such as Apple Macintosh, Amiga, Digital Equipment Corporation's VAX, or IBM mainframe may also be used. The modem 160 or the network interface card 164 is connected to the ISA or PCI bus 162. The bus 162 interconnects the microprocessor 170 with a plurality of peripheral devices via a controller circuit (chip or substrate).

  The computer bus 162 has a plurality of peripheral devices connected via adapters or controllers. A video adapter board 172, where SVGA or better resolution is desired, is interconnected to the video monitor 118. The serial communication circuit 176 is connected to a pointing device such as a mouse 178. In other embodiments, parallel communication circuitry may be used in place of circuit 176. The keyboard controller circuit 180 is connected to the keyboard 182. A hard disk drive 184 of 500 Mb or greater and an optional CD-ROM drive 186 are preferably connected to the bus 162. The hard disk 184 stores database files such as patient files, DM files, other system files, and binary support files. CD-ROM drive 186 also stores database files and binary support files.

  The main memory 190 is connected to the microprocessor 170. In one embodiment, computer 110 may operate under Windows 95 operating system 192. The memory 190 executes a diagnostic script engine (not shown) and a disease management module (DMM) process 220. Some parts of the disease management module process software may be written in Borland Delphi's Pascal, version II, and other parts may be written in Microsoft C, version 7.0. Further, in one embodiment, the database is embodied in other database programs such as Microsoft Foxpro or a SQL compatible relational database program.

System Processes and Databases Referring to FIG. 3, a portion of the processes, files and databases used by the medical management system 100 will be described. Except for the DMM process, authorization database, imaging modality database, laboratory test database, disease database, and other DM specific databases described below, these processes, files and databases are US Pat. No. 5,660,176 entitled “Medical Diagnosis and Treatment Advice System”.

  The medical management system 100 uses several key processes and associated databases. A set of patient / assistant login processes 200, 210 and 212 are used by the system 100 to identify patients who have previously been registered with the system in one of three ways. 1) Request a patient identification number (PIN) in process 200. 2) Identify assistants that have been previously registered with the system by requesting an assistant identification number (AIN) in process 210; Or 3) Identify a patient with an assistant who has previously been registered with the system by requesting a patient identification number at process 212. One of a set of processes 202, 214 or 216 is used to register a patient or assistant. If the user is a patient, the patient registration process is used by the system in process 200 to register a new or first patient. If the user is not a patient, the assistant registration process is used by the system at process 214 to register a new or first assistant. Next, if the patient is not already registered, the supported patient registration process is used by the system in process 216 to register the patient.

  When the user is logged in or registered, the system gives a selection of processes. The main process for this example is the DMM process 220 that manages the disease or patient state ID. The DMM process 220 may access the laboratory test selection database 260 or the imaging modality selection database 258 during disease management and access the treatment table 250 to obtain current treatment information for a particular disease or diagnosis. May be. The patient and assistant registration database 240, consultation history database 242, patient response database 244, medical history object database 246, patient drug therapy database 248, in-process database 252 and patient medical history database 254 are combined with these processes. Yes. These databases have electronic medical records for each patient registered in the medical system 100. The electronic medical record contains all the information about each patient. The authorization database 256, disease database 262, and other DM specific databases 264 are described below. In other embodiments, other choices are added to access other medical information processes.

Top Level System Process Flow With reference to FIGS. 4a, 4b, 4c and 4d, medical management system software top level flow 300 is described. The telephone number used to access system 100 via the telephone may vary in various embodiments of the system. If the sponsoring organization or hospital wants to provide access to the medical management system 100 without incurring costs to the caller, a free (eg, 800, 888 or other number) service number can be used. If the sponsoring agency or hospital wants to recover the operating costs of the system 100 from the caller, it may use a paid call or a premium billing number (eg, 900 services). A "Current Procedural Terminology" (CPT-4) code can be used to explain and send an invoice to a third party payer for a telephone consultation. The current procedural term code is a descriptive list of terms that identify codes for medical service reporting and procedures. The CPT-4 code is the most widely accepted name for reporting medical services to insurance companies. If the system 100 is accessed via the Internet or other network, an appropriate web address is provided to the user.

  In the start state 302, a user 114 (FIG. 1) desiring medical advice dials the telephone number of the system 100 from the telephone 124 (FIG. 2a). The user may be a patient or may be an “assistant” helping the patient, such as a parent, relative or friend. Alternatively, the user may access the system 100 from the user computer 116 via the Internet as described above. Turning to state 304, the system 100 automatically answers the call and plays a conversation file stored on the system hard drive using a speech synthesis board such as 0/410 from Dialogic, Welcome the caller 114 with a preface greeting message. Alternatively, if the user is using the browser 120 (FIG. 2a) or other user interface on the Internet 102, the greeting message is displayed to the user on the display device 118. As stated above, the system 100 communicates with the user 114 by telephone or by a message displayed on a display device. The next stage of the process or function flow chart describes only one form of communication with the user for the sake of brevity.

  At state 306, the system 100 asks each patient calling the system a series of “initial screening questions”. These questions are designed to identify critically ill patients and are not designed to identify patient challenges. The initial screening questions allow the system to screen patients who need immediate medical care.

  A patient who turns to decision state 308 and is found to be in a critical condition is instructed to call emergency response telephone number “911” in state 309 or automatically to the nearest emergency medical service system in the patient's area. Connected. The session is terminated by process 300 in state 310. The following is an example of an initial screening question.

・ Emergency medical care?
・ Respiratory difficulty?
・ Do you feel severe pain or pressure on your chest?
If the system determines that the patient needs emergency medical care, in state 311 the system may provide the patient with a menu of emergency medical procedures. If the patient or caller on behalf of the patient is far away from the nearest emergency assistance, for example in a rural environment, the user may need to initiate an emergency procedure immediately. The emergency medical procedure menu offers the user several options. If the user presses the touch tone key “1” or speaks “1” to the telephone handset, the process 300 branches to state 312 and the known CPR (cardiopulmonary resuscitation) information is explained. The If the user has a speakerphone function combined with the telephone 124, the user may be able to listen to the explanation and use the instructions given by the system 100 without using the hand away from the telephone. . If the caller presses the touch tone key “2” or speaks “2” to the telephone handset, the process 300 branches to state 313 where Heimrich Hug information for a known stuffy breath is explained. . When state 312 or state 313 is complete, the session ends at state 314.

  In state 308, if it is determined that the patient does not require emergency medical care, that is, if the system 100 is satisfied that there is no immediate life-threatening condition, to determine whether the user is an actual patient. Process 300 moves to decision state 315. If so, the process 300 determines whether the patient has previously registered or has consulted the system 100, i.e., the patient is not a new patient or is the first call. Proceed to decision state 316 to determine if it is a person. If so, in the login process 200, the system 100 verifies the patient's identity and retrieves the patient's medical record. When process 200 is complete, process 300 proceeds to state 344 (FIG. 4d) via interpage connection symbol C317. If the patient is not registered, as determined at decision state 316, the system 100 proceeds to a patient registration process 202 for the new patient. When process 202 is complete, process 300 proceeds to state 344 of FIG. 4d via interpage connection symbol C317.

  As determined in state 315, if the user is not a patient, process 300 proceeds to decision state 320 of FIG. 4b via interpage connection symbol A318. For example, there may be times when a patient may not be able to use the system 100 directly due to injury, weakness, or a state of consciousness change. In these cases, an “assistant” may interact with the system for the patient.

  The assistant registers with the system via the assistant registration process 214. The assistant registration record is structurally identical to the patient registration record, but the three fields ASST_PERM, ASST_EXP, and RELATIONS have special meaning to the assistant. The ASST_PERM field is a Boolean flag that can be set truly offline only by a system administrator who has confirmed through other means that there is a relationship between the patient and the assistant. The relationship is one-to-many, i.e. one patient may have more than one assistant, and one assistant may relate to more than one patient. The ASST_PERM flag may be further limited by the ASST_EXP field. The ASST_EXP field contains a time stamp for the expiration date of the ASST_PERM attribute. If the ASST_PERM flag is true, then the RELATIONS pointer is set to one or more patient records for which this assistant is a “permanent assistant”, otherwise the RELATIONS field is empty.

  If the following three conditions are met, the medical information collected during the assisted consultation is written to the patient medical record.

  (A) The assistant's ASST_PERM flag is true.

  (B) The ASST_EXP time stamp has not been reached.

  (C) The assistant has a relationship pointer to the patient record. If one of these conditions is not met, new medical information collected for this patient is saved in a pending file 252 (FIG. 3) for offline verification by the system administrator.

  In state 315, the system 100 determines whether the user is a patient or an assistant. If the user is not a patient, the system then determines that the user is an assistant and in decision state 320 checks to see if the assistant is registered. If the assistant is not already registered with the system, the system registers the new assistant with the assistant registration process 214. If the assistant is already registered with the system 100, the process 300 performs an assistant login process 210. When process 214 or process 210 is complete, process 300 proceeds to decision state 321.

  As determined in decision state 321, if the patient is not already registered in system 100, the system then allows the assistant to register a new patient in supported patient registration process 216. However, as determined in state 321, if the patient is already registered in the system 100, the process 300 performs a supported patient login process 212. Upon completion of process 216 or process 212, process 300 proceeds to decision state 334 of FIG. 4c via interpage connection symbol B327.

  In decision state 334, process 300 determines whether the patient's date of birth is in the patient's medical record. If so, process 300 proceeds to state 344 of FIG. 4d via interpage connection symbol C317. If not, the system 100 attempts to obtain the patient's date of birth. Turning to state 335, the system 100 asks the assistant if he knows the date of birth of the patient. If so, process 300 proceeds to state 336 to request the patient's date of birth. In state 337, the system 100 repeats the patient's date of birth obtained in state 336. In decision state 338, the assistant verifies that the date of birth read back by system 100 is correct. If not, process 300 loops back to state 336 to again determine the patient's date of birth. If the patient's date of birth identified in state 338 is correct, the process 300 flags the date of birth in state 339 to proceed to state 344 in FIG.

  As confirmed in state 335, if the patient's date of birth is not known, process 300 proceeds to state 340 and the system asks the assistant to indicate the approximate age of the patient. Patient age is an important parameter used by the DMM process 220, diagnostic module and treatment table 250. In state 341, the system 100 repeats the approximate age of the patient obtained in state 340. In the decision state 342, the assistant checks whether the age read back by the system 100 is correct. If not, process 300 loops back to state 340 to request the patient's approximate age again. If the approximate age of the patient identified in state 342 is correct, then in state 343 the system 100 advises the assistant to prepare the patient's actual date of birth before the next consultation, as shown in FIG. Proceed to state 344. The system 100 uses the approximate age in the session between the diagnostic module and the treatment table 250.

  In state 344 of FIG. 4d, system 100 presents a system selection menu to the user. Now, the caller is asked to choose from the following six options: diagnostic system, treatment table, disease management, audio / visual / image library, automated demand management, or end session. .

  A. Diagnostic system: The system starts the evaluation process 280 with a menu. In the menu, the system asks the patient to begin identifying the illness.

  B. Treatment table: The system guides the patient to the treatment table process 250 in the menu. In the menu, the system asks the patient to select a treatment selection method.

  C. Disease Management: The system initiates the DMM process 220 and the system first checks to see if the patient has used the disease management module previously. This process is described in detail below.

  D. Audio / Visual / Image Library: The system initiates an audio / visual / image library process 282 that allows the patient to hear a medical checkup sound, show a medical checkup video, or view a medical checkup photo or other image.

  E. Automated Demand Management: The system is an automated demand management process to help patients determine if a doctor should be, if so, who should be, and when a doctor should visit. Start 284.

  F. End session: The system performs several stages and ends the session.

  At the end of the evaluation process 280, the system 100 gives the patient the option of selecting another disease. Upon completion of the treatment table process 250, the system gives the patient the option of selecting another treatment. Upon completion of the audio / visual / image library process 282, the system 100 gives the patient the option of selecting another audio clip, video, or image. Upon completion of the automated demand process 284, the system 100 gives the patient the option to receive advice for other problems.

  Upon completion of the evaluation process 280, treatment table process 250, disease management module process 220, audio / visual / image library process 282, or automated demand management process 284, the system 100 loops back to state 344 to the user. Provide the system selection menu again. If the user selects an end session selection in state 344, system 100 moves to decision state 345. In decision state 345, system 100 determines whether process 280, process 250, process 220, or process 284 did not occur in the information mode. That is, to determine if it occurred in real mode or pending mode, and to check if any of the configured memory variables are past medical history conditions that need to be saved in the patient history file, Look up the symbol table corresponding to your patient. If both conditions are true in state 345, system 100 proceeds to decision state 346 to see if consultation is in real mode. If not, the consultation is in pending mode and the system 100 then writes the new patient information obtained during the consultation to the pending file 252 in state 347.

  If the decision state 346 is true, i.e. real mode, the data is stored in the patient history file to confirm that the data is correct for each past health condition that needs to be evacuated. In state 348, the system 100 requests the patient to allow evacuation. For example, during consultation for asthma, system 100 may have learned that a patient has been diagnosed with HIV positive. “Can I record information about your HIV diagnosis in your medical records?” System 100 will ask. If the patient answers “yes”, then the system 100 will ask, “Make sure your diagnosis for HIV was positive, this is correct”. If the patient answers “yes”, the system 100 then writes a score indicating the diagnosis and accuracy of the system to the patient's medical history file. After confirmation, each data item is stored in the patient's file in 254 (FIG. 3) in the patient history database.

  Upon completion of either updating the patient history database 254 in state 348 or determining that state 345 is false, or upon completion of state 347, process 300 moves to decision state 349. Before the system 100 finishes the consultation with the patient, the system 100 presents a summary of all the advice given. During a telephone session, the patient is asked to write down the key points and repeat. The system 100 then gives the patient the option of receiving a summary of the consultation session and the specific recommendations provided by the system via fax, e-mail (e-mail) or postal services such as first class mail. To give. If a fax or email is desired, the process 300 proceeds to a decision state 350 to verify that the information is available for sending a summary and recommendation. If not, the process 300 asks the patient at state 352 for information, such as a fax number, email address, or postal address. Patients also have the option to have a consultation summary sent to their health care provider or specialist. Proceeding to state 351, process 300 adds a copy of the current telephone session to the fax queue or e-mail queue as needed for the next transmission. Upon completion of state 351, or if in state 349 process 300 determines that a session copy should not be sent, the session ends in state 353.

Disease Management Overview The present invention has a computer program called a disease management module (DMM). The disease management module is one of several high level service modules that provide automated medical services to users of the medical management system 100. In this context, disease management (DM) refers to the continuous treatment of a patient who has been diagnosed with a specified health problem called a disease. DDM may continue treatment throughout the life of the patient. DMM assesses and assesses the patient's disease progression, reviews and adjusts the therapy to the optimal level, and provides the patient with medical advice to treat and deal with sudden and severe manifestations of disease symptoms Therefore, disease management is performed in a fully automated manner using periodic interaction with the patient to obtain health status measurements from the patient. The goal of the disease management module is to promote patient health in an automated manner that reduces costly medical interventions.

  Various features of DMM software are specially designed for storing and using patient-specific information so that disease management can be more adapted to individual cases. As the module manages a single patient over a long period of time, the module will determine the frequency and reason for patient-to-DMM contact, the patient's subjective understanding of the disease, the patient's objective response to various treatments, and the patient's treatment Build a profile about the case in the preferred format. The module then uses that knowledge to coordinate internal procedures, so the module adapts even more to individual patients.

  When a patient is first enrolled in the DM, the DMM performs a registration procedure that verifies the patient's medical history, initializes initial therapy for the patient's disease, and schedules for patient contact. For every registered DM patient, the DMM conducts periodic automated sessions with the patient. During each session, the DMM obtains and updates the patient's medical history with the latest health measurements, analyzes and evaluates the patient's health as needed, adjusts the therapy as necessary, and provides the appropriate medical care for the patient. Give above advice. At the end of each session, the DMM schedules the next session. Eventually, by moving the patient to another state, such as medical care by a human doctor, care by a diagnostic module in the medical system, or normal health with appropriate follow-up medical examination, the DMM will cause the patient to become ill. Release from the managed state.

  To illustrate the features in the overall context, the overall features of the DMM module are summarized here. Each feature will be described below.

  In all contact with the patient, the DMM must ensure that it adheres to a number of permits, consents and approvals given by various agencies. DMM uses an authorization database to manage these regulatory data.

  DMM uses scripts to conduct online interactive conversations with patients (or their agents). A script is a special computer program that can output text and questions to a patient, wait for a response from the patient, record the response, and perform the following actions based on the response. The development and use of the script is described in US patent application Ser. No. 08 / 893,402 filed Jul. 11, 1997 entitled “Computerized Medical Diagnosis and Treatment Advisory System Including List-Based Processing” and “Network Access”. In a PCT application claiming priority under US patent application Ser. No. 08 / 893,912 filed Jul. 11, 1997, entitled “Computerized Medical Diagnosis and Treatment Advice System Comprising”.

  Standard online conversations with patients take the general form of a series of scripted questions and patient answers. As the script is executed, the script considers the patient's current situation, selects questions, and presents questions to the patient. The patient answers, the script analyzes the answer and selects other questions. This process is performed until the session ends normally.

  The script preview mode for DMM allows a patient to answer a question in “look ahead” mode to know what will happen to the result of the answer without formally selecting the answer. Abnormal script termination can be handled by the DMM in an intelligent proactive manner using a no-response function. If the patient suddenly fails to answer in the middle of a conversation, this function can be applied to all known about the patient, i.e., the patient's location and the disease being managed to respond proactively, if necessary Can be used, including the ability to contact a nearby emergency support facility or call 911 for the patient.

  The DMM makes all contact with the patient in the form of a disease management session. A disease management session is an online conversation with a regularly scheduled patient. A DM session can be initiated either by the patient calling the medical system (inward) or by the system calling the patient (outward). Every DM session consists of four main tasks performed in the order of open session, health assessment, therapy optimization and closed session.

  The open session task initializes the data and registers the patient. The open session task uses the disease being managed to establish the assessment health parameters to be measured and tracked, including the patient's health history and associated thresholds, limits, ranges and critical values. The open session task also provides instructions to the patient on how to observe symptoms, take health measurements, assess the patient's health, and see the future of the patient's disease.

  Obtaining health measurements from the patient for the period from the last session, the health assessment task uses the PQRST sequence to encode symptom descriptions and calculates various associated health counts, patterns and trends. The health assessment task analyzes the health status using the correlation assessment function and the critical curve assessment function. The correlation assessment function is a subjective objective correlation that is a statistical measure of how well a patient can assess their own disease state and progression to assess patient health based on subjective data. Factor (SOCF) is used. The PQRST sequence is a coding scheme used to convert a subjective description of pain symptoms into a DMM-scale digitized pain code. A critical curve is a temporal plot of designated health parameters that the DMM can compare to a standard critical curve to detect or predict rapid deterioration in patient health.

  Finally, the health assessment task routes the patient from the system to a specialist for human medical care, or directs the patient to the diagnostic module process to diagnose a new condition, or determines the next stage of therapy for the patient To determine what action to take on the patient, such as proceeding to the next task.

  The third task of the DM session is therapy optimization. The clear goal of therapy optimization is to phase the therapy in a way that balances risk and benefit, maximizing effectiveness, minimizing adverse side effects, and optimal for this patient over time. Focus on therapy. This task selects one of several possible therapies from the treatment table, adjusts medication in small steps controlled by the patient consent level function, presents risks and benefits to the patient, and accepts recommendations to the patient Or let them refuse. If the patient refuses, the task will in turn calculate the best therapy until the limit stored in the authorization database is reached. In all its work, the task looks at the treatment modification authorization level (TAPL) to determine how much authority to automatically modify the therapy. If the task has too little authority to recommend a therapy, or if the patient rejects all therapy proposals, the task sends the patient to a human specialist.

  The final task of the DM session, the close session, accumulates all assessment measurements, parameters and determinants in the patient history database. The task also processes the therapy changes accepted by the patient, issues a description associated with the patient, and finally changes the patient's schedule for the next session. The task then begins the process of outputting the various session logs and reports sought during the session, and finally the DMM saves the associated data and terminates the current DM session. The DMM is closed for this patient until the next session repeats the process.

Disease Management Module Referring to FIG. 5, the process 220 is described. Process 220 constitutes the executable part of the disease management module (DMM). The disease management module conducts an online interactive conversation with the patient to manage the patient's known disease. Process 220 consists of four processes 404, 406, 408 and 410. A DM session begins when control is passed to program 220 at start node 402. From start node 402, process 220 calls process 404. As described below with reference to FIG. 6, process 404 performs initialization, file opening, and registration functions. When process 404 returns control to process 220, process 220 then invokes process 406. Process 406 inputs health measurements from the patient, analyzes them, and evaluates the patient's current health status. When process 406 returns control to process 220, process 220 then calls process 408. Process 408 calculates the optimal next therapy step accepted by the patient. When process 408 returns control to process 220, process 220 then calls process 410. Process 410 outputs various reports, saves session data, and closes the working file. When process 410 returns control to process 220, process 220 passes control to step 412. Stage 412 returns control to the process that invoked process 220 at node 402.

Open Session Referring to FIG. 6, the process 404 is described. Process 404 verifies the data necessary to execute the DM session. Process 404 registers a new patient for the DMM and loads the patient's existing data that has been previously executed in the DM session. Finally, process 404 creates a disease management order (DMO) record. Cumulative decisions made by the DMM during this DM session are accumulated in the disease management order record. DMO is further explained in the chapter on disease management orders. Process 404 receives control at start node 430. Process 220 then passes control to decision 432. Decision 432 looks up the patient's identity in the DM register to see if the patient is registered, i.e., has previously performed a DM session. If the patient is not registered, process 404 passes control to step 434, and if the patient is registered, control is passed to step 452, which is described later in this section.

  Stage 434 is the first of seven consecutive stages 434, 436, 438, 440, 442, 444, 446 that enroll patients for disease management. Step 434 outputs a message welcoming the patient and informing the patient that the patient is about to begin registration for DM. Step 436 then inputs the name of the disease to be managed. Next, step 438 is necessary to perform disease management including the name of the agent who can represent the patient, the name and location of the patient's doctor, the name and phone of the emergency facility near the patient, etc. Interview the patient to enter data. Step 440 then creates a new patient record in the DM registry. Next, step 442 identifies the patient as a registered DM patient. Step 444 then creates a new data record for use by the DMM in the patient database. Step 446 then creates a new data record for the session data in the session database. Step 446 completes patient registration as a new DM patient. After step 446, control proceeds to step 448. Step 448 creates a new disease management order (DMO) record in which the cumulative decisions made by the DMM during this DM session are accumulated. Step 448 initializes the DMO to indicate that the patient is a newly enrolled DM patient and requires an initial health assessment. After step 448, process 404 passes control to step 450, which returns control to the process that invoked process 404.

  Continuing with the description of process 404 at step 452. Step 452 retrieves the patient's medical record from the patient database. After step 452, control passes to step 454, which loads the last DM session data for this patient from the session database. After step 454, control passes to step 456, where step 456 confirms that the last session has ended normally and sets the appropriate control data if it has not ended normally. After step 456, control passes to step 458, which initializes the DMO to indicate that this patient requires the current health assessment for the next treatment. After step 458, control passes to step 450, which returns control to the process that invoked process 404.

Health Assessment With reference to FIG. 7, process 406 is described. Process 406 performs a health assessment for the DM session. Process 406 is essentially a staging process that invokes other processes that perform patient health assessments. Process 406 receives control at start node 480. After node 480, process 406 calls process 482, which is named a critical symptom filter and is described below in connection with FIG. When process 482 returns control, process 406 passes control to test 484, which determines the DMO record code to determine whether this patient is a new DM registrant or a revisit DM patient. To test. For new patients, process 406 calls node 488. Node 488 evaluates the health of the newly registered patient. Node 488 is described below with reference to FIG. For the current patient, process 406 calls node 490. Node 490 performs a health assessment on the revisit DM patient. Node 490 is described below with reference to FIG. After the health assessment for the new or revisited patient is complete, process 406 returns control at node 492.

Critical Symptom Filter With reference to FIG. 8, process 482 is described. Process 482 classifies the patient's current health status, determines the need and reason for a specific assessment, and forwards several tests to the patient's current symptoms in order to transfer this assessment to the next DM process. Applies to These needs are saved in the patient's DMO, which is processed by the following DMM routine. DMO records are described later in the chapter on disease management orders.

  Process 482 receives control at start node 510. From there, process 482 passes control to test node 512. Test node 512 represents a first filter by asking if the patient currently has significant symptoms. If the patient does not have significant symptoms, the patient can be evaluated by automated means, so process 482 passes control to step 544. Setting a DMO recording code 544 to indicate that the patient's health needs to be further evaluated by the next routine. Control returns via node 526.

  If at node 512, the patient currently has significant symptoms, process 482 needs to determine whether the patient has symptoms related to the disease currently being managed. To do this, process 482 first passes control to step 514, which inputs symptoms from the patient and examines them in a table of related symptoms. Process 482 then passes control to test 516, which branches to node 520 if the condition is associated with the disease currently being managed. If the symptom is not related to the disease currently being managed, process 482 branches to node 530. This completes the second filter. The second filter here distinguishes between patients who have significant associated symptoms and those who do not.

  If, at node 516, the patient has an associated symptom, process 482 invokes the severity assessment function 520 to further classify whether the associated symptom is mild or severe. For patients with significant associated symptoms, process 482 passes control to step 522, which sets up a DMO record to show the results of previous studies. From step 522, control returns via node 526. However, if test 520 determines that the symptoms are mild, process 482 passes control to node 524, which sets a DMO record to indicate the need for a standard health assessment. From node 524, process 482 returns control via node 526.

  If at node 516, the patient does not have an associated symptom, process 482 needs to determine whether the patient has side effects associated with the patient's current therapy. To do this, process 482 first passes control to step 530, which examines the patient's symptoms in the current therapy side effect table. Process 482 then passes control to test 532, which is a filter that determines side effect symptoms. If the patient's condition is a side effect, process 482 invokes severity assessment function 520 to classify whether the side effect is mild or severe. For mild side effects, process 482 passes control to node 536, which sets the DMO record to be evaluated by the next process. For serious side effects, process 482 first passes control to step 534, which records a DMO record to route the patient from the system to the human doctor and then calls through node 526. Return to the process.

  If, in trial 532, the patient's condition is not a side effect, the condition is a significant symptom that is unrelated to either the disease currently being managed or the therapy being applied. Process 482 invokes severity assessment function 520 to classify whether the symptom is mild or severe. For mild symptoms, process 482 passes control to node 542 and node 542 sets the DMO recording flag to intentionally engage with the patient after all DM processing has been performed, Also record the reasons for the discussion. Process 482 then first passes control to node 544 that sets the DMO record to force the next health assessment, and then passes control to node 526, which returns to the process that called process 482. For severe and unrelated symptoms, process 482 first passes control to step 540. Step 540 records the DMO record to route the patient from the system to the human doctor and then returns to the calling process via node 526.

Severity Assessment With reference to FIG. 9, the severity assessment function 520 is described. This function uses a number of criteria to determine whether a given symptom is considered mild or critical to the DM assessment. Function 520 receives control at start node 560. At start node 560, function 520 initiates a series of six consecutive steps and then returns the calculation result. First, function 520 passes control to node 562. Node 562 asks the patient to rate the severity of the symptom on a 0 to 10 scale. The function 520 then passes control to the node 564. Node 564 obtains the absolute severity measure of the symptom itself from the symptom database. Different symptoms have different severity scales and the patient's assessment is now collated with the assessment of symptoms. As a result, function 520 then passes control to node 566. Node 566 normalizes the patient's assessment to be expressed on a symptom severity scale. Next, function 520 passes control to node 568. Node 568 uses the sensitivity factor set to adjust the severity scale normalized by the current sensitivity setting of the DMM up or down. As mentioned above, the higher the sensitivity, the less conservative the system assessment. At the lowest sensitivity setting, the severity scale for all symptoms is considered mild. Next, function 520 passes control to node 570. Node 570 translates the final adjustment scale into two classes, light or heavy. It is important to point out that this final stage can be classified into any number of grades in other situations. However, for current assessment purposes, symptoms must be classified as mild or severe. Next, function 520 passes control to node 572. Node 572 returns a code for either “mild” or “severe” to the calling process.

Initial Health Assessment With reference to FIG. 10, process 488 is described. This process performs a health assessment on the patient who will have the patient's first disease management session. Process 488 receives control at node 600. Process 488 then passes control to node 602. Node 602 loads a health assessment specification for the disease to be managed from the disease database. These specifications have various parameters used in the disease management session, such as patient description, treatment options, required approvals, etc. After these values are obtained, process 488 passes control to node 604. Node 604 initializes the patient history and the DM session portion in the session database. Process 488 then passes control to node 606. Node 606 performs an initial health interview to ask the patient about subjective assessments of current health, objective health measurements that the patient may have, existing therapies or side effects. Process 488 then passes control to node 608. Node 608 returns control to the calling process.

Current Health Assessment With reference to FIG. 11, process 490 is described. This process allows the patient to be aware of current health data from the patient, both subjectively (ie, perceived and felt by the patient), objective (ie, measured by the patient, usually with a measuring instrument) You get in three forms of side effects. These health measurements are then used to analyze the current health status. Process 490 receives control at node 620. From node 620, process 490 passes control to test 622. Test 622 examines the patient's current DMO record to determine what processing has been done and what needs to be done. If the DMO record code does not indicate that a health assessment is required, process 490 passes control to node 634, which returns control to the calling process. If a health assessment is required, process 490 passes control to a series of five stages to obtain various health assessments. First, process 490 passes control to step 624. Step 624 asks the patient for a subjective assessment of the patient's current health status. Process 490 then passes control to step 626. Step 626 asks the patient for an objective health measurement of the patient's current health status. Process 490 then passes control to step 628. Step 628 asks the patient for current side effects. Process 490 then invokes correlation assessment function 630. This function is described in connection with FIG. Next, process 490 invokes critical curve assessment function 640. This function is described in connection with FIG. Process 490 then passes control to step 632. Step 632 returns control to the calling process.

Correlation Assessment With reference to FIG. 12, process 630 is described.

  This function calculates and normalizes SOCF for recently added data, calculates other assessment parameters and statistics, and updates the patient's medical history. Finally, this function calls the health assessment function again to bridge the data gap between this previous session.

  Process 630 receives control at start node 650. Process 630 then passes control to step 652. Step 652 obtains new health data that has been added to the patient's medical history from this previous DM session. Process 630 then passes control to step 654. Step 654 calculates a new point on the raw SOCF time plot by taking the ratio of the subjective measurement to the objective measurement during the same time, and sets the raw SOCF time plot array at the new point. Update. Process 630 then passes control to step 656. Step 656 normalizes the raw SOCF points and applies standard statistical normalization and curve fitting techniques to obtain one current SOCF. This SOCF is high in patients whose patient's subjective assessment tends to fit the objective health measure, and in patients whose patient's subjective assessment tends to be inaccurate compared to the objective health measure. Low. Stage 656 further calculates other parameters used in the remainder of the DM session, such as slope and slope trend for the last three data points, and the difference between patient measurements and standard measurements. To do. Step 656 further determines whether there is a large gap in the patient's health data that needs to be retroactively filled by interval assessment. Step 656 sets the DMO code appropriately to invoke another assessment. Process 630 then passes control to step 658. Step 658 updates the patient's medical history with the calculated assessment parameters. Process 630 then passes control to test 660. Test 660 determines whether patient health should be reevaluated for missing intermediate data. If test 660 determines that no further assessment is necessary, process 630 passes control to terminal node 662. Terminal node 662 returns control to the calling process. If test 660 determines that another health assessment is required, process 630 passes control to test 664. Test 664 determines the type of data to be reevaluated for the interval. If test 664 determines that objective data is available, process 630 invokes health assessment process 490, passing parameters that determine both subjective and objective patient health data to be evaluated for the interval. Process 630 then passes control to terminal node 674. Terminal node 674 returns control to the calling process. If test 664 determines that objective data is not available, process 630 invokes health assessment process 490 and passes parameters that only determine the subjective patient health assessment to be determined for the interval. Process 630 then passes control to terminal node 672, passing parameters that require only subjective patient health assessments to be obtained for that interval. Terminal node 672 returns control to the calling process.

Critical Curve Assessment Critical Curve Assessment is a DMM process that monitors patient health for significant deterioration. A critical curve is defined as a plot of health measurements versus time used to identify significant changes in health status. The critical curve assessment process selects disease-specific and patient-specific health parameters, plots it as a critical curve, updates the critical curve as a standard part of an ongoing DM session, If a specific critical point, inclination, and inclination tendency are shown, a specific operation is performed. This process is based on comparing the patient's critical curve to a standard disease-specific critical curve. A constant, high ordinate value indicates good health, a declining curve indicates declining health, and a sharp decline in the curve indicates a health crisis. The “critical point” on the curve is the point that predicts a significant decline in health.

  An example of a typical critical curve is shown in FIG. 23, where the points enclosed as “critical points” are shown. Referring to FIG. 23, it will be noted that at the critical point, the slope of the curve (ie, the tangent to the curve at the critical point) is rapidly decreasing. This predicts that the next health measure will be below the critical point. In addition, at the critical point, the rate of slope change may also be negative, indicating that the slope of the curve is further decreasing, and the rate of slope change predicts a rapidly deteriorating health condition. Yes. For simplicity, these three critical test items are commonly referred to as critical points, slopes, and trends in the DMM process. They are calculated using the three most recent health measurement points. For critical curves with sufficient data points, curve fitting techniques can also be used.

  The DMM has a disease database 262 (FIG. 3) that contains standard critical curves for various diseases, patient populations, and health parameters. The critical curve assessment process extracts the appropriate disease data set, selects the appropriate health parameters to use, applies them to the current patient, and sets the patient's history as the standard curve for the current patient. Retreat to 254 (FIG. 3). As the DMM periodically interacts with the patient, the critical curve assessment process obtains current data from the patient, plots it on the patient's critical curve, and converts the patient's actual CC to the patient's standard CC. We use curve fitting and pattern matching techniques to compare with. This comparison allows the DMM to detect key points and trends in the patient's curve, such as “critical points” that predict significant imminent health decline. When the curve is approaching this critical point, the critical curve assessment method orders the therapy to prevent anticipated deterioration or flags the patient to refer to a health care provider. Especially if the subjective and objective correlation factor (SOCF) is high (which means that the patient knows that the patient's disease process is good and that the DMM can increasingly rely on the patient's response) Both objective and subjective health data are used to plot the CC.

The concept of homeostasis explained by Homeostasis Claude Bernard helps to understand the concept behind the critical curve and its analysis. Simply put, homeostasis is a functional balance of the body. This balance is maintained by various internal control mechanisms that force certain system parameters to remain in the desired range. Using these homeostasis mechanisms, the body can tolerate the disease to a certain point and at that time the progression of the disease begins to accelerate. A good example of this is:
A bicarbonate buffering system to maintain the pH of the blood,
・ Oxyhemoglobin separation curve, and ・ Deterioration of patients with chronic obstructive pulmonary disease.

Critical Curve The critical curve (CC) describes the patient's health status during a disease episode. The critical curve plots the patient's health over time, starting from a normal (high) state of health and decreasing to a lower state of health as the disease progresses.

  Normal, disease-free patients will have a fairly stable plot at high health levels. By using reserve capacity and internal defense mechanisms, the early part of the curve is asymptotic to normal health, often because a healthy body can suppress the disease for a while. After the initial phase, as the reserve capacity is exhausted and the disease is discovered and produces a secondary effect, the health curve begins to descend at a steep angle. At a certain critical point, the curve becomes so dramatically steep that the patient's condition may get worse quickly.

  Many physiological parameters have a characteristic response to changes that can be compensated to a certain point and then respond with very large changes in finding signals for small changes in disease progression . Knowing where the patient is on the critical curve is very important because significant intervention is needed if the patient's disease onset is about to accelerate. When there is an indication or suspected that the patient's condition is approaching a steep area of the health curve, the DMM can recommend changes to therapy or consultation with the patient's caregiver. If confirmation of changes in health status is required, the DMM re-entry feature allows the DMM system to confirm hypotheses before making recommendations.

Criticality curve analysis For patients with known illnesses who manage the illness at home with appropriate maintenance therapy, DMM monitors the patient's periodic contact and health status reports. If the trend line indicates that the patient's health curve is reaching a critical point, the DMM can change the therapy and / or notify the patient's doctor. Because patients can successfully manage the disease for months, this curve analysis method can save a significant number of unnecessary doctor visits, and health change is critical -The doctor and patient can be notified at the same time when the points indicate that they are approaching.

  Obviously, it is best to use easily quantifiable parameters as markers for the progression of the disease to embody this curve, but if a subject has a high subjective and objective correlation, The patient's subjective assessment can accomplish the same thing.

  The system measures tidal volume and peak flow over time. If a slight change in tidal volume is found to be a significant difference in the patient's disease severity in the patient's impression (as compared to the patient's previous change), the patient has a steep curve In the part. A flag is set and significant intervention is required.

  If the treatment modification authorization level is set low, the patient is routed to his doctor, who receives reports, frequent faxes, emails, or downloads for new deployments. If the treatment modification level is set high, treatment optimization may occur before the patient meets the doctor. A report may be sent to the doctor and may or may not need to meet the patient.

  It is this analysis and the recognition of this relationship that constitutes a “curve” analysis of health.

Example: Chronic obstructive pulmonary disease As an example, chronic obstructive pulmonary disease is described. Chronic obstructive pulmonary disease slowly destroys lung tissue. As mentioned earlier, many physiological parameters have the same response to changes and can be compensated up to a certain point, and after a loss of reserve capacity, very small changes in disease state can occur in patients. In the early phase of the disease, very large changes in the development of disease progression occur. Since patients with chronic obstructive pulmonary disease lose only spare lung volume, there is no significant change in resting health. The threshold has been reached after the spare tissue has been destroyed, and since then an increasingly small time gap (and progression of the disease process) is increasingly critical to the patient's ability to exhale carbon dioxide and deliver oxygen to the blood. It will worsen. Ultimately, even very small changes in chronic obstructive pulmonary disease result in respiratory dysfunction.

  The patient is reaching the critical part of the curve when an increasingly greater decrease in lung function plotted against time begins to appear. Serious intervention is needed and should be started as soon as possible.

The critical curve assessment process is particularly useful for DMM setting for the following reasons.
• DMM is fully automated.
• DMM keeps track of patient health over time.
DMM has various modules that track patient contact and calculate correlations.
• DMM knows the patient (medical history, subjective and objective correlation factors).
DMM has access to a database of medical knowledge.
• DMM can use mathematical trend analysis to analyze disease progression.
• DMM can choose alternative therapies as conditions change.

  The critical curve assessment function 640 will be described with reference to FIG. This function has two phases. The first phase (starting at node 702) updates the patient's critical curve by adding health measurements to the patient's medical history since the last critical curve assessment. The second phase (starting at node 712) compares the patient's actual critical curve with the standard critical curve used for this patient. If the patient is at (or approaching) the critical part of the curve, this suggests the possibility of rapid deterioration of the disease being managed, and the patient is referred to a human doctor for consultation .

  Process 640 receives control at start node 700. Process 640 then passes control to step 702. Step 702 updates the patient's actual critical curve with the new health measurements. Next, process 640 passes control to step 704. Step 704 analyzes the patient's updated critical curve to obtain the latest critical curve point, slope, and 3-point trend. Process 640 then passes control to step 706. Step 706 saves the patient's critical curve data to the patient's medical history. Process 640 then passes control to test 708. Test 708 examines the DMO recording code to see if the patient's critical point should be evaluated. If the critical point of the patient is not to be evaluated, process 640 passes control to terminal node 710. Terminal node 710 returns control to the calling process. If test 708 indicates that a health assessment is required, process 640 passes control to step 712.

  Stage 712 begins the assessment phase of process 640. Step 712 retrieves or calculates the working data necessary to use the critical curve to assess patient health. The work data has the patient's recent actual health points and slopes, the matching points and slopes on the patient's standard critical curve, and the thresholds used to instruct the patient to be critical for each set . Once step 712 calculates these working data, process 640 passes control to test 714.

  Test 714 begins a series of steps to examine the patient's critical points. If test 714 knows that the patient's recent health points are not available or cannot be matched to the standard curve, process 640 passes control to terminal node 716, which in turn calls the calling process. Pass control to. If test 714 determines that a recent health point is available, then process 640 passes control to step 718. Step 718 compares the difference between the actual and standard critical health points. Process 640 then passes control to test 720. If test 720 finds that the patient has reached or exceeded the critical point threshold, process 640 passes control to step 722. Step 722 sets up a DMO record to route the patient to a human doctor for consultation. Process 640 then passes control to terminal node 724. Terminal node 724 returns control to the calling process. If test 720 finds that the patient has not reached the critical point threshold, process 640 passes control to test 726.

  Test 726 initiates a series of steps that examine the patient's critical slope. If test 726 determines that a critical slope is not available, process 640 passes control to terminal node 724. Terminal node 724 returns control to the calling process. If test 726 determines that the actual slope is available, process 640 passes control to 728. 728 compares the difference between the actual and standard critical slopes. Process 640 then passes control to test 730. If test 730 determines that the patient is below the critical slope threshold, process 640 passes control to node 724. Node 724 returns control to the calling process. If test 730 determines that the patient has reached or exceeded a critical slope threshold, process 640 passes control to node 732. Node 732 sets up a DMO record to route the patient to a human doctor for consultation. Process 640 then passes control to node 724. Node 724 returns control to the calling process.

Therapy Optimization Therapy Optimization evaluates and adjusts patient therapy from session to session with long-term goals that maximize effectiveness and minimize adverse side effects, and encourage patient collaboration and acceptance of recommended therapies. It consists of a set of processes to maintain. The therapy optimization process tracks patient-specific effectiveness by selecting therapy parameters from a medical treatment table and evaluating subjective and objective patient health data from session to session. The therapy optimization process selects from multiple treatments. The therapy optimization process strives to minimize side effects by providing patients with alternative therapy options and adjusting the therapy dosage level until the patient finds appropriate comfort. Disagreements between the DMM and the patient are resolved by sending the patient to a human doctor for face-to-face consultation and advice. The therapy optimization is guided and controlled by the therapy optimization authorization level (TAPI), a variable across the DMM that specifies the amount of autonomy at which the DMM must change therapy. TAPL is described in a separate chapter below.

  After the patient's health status has been assessed, the therapy optimization process can (to the extent allowed by TAPL) to achieve the best combination of several sub-goals for the overall goal of normal health recovery. Assess and adjust patient treatment. The therapy optimization process further strives to minimize the side effects of treatment. To the extent permitted by current TAPL settings, DMM will gradually titrate drug therapy doses until the benefit / side effect ratio is maximized. Its overall philosophy is to achieve the desired physiological changes with minimal side effects. Initial treatment is selected from the treatment table based on disease, age and gender. Because the response to treatment is widespread by patients, once a drug is selected as a therapy for a given disease, different prescriptions, doses, management methods and timing may result in trial and error for a particular patient. It is a problem. To review the therapy, the therapy optimization task compares the patient's current therapy to the treatment table to detect and analyze the differences. If new treatments are available, the patient and caregiver will be notified and the therapy may be changed by TAPL. To maximize treatment outcomes and minimize side effects, the function selects the initial therapy, reviews the patient's current therapy, adjusts various parameters of the therapy, and adjusts the effects of these changes. Can be monitored.

  The therapy parameters that can be changed include drug class, format, brand, dose, route, drug management mode, prescription, timing and frequency. As each of these is modified, the patient's health data and side effects are checked to see if the current modification of the therapy makes the patient better and so on. In order to find the overall best combination of therapy parameters, each therapy parameter is continuously changed on a trial and error basis. When the DMM adjusts the patient's therapy, the DMM adjusts the DM session schedule appropriately, usually instructing the patient to re-enter the system within a few iterations of therapy or dose.

  Minimizing side effects is a special goal of the therapy optimization process and seeks to reduce unwanted side effects of therapy. This task reveals the complex trial and error method used by DMM for therapy optimization features. Example 1: Among cancer patients, patients who are receiving chemotherapy are determined that side effects are not worth slowing down disease progression. At that point, knowing that any further increase is useless, one “retracts” (decreases the amount). If multiple drugs are needed, the process becomes more complex, but the same relationship persists. Example 2: A dose inhalation anesthesia machine metered in albuterol helps asthma patients to breathe, but at certain patient-specific doses, side effects worsen and patients become unacceptable. At that time, the dose is reduced in small increments to obtain the best ratio of efficacy to side effects.

  With reference to FIG. 14, the therapy optimization process 408 is described. Process 408 performs the therapy phase of the DM session. This phase calculates the next best therapy phase that is accepted by the patient, using two main dependent processes and a loop that attempts various treatments until the patient accepts one of them. The general goal of process 408 is to optimize therapy over time by maximizing effectiveness, minimizing side effects, and adjusting the therapy format and modality to meet patient comfort levels The method is to select the therapy stage. Process 408 receives control at start node 760. Process 408 then passes control to test 762. Test 762 tests whether the patient provided a current objective health measurement during the initial portion of this DM session. If test 762 finds that the patient did not provide current objective health data, process 408 passes control to test 782. Test 782 tests whether the patient entered a subjective assessment of the patient's health during the early part of the DM session. If test 782 knows that the patient has provided a subjective health assessment, process 408 calls process 790. Process 790 adjusts the therapy based on current subjective health data. Process 790 is described in detail below in connection with FIG. When process 790 returns control, process 408 passes control to terminal node 792. Terminal node 792 returns control to the calling process. If test 782 knows that the patient is not providing a current subjective health assessment, process 408 passes control to 784. 784 sets up a DMO record to route the patient to a human doctor for consultation. Process 408 then passes control to terminal node 786. Terminal node 786 returns control to the calling process.

  If test 762 finds that the patient is providing current objective health data, process 408 passes control to step 764. Step 764 initializes a loop that attempts various treatments until either the patient accepts one of them or the number of retries is exhausted. Step 764 obtains the maximum number of acceptable therapies from the authorization database for this patient. Next, process 408 calls process 770. Process 770 selects the next best therapy from the treatment table for this patient and provides it to the patient. The patient can accept it, modify it, or refuse it. Process 770 is further described below in connection with FIG. If process 770 returns control, process 408 passes control to test 772. If test 772 determines that the patient has accepted the recommended therapy, process 408 passes control to terminal node 780. Terminal node 780 returns control to the calling process.

  If test 772 determines that the patient has rejected the recommended therapy, process 408 passes control to test 774. If test 774 determines that the loop retry frequency is greater than one, process 408 passes control to step 776. Step 776 subtracts the loop retry count by 1 and then process 408 calls process 770 again to repeat the loop one more time. If test 774 determines that the retry frequency is 1, then process 408 passes control to step 778. Step 778 sets up a DMO record to route the patient to a human doctor for consultation. Process 408 then passes control to terminal node 780. Terminal node 780 returns control to the calling process.

Therapy adjustment (subjective)
The process 790 is described with reference to FIG. Process 790 calculates the next best therapy for the patient based solely on the patient's subjective assessment of the patient's health. Process 790 uses the subjective / objective correlation factor (SOCF) described below in the Subjective / Objective Correlation Factor section. SOCF shows how reliable this patient is in subjectively assessing the patient's own disease, and process 790 relies on SOCF to calculate the next therapy step.

  Process 790 receives control at start node 810. Process 790 then passes control to test 812. If test 812 determines that the patient does not require therapy adjustment, that is, if the patient's DMO record has already been completed for the approved therapy, process 790 passes control to terminal node 814. Terminal node 814 returns control to the calling process. If test 812 determines that this patient requires therapy optimization, process 790 passes control to test 816. Test 816 determines whether the patient currently has symptoms (by asking the patient whether the patient has been asked or by getting the patient's saved answer). If test 816 finds that the patient has no symptoms, process 790 passes control to test 818. If test 818 determines that the current DMM / TAPL setting does not allow therapy adjustment, process 790 passes control to node 826. Node 826 sets up a DMO record to maintain the same therapy, eg, the same dose in the case of drug-based therapy. Process 790 then passes control to terminal node 824. Terminal node 824 returns control to the calling process.

  If test 818 determines that the current TAPL setting allows therapy adjustment, process 790 passes control to test 820. If test 820 determines that the patient does not want to reduce the dose, process 790 passes control to step 826. Step 826 sets up a DMO record to maintain the same therapy. Process 790 then passes control to terminal node 824. Terminal node 824 returns control to the calling process. If test 820 determines that the patient wants to reduce the dose, process 790 passes control to step 822. Step 822 searches the treatment table for the next lowest dose level and sets a DMO record to reduce the dose. Process 790 then passes control to terminal node 824. Terminal node 824 returns control to the calling process.

  If test 816 finds that the patient currently has symptoms, process 790 passes control to test 830. If test 830 finds that TAPL does not tolerate therapy changes, process 790 passes control to step 832. Step 832 sets up a DMO record to route the patient to a human doctor for consultation. Process 790 then passes control to terminal node 833. Terminal node 833 returns control to the calling process. If test 830 finds that TAPL allows a change in therapy, process 790 passes control to step 834.

  Stage 834 initiates a phase of process 790 that calculates the next therapy stage for the symptomatic patient, but reports only the current subjective health assessment. Step 834 uses the current SOCF from the patient's medical history and modifies it with the current sensitivity factor set to adjust it to the sensitivity used for this patient, and then the patient's current The SOCF is classified as “high” or “low” at any time. If test 834 classifies the patient's SOCF as “high”, the patient's subjective health assessment is reliable and process 790 passes control to step 838. Step 838 looks at the treatment table to see how much therapy (ie, dose in the example) can be increased for high SOCF patients and what the corresponding benefits and risks are. Next, process 790 calls function 840. Alternatively, if test 834 considers SOCF to be “low”, process 790 passes control to step 836. Step 836 obtains the dose and risk / benefit factors for the unreliable patient. In any case, process 790 continues by calling function 840.

  The patient consent level function 840 provides the recommended therapy to the patient and obtains the patient's consent for the recommended therapy or some variations thereof. The patient can also completely reject the recommended therapy. Function 840 is described below in connection with FIG.

  When function 840 returns control, process 790 passes control to step 842 if function 840 returns a result that the patient agrees to the increased dose. Stage 842 sets a DMO record to indicate the next therapy with increased dose and appropriate changes in the schedule for earlier DM sessions. Process 790 then passes control to terminal node 844. Terminal node 844 returns control to the calling process.

  When function 840 returns control, process 790 passes control to step 846 if function 840 returns a result that the patient agrees to continue therapy at the same dose. Step 846 sets up a DMO record to indicate that the same therapy will continue. Process 790 then passes control to terminal node 844. Terminal node 844 returns control to the calling process.

  When function 840 returns control, process 790 passes control to step 848 if function 840 returns a result that the patient agrees to reduce the dose. Step 848 sets a DMO record to indicate the next therapy with a reduced dose. Process 790 then passes control to terminal node 844. Terminal node 844 returns control to the calling process.

  When function 840 returns control, process 790 passes control to test 850 if function 840 returns a result that the patient refuses the recommended therapy at any level. Test 850 examines the current sensitivity factor set to see if process 790 should try a suboptimal therapy or route the patient to a human doctor. If test 850 determines that other treatments may be attempted, process 790 passes control to node 852. Node 852 sets a DMO record to indicate that the patient has rejected the recommended therapy. Process 790 then passes control to terminal node 844. Terminal node 844 returns control to the calling process. If test 850 determines that the patient should be referred to a specialist, process 790 passes control to node 854. Node 854 sets up a DMO record to route the patient to a human doctor. Process 790 then passes control to terminal node 844. Terminal node 844 returns control to the calling process.

Therapy adjustment (objective)
The process 770 is described with reference to FIG. Process 770 calculates the next best therapy for this patient based on the patient's current objective health measurement. Process 770 receives control at start node 870. Next, process 770 passes control to test 872. Test 872 compares health assessment parameters to determine if the patient's objective health data meets or exceeds various thresholds. Test 872 first compares the patient's current health measurement with an absolute threshold for that measurement to see if the measurement itself is within an acceptable range. Test 872 then compares the slopes of the last two health measurements to see if the patient's health is deteriorating at a rate exceeding the threshold. Test 872 then compares the changes in the slope of the last three measurements to see if the rate of change in the patient's health is deteriorating more and more rapidly. If one of these thresholds is met or exceeded, process 770 passes control to step 874. Step 874 sets the DMO to route the patient to a human doctor. Process 770 then passes control to terminal node 876. Terminal node 876 returns control to the calling process.

  If test 872 determines that all of the patient's current health statistics are below the threshold, process 770 passes control to test 878. Test 878 begins a phase of process 770 that calculates the next recommended therapy for this patient. Test 878 calculates current patient health measurements from previous DM sessions to classify changes in the patient's health status as “better, same, or worse” for the purpose of calculating the next therapy step. Compare with the value of.

  If test 878 determines that the patient is worse than the previous time, process 770 passes control to test 880. Test 880 determines (from the treatment table) whether the dose of the current therapy can be increased. If test 880 determines that the dose can be increased, process 770 passes control to node 882. Node 882 sets the DMO to increase the dose. Next, process 770 passes control to test 896. If test 880 determines that the dose cannot be increased, process 770 passes control to node 884. Node 884 sets the DMO to continue therapy at the same dose. Next, process 770 passes control to test 896.

  If test 878 determines that the patient is in the same health as the previous time, process 770 passes control to test 892. Test 892 determines whether the patient's current health measurements are at normal limits. If test 892 determines that the patient's current health data is normal, process 770 passes control to step 890. Step 890 sets the DMO and reduces the dose. Process 770 then passes control to 896. If test 892 determines that the patient's current health data is outside normal limits, process 770 passes control to test 880. Test 880 has been described above for process 770.

  If test 878 determines that the patient is better than the previous time, process 770 passes control to test 886. If test 886 determines that the current dose can be reduced (by examining the treatment table), process 770 passes control to step 890. Step 890 has been described above for process 770. If test 886 determines that the current dose cannot be reduced, process 770 passes control to step 888. Step 888 sets the DMO and continues therapy at the same dose. Next, process 770 passes control to test 896.

  Test 896 determines whether the TAPL settings for this patient allow the DMO previously calculated by process 770. If test 896 determines that TAPL allows the written DMO, process 870 calls patient consent level function 840. The patient consent level function 840 indicates the therapy recommended to the patient and obtains the patient's consent to the therapy as recommended or with minor modifications. The patient may completely refuse the recommended therapy. Function 840 is described below in connection with FIG. If function 840 returns a result that the patient accepts the recommended therapy (possibly somewhat modified), process 770 passes control to terminal node 898. Terminal node 898 returns control to the calling process. If function 840 returns a result that the patient completely rejects the recommended therapy, process 770 passes control to test 900. Test 900 examines the current sensitivity factor set to see if process 770 should try a suboptimal therapy or route the patient to a human doctor. If test 900 determines that another treatment may be attempted, process 770 passes control to node 902. Node 902 sets a DMO record to indicate that the patient has refused the recommended therapy. Process 770 then passes control to terminal node 904. Terminal node 904 returns control to the calling process. If test 900 determines that the patient should consult a doctor, process 770 passes control to node 906. Node 906 sets up a DMO record and routes the patient to a human doctor. Process 770 then passes control to terminal node 904. Terminal node 904 returns control to the calling process.

  If test 896 determines that the TAPL does not allow the recommended therapy, process 770 passes control to step 908. Step 908 sets up a DMO record and routes the patient to a human doctor. Process 770 then passes control to terminal node 904. Terminal node 904 returns control to the calling process.

Patient Consent Level The patient consent level function 840 is described with reference to FIG. Function 840 presents the recommended therapy to the patient and obtains the patient's consent for the therapy as recommended by the DMM or with some changes to the therapy based on the patient's response. The patient may completely reject the recommended therapy. At start node 920, function 840 receives control. Process 840 then passes control to step 922. Step 922 outputs the therapy recommended by the DMO to the patient. Process 840 then passes control to step 924. Step 924 presents risks and benefits to the patient. Next, process 840 passes control to step 926. Step 926 presents the patient with other therapy options. Next, process 840 passes control to step 928. Step 928 asks the patient for consent to the recommended therapy or a version of the therapy. Next, process 840 passes control to step 930. Step 930 updates the DMO to record the provided options, the given alerts, and the consent level received with the appropriate date and time records. Next, process 840 passes control to step 932. Step 932 calculates the result of the function to be returned to the calling process. The level of consent allowed by the patient may have several values. The four values used in the flow chart assume drug therapy and are as follows: (1) Increase dosage. (2) Keep the same level of dosage. (3) Reduce dosage. (4) Reject this therapy. Process 840 then passes control to terminal node 934. Node 934 returns control to the calling process.

Close Session With reference to FIG. 18, the close session process 410 is described. Process 410 is the last process executed for all DM sessions. It is particularly responsible for processing the disease management order (DMO), which is the trial conducted and the reason for it, the recommended next stage of therapy, the consent given by the patient, and the patient's prescription Includes a complete set of various related orders such as faxing to pharmacies, requesting tests from the lab, preparing the patient's report to the doctor, sending printed instructions to the patient, etc. Yes. Apart from performing the DMO details, process 410 records all events that occurred during the DM session, accumulates all relevant data, ends all applicable files, plans the next DM session, And finally, it is responsible for saying goodbye to the patient to indicate that the current DM session has ended.

  Process 410 receives control at start node 950. Process 410 then passes control to test 952. Test 952 records therapy directed by DMO in the patient's medical history. Process 410 then passes control to test 954. Test 954 determines whether the DMO contains a special order to be processed. If test 954 determines that the DMO has no special therapy order, process 410 passes control to step 972. Stage 972 schedules the next DM session as specified in the patient's current therapy schedule. Process 410 then passes control to node 962. Processing from node 962 is described below for process 410. If test 954 determines that the DMO has a special order, process 410 passes control to step 956. Step 956 schedules the next DM session as specified by the DMO. Process 410 then passes control to step 958. Step 958 prepares and sends various notifications and reports and reports to various contacts. These notifications and the contacts that receive them are controlled by the regulations, quotas and other authentication fields maintained in the authorization database. Next, process 410 passes control to step 960, which informs the patient about the next stage of therapy and provides the patient with instructions as directed by the DMO and authorized by the authorization database. Process 410 then passes control to step 962.

  Step 962 informs the patient's doctor about the DM session and the therapy commanded by the DMM. Since the patient's doctor can always receive all the information generated for the patient, the doctor can specify the notifications to be sent and the details to be reported. The doctor's current requirements and notification restrictions are stored in the authorization database and can be modified by the doctor using a process external to the DMM. Process 410 then passes control to step 964. Step 964 provides information to the patient about actions taken by the DMM software, within the allowable range of the authorization database. This stage tells the patient what the system is doing and why it can gain patient confidence and help the patient to make better decisions in future sessions Make it possible. This feedback is an important factor in optimizing long-term therapy, which is one of the features of the present invention. Step 964 also reviews all special flags that are set to speak new symptoms to the patient. Process 410 then passes control to step 966. Step 966 stores all relevant data in various suitable primary and backup storage devices. Process 410 then passes control to step 968. Step 968 terminates the reference of all applicable data files and frees all temporary computing system resources allocated to the DM session. Next, process 410 passes control to terminal node 970. Node 970 returns control to the calling process.

Question Version The DMM question version feature allows several different versions of the same question to be written into the script, and the decision of which version to use is delayed until execution time. The function uses an entire data item called the Question Version Index (QVI) to select the desired version of the question from the script at run time.

  A question version feature is a multi-sided cylinder with one of the different question versions written on each side and can be visualized as a “question roller”. To ask a question, the cylinder is rotated to display a surface containing the desired question text. If the set of questions is written in a separate cylinder and all cylinders rotate together to show the same face, as specified by the overall control element, is the entire question set of the script adjusted? Alternatively, it can “rotate” as a unit. This allows the script to be adjusted or fine tuned to listen to different versions of the question at different levels as a whole.

  One use of the question version feature is that the overall DMM QVI that adjusts the sensitivity of the language can be used to globally adjust the sensitivity and selectivity of the language used by the overall DMM. In this way, if it is necessary to change the sensitivity or selectivity of a question, the question roller can be turned to one side or stepped to increase sensitivity, and the opposite direction to increase selectivity. Turn or step forward. For this usage, each question version is slightly different in wording and sensitivity. In some cases, the only difference is voice comma (pause) or intonation. An example is shown below.

Is this the absolute worst headache you can imagine someone has?
Is this the worst headache you can imagine someone has?
Is this the worst headache you have ever experienced?
Is this one of your worst headaches?
Another use of the Question Version feature is to write script questions aimed at different levels of patient education, intelligence, disease understanding, or medical expertise. For example, the DMM can ask the same question in various formats written for third graders, for high school students, for college graduates, or for healthcare professionals. Thus, the DMM can take an output that is appropriate for the patient's communication needs. The need is what natural language to use, what level of understanding, what grammar to use (for example, we are to the patient, to the patient's relatives, or to the patient's doctor). And a wide range of decisions based on what is currently known about the patient, such as what medical details are disclosed. In order to know the level of language, education, and intelligence that the patient can understand, the DMM can examine the patient's medical history. In the absence of an indicator, the results of the mini-language IQ test can be used as part of the initial health assessment task to establish a QVI for use with the patient.

  Yet another use of the question version feature is to allow dynamic adjustment of the level of the question based on patient response or demand. Thus, a patient who is confused or missing me can ask the DMM to give more detailed instructions on how to respond to the question. The DMM can react by changing the QVI to select a more appropriate question version. On the other hand, since the patient studies during the session, later the patient can require fewer instructions and a faster communication mode. Furthermore, by adjusting its QVI, the DMM can respond appropriately. In this way, the DMM can learn about the patient's current and past use of the DMM and modify itself to adapt to the patient's natural language, education, medical knowledge, and the required medical sensitivity.

  Question version functionality is implemented in software by allowing script authors to collect different versions of a question into "version groups", where each version of the question corresponds to a different QVI. Yes. At run time, the DMM uses a sensitivity factor set to establish an overall QVI to define the current question version to be used by all scripts for the current patient. When a DMM process (such as a script engine) needs to output a question, it finds the desired question from the script question group and uses the entire QVI to retrieve it. Questions that do not require different versions are written as a version group with only one question, which serves as the default question. This default question is used as well when there are no questions in the version group for the current overall QVI.

  This question version design allows a question version to be written for a wide range of QVIs without writing a version for each QVI. A simple script can have exactly one question version, and as the script is improved, additional additional question versions are added. For example, the first script may be written in English and may be later refined to add a Spanish version of each question.

  The question version functionality is implemented in the form of a question version index and two separate feature sets of QVI and question selection. In FIGS. 19a and 19b, these elements are shown as follows.

        The overall version index (QVI) is a data item 1020.

        Set QVI is process 1000

        The question selection process is shown as process 1001.

  The current setting of the global version index 1020 determines whether one of several different question versions is selected and output to the patient. Data element 1020 is stored as a control field in authorization database 256 (FIG. 3), changed by process 1000 and used by process 1001.

  Process 1000 is a DMM-wide system service routine that periodically sets and updates data element 1020. Process 1000 receives control at start node 1002. Process 1000 then passes control to step 1004. Stage 1004 identifies the patient for which data element 1020 is to be set. Process 1000 then passes control to step 1006. Step 1006 retrieves the current value of the patient data element 1020. Process 1000 then passes control to step 1008. Step 1008 calculates a new value for the data element 1020. The stage obtains the desired level of sensitivity from the current sensitivity factor set, other from the patient's medical history to the patient's education level, the level of language understood, and other QVI settings used in previous DM sessions. Get parameters. After step 1008 calculates a new QVI value, process 1000 passes control to step 1010. Step 1010 stores the new value in the patient data element 1020. This completes the operation of updating the patient data element 1020. Process 1000 then passes control to terminal node 1012. Terminal node 1012 returns control to the calling process.

  Process 1001 is a DMM-wide routine that uses the overall version index 1020 to select one question from a set of questions. Process 1001 receives control at start node 1022. Process 1001 then passes control to step 1024. Step 1024 loads a set of questions applicable to the current script data area. Process 1001 then passes control to step 1026. Step 1026 obtains the current value of the question version index 1020 from the patient authorization file. Process 1001 then passes control to test 1028. Test 1028 determines if the question version selected by QVI is in the set of questions obtained in step 1024. If test 1028 determines that the desired version is in the set of questions, process 1001 passes control to step 1030. Step 1030 retrieves questions having the desired question level from the set. Process 1001 then passes control to step 1034. Step 1034 returns the question selected from the set as a result of the function to the caller. Process 1001 then passes control to terminal node 1036. Terminal node 1036 returns control to the calling process. If test 1028 determines that the desired version is not in the question set, process 1001 passes control to step 1032. Step 1032 retrieves a default question from the set. Process 1001 then passes control to step 1034. Step 1034 returns the question selected from the set as a result of the function to the caller. Process 1001 then passes control to terminal node 1036. Terminal node 1036 returns control to the calling process.

Preview Mode Preview mode is a run-time mode of a DMM script that allows you to “think ahead” to examine the outcome of a response before giving the patient an “official” response. As a result, the patient can say-at any point in the script-"Show me what this response will do." One use of the preview mode is to have a patient hold an ongoing conversation to see what the question at hand means. Knowing the outcome of the response helps clarify the impact or focus of the question. Thus, one good way to find the best path in a printed flowchart or procedure is to look ahead to see what results (or recommendations) will be in answering a question in some way. Another use of the preview mode is to explicitly alert the patient that a particular question has important results to the script, and using the preview mode allows the patient to consider the results of each answer Is to do. For example, one answer may initiate an action to contact the patient's doctor or move the patient to an emergency facility. If the script can alert the patient about this result, the patient can preview these responses without activating them and can change the script's conversation instructions.

  The process 1060 will be described with reference to FIG. This process just illustrates the stage of a DM session that deals with the preview mode feature that is included in the process of querying the patient and processing the response. Other stages of the DM session that are not relevant in preview mode have been removed for clarity. Process 1060 receives control at start node 1062. Process 1060 then passes control to test 1064. If test 1064 determines that there are no more questions to ask, process 1060 passes control to terminal node 1066. Terminal node 1066 terminates the preview mode. If test 1064 determines that there is something to ask, process 1060 passes control to step 1068. Step 1068 outputs a question to the patient. Process 1060 then passes control to step 1070. Step 1070 outputs a set of answers for the patient. Process 1060 then passes control to step 1072. Step 1072 inputs the response from the patient along with an indicator that the patient desires or does not want to preview the script's behavior for this response. Process 1060 then passes control to test 1074. If test 1074 knows that the patient has responded with a set preview indicator, process 1060 passes control to step 1076. Step 1076 takes the preview information encoded in the script (as part of the standard question and response text) and explains what the selected response does in "real" mode. Output to patient for viewing. For example, the preview text may tell the patient that “YES response will increase the amount of daily medication for the next two weeks”. After the preview text is output to the patient, process 1060 passes control to step 1068. As already mentioned for step 1068, step 1068 asks the same question again. However, if test 1074 knows that the patient responded without a preview indicator, process 1060 passes control to step 1078. Step 1078 performs the actions normally described for a given response, after which process 1060 passes control to test 1064. Test 1064 determines whether there is a next question to ask as described above for test 1064.

All DMM interactions with unresponsive feature patients are controlled by scripts. During a standard session, the script selects a question and outputs it to the patient, who enters the response. The script analyzes the response, selects another question, and outputs it to the patient. This question-response-question-response conversation continues until the session ends normally. However, if the patient is unable to respond to expectations during a conversation, all scripts are designed to call the no response (NR) feature, which is responsible for taking the appropriate continuation action on the script. . The NR feature is a DMM software mechanism that is activated when a timeout condition is displayed by the operating system. This NR mechanism can take several actions predetermined by the script and can be changed according to the operation of the script. The NR action is from the quiet entrance of the DM session record to the use of health data from the patient's medical history, pharmacotherapy and symptom data from the disease database in contact with the patient's responsible neighbor, or nearby emergency response facility. Can be reached.

  One use of the NR function is to make a medical illness specific and patient specific assessment of the patient's inability to respond. Clearly, in patients with certain illnesses (eg heart problems, head problems, diabetes), the sudden failure of the patient during normal conversation may indicate several possibilities. This NR feature is a special value of DMM content with detailed medical information about patients from previous sessions and FO support system content, which is indexed by geographical location around the world Has a wide range of related databases (eg, emergency rooms, 911 institutions, medical assistants). Due to what the system knows about the patient, the NRF can be very situation specific. A very simple example would be a 60 year old man consulting for chest pain. A sudden failure to answer a question suggests a cardiac arrest and will initiate an emergency action, including calling the patient's local 911 agency.

  The process 1100 is described with reference to FIG. Note that process 1100 shows only those portions of the script that are relevant to the unresponsive feature. The other stages of the script have been removed for simplicity. Process 1100 receives control at start node 1102. A start node 1102 represents a general start node of the script. Process 1100 then passes control to stage group 1104. Stage group 1104 represents all of the script operations that are not related to unresponsive features. If the script ends as part of one of these stages, process 1100 passes control to terminal node 1106. Terminal node 1106 terminates the script. If one of the stages in stage group 1104 wants to ask the patient, process 1100 passes control to stage 1108. If the patient fails to respond, step 1108 sets the required NR parameters later. The source of these parameters is the patient's medical history 254, which is used if the patient fails to respond, such as the patient's illness, health status, medications taken, doctors, nearest emergency facility, etc. Contains relevant information to be taken. Stage 1108 accumulates the NR parameters as data set 264. Process 1100 then passes control to step 1112. Step 1112 outputs the actual question to the patient. Process 1100 then passes control to test 1114. The details of step 1114 vary between operating systems and hardware platforms. However, its typical behavior is to set a timeout flag for the specified latency, gain control over the operating system, and control when the operating system returns to responding or when the latency expires. Is to win again. When test 1114 receives a response, process 1100 passes control to stage group 1104 where normal script operation continues. If test 1114 receives a timeout, process 1100 passes control to step 1116. Stage 1116 retrieves patient, disease, and location specific NR data from data sets 264 and 254 and performs the required NR operation. If step 1116 performs NR operation, process 1100 passes control to terminal node 1116. It represents the general termination of the script due to a timeout.

Sir Thomas Lewis, the PQRST sequence , said the pain was "known to us by experience and explained by the figures". The ability to encode the subjective experience of distress in a standard and repeatable format is a fundamental asset for any automated medical system. Many diagnostic sessions begin with the patient reporting some kind of pain to the doctor in the form of a main complaint. A thorough explanation of distress can eliminate many diagnoses, eliminate the use of table lookups or database access mechanisms, and suggest illness early.

  The PORST array feature describes a software process and a set of data that work together to encode a patient's pain description into an integer specially formatted array "pain code". Since encoding is done in a way that preserves that subjective information, it is possible to decode the pain code using an integer in the array, and the original word used to describe the pain To recover.

  The pain code is composed of sub-codes. Each subcode identifies one well-defined detailed aspect of the pain experience such as position, sensation, frequency, etc. Pain subcodes are arranged in a specific order or format known to all software processes that manipulate the pain code. The order used to encode the aspects is itself numbered as a sequence number, so that the first aspect of the array always identifies the encoding scheme used for the array. This allows the PQRST sequence to be flexible and expandable, as different coding schemes can be used to meet different needs. A software process that needs to decode the PQRST in the future simply checks the initial modal code and knows from that value what decoding scheme should be used for the remainder of the modal.

  The PQRST sequence feature allows patient distress reports to be encoded in a digital format suitable for the software process. For example, “When I bend my right arm or rotate my wrist, it is mild, but the area of the elbow is really badly hurt, some kind of jumble or crushing sound, but no bleeding” Complaints also cause the patient to choose from standard descriptive terms (eg, jerky, tight, no sensation), and the chosen term (7,2,3,8,5,970612,2,13) Can be encoded by converting it to an array of integers close to it. This arrangement represents numerically various aspects of distress, such as location, repeatability, quality, or date of 970612. For any given aspect, the number represents the degree or explanation of the pain. Thus, if the number of the fourth aspect represents a sound related to movement, the subcode value 8 can represent “jumble / crushed noise related to joint movement”.

  The “PQRST” label was adopted from the classic easy-to-remember name used by medical students against the basic aspect of distress, resulting in P-stimulation / relaxation (causing, worsening, or improving) , Q-characteristic (sharp or dull), R-region (such as head or chest), S-severity (mild to pain), and T-timing (when pain began). These aspects represent the origin of the PQRST sequence, cause (infection, trauma), mass (moles, clumps), dimensions (fingertips, golf ball), sensation (tickle, pulse), and objective association (color) Can be extended to include subjective descriptions of other useful illnesses, along with many additional aspects related to pain, such as odor, release).

To encode the pain description into the pain code, the process works as follows:
Use a predefined set of pain aspects (ie, small surfaces, elements, dimensions).

        • Use a predefined set of terms that are defined for each aspect.

        • Obtain applicable terms from patients.

        • Encode all modal terms into subcodes.

        Format the subcode as a physical data item (PQRST array).

        Store the PQRST array on memory or disk.

        Use the storage location address as a pointer.

  In order to handle the pain code as a whole, the program performs the following operations.

        Pass the pointer to the PQRST array.

        Use a pointer to access the PQRST array if necessary.

  To decode the pain code, the program reverses the encoding process.

        Use that pointer to locate the PQRST array in memory or storage.

        -Retrieve PQRST sequence from memory or disk.

        -Search each subcode.

        Decode each subcode into a subjective modal term.

        ・ Output the term of the aspect as a subjective explanation.

  The process 1140 is described with reference to FIG. Process 1140 constitutes the steps necessary to create a PQRST sequence that represents a digitized form of a subjective description of the patient's distress. Process 1140 is described on the assumption that when the patient is online and prompted by process 1140, he can enter conversational details of the subjective pain description. Process 1140 receives control from the calling process at start phase 1142. Step 1142 is the beginning of a loop that encodes the pain modalities entered by the patient into a set that fits the pain subcode. Step 1142 allocates space to the PQRST sequence that contains the subcode. Process 1140 then passes control to step 1144. Step 1144 establishes the next pain aspect to be encoded. Process 1140 then passes control to step 1146. Step 1146 retrieves a list of standard modal terms from the database 1150 and outputs them to the patient in a picklist format. That is, it is a list that the patient can examine and from which the patient can choose one of the modal terms. Process 1140 then passes control to step 1152. Step 1152 asks the patient to select the term of the aspect that best fits the patient's subjective explanation for the distress aspect encoded from the picklist. Process 1140 then passes control to step 1154. Step 1154 converts the modal terms selected by the patient into an integer that identifies the modal terms. This integer is a subcode for the current aspect. It is just the index position in the picklist of terms for the selected aspect. Process 1140 then passes control to step 1156. Step 1156 inserts the subcode integer into the PQRST array at the index position representing the aspect to be encoded. Process 1140 then passes control to test 1158. Test 1158 determines whether more aspects should be coded. If test 1158 determines that there are more aspects to be coded, process 1140 passes control to step 1144 to begin repeating the loop just described. If test 1158 determines that there are no more aspects to be encoded, then process 1140 passes control to step 1160. Step 1160 stores or copies the PQRST sequence into an appropriate data set, such as patient history 254. Process 1140 then passes control to step 1162. Step 1162 returns control to the calling process.

  With reference to FIG. 22b, process 1170 is described. Process 1170 is an example of the steps required to use a PQRST sequence as an index to retrieve a specific diagnosis from a disease table. This example assumes that a list of illnesses (or a combination of illnesses if there are more than one illness for a given distress code) is indexed by distress code and stored in the illness database 262 is doing. This example further assumes that there is a software process for accessing the database that can retrieve the elements of the database when given an access key. One obvious example of such a database access mechanism is an appropriately formatted structured search language (SQL) declaration, while another example is a disease that is accessed using the index position of each element. A simple array of names or pointers. Process 1170 receives control at start node 1172. Process 1170 then passes control to step 1174. Step 1174 loads a copy of the PQRST sequence that is used to select a diagnosis from the database 262. Process 1170 then passes control to step 1176. Step 1176 converts the DMM distress code into a formatted access key as required by the process of accessing the database 262. Process 1170 then passes control to step 1178. Step 1178 uses the access key to retrieve from the database 262 a record that matches the pain code. Process 1170 then passes control to terminal node 1180. Terminal node 1180 returns control to the calling process.

Disease management order (DMO)
A disease management order is a data record attached to a patient at the beginning of a DM session, which moves with the patient from process to process and is used to summarize decisions and orders issued by various processes during the session. Used at the end of the session (by the session termination process). The DMO record contains many fields and is stored in the session area of the DM specific database 264 (FIG. 3). One key field of the DMO, named “Code”, records the next action to be normally performed for the patient.

  One application of DMO is to signal special processing needed for a patient. For example, in order for a single requirement to flag a new patient for an initial interview, the open session process sets the DMO code field to “Calculate initial health” (FIG. 6, node 448). ). The DM session process then continues to the health assessment, which examines the DMO code and directs the patient to the initial health assessment process 488 (FIG. 7).

  Another use of DMO is to repeat the process as needed. For example, if the correlation assessment process requires additional health data during the session, it can call the health assessment again to obtain the missing data (FIG. 12, node 660). If the process has sufficient data, the DMO code is set to “optimize therapy” and the patient is removed from the assessment cycle.

  Another use of DMO is to track various reasons for the decisions made, which can be used in the end session process to issue a detailed report of what the DM process has learned about the patient. it can. For example, the therapy coordination process may refer the patient to the doctor for different reasons (FIG. 14, nodes 778 and 784; FIG. 15, nodes 832 and 854). In each case, the DMO code is set to “see MD”, but the DMO reason field is set to indicate a different reason.

  Finally, the essential use of DMO is to show “doctor orders”, ie to store all of the orders issued during a session. Thereby, those orders can be fulfilled when the session ends (FIG. 18, node 956).

Authorization Database Authorization Database 256 (FIG. 3) is the total collection of software elements that control access to DMM data and operations taken by the DMM process. This database provides DMM security, protection, reliability, control, and management functions in the form of passwords, access rights, need to know and clearance of knowing rights, public authorization, consent, constraints, limits, thresholds, etc. Support. This authorization database is an interface through which human staff of medical and software professionals define and control what automatic actions the DMM can and cannot perform through it. Since authorization manages the operation of all DMM processes, the authorization database must be asked for permission for all the detailed steps that the DMM should perform, from “fully automatic” to “globally automatic. It can be used to dynamically configure the system to operate in a variety of modes ranging from “unintentional”. The latter mode is particularly useful for experimental, testing, problem tracking, or system audit applications.

  Three tables in the authorization database relate to the operation of the DMM process described above and are described under the headings of the respective sections below. They are regulatory approval, sharing approval, and modified authorization level of therapy (TAPL).

Regulatory Authorization Regulatory authorization is a data set that ensures that the DMM meets all applicable provisions, licenses, and legal requirements and constraints in the field in which it operates. The regulatory approval data set is organized by jurisdiction and is defined for each jurisdiction, and its data fields can be disclosed between government aircraft. Regulatory approval functions are normally ignored by other automated medical systems, i.e., considered as practical medicine within the jurisdiction controlled by such a system and across jurisdictions beyond international boundaries. Therefore, it describes a very complex problem that must be met with so many different medical practical constraints and authorization regulations. This feature allows the DMM to comply with the law in its operation and contact with patients, doctors, health care organizations, government agencies, etc.

  Regulatory approvals are DMM-wide and can be used where they are applicable. One example is the closed session process (Figure 18, nodes 958-964), which is a legal requirement for the disclosure of confidential medical data prior to the delivery of DM sessions or patient notifications, instructions and reports Conditions and prohibitions must be taken into account.

Sharing authorization Sharing authorization is used to process the disclosure of individual medical data items. Each patient history data field is an access control field that defines whether medical data items can be disclosed to patients, various agents or machines, and other software objects that have special access authorization Is related to Sharing authorizations determine what items of medical data can be disclosed in the message and report to patients, patient representatives, doctors, laboratories, pharmacies, health care machines, or government agencies (ie, “Share Used by the DMM close session process (FIG. 18, sections 958, 960) to determine.

  Another use for sharing authorization is to prevent disclosure of diagnostic results to a patient when it is inappropriate to disclose (FIG. 18, node 964).

Modified authorization level of therapy (TAPL)
The Therapy Modified Authorization Level (TAPL) is a data set that specifies various levels of authority that the DMM has in changing patient therapy. TAPL is the degree of authority that the DMM has to deal with a patient's illness without the person's prior approval. When an item of patient history data is sought, for example, by a government agency or insurance company, the DMM looks at the access control field of that data item to know what sharing authorization level is required for it. The DMM then consults the authorization database to make sure that the requesting authority has the specified level of access authorization.

  At its most restrictive level, when the DMM database determines that a patient can benefit from a change in therapy, notify the physician and in any case obtain permission before adjusting the therapy TAPL requests the DMM. The least restrictive TPAL setting allows the DMM to automatically change the patient's treatment without human intervention. TAPL settings between these extremes require different degrees of prior notification and approval for different treatment interventions. TAPL is used by all DMM functions that change the patient's therapy or give advice on its effect (FIG. 15, node 830; FIG. 16, node 896).

Meta structure
Metadata Array For the purpose of discussing the meta-functions of a medical management system, the system data structure used to record, track, analyze, and report medical problems is called a metadata array. Visualized as a dimensional grid or array. This array lists the cause of the disease (eg trauma, infectious disease, allergies) along one dimension (abscissa or x-axis) with the label “cause” and the second with the label “anatomy”. List anatomical systems or organs affected by disease along the dimension (ordinate or y-axis). A given disease can be known as a cell in the metadata array at the intersection of the applicable “cause” and “anatomy” dimensions.

  In an embodiment, both “cause” and “anatomy” are naturally broadly subdivided. Thus, for example, the causes of infectious diseases are subdivided into bacteria and viruses, and bacteria are divided into gram positive and gram negative. Gram positives can be further subdivided into streptococci, etc. to the point that the system can identify the ultimate cause such as “meningococcal gram negative bacteria infection”. The anatomical dimension can obviously be further subdivided into organ structures, organs, tissues, cells, etc.

Because the metadata cube medical management system has a lot of contact with a patient, additional patient data extends the metadata array along the time dimension to form a metadata cube. The time axis is further referred to as its “Z” axis.

  The metadata cube is an internal data structure that supports various meta functions. The details vary depending on which medical system module performs which kind of meta-analysis, but all of the examples below apply.

・ Several symptoms of the same complaint (frequency meta)
・ Several infections in different dissection systems (cause meta)
・ Different diseases in the same dissection system (anatomy meta)
Long-term patient history, eg smoking habits over 35 years (volumetric meta)
• Chronic illness, eg 5 years of asthma or malaria illness • Short term disease progression, eg 3 days of gastrointestinal distress, headache, vomiting
Metafunctions Metafunctions are medical software objects that operate at the overall level of the entire medical management system and its various modules. They observe, record and analyze patient interactions with the system for the following purposes:

  Evaluate the use of the patient's system.

  Search for patterns or relationships that might indicate a problem.

  "Back" to explore the entire interaction with the patient's system.

  Analyze the patient's current session with past session content.

  The meta-function automates the view of the doctor, who is the person who sees the patient as an overall, complex biomechanism, making wrong decisions and requiring corrective measures at certain time intervals. They provide DMM with a powerful ability to analyze patient health as a whole and develop long-term medical diagnosis, treatment, advice, and management tactics.

  The frequency meta function uses the sequential meta function to analyze the frequency of consultation for the same disease. The anatomical meta-function analyzes patient complaints based on the relevant anatomical organ system. The causal-effect linked metafunction analyzes the disease back to its cause and then analyzes it for other diseases. The regional and volumetric meta functions analyze changes in disease parameters over time. The limit curve meta function monitors patient health for significant deterioration compared to a standard curve for the disease being managed. The interval meta evaluates the time interval of consultation for the same disease. The reliability meta-calculation establishes the reliability and normality of the data.

  The meta-function described for disease management is the same “metadata cube” as described in US Pat. No. 5,660,176 entitled “Computerized Medical Diagnosis and Treatment Advisory System”. "The data structure is used. However, since DM has different targets, it looks at different data elements of the cube along different coordinate axes.

  The term “meta” refers to the overall nature of these functions. It focuses on dealing with health data at the level of long-term trends, overall patterns, statistical distributions and other summarized relationships, not at a detailed level. As used herein, the term “function” refers to the various computational and analytical techniques used. Computational and analytical techniques include classical and fuzzy logic, arithmetic, geometry, trigonometry, analytic geometry, calculus, statistics, probability, domain mapping, transformation (Laplace, Fourier), heuristics, gradual Chemical formulas, etc. are used.

  Meta functions are implemented and embodied in the form of appropriate data and process structures such as databases, tables, arrays, modules, objects, scripts, lists, subroutines, procedures, functions, and so on.

Sequential Aggregation Meta The Sequential Aggregation (SS) meta function detects and aggregates the results of a single patient accessing separate modules of the overall medical management system, such as a diagnostic module and DMM. This is because it may represent a significant change when separate sessions are combined or it may worsen the patient's condition. The SS meta-function may be able to analyze the combined effects of the separate modules and issue recommendations based on this overall analysis.

  SS Meta uses preset thresholds for different combinations of system modules to be summed. This threshold is included in an internal table listing all combinations of modules such as medical diagnosis + disease management, medical diagnosis + medical audio / video / image library, medical diagnosis + treatment table consultation, etc. Yes.

  For example, for asthma, if a medical diagnostic module is referenced and diagnosed as asthma, the DM module is later used for asthma management, a medical audio / video / image library • If the module is referenced several times for pre-recorded asthma messages, the SS meta-function will perform medical diagnostics + disease management + medical for asthma to calculate thresholds that trigger special recommendations. The appropriate value from the audio / video / image library table will be used. Thus, even if a threshold is not obtained for any one module, diagnosis, disease management, and audio / video / image library consultation combine consultation for asthma and consider them together to determine the threshold.

Frequency meta frequency meta function investigates the number of times a patient consults the system and makes recommendations based on the frequency of consultation. This function calculates how many times the patient consulted the system, medical audio text consultation or treatment table consultant for the same complaint or illness, and sequentially aggregated meta function to analyze the combined effects of consultation Can be used to make recommendations based on this overall analysis.

  A threshold for the number of consultations (for internal as well as external) is established for a unit of time when the patient is authorized to the medical management system for each disease being managed Has been. The threshold is different for each disease and is modified by the sensitivity factor set. When this threshold is reached, the frequency meta function makes a recommendation. That is, a recommendation from the frequency metafunction can be triggered only by the fact that the patient has had a certain type of occurrence.

• Interval Meta Interval Meta function analyzes the time interval between each interaction for the same disease to detect trends that may indicate a problem. For example, when the function is trying to discover that interactions with the patient's system are occurring very close together, the function can make a recommendation based only on this fact.

  The method of sequential aggregation series is used. Consultation intervals are drawn on the diagram, and if the interval gets shorter and shorter, a meta recommendation is made.

• Cause Meta Cause Meta function is a DM background task that looks for disease or cause patterns that may help identify the root cause. Its function monitors and analyzes patient use of various system modules.

  The causal meta-function detects sequential aggregation series between medical diagnosis, disease management, medical audio text library, treatment table consultation, and all combinations thereof at decreasing time intervals. For example, a patient consulted the system on several occasions with complaints that reveal different parts of the body, and that during each session the medical diagnostic module was responsible for each separate problem caused by infection (proper Suppose that The causal meta-function detects such a series of consultations and alerts that the root cause may be in the patient's immune system if they reach a preset threshold per unit time. If the system is treating a patient with multiple causes of trauma, the cause metafunction will help the system consider the possibility that the patient is abusing drugs or alcohol.

Anatomy metaanatomy metafunction analyzes the patient's contact with the medical system in terms of a single organ or body anatomical system. This feature looks for different diseases being processed that may affect the same anatomical system. This function—when all of the different illnesses affect the same organ—often automates basic DM aspects to monitor and frequently measure the function of that organ.

  For example, if a patient consults a medical diagnostic module in three different cases: abdominal pain, vomiting, and diarrhea, the anatomical metafunction recognizes that these problems are all related to the gastrointestinal tract, Allows the system to adjust recommendations based on information.

  For example, both diabetes and hypertension cause a slow but progressive deterioration of kidney function. The anatomy meta-function detects the need for such special monitoring. Based on certain internal preset thresholds, the anatomical meta-analysis can recommend evaluation of the function of the affected organs in the disease management system. In the above example, for patients being managed for diabetes and hypertension, the anatomical meta-analysis can cause the medical management system to recommend testing for serum creatine, kidney function.

Cause-to-anatomy meta- cause-to-anatomy meta function coordinates the interaction between the cause and anatomy meta functions. Since there is a closer interaction between the causal meta and anatomical meta functions, those interactions are described here.

  Because the patient uses the medical management system for a long time, the cause / anatomy cells are stacked along the time or Z-axis, which tracks the time of interaction between the cause and the anatomy system, that is, what actually happened to the patient Diagnose.

  The metadata cube represents the addition of patient interaction to the system over time. Although much of the patient's past history is stored using the ICD-9-CM code, this technique, like conventional text slips in the field of patient medical records, provides a very useful analysis. Enable.

  The system can specify the cause of the problem without knowing the anatomical system involved, and the system can indicate what organ or system is involved without knowing the cause of the patient's problem It is important to keep in mind. For example, 6-year-old children who complain of muscle pain, headaches, runny nose, and joint pain complaints are most commonly viral infections, but describe the system of specific organs affected Is difficult.

  Interestingly, within the diagnostic module, different patterns are created in disease management while multiple problems occur in the same module. For example, diabetes can be manifested by or in the interaction of endocrine and vascular systems. However, another way to visualize the disease process in diabetes is to take it one step further. Whenever a medical management system (such as diabetes) affects other defective processes affecting the defective system, then "blood vessels" are further searched for the cause of the disease.

Cause - cause meta- chain meta-function automates the analysis of medical facts that a disease creates a pathological change in other organs of the body, which causes the disease to cause other diseases It means to cause. For example, the linkage meta function investigates a given disease as a cause and as a result and performs three analyzes on a given disease D.

        1. Find the root cause of D.

        2. Find other diseases caused by D.

        3. Repeat steps 1 and 2 recursively to find other root causes and other illnesses caused by D.

  Thus, linked meta-analysis tracks all the effects of illness on the body. To recursively find remote objects and illnesses, it uses a cause meta function (which function is used to detect a direct cause of a complaint or illness). Given the initial illness, linkage meta-analysis utilizes the metadata cube to detect patterns that cause the analysis to reverse the analysis of the patient's other possible causal linkages. Thus, it performs the analysis needed to detect related problems that are hidden away or not yet on the surface.

  The internal causal effect table used by the causal effect meta-function contains basic medical knowledge of the anatomy system, their relationship, their disease and disease cause chain. This table identifies the patterns necessary to explore the root cause and secondary illnesses. The second table used to control the processing of the causal chain contains other data such as probability of occurrence, importance of secondary illness, and possible therapeutic window.

  The result of the chained meta-calculation is a list of diseases to be verified and monitored in the current patient. These results are useful in the following.

        ・ Guarantees that side effects of illness will not be lost.

        ・ Do not overlook disease management therapy necessary to stabilize patients.

        Confirm the cause by ascertaining other effects (headache is consistent with cecal inflammation).

        ・ Negate the cause by not finding the desired effect (denial of malaria due to the absence of malaria parasites in the blood).

An example of the region meta region meta can be explained by plotting the pain or discomfort over time and summing the regions under the curve to find the total amount of distress or discomfort at that time . Many patients, especially those with incurable illnesses such as those with end-stage cancer, have continuous distress, but they are isolated and do not see their doctor regularly or they This is important because most doctors do not evaluate how much a patient suffers. They tend to “follow the pain” and never try to catch the pain. Here, once the suffering threshold is encountered, the patient will obtain anesthetic pain medications or increase their dosage.

Volumetric meta The volumetric meta function performs analysis based on the (three-dimensional) product of disease x anatomy x time and makes recommendations based on predetermined thresholds. The term “volumetric” refers to the metadata cube analysis method used, in which the history of smoking is expressed by the three axes P (poison), R (respiratory system) and Z (time). Appears as an enclosed volume. For example, a patient who smokes two cigarettes daily for 30 years is considered to have a 60-year history affecting the respiratory system.

  Volumetric analysis is important in many disease processes. Thus, patients with a 60 box-year smoking capacity have accumulated significant damage to the respiratory system. If this continues longer, it will result in a larger volume, more poison will affect the functioning of the respiratory system, and maybe more diagnosis and treatment.

  Another example of volumetric analysis is the long-term damage that diabetes causes in microvascular circulation.

  The volumetric metafunction software implementation includes an internal disease management table listing volumetric products for various diseases, as well as their threshold parameters. These thresholds (values dynamically modified by the sensitivity factor set) control special behavior and system analysis. If an applicable threshold is reached, the system performs a special analysis, then issues an internal alarm, searches for possible evidence of damage done to the applicable organ system, and makes a special recommendation to the patient. Do.

• Reliability meta- reliability meta function investigates the reliability of all patient data items to see if patient care is insufficient. If this function finds that the probability of diagnosis (separated or combined) is below the confidence threshold (corrected by the sensitivity factor set), this function recommends patient re-evaluation can do.

  This function uses an internal reliability indicator combined with all data items, which tracks the probability that the data item reflects the patient's actual health at the time it is recorded. These reliability indicators are established when they are first established for each data item of the medical management system and are correspondingly maintained throughout the lifetime of the system.

  For example, if the patient tells the system that he has a history of migraine headaches, the system can ask the patient:

-Who made the diagnosis of migraine? (Patient, friend, nurse, doctor, or neurologist)
• What tests were performed by whom, on what organization, and what results?
・ Who confirmed the test, how and in what relationship?
The philosophy is that, of course, if a headache specialist makes a diagnosis after a thorough and thorough workup, including brain imaging (MRI), lumbar puncture, and EEG, the probability of a correct diagnosis is very high That is to say. This will be recorded on the reliability indicator and combined with the diagnostic data item. If reliability is too low, a re-evaluation of higher level or standard protection will be planned, which will invoke more precise and complete questions.

Benefits of Disease Management Benefits of the medical management system and disease management module are as follows.

Benefits to patients- Faster, easier, cheaper medical services-Medical services accessible from outside the home when needed-Remote areas, medical services accessible in poor societies-Latest, best, tested・ Updated medical services ・ Patients can spend time slowly, repeat sessions and browse ・ Patients have complete medical history files
Benefits for healthcare professionals • Reduces contact with trivial, inappropriate, and useless patients • Improves doctor's diagnostic skills / experience • Doctors can compare their opinions with others • Repeated patients are better, continuous Provide medical records • Healthcare workers can access many medical data resources • Computer support for access to statistics, databases, decision-making and scheduling • Sessions and disease history available • Healthcare workers record Advice / action can be justified based on the responses made ・ patients can be compared within a group ・ large case database
Benefits to Healthcare Managers • Saves the cost of trivial contacts • Tracks contacts • Statistical information and planning • Outlines doctor / hospital work • Session logs reduce legal obligations and risks Ensure policy compliance / Standardize advice and treatment
Examines and evaluates benefits to health care regulators , HMOs, and physician actions. Medical records can be used for critiques. Compliance with regulations can be verified.
Benefits for health care teachers • Medical work can be simulated in large patient populations • Helps in medical research • Can compare case studies • Can be repeated while changing case handling The above detailed description is fundamental to the present invention Although novel features have been applied, shown, described, and pointed out to various embodiments, various omissions, substitutions, and modifications to the form and details of the described system depart from the scope of the present invention. It will be understood that these can be added by those skilled in the art.

1 is a block diagram of an automated medical diagnosis, treatment, disease management and information system according to the present invention. FIG. 2 is a schematic diagram of an arrangement of components of the system shown in FIG. 2B is a schematic diagram of an arrangement of components of the server computer shown in FIGS. 1 and 2A. FIG. FIG. 2 is a block diagram of a portion of a process and database file used by the system of FIG. 2 is a flowchart of a top level process performed by the system of FIG. 2 is a flowchart of a top level process performed by the system of FIG. 2 is a flowchart of a top level process performed by the system of FIG. 2 is a flowchart of a top level process performed by the system of FIG. 4D is a flowchart of the disease management module process shown in FIG. 4D and performed by the system of FIG. 6 is a flowchart of an open session process shown in FIG. 6 is a flowchart of the health assessment process shown in FIG. 8 is a flowchart of the critical symptom filter process shown in FIG. It is a flowchart of the severity assessment function shown in FIG. 8 is a flowchart of the initial health assessment process shown in FIG. 8 is a flowchart of the current health assessment process shown in FIG. 12 is a flowchart of a correlation assessment function shown in FIG. 12 is a flowchart of the critical curve assessment process shown in FIG. 12 is a flowchart of the critical curve assessment process shown in FIG. It is a flowchart of the therapy optimization process shown in FIG. 15 is a flowchart of the therapy adjustment health data process shown in FIG. 15 is a flowchart of the therapy adjustment health data process shown in FIG. FIG. 15 is a flow chart of therapy adjustment based on the objective health data process shown in FIG. FIG. 15 is a flow chart of therapy adjustment based on the objective health data process shown in FIG. It is a flowchart of the patient consent level function shown in FIG.15 and FIG.16. 6 is a flowchart of a close session process shown in FIG. FIG. 6 is a flowchart of a question version feature utilized by the disease management module process shown in FIGS. 1 and 5. FIG. 6 is a flowchart of a question version feature utilized by the disease management module process shown in FIGS. 1 and 5. FIG. 6 is a flowchart of a preview mode feature utilized by the disease management module process shown in FIGS. 1 and 5. FIG. 6 is a flowchart of a no-response feature utilized by the disease management module process shown in FIGS. 1 and 5. 6 is a flowchart of functions utilized by the diagnostic process in generating the disease management module process shown in FIGS. 4d and 5 and / or generating the PQRST (pain code) sequence entry for the patient shown in FIG. 4D. FIG. 22B is a flow chart of functions utilized by the diagnostic process shown in FIG. 4d in a search for a diagnosis using the PQRST (pain code) sequence input accumulated for the patient in FIG. 22A. 2 is a representative critical curve graph of health measurements plotted over time for a particular disease.

Claims (15)

Stores a patient's medical record corresponding to a specific patient (114) having a known or presumptive medical disease or condition, and a health parameter in the patient's medical record representing the patient's health history Memory (184) to
A disease database (262) storing disease specific changes to said medical disease or condition;
Means (452-458) for retrieving a medical record of a patient corresponding to a particular patient (114) having a known or presumptive medical disease or condition from said memory (184) by said patient identification number; A computerized disease management system comprising a computer with a computer program for functioning as means (406) for assessing the health of the patient,
The means (406) for assessing the health of the patient comprises:
Means for automatically receiving the patient's health status to obtain health data;
Means (966) for automatically storing the obtained health data in the medical record of the patient;
Means (652, 702) for automatically selecting specific health parameters corresponding to a portion of the patient's medical records;
Means (656, 704) for automatically calculating changes from a previous disease or condition management session of the patient's health status as indicated by health parameters;
Means (712) for automatically comparing the health status change with a disease specific change for the medical disease or condition from the disease database (262);
The computer program further includes a computer,
Based on the obtained health data and comparison results, disease therapy optimization means (408) comprising means (770, 790) for adjusting the disease or condition therapy, intervention or education process for the specific patient (114) ) Means for optimizing disease therapy (408);
A computerized disease management system that functions as means (958, 960) for automatically outputting data indicative of adjustments (770, 790) of a disease or condition therapy, intervention or educational process for the particular patient. A computer with a medical advice module (280, 250, 220) for causing the computer to function as a means (960, 964) for automatically providing medical information to a particular patient (114);
An authorization database (256) for storing authorization information indicating a level of accessibility to the medical information for each of a plurality of patients, wherein the authorization information includes an authorization database having an authorization level for the specific patient. A computerized medical advice system. Computer
A means of assessing the health of patients with the disease;
A computerized disease management system comprising a computer having a computer program for functioning as a means for optimizing disease therapy based on the patient's health assessment. Computer
A means of recording subjective health measurements in an electronic medical record corresponding to a particular patient;
Means for recording an objective health measurement in the electronic medical record;
A computerized correlation assessment system comprising a computer with a computer program for functioning as means for calculating a metric based on the subjective health measurement and the objective health measurement. Computer
Means to provide a critical curve for a particular disease;
Means for recording a plurality of health parameters in an electronic medical record corresponding to a specific patient having the specific disease;
A computerized critical curve assessment system comprising a computer with a computer program for functioning as a means for comparing at least one health parameter with the critical curve to obtain health assessment information. A computer with a disease management module for causing the computer to function as a means for automatically providing health assessment and therapy information for patients with disease;
A disease management system comprising an authorization database storing authorization information indicating a level of accessibility allowed for health assessment and therapy information. A computer with a medical advice module for causing the computer to function as a means to provide medical information to the patient;
A computerized medical advice system having an authorization database storing authorization levels associated with the medical advice module. Computer
Means for determining the availability of objective and subjective health measures for particular patients with particular diseases;
A computer program for functioning as a means for adjusting the therapy for the patient based on an available objective health measure, or as a means for adjusting the therapy for the patient based on an unavailable objective health measure and a subjective health measure available A computerized system for therapy optimization, comprising a computer comprising: Computer
Means for providing a plurality of groups of questions indicative of assessing patient health, wherein the groups are indicative of assessing the patient's health relative to a language level understandable by each group;
Means for identifying said language level understandable by a particular patient;
Means for selecting one of the group of questions based on the identified language level;
A computerized question explanation system comprising a computer with a computer program for functioning as a means to ask the patient from a selected group. Computer
Means for encoding a patient's subjective pain perception into a pain code;
A computerized medical diagnostic system comprising a computer having a computer program for functioning as a means for diagnosing a disease by indexing a disease database with the pain code. Computer
Means for providing a treatment change authorization level corresponding to a particular patient having a particular disease;
Means for automatically determining therapy adjustments for said patient;
A computerized treatment modification system comprising a computer with a computer program for causing the patient to function as a means of recommending the therapy adjustment as permitted by the treatment modification authorization level. Computer
A means for setting a preview mode for a medical script;
A means of asking questions about the patient's health;
Means for allowing the patient to receive information regarding the results of answering the question;
A computerized preview mode system having a computer with a computer program for functioning as a means to reset the medical script as if the question had not been answered. Computer
Means for providing a plurality of parameters;
A means to ask selected questions from a medical script;
Means for waiting for a preset time in response to the question;
A computerized no-response system comprising a computer having a computer program for functioning as means for executing an action based on the parameter after the preset time has ended without response. Computer
A means of filtering the critical symptoms of a particular patient with a particular disease;
Means for obtaining and storing initial health measurements from said patient if said patient has not been previously evaluated;
A computerized health assessment system comprising a computer with a computer program for functioning as a means for obtaining and storing subsequent health measurements from the patient if the patient has been previously evaluated. Computer
Means for determining the severity of critical symptoms obtained from a particular patient having a particular disease;
Means for assessing the health of the patient if the level of severity is sufficiently low;
A computerized severe symptom filtering system having a computer with a computer program to function as a means for taking a predetermined action if the level of severity is sufficiently high.