This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
> TITB-00090-2009.R1
TITB-00090-2009.R1 < medication treatment management is presented, along with the proposed system architecture. Particular emphasis is given on the description of information and communication flows taking place between and inside the subsystems located at the patient and clinical sites, as well as on the information structures defined, towards an interoperable and extensible design. In the Results section, a specific application scenario concerning hypertension management is described, aiming to illustrate the functionality of the system, while our prototype implementation details are also presented. Finally, remarks and open issues concerning the proposed approach, as well as future work directions, are discussed. II. METHODS
2
Assessed by
Goal Achievements
Require
Medication Treatment
May cause
Actions
Require
Adverse Drug Events
Detected by
Detected by
Measurements Measured by
Can be measured by
Sensor Measurements
Patient Reports Can be measured by
Patient Measurements
Fig. 1. Conceptual framework of medication treatment management.
A. Functional Framework for Medication Treatment Management In the proposed framework, the functionality is physically distributed as it is partially performed in the clinic, in the patient monitoring hub, that is typically called as a Mobile Base Unit (MBU), and the sensors. Processing takes place in all parts following a multi-step configuration in which the physician formulates the rules for medication treatment to be implemented by the BAN, while the MBU coordinates the sensor network and notifies the medical personnel with respect to the monitoring outcome. The design decision of employing more data processing capabilities in the patient site [14], rather than employing a back-end infrastructure located at the clinical site, was mainly determined by three factors: a) technological advances in mobile devices hardware and software (processing power, network capabilities, sophisticated operating systems, multi-threading applications, etc.) allow mobile nodes to take over a part of the processing burden typically assigned to central servers; thus, there is no reason for the MBU to communicate with the clinical site constantly, as such an approach has proven to be extremely energy demanding [15], b) intermittent or high latency network connection for the MBU could cause a thin client architecture to be problematic, and c) the home care unit should run independently in case of communication problems with the back-end infrastructure. The overall idea is summarized below. During a patient visit, a physician decides on a new medication prescription. Once defined, information related to the prescription is automatically structured in an appropriate form and transmitted to the MBU, initiating a new monitoring and treatment plan. Information includes necessary drug and prescription details, e.g., drug name, regimen, etc., treatment goals in terms of monitored signs and symptoms, important ADEs that may occur, and ADE detection patterns. This information is processed by the MBU, in order to instantiate the required procedures that implement the medication management functionality on the patient site. Dosage plan information is used to automatically generate reminders for the patient, towards improving patient medication adherence. Medication treatment goals are compared against actual signs and symptoms evolution, using rules defined in the monitoring scheme, and the monitoring outcome is provided to the
medical personnel via periodic reports. Similarly, the list of possible ADEs that are monitored is used for reporting such events immediately or periodically, depending on the ADE severity. The detection of such ADEs as well as the actions when these are detected, are also part of the monitoring plan transferred to the MBU from the clinical site. The conceptual framework of the monitoring scheme for medication treatment management is depicted in Fig. 1. Specifically, medication treatment is characterized by the treatment goals and potential ADEs. The former are assessed via vital sign measurements, while the latter require measurements (performed automatically by sensors or by patients themselves) and/or patient reported symptoms. Specifically, each ADE is linked to a series of measurements, i.e., vital sign measurements or patient-targeted questions, which is periodically recorded and evaluated via rule conditions with a predefined frequency, in the regular monitoring mode. When conditions for an ADE are met, this leads to an action, which can be a direct alert, an entry in the periodic report for the medical personnel, or an adaptation of the monitoring scheme (mode), that is meant to provide more insights in the detection of ADEs. This new mode might include an increased frequency of the recording and evaluation of the measurements, or even additional measurements. Upon defined conditions, the monitoring scheme can be toggled again to the regular mode. It has to be noted that the number of monitoring modes along with the conditions and actions assigned to each measurement can be further extended, if needed. This approach allows for dynamic management of the personalized medication treatment. B. Architecture The major principles in the design of the proposed system architecture are interoperability and extensibility. Thus, particular emphasis was given on data representation, communication aspects among system components, and scalability issues. Figure 2 depicts the overall architecture of the proposed framework, which comprises of two subsystems, one residing at the clinical site, and the other at the patient site. The Medical Center incorporates the necessary infrastructure (i.e., Application Server, Web Services Engine, etc.) for the
Copyright (c) 2009 IEEE. Personal use is permitted. For any other purposes, Permission must be obtained from the IEEE by emailing
[email protected]. Authorized licensed use limited to: Univ Politecnica de Madrid. Downloaded on January 26, 2010 at 07:48 from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
> TITB-00090-2009.R1
TITB-00090-2009.R1
TITB-00090-2009.R1 < monitoring procedure by the physician upon a new medication treatment plan. The back-end system is able to retrieve the BAN description and provide all the necessary information to a GUI handler module, which determines the appropriate items for display in the GUI, together with sets of accepted values (e.g., the specification of a time frame), so as to reassure the appropriate configuration of medical rules by the physicians. At the clinical site, the dynamically constructed GUI is used to setup the medication monitoring procedure, according to the BAN description and the available information on the drug to be prescribed. Based on a predefined monitoring template for the selected drug that can be adjusted by the physician and the home monitoring environment, the medication monitoring procedure is configured and sent back to the MBU in form of an XML document that follows the formatting instructions of the schema depicted in Fig. 4. This schema contains two core structural elements describing the prescribed drug (DRUG element) and the rules defining the occurrence of ADEs (ADVERSE element) and the designated actions. Specifically, the building blocks of the drug-related information are: a) the prescription start and end dates (PRESCRIPTION_START, PRESCRIPTION_END) along with the suggested regimen (DOSAGE, TIME, FREQUENCY elements), and b) the definition of the medication goals (GOAL tag), i.e., the rules defining the target values of predefined vitals signs (VARIABLE element) in a specific timeframe (TIMEFRAME tag). The elements describing ADEs are classified into different modes (MODE element), depending on the monitoring rules defined by the physician. Each mode contains the rules (multiple RULE elements) applied on specific measurements (MEASUREMENT element) that correspond to either vital signs or symptoms implying the presence of an ADE. For each rule, the corresponding ACTION elements are defined, i.e., logging into the report system, alerting to the Medical Center, and/or changing the monitoring ADE mode. The rules are applied regularly (FREQUENCY subelement of RULE), as defined by questions posed to the patients, or predefined sensor measurements (CONDITION element), taking into account the options offered by the BAN. In the same rationale, appropriate XML documents based on HL7 CDA (Clinical Document Architecture) [18] are used to structure the reports provided to the medical personnel, as a result of the monitoring outcome, containing information such as the medication identification number, the timestamp of the recorded event, the conditions met that fired the action(s), etc. III. RESULTS A. Application Scenario Aiming to illustrate the functionality of the proposed system, an application scenario related to hypertension management is presented in the following, since monitoring Blood Pressure (BP) plays a significant role in assessing the response to hypertensive drug treatment outside the medical environment [19]. During a visit in a hypertension outpatient clinic, the physician decides to prescribe a medication, e.g., amlodipine
5
(a)
(b) Fig. 5. Sample screen captures of the professional interface illustrating: (a) the monitoring patterns setup, and (b) a weekly report according to the monitoring patterns defined (goals and ADEs).
(a calcium channel blocker), to a newly-diagnosed patient. After ensuring that the patient has no contra-indications regarding the medication according to his/her medical profile, the physician specifies the suitable frequency and dosage (e.g., 5 mg every morning) and informs the patient about the possible ADEs and the therapeutic goal. In a next step, the physician selects the measurements and symptoms that need to be recorded for the medication treatment monitoring. For this purpose, the Medical Center contacts the MBU to retrieve information regarding the biomedical parameters that can be monitored, which is in turn presented to the physician via a dynamically constructed Web interface (Fig. 5(a)). In the same
Copyright (c) 2009 IEEE. Personal use is permitted. For any other purposes, Permission must be obtained from the IEEE by emailing
[email protected]. Authorized licensed use limited to: Univ Politecnica de Madrid. Downloaded on January 26, 2010 at 07:48 from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
> TITB-00090-2009.R1 < time, the Medical Center queries the Drug Database and suggests a number of ADE-related patient symptoms to be monitored by the relevant predefined monitoring procedure template for the specific drug and sensor setup, which can be adapted per case. For example, if a desirable symptom is not included in the list, in order to assess it, the physician may directly type a question that will be addressed to the patient. In this case, BP monitoring is used to monitor the medication response to antihypertensive treatment. Thus, the physician describes the therapeutic goal for the patient (Systolic BP
