EP2710504A2 - Systèmes, procédés et produits programmes informatiques pour la surveillance d'un patient - Google Patents

Systèmes, procédés et produits programmes informatiques pour la surveillance d'un patient

Info

Publication number
EP2710504A2
EP2710504A2 EP12724263.4A EP12724263A EP2710504A2 EP 2710504 A2 EP2710504 A2 EP 2710504A2 EP 12724263 A EP12724263 A EP 12724263A EP 2710504 A2 EP2710504 A2 EP 2710504A2
Authority
EP
European Patent Office
Prior art keywords
patient
weight
module
ivr
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP12724263.4A
Other languages
German (de)
English (en)
Inventor
Daniel L. Cosentino
Christopher T. Abrahamson
Kristin N. Parrott
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Cardiocom LLC
Original Assignee
Cardiocom LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US13/112,276 external-priority patent/US20120041775A1/en
Application filed by Cardiocom LLC filed Critical Cardiocom LLC
Publication of EP2710504A2 publication Critical patent/EP2710504A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/20—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/30—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for calculating health indices; for individual health risk assessment
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H80/00—ICT specially adapted for facilitating communication between medical practitioners or patients, e.g. for collaborative diagnosis, therapy or health monitoring
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records

Definitions

  • the present disclosure is directed, generally, to wellness monitoring devices and, more specifically, to measuring devices that monitor patients with a disease or condition.
  • BACKGROUND There are a number of diseases and health-related conditions that are known to be associated with certain physiological parameters, including weight change due to fluid gain or loss.
  • diseases and conditions associated with fluid retention and associated weight change include kidney disease, congestive heart failure (CHF), cirrhosis of the liver, lymphatic obstruction, lymphedema, certain medications, and pre-eclampsia.
  • CHF congestive heart failure
  • cirrhosis of the liver include lymphatic obstruction, lymphedema, certain medications, and pre-eclampsia.
  • Chronic Kidney Disease also known as chronic renal failure, includes a progressive loss of renal function over a period of months or years.
  • CKD includes all individuals with kidney damage, as well as all individuals with a glomerular filtration rate (GFR) of less than 60 mL/min/1.73 m 2 for 3 months, irrespective of the presence or absence of kidney damage. 2 038386
  • CKD is often divided into a series of five stages.
  • Stage-five C D often referred to as End Stage Renal Disease (ESRD)
  • ESRD includes patients with established kidney failure such as those with a GFR ⁇ 15 mL/min/1.73 m 2 , or those patients who require permanent renal replacement therapy.
  • ESRD patients are usually treated by drugs, dialysis, and/or kidney transplant.
  • Type 2 diabetes mellitus is the most common cause of ESRD in the U.S.
  • Diabetic nephropathy is believed responsible for at least 25% of all renal dialysis patients.
  • Other common causes of ESRD include hypertension and glomerulonephritis.
  • ESRD symptoms include weight change, such as weight gain due to fluid retention in the patient's tissues or weight loss.
  • a measure of the patient's weight change is often used as an indicator of the patient's condition, where a weight above a threshold or below a threshold may require medical intervention, such as dialysis or drug therapy. Consistent monitoring of a patient's weight and application of appropriate treatment can minimize a patient's decline, reduce risk of re- hospitalization, and/or improve quality of life.
  • computerized weight measurement device comprises receiving data indicative of a weight.
  • the weight is compared to a first weight parameter and a second weight parameter, generating information relevant to End Stage Renal Disease (ESRD) from comparing the weight to at least one of the first and second parameters.
  • Output is then provided that includes the generated information.
  • ESRD End Stage Renal Disease
  • Software can be utilized to facilitate assessment and treatment recommendations of a remotely monitored patient and can run in the background.
  • the pathway assistant which searches data for key information and creates pathways or roadmaps, provides an automated system for standardized assessment, treatment, and evaluation of patients being monitored.
  • the pathways generated allow a user, nurse, or caregiver, to follow precise instructions for assessing a patient's condition.
  • the pathways software limits human error associated with assessment thus providing an advantage over prior art.
  • the pathways software also facilitates highly scalable, cost effective monitoring. Using the pathways software 1 Nurse can manage hundreds or even thousands of patients. Typically, staffing ratios can be increased from 1 Nurse : 75 patients to 1 Nurse : 500+ patients.
  • a second embodiment is a system which comprises a scale measuring a weight of a patient.
  • the scale includes a processor-based device with a memory which stores a first weight parameter and a second weight parameter relevant to ESRD.
  • the processor-based device compares the weight of the patient to the first and second weight parameters and provides patient feedback based on the comparison.
  • Another embodiment consists of a computer program product having a computer readable medium having computer program logic recorded thereon for monitoring a patient.
  • the computer program product comprises code for facilitating assessment and treatment, including critical pathways.
  • Yet another embodiment is a system for monitoring ESRD that comprises means for measuring a weight of a patient, means for comparing the weight of the patient to a plurality of weight parameters relevant to ESRD, and means for providing output consistent with the comparing the weight of the patient to the plurality of parameters.
  • a method in another example embodiment, includes receiving data indicative of a physiological parameter; scanning the data; determining if any of the data matches pre-defined criteria, and if any of the data matches pre-defined criteria, then generating a medical pathway for assessment by a user; and providing output including the medial pathway; wherein the user can follow the medical pathway to assess, educate, intervene, or provide treatment recommendations to the patient; or notify a remote health care provider of the patient status.
  • a system for assessment of remotely monitored patients includes a receive module for receiving data from remote monitoring devices; a pathways module for generating medical pathways based on the data received; and a management module for managing a plurality of medical pathways.
  • a method may include initiating a call between a patient and an interactive voice response (IVR) system.
  • the method may also include authenticating the patient on the call.
  • the method may further include collecting data from the patient after authenticating the patient.
  • the method may also include performing risk assessment of the patient based, in part, on the collected data.
  • IVR interactive voice response
  • a system in another example embodiment, includes an authentication module for authenticating a patient for accessing an interactive voice response (IVR) system.
  • the system also includes a text-to-speech module for providing prompts to the patient.
  • the system further includes a data collection module for receiving responses to the prompts from the patient.
  • the system also includes a risk assessment module for evaluating the responses received by the data collection module.
  • an apparatus in yet another example embodiment, includes a processor coupled to a memory device, in which the processor is configured to initiate a call with a patient.
  • the processor is also configured to authenticate the patient.
  • the processor is further configured to collect data from the patient.
  • the processor is also configured to perform risk assessment of the patient from the collected data.
  • FIGURE 1 is an illustration of an exemplary system for monitoring patient wellness, adapted according to one example embodiment
  • FIGURE 2 is an illustration of an exemplary operational flow performed by a monitoring device according to one example embodiment
  • FIGURE 3 is a block diagram of an exemplary monitoring device adapted according to one example embodiment
  • FIGURE 4 is an illustration of an exemplary integrated monitoring device, such as may include the features shown in FIGURE 3 to provide patient monitoring, according to one example embodiment;
  • FIGURE 5 is an illustration of an exemplary integrated monitoring device, such as may include the features shown in FIGURE 3 to provide patient monitoring, according to one example embodiment;
  • FIGURE 6 is operational flow diagram of a pathways software, according to an example embodiment
  • FIGURE 7 is an example screen shot of a global queue, according to an example embodiment
  • FIGURE 8 is an example screen shot of a member queue, according to an example embodiment
  • FIGURE 9 is an example screen shot of a open pathways screen, according to an example embodiment
  • FIGURE 10 is an example screen shot of an assessment category, according to an example embodiment
  • FIGURE 11 is an example screen shot of a guide me screen, according to an example embodiment
  • FIGURE 12 is an example screen shot of a notes field, according to an example embodiment
  • FIGURE 13 is an example screen shot of a summary field, according to an example embodiment
  • FIGURE 14 is an example screen shot of a triggered rules field, according to an example embodiment
  • FIGURE 15 is an example screen shot of a closed pathway field, according to an example embodiment.
  • FIGURE 16 is an example screen shot of a pathway summary, according to an example embodiment.
  • FIGURE 17 is a flow chart illustrating setting up a patient for access to an IVR system according to an example embodiment.
  • FIGURE 18 is a flow chart illustrating authentication of a patient in an IVR system according to one embodiment.
  • FIGURE 19 is an example screen shot of message selection for an IVR system according to an example embodiment.
  • FIGURE 20 is an example screen shot of custom message entry for an IVR system according to an example embodiment.
  • FIGURE 21 is an example screen shot illustrating assignable numeric values to questions for risk stratification according to an example embodiment.
  • FIGURE 22 is an example screen shot illustrating glucose alerts configurable for patients of the IVR system according to an example embodiment.
  • FIGURE 23 is an example screen shot illustrating configuration of administrators according to an example embodiment.
  • FIGURE 24 is an example screen shot illustrating a graphical view of patient health information according to an example embodiment.
  • FIGURE 25 is an example screen shot illustrating a tabular view of patient health information according to an example embodiment.
  • FIGURE 26 is an example screen shot illustrating an administrator dashboard summary according to an example embodiment.
  • FIGURE 27 is an example screen shot illustrating biometric alerts according to an example embodiment.
  • a pathway assistant can be utilized to facilitate assessment or treatment recommendations of a remotely monitored patient and can run in the background.
  • the pathway assistant which searches data for key information and creates pathways, provides an automated system that standardized the assessment, treatment, and evaluation of patients being monitored.
  • the pathways generated allow a user, nurse, or caregiver, to follow precise instructions and assessing a patient's condition.
  • the pathways software limits human error associated with assessment and significantly increase efficiencies for managing large dialysis patient populations (hundreds of thousands of dialysis patients) thus providing an advantage over prior art.
  • FIGURE 1 is an illustration of the exemplary system 100 for monitoring patient wellness, adapted according to one embodiment.
  • Physiological data of a patient is monitored utilizing a monitoring apparatus 101 and output is provided to the patient, caregiver, a remote computer 102, and/or a health care provider.
  • Data generated from the monitoring is transmitted to the remote computer 102 via a communication network 103.
  • patient data contemplated for transmission includes a patient's weight but might include any physiological parameter answers to questions, or other data.
  • Patient data may also include other data from the monitoring, such as blood pressure, electrocardiogram, fluid intake, fluid output, bio impedance, blood glucose, symptoms related to ESRD, and the like.
  • the remote computer 102 may be, for example, at a facility for a health care provider, a dialysis treatment center, where a nurse, physician or nurse practitioner monitors the patient data and provokes treatment in accordance with such data.
  • the monitoring apparatus 101 is located at a healthcare facility, a dialysis treatment center, a patient's residence, or other location convenient to the patient.
  • the monitoring apparatus 101 includes processes that present messages to a patient informing the patient of the results of the monitoring, inviting the patient to contact a health care professional, accelerate their dialysis treatment schedule, or instructing the patient to modify drug, diet or care plan, ask the patient certain questions, and the like.
  • the monitoring apparatus includes a weighing device, such as a scale that has a processor and memory operably configured to compare the patient's weight with various parameters relevant to ESRD, or other conditions, and to perform one or more processes to facilitate the patient's treatment. Operation of the monitoring apparatus 101 and communication therewith are described in more detail below.
  • FIGURE 2 is an illustration of an exemplary operational flow diagram 200 performed by a monitoring device according to one example embodiment.
  • the monitoring device 101 (FIGURE 1) can be adapted to perform the operational flow 200.
  • the operational flow 200 begins at 201.
  • the monitoring device presents a message (e.g., on a computer screen or other type of screen) imploring the user to step on the scale.
  • the monitoring device uses one or more transducers, measures the weight of the patient.
  • the monitoring device presents a message in response to the patient's stepping on the scale, where the message gives the patient's weight (also referred to below as "daily weight").
  • the monitoring device may also calculate and/or store the patient's dry weight with a date and time.
  • the dry weight is one parameter used to assess the condition or fluid status of the patient.
  • the dry weight may be set, remotely or otherwise, by a health care provider familiar with the patient's condition.
  • a message is presented giving the patient's dry weight.
  • the monitoring device compares the patient's weight to the patient's dry weight at block 205. If the patient's weight is substantially equal to the patient's dry weight, the monitoring device presents a message to the patient to that effect at block 206. If the patient's weight differs from the patient's dry weight, the patient receives a message informing the patient of the difference at one of blocks 207 and 208.
  • the process can start at block 209, whereby the patient's weight is compared to the patient's warning weight to derive information about the patient's condition.
  • the warning weight in this example, includes a high weight limit of the patient and may be calculated by the monitoring device or set, remotely or otherwise, by a health care provider.
  • the warning weight is a number equal to a mean pre-dialysis weight plus a constant, as shown in Equation (1).
  • Warning Weight (mean pre dialysis weight over past 30 days) +
  • the patient is 6
  • the monitoring device uses a weight gain calculation, such as that shown in Equation (2) in order to formulate the message of block 210.
  • the operational flow 200 then exits at block 215.
  • Weight Gain (Warning Weight - lKg) - Daily Weight
  • the patient's weight is at or above the warning weight, the patient is informed of such condition. Specifically, if the patient's weight is at the warning weight, a message to that effect is presented to the patient at block 211. Similarly, if the patient's weight is above the warning weight, a message to that effect is presented to the patient at block 212.
  • the operational flow 200 advances to block 213 where it is discerned whether the monitoring device has an enabled call function. If the call function is not enabled, then the operational flow 200 exits at block 215. If the call function is enabled, then the patient is presented a message at block 214 to call his or her health care provider. In some embodiments, the message is interactive (e.g., using a touchscreen or keypad), allowing the patient to establish the call. In other embodiments, the call may be placed automatically. In other embodiments, the patient could be provided with specific dialysis care plan or treatment instructions. In addition, questions may be asked of the patient to aid in diagnosing the patient's condition. The operational flow exits at block 215.
  • the operational flow 200 is especially useful in monitoring ESRD patients. For instance, comparing a patient's weight to the dry weight and/or the warning weight provides some reference as to the patient's interdialytic weight gain (IDWG). This is important as excessive interdialytic weight gain (IDWG) is usually related to an overload of sodium and water, and is an important factor for arterial hypertension in dialysis, which may accelerate left ventricular remodeling and increase risk for cardiovascular events and death.
  • Various embodiments may use other parameters in addition to, or alternatively to, a dry weight and a warning weight, e.g., a lower weight limit for a patient equal shown in Equation (3).
  • various embodiments may modify one or more of dry weight and warning weight from the descriptions given above or monitor other physiological parameters.
  • Communication is established with the remote device 102 (FIGURE 1) to transmit data consistent with the comparison at block 209 and/or at block 205 and/or any other information relevant to the patient's wellness, i.e. answers to questions asked.
  • the remote device Once communication is established with the remote device, the information is transferred and analysis of the data can be performed.
  • a health care provider can provide treatment to the patient by, e.g., initiating automatic processes in the monitoring device (e.g., taking blood pressure or presenting a questionnaire), scheduling a nurse or doctor visit, and the like. The content and timing of the communication is discussed in more detail with respect to FIGURE 3 below.
  • FIGURE 2 shows various messages presented to a user, and some of the messages can be interactive. Other embodiments may present messages using a different medium (e.g., audio and/or video), a different format (e.g., using different measuring units or languages) or, even, different substance. Any message that may be useful to present to a patient may be presented in various embodiments. For instance, Table 1 provides a non-exclusive list of message alternatives that may be adapted for use in the operational flow 200. The messages can be used to gain information from the patient regarding the patient's symptoms and status. Answers to the questions can then be transmitted to the remote device 102 (FIGURE 1). TABLE 1
  • the monitoring device may present one or more interactive messages in Table 2 as a standard question set, where questions answered positively generate an exception (reported to the remote device 102) regardless of a symptom score that may be assigned and where scores can be changed at a later date.
  • the scope of embodiments is not limited to the monitoring of ESRD, as functionality to monitor other diseases may be additionally included in some embodiments.
  • a Telescale® monitoring device available from Cardiocom, LLC, which is operable to monitor symptoms of diseases such as congestive heart failure, is modified to additionally include functionality to perform the operational flow 200 of FIGURE 2 and to include some or all content of Tables 1 and 2.
  • a Telescale® monitoring device is described in United States Patent 6,290,646, which is incorporated herein by reference in its entirety.
  • An important aspect of the invention is a library of interactive messages and education statements for ESRD patients that are focused on a broad range of topics including, but not limited to: access management, fistula and graft options, infection and wound identification and management, adherence with dialysis treatment schedules, compliance with fluid intake restrictions, general dialysis treatment options (home hemodialysis, peritoneal dialysis), and transplant options.
  • Such interactive messages may be included in the question set of one embodiment, where the interactive messages also include the co-morbidities of ESRD such as CHF, hypertension and diabetes, which are important in the integrated care for dialysis patients.
  • FIGURE 3 is a block diagram of an exemplary monitoring device 300 adapted according to one embodiment and operable to perform the functions described above with respect to FIGURE 2.
  • a microprocessor system 324 including a CPU 338, a memory 340, an optional input/output (I/O) controller 342 and a bus controller 344 is illustrated. It will be appreciated that the microprocessor system 324 is available in a wide variety of configurations and is based on CPU chips such as a general purpose processor, an Application Specific Integrated Circuit (ASIC), a Digital Signal Processor (DSP), a multi-core chip package, and/or the like.
  • ASIC Application Specific Integrated Circuit
  • DSP Digital Signal Processor
  • the memory 340 includes computer-executable code therein, which when executed, causes the CPU 338 to perform functions consistent with that shown in FIGURE 2 and other functions described herein.
  • various elements of embodiments are in essence the software or firmware code defining the operations of such various elements.
  • the executable instructions may be obtained from the memory 340, which includes a tangible readable medium (e.g., a hard drive media, optical media, RAM, EPROM, EEPROM, tape media, cartridge media, flash memory, ROM, memory stick, and/or the like).
  • readable media can include any medium that can store
  • the monitoring device 300 may be powered in any of a variety of ways, such as by ordinary household A/C line power, DC batteries, rechargeable batteries, and/or the like.
  • Power source 319 provides electrical power for operating the electronic devices.
  • a power source for operating the electronic scale 318 is generated within the housing, however those skilled in the art will recognize that a separate power supply may be provided or the power source 319 may be adapted to provide the proper voltage or current for operating the electronic scale 318.
  • the housing 314 includes a microprocessor system 324, an electronic receiver/transmitter communication device such as a modem 336, an input device 328 and an output device 330.
  • the modem 336 is operatively coupled to the microprocessor system 324 via the electronic bus 346, and to the remote computer 102 via a communication network 334 and modem 335.
  • the communication network 334 may be any communication network such as the telephone network, wide area network or Internet. It will be appreciated that the modem 336 may include a generally well known product commercially available in a variety of configurations operating at a variety of BAUD rates for dial-up or high-speed Internet access.
  • the output device(s) 330 are interfaced with the microprocessor system 324.
  • These output devices 330 include a visual electronic display device 331 and/or a synthetic speech device 333.
  • Electronic display devices 331 are well known in the art and are available in a variety of technologies such as vacuum fluorescent, liquid crystal or Light Emitting Diode (LED).
  • the patient reads alphanumeric data as it scrolls on the electronic display device 331, which in some embodiments, may include a touch-screen device that interacts with the patient by sensing touch.
  • Output devices 330 include a synthetic speech output device 333 such as a
  • Chipcorder manufactured by ISD (part No. 4003), or direct wav. file or sound file playback by digital to analog converter, but may also include a speech-input and recognition device.
  • other output devices 330 include pacemaker data input devices, drug infusion pumps, home dialysis equipment or transformer coupled transmitters.
  • the messages shown in FIGURE 2 and Tables 1-3 can be presented audibly or on a user interface presented on the display device 331.
  • input device(s) 328 may be interfaced with the microprocessor system 324 and may be included additionally to, or alternatively to, a touchscreen.
  • an electronic keypad 329 is provided for the patient to enter responses into the monitoring apparatus. Patient data entered through the electronic keypad 329 may be scrolled on the electronic display 331 or played back on the synthetic speech device 333. Patient input may also be audibly received through the speech device 333 in some configurations.
  • the microprocessor system 324 is operatively coupled to the modem 336, the input device(s) 328 and the output device(s) 330.
  • the electronic scale 318 is operatively coupled to the central system 324. Electronic measurement signals from the electronic scale 318 are processed by the A/D converter 315. This digitized representation of the measured signal is then interfaced to the CPU 338 via the electronic bus 346 and the bus controller 344.
  • the physiological transducing device includes the electronic scale 318.
  • the electronic scale 318 may include one or more of the following elements: load cells, pressure transducers, linear variable differential transformers (LVDTs), capacitance coupled sensors, strain gages and semiconductor strain gages. These devices convert the patient's weight into a useable electronic signal that is representative of the patient's weight.
  • the electronic scale 318 is generally well known and commercially available, and any compatible electronic scale now known or later developed can be used in various embodiments.
  • an A/D converter 315 may be included within the scale 318 or within the microprocessor system 324 or within the housing 314.
  • One skilled in the art has a variety of design choices in interfacing a transducing device comprising an electronic sensor or transducer with the microprocessor system 324.
  • the scale 318 may provide an analog or digital electronic signal output depending on the particular type chosen. If the electronic scale 318 provides an analog output signal in response to a weight input, the analog signal is converted to a digital signal via the A/D converter 315. The digital signal is then interfaced with the electronic bus 346 and the CPU 338. If the electronic scale 318 provides a digital output signal in response to a weight input, the digital signal may be interfaced with electronic bus 346 and the CPU 338. Furthermore, an internal A/D converter connected to a transducer, such as a pressure sensor, can be used to provide pressure information to the CPU for blood pressure measurement.
  • a transducer such as a pressure sensor
  • various embodiments may differ from the configuration shown in FIGURE 3.
  • the communication path including modems 335 and 336 may be supplemented by, or replaced by, a wireless communication path operable to communicate over one or more networks, such as an IEEE 802.1 1 network or a 3G or 4G cellular network.
  • various embodiments may include more or fewer transducers or transducers of different types than that shown in FIGURE 3 while still performing functions the same as, or similar to, that shown in FIGURE 2.
  • the monitoring device 300 presents a message, such as that shown in block 202 of FIGURE 2, inviting the patient to ascend the scale 318.
  • the patient's weight is measured and compared to parameters by the CPU system 324.
  • one or more interactive messages may be presented to the user via the output devices 330, 331, 333 to inform the user of the user's weight status, blood pressure, and/or to inquire about other health factors. Examples of interactive messages to inquire about health factors are shown in Tables 1-2, above.
  • the user interacts with the monitoring device 300 by using the keypad, the display 331 (in the case of a touchscreen), and/or the speech module 333 (if the speech module 333 includes input-receiving functionality) to answer the interactive messages.
  • Communication with the remote computer 102 may be initiated by the monitoring device 300 automatically in some embodiments.
  • the monitoring device 300 automatically alerts the remote computer 102 to the exception or may automatically alert a care giver.
  • the patient's weight data, blood pressure or other vital signs, exceptions, and/or answers to interactive messages are automatically transmitted to the remote computer 102 as they are generated. Establishment of communication can be automatic, periodic, exception-driven, patient-initiated, remote computer 1020-initiated, and/or the like.
  • the patient's weight data, blood pressure, or other vital signs, exceptions, and/or answers to interactive messages are transmitted to the remote computer 102, where such information is further analyzed and/or processed.
  • a medical professional caregiver may telephone the patient to discuss, clarify or validate any particular wellness parameter or physiological data point.
  • particular software is used to facilitate further assessment or treatment recommendations as will be explained in more detail below.
  • the conversation may be carried out over a telephone network by a conventional telephone device (not shown) or over the computer network 103 (FIGURE 1) using the speech device 333 and a computer network telephony technology, such as Voice Over IP (VOIP).
  • the medical professional caregiver may update the list of wellness parameter questions listed in Tables 1-3 from the remote computer 102 over the two-way communication network 103 (FIGURE 1).
  • the modified query list is then stored in the memory 340 of the microprocessor system 324.
  • FIGURE 4 is an illustration of an exemplary integrated monitoring device 400, such as may include the features shown in FIGURE 3 to provide patient monitoring.
  • the integrated monitoring device 400 includes an electronic scale 418.
  • the electronic scale 418 further includes a top plate 411 and a base plate 412.
  • the integrated monitoring device 400 further includes a housing 414 and a support member 416.
  • the base plate 412 is connected to the housing 414 through the 2012/038386
  • the housing 414 further includes output device(s) 430 and input device(s) 428.
  • the integrated monitoring device 400 is integrated as a single unit with the support member coupling the base plate 412 and the housing 414, thus providing a unit in a one piece construction.
  • An example scale is described in U.S. Patent No. 7,577,475, which is incorporated herein by reference in its entirety.
  • blood pressure measurement apparatus and electrocardiogram (EKG) measurement apparatus can be utilized with the integrated monitoring device 400 for recordation and/or transmission of blood pressure and EKG measurements to a remote location.
  • EKG electrocardiogram
  • other monitoring devices such as blood glucose, oxygen saturation, bio impedance, and other physiological body functions that provide an analog or digital electronic output may be utilized with the integrated monitoring device 400.
  • various embodiments may provide enhanced
  • FIGURE 5 is an illustration of an exemplary integrated monitoring device 500, such as may include the features shown in FIGURE 3 to provide patient monitoring.
  • the integrated monitoring device 500 includes a monitoring console 502.
  • the console 502 preferably includes a "yes" button 504 and a "no" button 506 for interacting and answering questions posed to the patient.
  • the console 502 preferably also includes scroll buttons 510 for scrolling and other buttons 508.
  • the console can be connected to a physiological measuring device 512.
  • physiological measuring device can be any device capable of measuring or monitoring a physiological parameter, such as a blood pressure monitor, a pulse oximeter, a scale, a glucose meter, a peak flow meter for measuring lung capacity, and the like.
  • FIGURES 4 and 5 are shown as stand-alone units, the scope of embodiments is not so limited, as other embodiments may differ somewhat in configuration.
  • the calculating and communication functionality is included in a general purpose computer that is in communication with one or more peripheral physiological transducing devices.
  • Warning Weight (mean pre dialysis weight over past 30 days) + lKg
  • Weight Gain (Warning weight - lKg) - daily weight
  • software or a pathway assistant, can be utilized to facilitate diagnosis or treatment of a remotely monitored patient and can run in the
  • the pathway assistant which searches patient data for key information and creates pathways, provides an automated system that standardized the diagnosis, assessment, treatment, evaluation and management of patients being monitored.
  • the pathways generated allow a user, nurse, or caregiver, to follow precise instructions for assessing a patient's condition.
  • the pathways software limits human error associated with assessment and provides more efficient, large population
  • a logic flow diagram is provided for creating a pathway 600, such as a pathway for diagnosing or treating a patient.
  • Operational flow starts at block 602.
  • a scan module 604 scans new log files received from, for example, a remote monitoring device or other remote data source (i.e. dialysis treatment center lab values,).
  • a determine module 606 determines if any data in the new log files matches pre-defined data. If the determine module 606 determines that data does match pre-defined data, operational flow branches "YES" to a pathway module 608 that creates a pathway for assessment by a user, nurse, or care giver. Operational flow ends at block 10. Referring to the determine module 606, if the determine module 606 determines that no data matches, operational flow branches "NO" to the end block 610, and no corresponding pathway is created.
  • the pathway assistant searches for key types of activities that include real time biometric/symptomatic alert pathways, upcoming scheduled pathway activities/events, or other data driven patient or population specific elements.
  • a pathway is generated and assigned to the patient.
  • a monitoring apparatus 101 connects with a remote computer 102 and transmits information the remote computer 201
  • a device log is created which describes the types of data that has been received, for example, weight, PEFR, SP02, Glucose, Blood Pressure, Heart Rate, and Health Check responses.
  • the pathway assistant scans this device log for pre-selected criteria, and when matches are found, the associated pathway is created and assigned to a patient.
  • the pathway generated by the assistant is different from standard alerts in that they allow for more granularity in the areas of recurrence and trending.
  • the pathway itself creates a standardized methodology for dealing with episodes and out of scope symptoms, biometrics or lab values.
  • the pathway provides a roadmap for a caregiver to follow to ensure that correct assessment and treatment recommendations are provided.
  • the pathway is advantageous because it facilitates assessment and treatment of patients in a standardized methodology that limits human error.
  • the pathway assistant also creates pathways for upcoming scheduled events. These events are not alert events but normal regular follow-up or maintenance. This type of pathway is created in a "suspended" state, meaning that it is not active or in need of immediate attention. On the due date of the schedule, the pathway automatically moves to an active status to indicate it is in need of attention.
  • An example of a scheduled event might include annual medication assessments, QOL surveys, or flu shot reminders.
  • Pathways can be triggered by referencing multiple variables. Some of these variables include: vital signs or symptoms transmitted by a monitoring device; predefined schedules, manually by a user, lab values, or dialysis treatment values. The pathways can be organized for better handling.
  • Figure 7 is an example of a global pathways work queue 700. This global queue 700 lists all the current pathways.
  • Figure 8 is an example of a member pathways work queue 800. This member queue 800 lists all the current pathways for a particular member. From the global pathways work queue 700, a user can select a member to go to the member queue 800. From here, a user can choose to manually open a pathway, open a pathway that is "due", open a "scheduled” pathway, or view closed pathways.
  • Figure 9 is an example screen shot 900 for manually opening a pathway and provides a listing of available pathways.
  • Figure 10 is an example of a member pathway 1000.
  • Each pathway 1000 has certain assessment categories 1002.
  • the categories are color coded to facilitate use by a user. Red categories have an alert or positive response to a question. Green categories have a response that is normal or expected. Blue categories indicate a category that has not yet been addressed.
  • Each category has certain "questions" 1004 to be asked and the answers recorded. It is noted that the pathway includes the possible answers. An example question to be asked is "did you have a salty meal?" and the available answers are yes or no. The user can populate the correct answer.
  • Each question has the possibility to have corresponding actions, or secondary pathways, based on the answer.
  • Questions and actions can have "guide me” links that open to provide detailed educational content 1100, as illustrated in Figure 1 1.
  • Question and action selection is point and click on the requested boxes or radio buttons. Questions and actions have branching logic built-in. For example, if you select "YES" to a certain question, the pathway may automatically populate with additional questions.
  • Actions can be programmed to be optional or required.
  • each pathway 1000 has a Notes filed 1202 where a user can freelance notes and see previous notes.
  • each pathway 1000 has a "Summary” 1302 where a user can view a summary of the pathway. The summary is preferably dynamically built when the user selects questions and actions and documents standardized text notes.
  • each pathway 1000 has a "triggered rules" 1402 section where a user can view the rules that triggered the pathway.
  • each pathway 1000 has a "close pathway” 1502 section. A user can select a "closing action” and the "close” button will become enabled as long as all required documentation is completed in the pathway. A user can also reschedule the pathway with a new due date in the future.
  • data may be collected by a telephone system such as an interactive voice response (IVR) system.
  • IVR interactive voice response
  • An IVR system allows patients to call into a system using their telephone without any additional equipment.
  • the IVR system prompts the patient with questions and allows the patient to respond with a voice response and/or a touch-tone keypad response.
  • the responses may be made available to clinicians and/or administrators immediately during the call or after the patient's telephone call has ended.
  • the IVR system may be designed to call patients at predetermined times. Thus, the IVR system may perform regular check-ups on patients and/or check-in on patients who have not called in for a certain period of time.
  • An IVR system provides administrators with information useful to the diagnosis of or care of patients in an efficient manner. For example, administrators may obtain more frequent knowledge of a patient's health status than otherwise possible with patient visits to an administrator's office. The additional data may be analyzed to detect trends or trigger pathways as described above with reference to FIGURE 6. Additionally, the IVR system may prevent unnecessary hospitalizations or emergency room visits by providing the patient with immediate information or instructions for their care. When the patient is prescribed a care plan involving routing check-ins or care tasks, the IVR system may proactively call the patient and encourage adherence to the care plan. The care plan may be part of a chronic disease management protocol.
  • an IVR system may provide access to previously collected data, diagnostic information, and/or behavioral suggestions for patients communicating with the IVR system. For example, a patient may be able to ask "what-if ' questions to the IVR system and the IVR system may respond with answers to educate the patient. Additionally, the IVR system may provide automatic feedback to a patient based on their response to prompts from the IVR system. For example, the IVR system may provide guidance regarding a patient's weight based on their responses.
  • a patient may be set up according to the flow chart of FIGURE 17.
  • a patient is added to an electronic healthcare system.
  • An administrator may add a patient to the electronic healthcare system through a web-based form.
  • an IVR device type is added to the patient record.
  • the IVR device type indicates to the electronic health care system that the patient will have access to the IVR system.
  • a patient pass code is automatically assigned to the patient.
  • the patient pass code is assigned as the last four digits of the patient's social security number (SSN).
  • the patient pass code is automatically generated to be a unique code based on the patient's phone number.
  • a health check type is chosen.
  • An administrator may assign a health check type to the patient to indicate to the electronic health care system a default question or set of questions to ask the patient when a call is initiated through the IVR system.
  • the health check type may be a Chronic Kidney Disease (CKD) check to ask the patient questions about symptoms related to CKD.
  • the patient is activated in the IVR system.
  • an administrator selects an "Assign Device" button at the end of a web form the IVR device type is immediately processed and added to the patient's record in the electronic healthcare system.
  • the request to add the IVR device type to the patient's record may be saved and provided to a supervisor for reviewing the administrator's input.
  • the patient setup is complete.
  • a default pass code is provided when the IVR device type is added to a patient record, the patient or the administrator may modify the pass code. For example, after initiating a call to the IVR system the patient may change the pass code. In another example, if the patient forgets their pass code the administrator may enter the electronic health care system and recover or reset the patient's pass code.
  • FIGURE 18 is a flow chart illustrating authentication of a patient in an IVR system according to an example embodiment.
  • a call is initiated. The call may be initiated by either the IVR system or the patient.
  • a voice prompt is provided to the patient welcoming the patient to the IVR system. The prompt may serve as a friendly greeting and an assurance to the patient that the IVR system is authentic.
  • the voice prompt may included additional information such as a secret phrase that allows the user to be confident in the security or privacy of health information provided over the telephone system by the patient.
  • the IVR system retrieves phone number information of the initiated call from the Dialed Number Identification Service (DNIS) or other caller identification system. If the number is not available the flow continues to block 1818 to prompt the patient to enter their home phone number or another phone number registered with the IVR system. According to one embodiment, a patient may respond using the touch-tone keypad. According to another embodiment, the patient may speak the phone number. The IVR system may allow a patient to enter a home phone number, work phone number, or cellular phone number stored. After the patient enters their phone number the flow continues to block 1808. At block 1808 the IVR system checks the input phone number against the database. If the phone number is not found in the IVR system the flow returns to block 1818 to again prompt the patient to enter a phone number. After a phone number entered by the patient is accepted at block 1808 the flow continues to block 1810.
  • DNIS Dialed Number Identification Service
  • the IVR system checks the phone number against the database at block 1808. If the phone number is located in the database the flow continues to block 1810.
  • the blocks 1806 and 1808 may be skipped because the IVR system used a phone number from the database to initiate the call.
  • the IVR system After the phone number information is located in the database at block 1808, the IVR system prompts the patient to enter their pass code at block 1810. At block 1812 the IVR system checks the entered pass code against the database for the phone number of the patient. If the pass code does not match the pass code on record for the phone number an error prompt is read to the patient at block 1820 and flow continues to block 1810 to allow the patient to re-enter their pass code.
  • a health check may begin.
  • the IVR system may prompt the patient with a question or series of questions based on the default health check configured by an administrator in FIGURE 17.
  • the health check provided to the patient may include questions including yes/no questions, true/false questions, multiple choice questions, and/or numeric entry questions.
  • the health check may be customized by an administrator to include rotating messages, custom questions, and/or branching logic to identify areas of concern for the patient when positive symptoms are reported by the patient.
  • the branching logic questions may optimize interaction between the IVR system and patient to reduce the number of question prompts provided to the patient.
  • an administrator may enter a custom message for a particular patient after reviewing the patients responses to the IVR system.
  • the custom message may be entered as text to the IVR system by the administrator in a web-based form and provided to the patient through the IVR system with a text-to- speech translator.
  • FIGURE 19 is an example screen shot of message selection for an IVR system according to an example embodiment.
  • a screen shot 1900 may include an indication 1902 of previously configured message prompts for a patient.
  • the screens shot may also include additional messages 1904 that may be selected by an administrator for presentation to the patient. Messages selected from the available messages 1904 may be configured for presentation to the patient on certain days of the week between a start date and an end date.
  • FIGURE 20 is an example screen shot of custom message entry for an IVR system according to an example embodiment.
  • a screen shot 2000 includes entry lines for custom messages.
  • the custom message may include multiple sequential prompts entered as "Screen 1," “Screen 2,” and "Screen3.”
  • the IVR system may identify high risk patients through risk stratification. For example, patients who have entered outlying data and or who were non-responsive to certain questions may be flagged for an administrator's attention. At defined time periods or on a continuous basis, the IVR system may calculate numeric values for each health message in the IVR system. When the numeric values for a patient exceed a predetermined threshold the administrator may be notified to further evaluate the patient. Additionally, variance percentages may be configured to compare threshold values from one day to another day. Questions presented to a patient may be categorized as one of a standard question, an acute question, a compliance question, and/or a first response question. Categorization of questions may further increase efficiencies for an administrator managing patients and assist in identifying outlier patients.
  • FIGURE 21 is an example screen shot illustrating assignable numeric values to questions for risk stratification according to an example embodiment.
  • a screen shot 2100 includes a display 2102 of a health check in the IVR system.
  • the screen shot 2100 also includes a display 2104 of assignable risk parameters for the health check displayed in the display 2102.
  • Aft administrator may select from a number of categories of risk parameters including SP02, Peak Flow, Heart Rate, Reminders, Other, Device, Symptoms, Weight, Blood Pressure, and/or Glucose.
  • a risk parameter category the administrator may select parameters for configuring alerts. For example, when the "Weight" category is selected an administrator may set alerts to trigger at a specific weight, a maximum weight, a minimum weight, and/or a weight gain/loss over a specific period of time.
  • an administrator may set an alert to occur for a patient who gains or loses 3.0 pounds in one day or for a patient who gains or loses 5.0 pounds in seven days.
  • the health check of the display 2102 may be configured by an administrator through a health check template item editor. Through the editor an administrator may build custom logic for combinations of messages to present to a patient. Logic flow through the messages may be controlled by the value of numeric responses and stored patient setup variables.
  • FIGURE 22 is an example screen shot illustrating glucose alerts configurable for patients of the IVR system according to an example embodiment.
  • a screen shot 2200 includes configurable alerts for high and/or low glucose values for a patient.
  • the alerts may be configured for specific periods of time. For example, separate high glucose and/or low glucose levels may be configured for morning, midday, evening, night, and/or early AM.
  • FIGURE 23 is an example screen shot illustrating configuration of administrators according to an example embodiment. Administrators may be classified into several enterprise roles illustrated in a display 2302 of a screen shot 2300. For example, enterprise roles may include administrators, general users, health care providers, and/or power users. A display 2304 may present the privilege levels of one of the enterprise roles displayed in the display 2302. For example, privileges may include adding new records, viewing global follow ups, editing global follow ups, viewing global interventions, editing global interventions, viewing global labs, editing global labs, viewing global facilities, editing global facilities, and/or viewing global medications.
  • FIGURE 24 is an example screen shot illustrating a graphical view of patient health information according to an example embodiment.
  • FIGURE 25 is an example screen shot illustrating a tabular view of patient health information according to an example embodiment. Administrators may also view a dashboard summary of data stored in an electronic health system including number of patients enrolled with disease programs, number of patients enrolled for various device types, and number of patients enrolled for various peripherals.
  • FIGURE 26 is an example screen shot illustrating an administrator dashboard summary according to an example embodiment. Administrators may be alerted to patients having irregular measurements or responses in an alert display.
  • FIGURE 27 is an example screen shot illustrating biometric alerts according to an example embodiment. Alerts may be represented by a graphical icon and/or a score. The graphical icon may provide the administrator with information regarding the type of alert for a patient and the score may provide a relative importance for addressing the alert.
  • embodiments provide one or more advantages. For instance, embodiments can be used to remotely monitor patients who are under treatment for HF, Hypertension, Diabetes, COPD, ESRD, CKD, and other complex chronic conditions. In some scenarios, remote monitoring with exception-based response can provide a lower-cost solution than frequent monitoring performed directly by a T/US2012/038386
  • some embodiments provide a convenient and relatively inexpensive way to monitor a patient with any desired schedule. From the patient's perspective, use as directed of some embodiments may manage the patient's condition to minimize deterioration or hospitalization.
  • the weight measuring devices of the present invention can be used to monitor a patient that is known or suspected to have a disease or health-related condition known to be associated with weight change.
  • monitoring refers to methods by which a healthcare provider can estimate or determine whether or not a patient with a disease or health-related condition requires a change in therapy based on the measure of a particular parameter (such as weight or blood pressure of the patient).
  • assessing and “assessment” refer to methods by which a healthcare provider can monitor or determine the change in health status.
  • the healthcare provider often makes a health status assessment on the basis of one or more vital sign or symptom status questions that is indicative of the change in the patient's condition.
  • a “disease” or “health-related condition” can be any pathological condition of a body part, an organ, or a system resulting from any cause, such as infection, genetic defect, and/or environmental stress.
  • the cause may or may not be known.
  • the weight change may be a change that is associated with volume overload or volume depletion.
  • Volume overload refers to expansion of the extracellular volume.
  • diseases and conditions associated with volume overload include renal failure, heart failure, cirrhosis of the liver, nephrotic syndrome, preeclampsia, and pregnancy.
  • diseases and conditions associated with volume depletion include inadequate fluid intake, hemodialysis, peritoneal dialysis, diarrhea, acute renal failure, diabetes, diuretic therapy, adrenal disorders, and acute gastroenteritis.
  • Kidney disease refers to an acute or chronic injury to at least one kidney of a subject, and in particular renal tubular cell injury. Kidney injury can be confirmed by any of a number of measurable criteria known in the art, including but not limited to measurement of the level of microalbuminuria and glomerular filtration rate (GFR).
  • GFR glomerular filtration rate
  • the kidney disease may be CKD.
  • ESRD almost always follows CKD. A person with CKD may have gradual worsening of kidney function for 10 - 20 years or more before progressing to ESRD.
  • Non-limiting examples of causes of ESRD include chronic infection, chronic inflammation, glomerulonephritides, vascular disease, interstitial nephritis, a drug, a toxin, trauma, a renal stone, long standing hypertension, diabetes (diabetic nephropathy), heart failure, nephropathy from sickle cell anemia and other blood dyscrasias, nephropathy related to hepatitis, HIV, cystic kidney disease, congenital malformation, obstruction, malignancy, lupus nephritis, membranous glomerulonephritis, membranoproliferative glomerulonephritis, focal glomerular sclerosis, minimal change disease, cryoglobulinemia, Anti-Neutrophil Cytoplasmic Antibody (ANCA)-positive vasculitis, ANCA-negative vasculitis, amyloidosis, multiple myeloma, light chain deposition disease, complications of kidney transplant,
  • ESRD patients may require renal replacement therapy (e.g., hemodialysis, peritoneal dialysis, or kidney transplantation), drug therapy, modification of fluid intake, and/or modification of diet.
  • renal replacement therapy e.g., hemodialysis, peritoneal dialysis, or kidney transplantation
  • drug therapy e.g., drug therapy, modification of fluid intake, and/or modification of diet.
  • the patient with ESRD may be afflicted with or was previously afflicted with a disease other than kidney disease.
  • the other disease can be a disease linked to or predisposing one to kidney disease.
  • the subject is a diabetic subject, as diabetes can be a risk factor for developing kidney disease.
  • the subject is a diabetic subject suffering from, or at risk of suffering from, diabetic nephropathy.
  • weight refers to the measured heaviness of a patient to be monitored. Unless otherwise specified herein, weight can be measured using any method or device known to a patient, a healthcare provider, or to those of ordinary skill in the field of the invention. Weight can be determined and monitored by the healthcare provider at any frequency as determined by the patient's healthcare provider, taking into account the patient's disease and individual health status. For example, patient's weight can be measured once a day, twice a day, once every two days, once every three days, once a week, twice a week, once every two weeks, once every three weeks, or once a month using the devices and methods set forth herein.
  • weight parameter refers to a specific value of a particular parameter that is determined or ascertained by a healthcare provider. In particular embodiments it is dependent upon the clinical course and/or characteristics of the particular patient that is to be monitored.
  • weight parameters include dry weight (as discussed above), weight of the patient immediately after a previous session of dialysis, weight of the patient immediately prior to a previous session of dialysis, weight of the patient within 1 -2 weeks prior to or after a previous session of dialysis, weight of the patient within 2-3 weeks prior to or after a previous session of dialysis, or median weight of the patient between a first dialysis session and a subsequent dialysis session.
  • a weight parameter may also be a median or mean weight of a subject of similar height from the same or a similar population of subjects.
  • Some embodiments of the present invention include comparing the weight of a subject to a first weight parameter and a second weight parameter.
  • the first weight parameter is distinct from the second weight parameter.
  • generating information relevant to a patient's disease or health-related condition involves converting the weight of the patient to a Body Mass Index (BMI).
  • BMI is calculated from the weight and height of the patient.
  • the BMI of the patient may then be compared to at least one of the first and second parameters.
  • the healthcare provider will understand that associating a change in weight of a patient relative to one or more weight parameters may signal that a subject is more likely to suffer from an adverse event and that a particular instruction to the patient is warranted.
  • the change in weight of the patient relative to a weight parameter that may warrant a change in therapy or patient instructions may vary and largely depends on the decision of the healthcare provider and individual characteristics of the patient.
  • multiple determination of patient weight can be made, and a temporal change in the weight relative to one or more weight parameters can be used to monitor the progression of disease and/or efficacy of appropriate therapies directed against the disease. For example, one might expect to see a decrease or an increase in weight over time during the course of effective therapy.
  • the presently disclosed subject matter provides in some embodiments a method for determining treatment efficacy and/or progression of ESRD in a subject.

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Biomedical Technology (AREA)
  • Public Health (AREA)
  • Primary Health Care (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • General Business, Economics & Management (AREA)
  • Business, Economics & Management (AREA)
  • Pathology (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Measuring And Recording Apparatus For Diagnosis (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

Selon l'invention, un logiciel, ou un assistant d'établissement de protocoles, peut être utilisé pour faciliter l'examen ou les recommandations de traitement d'un patient surveillé à distance et peut être exécuté en arrière-plan. L'assistant d'établissement de protocoles, qui inspecte des données à la recherche d'informations clés et établit des protocoles, constitue un système automatisé qui standardise l'examen, le traitement, la gestion et l'évaluation de patients sous surveillance. Les protocoles établis permettent à un utilisateur, une infirmière ou un soignant de suivre des instructions précises et d'évaluer l'état d'un patient. Le logiciel d'établissement de protocoles permet de limiter les erreurs humaines associées à l'évaluation et d'obtenir une gestion plus rentable pour de grandes populations de patients, ce qui constitue un avantage par rapport à l'art antérieur. La collecte de données pour le logiciel peut être réalisée par un système de réponse vocale interactive (IVR). Le patient peut appeler le système IVR, ou le système IVR peut être configuré pour joindre le patient à des heures prédéfinies.
EP12724263.4A 2011-05-20 2012-05-17 Systèmes, procédés et produits programmes informatiques pour la surveillance d'un patient Withdrawn EP2710504A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13/112,276 US20120041775A1 (en) 2010-08-11 2011-05-20 Systems, methods, and computer program products for patient monitoring
US201261620371P 2012-04-04 2012-04-04
PCT/US2012/038386 WO2012162094A2 (fr) 2011-05-20 2012-05-17 Systèmes, procédés et produits programmes informatiques pour la surveillance d'un patient

Publications (1)

Publication Number Publication Date
EP2710504A2 true EP2710504A2 (fr) 2014-03-26

Family

ID=46177556

Family Applications (1)

Application Number Title Priority Date Filing Date
EP12724263.4A Withdrawn EP2710504A2 (fr) 2011-05-20 2012-05-17 Systèmes, procédés et produits programmes informatiques pour la surveillance d'un patient

Country Status (3)

Country Link
EP (1) EP2710504A2 (fr)
CA (1) CA2836467A1 (fr)
WO (1) WO2012162094A2 (fr)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1237774C (zh) * 1997-11-12 2006-01-18 I-弗琉公司 用于监控病人的方法和装置
US6290646B1 (en) 1999-04-16 2001-09-18 Cardiocom Apparatus and method for monitoring and communicating wellness parameters of ambulatory patients
US7577475B2 (en) 1999-04-16 2009-08-18 Cardiocom System, method, and apparatus for combining information from an implanted device with information from a patient monitoring apparatus
US20070106127A1 (en) * 2005-10-11 2007-05-10 Alman Brian M Automated patient monitoring and counseling system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2012162094A2 *

Also Published As

Publication number Publication date
WO2012162094A2 (fr) 2012-11-29
CA2836467A1 (fr) 2012-11-29
WO2012162094A3 (fr) 2013-09-19

Similar Documents

Publication Publication Date Title
US20120041775A1 (en) Systems, methods, and computer program products for patient monitoring
US20120041771A1 (en) Systems, methods, and computer program products for patient monitoring
US20200152038A1 (en) Alert management utilizing mobile devices
US11596305B2 (en) Computer-assisted patient navigation and information systems and methods
US10720238B2 (en) Providing an interactive emergency department dashboard display
US8766789B2 (en) First emergency response device
RU2629797C2 (ru) Способ визуализации информации указателя индекса гемодинамической нестабильности
US10354051B2 (en) Computer assisted patient navigation and information systems and methods
CN108140175B (zh) 劳务管理系统、劳务管理方法、以及劳务管理程序
US20170124279A1 (en) Adaptive Complimentary Self-Assessment And Automated Health Scoring For Improved Patient Care
US20170032093A1 (en) Closed loop alert management
US20130151274A1 (en) Method and apparatus for enhancing home healthcare
US20230386669A1 (en) System, apparatus, method, and graphical user interface for screening
US20180225419A9 (en) Remote Patient Monitoring System
WO2018106481A1 (fr) Procédés, systèmes implémentés par ordinateur et supports informatiques pour diagnostiquer un état de santé
US20200202996A1 (en) Patient-centered mobile communication system and method
CN114121266A (zh) 一种智能化的辅助诊断方法和系统
WO2012162094A2 (fr) Systèmes, procédés et produits programmes informatiques pour la surveillance d'un patient
AU2012259105A1 (en) Systems, methods, and computer program products for patient monitoring
US11238978B2 (en) Information processing method, information processing apparatus and non-transitory computer-readable recording medium storing information processing program
US11328827B2 (en) Intelligent touch care corresponding to a clinician documented change in condition or order
US11398313B2 (en) Intelligent touch care corresponding to a patient reporting a change in condition
US11862303B1 (en) Collection of digital health hubs with artificial intelligence
Zimlichman 15 Using patient-reported outcomes to drive patient-centered care
US20240013915A1 (en) Systems and methods for generating models for determining blood glucose levels using voice

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20131129

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20151201