PDF
ePub
Citation
Print
I. Introduction
Diabetes mellitus is a chronic disease that requires continuous effort by patients to learn about medical treatments and self-care, to prevent acute complications, and to reduce the risks of long-term complications [1]. According to data from Statistics Korea, diabetes mellitus ranked 5th among causes of death [2], and with consideration that more than 30% of patients with diabetes die of cardiovascular diseases (ranked 2nd and 3rd for the causes of death) [3], diabetes mellitus accounts for a huge portion of the causes of death. Moreover, the prevalence of diabetes mellitus is gradually increasing, and it is reported that the prevalence in adults at 30 years of age and older in 2011 was 12.4% [4]. With consideration of the higher prevalence in patients in their 30s and 40s, who are the key members of the Korean economy, compared to the United States [5], diabetes mellitus should be considered as a disease that requires state intervention rather than a personal problem. Once diabetes mellitus occurs, the disease is able be controlled to some degree, but it is generally an incurable disease, and the most important goals in controlling diabetes mellitus are the normalization of patients' blood glucoses, improvement of symptoms, and providing the possibility of normal and enjoyable life for patients [6]. In particular, as it was reported that the maintenance of normal blood glucose level of diabetic patients is able to prevent the complications of diabetes or delay the progression of complications [7], the importance of blood glucose self-monitoring is increasing.
Patients can control their disease in daily life by understanding changes in their own blood glucose level through the self-monitoring of blood glucose. Maintaining a blood glucose self-monitoring record helps an attending physician to plan a treatment schedule, and it provides the motive for necessity of self-management through diet, exercise, and insulin administration [8]. Also, regardless of having insulin treatment, it was reported that a patient who monitors his or her own blood glucose level has lower HbA1c compared to a patient who does not monitor [9], and domestic and overseas diabetes associations recommend patients to monitor their own blood glucose levels [1,10]. However, blood glucose self-monitoring is typically performed by recording measured values in a notebook or checking values automatically saved in a glucometer. The hassle of keeping written records and the difficulty of observing changes in blood glucose levels interrupt the self-monitoring of blood glucose levels by diabetic patients. Besides, approximately 1 billion USD was spent on the treatment of diabetes mellitus in Korea in 2012 [11]. The United States spends approximately 245 billion USD annually on the diagnosis of diabetes mellitus, and it is estimated that 1/3 of the total adult population of the United States will be diabetic patients in 2050 [12]. Therefore, the whole world is supporting a mobile health platform at the state level to reduce the social and economical effect of diabetes mellitus.
Mobile health is an unrestricted exchange of medical services between patients and doctors through cell phones, tablet PCs, etc. anywhere and at anytime. This means that there is a ubiquitous computing environment that systemically links with personal health devices or an Electronic Medical Record system [13]. The appearance of mobile health caused the quantified self trend which quantitatively manages all health information generated in daily life by using smart devices and applications used by medical consumers, and it is shifting the paradigm of medical service from hospitalcentered treatment to consumer-centered prevention [14]. Accordingly, a number of applications have been released for the self-monitoring of blood glucose, and the existing intervening factors are being supplemented. However, there is still the inconvenience of having to keep written records and the problem of interoperability with other personal health devices and medical information systems. For this reason, international organizations for standardization, such as the IEEE 11073 Personal Health Device Working Group (PHD WG) and Health Level Seven (HL7), developed ISO/IEEE 11073 and the Continuity of Care Document (CCD) standards to ensure interoperability between personal health devices and medical information systems.
As international standards for health information exchange are developed, a number of studies have been conducted in Korea to develop the ubiquitous computing environment that links with personal health devices to which various international standards are applied [15,16,17,18,19]. However, previous domestic studies [17,19] mostly conducted simulations at laboratories to develop several modules to confirm interoperability with personal health devices excluding glucometers or to verify the applications developed. Also, several commercialized applications [20,21] do not support the transfer of stored blood glucose levels, or they do not provide the conversion of personal health records. However, to reduce medical costs and support better treatment, personal health records that include blood glucose levels should be generated in the form of a standard information model that can share information between medical institutions. It is necessary to develop an application linked with a glucometer as well as to perform an evaluation of the usefulness and intention of usage of the developed application by users and healthcare professionals through clinical trials to support effective blood glucose self-monitoring by patients with diabetes.
The objective of this research was to develop and evaluate a cell phone application based on the international standard for blood glucose self-monitoring by patients with diabetes. The developed application communicates with a glucometer with the standard protocol implemented through ISO/IEEE 11073 and Bluetooth Health Device Profile (HDP), and blood glucose levels saved in the database are converted into a CCD document and transmitted to the web server through Hyper Text Transfer Protocol (HTTP). This study was approved to evaluate the usefulness and intention regarding a blood glucose management system for 87 users and five healthcare professionals by the Institutional Review Board at Kyungpook National University Hospital.
II. Methods
1. System Summary
A blood glucose self-monitoring system was designed so that a diabetic patient would be able to control his or her own blood glucose by using a glucometer and a cell phone (Figure 1). The system consists of an application that saves, displays, and transmits a blood glucose level measured by a glucometer, and a web server, which processes the transmitted blood glucose level. The blood glucose self-monitoring system comprises five domains, depending on the role of each component. Each component in a domain is composed of an independent module, and it is designed to provide a specific function for a diabetic patient through interconnection between modules. The roles and components of the domains are summarized as follows.
1) Storage domain
The application uses the SQLite Database of Android to save user information, receivers information, and blood glucose levels. The saved blood glucose levels are displayed as a list or a chart, or they are used to compose a CCD document with user information from the CCD Composer.
The receivers' information provides IP and port information to transmit the composed CCD document from the HTTP Client to the web server. The web server uses the MySQL Server to save the CCD document transmitted from multiple applications. The transmitted CCD document is objectified through the CCD Parser and saved in a database.
2) Boundary domain
SQLite Database Connectivity (SDBC) was developed to allow the components of the application to use the information saved in the SQLite Database. SDBC provides a method for the composure and deletion of a database and a table and provides access to information by using SQLiteDatabase, SQLiteOpenHelper, SQLiteQuery, SQLiteQueryBuilder, and SQLiteStatement class. Also, the CCD Composer and HTTP Client are developed to compose the CCD document and link with the web server. Because the web server was developed with the Java Server Page (JSP), it is connected to the MySQL Server by Java Database Connectivity (JDBC). Data Access Object (DAO) with a query to search, add, and change information was developed for the web server and the components of the application to use information smoothly regardless of the type of database.
3) PHD boundary domain
The application was developed with the IEEE 11073 Manager and Bluetooth HDP Connector to control the status of communication and connection with a glucometer. The IEEE 11073 Manager is a component that implements an optimized exchange protocol and device specializations from an ISO/IEEE 11073 protocol stack, and the data communication with a glucometer linked through the Bluetooth HDP Connector is processed with the Medical Device Encoding Rule (MDER).
4) Application domain
The application provides the functions necessary for continuous blood glucose self-monitoring as a component type of modular unit. All of the components are connected to each other, and they provide functions such as linking with a glucometer, displaying blood glucose levels, managing, composing and transmitting CCD documents, etc. Also, an adapter supports the smooth exchange of information between the components and the SQLite Database by processing a table record as an object through the Data Transfer Object (DTO).
5) User interface domain
The application required an effective interface design because it was intended to be operated on cell phones, which have smaller screens than regular desktop PCs. Therefore, a userfriendly interface was designed through minimization of screen rotation, layout setting, widget arrangement, and intuitive pictures and icons.
2. Glucose Meter Processing Module Based on ISO/IEEE 11073
ISO/IEEE 11073 defines a standard protocol to exchange health information between an agent and a manager. An agent can communicate with a manager through logical point-to-point connection, and a manger can communicate with multiple agents concurrently through separated point-to-point connection [22,23].
This research developed the IEEE 11073 Manager which implemented the ISO/IEEE 11073 protocol stack for standardized communication with a glucometer. It also developed the Bluetooth HDP Connector by using BluetoothHealth, BluetoothHealthCallback, BluetoothHealthCallback and BluetoothAppConfiguration classes which are provided by the Android 4.0 operating system. The ISO/IEEE protocol stack is implemented as a communication protocol, device specializations, and optimized exchange protocol.
Communication protocols can be used Bluetooth HDP, USB, and Zigbee. In this study Bluetooth HDP was used. Bluetooth HDP can communicate with any personal health device that implements ISO/IEEE 11073 because it is possible to use device specializations based on the optimized exchange protocol. In particular, because Android offers a package to support the Bluetooth HDP from 4.0 Ice Cream Sandwich, it can easily implement Bluetooth HDP in the cell phone environment.
The optimized exchange protocol consists of a Domain Information Model (DIM), Service Model (SM), and Communication Model (CM) that can support a variety of agents. The DIM is a set of classes that defined the attribute, method, event, and service to express the agent by object unit, and it is consisted of Numeric, Enumeration, Real-time sample array, PM-store, and Scanner child class around the Medical Device System (MDS) top-level class. Each device specialization of the glucometer was implemented by using these classes. SM is defined as a data communication method between an agent and a manager, and it consists of GET, SET, ACTION, and Event Report command. CM consists of eight state machines (Disconnected, Connected, Disassociating, Unassociated, Associating, Associated, Configuring, Operating). Multiple agents are connected to a manager through point-to-point connection. The communication process between the application and a glucometer is divided into Bluetooth HDP communication (communication protocol) and ISO/IEEE 11073 communication (optimized exchange protocol) (Figure 2).
Bluetooth HDP communication is composed of five stages of Method Invocation Processes. 1) An object is composed by calling the BluetoothHealthCallback() constructor. 2) An application configuration is registered by transmitting the type of personal health device and BluetoothHealthCallback object as parameters of the registerSinkAppConfiguration() method. 3) The paired glucometer object and BluetoothHealthAppConfiguration object are linked to the glucometer by transmission as parameters of connectChannelToSource() method. 4) onHealthChannelStateChange() method is called depending on the change in status of the health channel, and a stream with the glucometer is composed through the ParcelFileDescriptor parameter. From this moment, the ISO/IEEE 11073 communication process starts. 5) After the ISO/IEEE 11073 communication is over, the health channel is closed by calling the disconnectChannel() method, and the application configuration is disconnected by calling the unregisterAppConfiguration() method.
ISO/IEEE 11073 communication is composed of four stages of message exchange processes. 1) After the health channel is composed, an agent transmits an Association Request message to connect with a manager. The manager reviews it, and transmits an Association Response message. 2) The agent transmits a Configuration message to inform his/her configuration to the manager, and the manager transmits a GET message to obtain information on the MDS object of the agent. 3) The agent transmits an Event Report message to transmit measured bio-signals to the manager. 4) The agent transmits an Association Release Request message to disconnect the connection with the manager, and the manager prepares health channel disconnection by transmitting a Response message.
ISO/IEEE 11073 describes the type of transmitting information by using Abstract Syntax Notation One (ASN.1), and it encodes and decodes by using a binary code through MDER with constraints added to the Basic Encoding Rule (BER). For example, an Event Report message transmitted by an agent describes bio-signals through the three types of the data formats of ASN.1 (Figure 3).
ScanReportInfoFixed is a data format which describes fixed-type event information, Basic_Nu_Observed-Value is a data format describing the measured bio-signal values, and Absolute-Time-Stamp is a data format which describes the time of measurement. Different data formats can be used for ScanReportInfoFixed depending on the event type (fixed type, variable type, group type). The ASN.1 data format class was designed to process these binary codes through MDER.
3. CCD Module for Blood Glucose Representation
CCD is an XML-based clinical document which combines the Clinical Document Architecture (CDA) of HL7 and the CCR of ASTM [24], and it is an Electronic Data Interchange standard to share summarized patient information between healthcare providers and personal health records [25,26]. CCD is compatible with other standards, such as the new version of HL7 or Integrating the Healthcare Enterprise (IHD), the Healthcare Information Technology Standards Panel (HITSP) and the Clinical Data Interchange Standards Consortium (CDISC) because it uses the data type and terms used in the HL7 because it is derived from the CDA of the HL7 Reference Information Model (RIM) [25]. CCD consists of a header and a body. The header is composed of patient name, gender, purpose of document composure, time, version, etc., and the body is composed of 17 sections and 38 templates, including family history, sociability, vital signs, results, etc. HL7 provides a schema to verify whether the CCD document complies with XML specification and the document is valid. The CCD Library developed in previous research [27] by this research team provides functions to compose and parse CCD documents by using the Java Document Object Model (DOM) based on the CCD schema.
The CCD Library defines element, simple and complex data format, and attribute as parent classes, and the component of the CCD schema as a child class (Figure 4). CCD Component defines decode() method, which parses the CCD document entered with a string as a parent class that all XML components are inherited, and encode() method, which converts a CCD object into a string. CCDType is a parent class of the CCD data format, and it is composed of CCDSimpleType, which indicates a simple data format, and CCDComplexType, which indicates a complex data format. CCDElement is a parent class that all CCD elements are inherited, and it refers to a specific data format class and attributes class internally.
CCD Composer and CCD Parser were developed by using the CCD Library to compose and parse a CCD document within the blood glucose self-monitoring system. However, the schema of CCD Composer and CCD Parser was designed by using only id, languageCode, templateId, effective Time, recordTarget, author, and Vital Signs elements because the role of the CCD document in this research is a simple transmission of blood glucose levels.
CCD Composer composes the DOM tree composed of document and element components by using user information, receiver information, elements relevant to blood glucose levels, and data format class saved in the application, and converts it into a string (Figure 5A). The CCD object composes the document object and DOM tree in the object. The composed document object is transmitted as a parameter of encode() method, and the ClinicalDocument root node is composed at this moment. The composed root node is transmitted along with the document object as a parameter of encode() method of the data format class. The data format class composes the DOM tree through a composure of node and a repeated calling of encode() method for all elements and attribute object defined, and transmits it to the web server by converting it to a string.
The CCD Parser composes the DOM tree by parsing the transmitted CCD document string with Java DOM and parses it by using a node object (Figure 5B). The parsing process of the CCD document is opposite to the composing process, but the processes are similar. First, the CCD object extracts the ClinicalDocument root node from a string received, and calls decode() method from the ClinicalDocument element class as a parameter. For this step, a ClinicalDocument object is composed, and an object of data format class is also composed during this process. decode() method called from ClinicalDocument class calls decode() method from the data format class by using the transmitted node object. The data format class parses the CCD document through repeated calling of decode() method for all elements and attribute object defined in the same manner as in the previously described process.
4. Sampling and Data Collection
For the evaluation of the developed application, a survey was performed from September 12, 2014 to November 22, 2014 with the participation of healthcare professionals and users after approval was obtained from Institutional Review Board at Kyungpook National University Hospital (IRB No. 2014-07-043-001). A total of 92 questionnaires were collected, and the demographic characteristics of the respondents are summarized follows (Table 1).
5. Survey Instrument and Analysis Method
For the verification of accuracy of the application developed, five healthcare professionals (two doctors and three nurses) verified the functions of the application, and the opinions of the professionals on the application's usefulness after trying it was investigated and analyzed with a subject called "health management and patient safety improvement." Also, the intention of usage was evaluated for the five healthcare professionals and 87 users through a survey on mobile health application usage intention using a 5-point Likert scale [28]. Reliability and validity tests were performed for the used survey instrument. The reliability of the instrument was verified using Cronbach's alpha, and it was validated through factor analysis. The collected questionnaires were analyzed using SPSS ver. 19.0 (IBM SPSS Inc., Armonk, NY, USA).
III. Results
1. Development of Application
The application and the web server were developed to implement the blood glucose self-monitoring system designed during this research, and a glucometer with the standard protocol implemented (Fora D40d) [29], which is currently on the market, was used. The application was based on the Android 4.0.3 Ice Cream Sandwich operating system, and IEEE 11073-20601, 10417 and Bluetooth HDP were implemented for the communication with the glucometer, while CCD was implemented for the transmission of blood glucose levels. The web server was based on Apache Tomcat 7 and MySQL Server 5.6, and it saves the blood glucose levels of an application user.
The developed application provides various functions needed for blood glucose self-monitoring by patients with diabetes. The representative functions are link with a glucometer, measurement, blood glucose level display, blood glucose level management, patient information management, receiver information management, and blood glucose level transmission. A description of each function and the screen layout is summarized as follows.
1) Login and main
The login screen consists of a join button, which is used to create a user account; a find ID and password button, which searches for account information; and a login button, which redirects to the main screen (Figure 6A). A user account is created with name, gender, ID, password, and email address; account information can be searched by using the information above, excluding gender information.
The main screen is composed of the main buttons, such as blood glucose measurement, receivers information list, health information results, and health information transmit, as well as lower tab buttons, such as user information management, redirection to main screen, and settings (Figure 6B).
2) Receivers information list
The receivers information screen is composed of a list that displays the name and affiliation of receivers registered; a delete button, which deletes selected receivers; and an add button, which adds new receivers (Figure 6C). The select button next to the receivers information selects targets who will receive blood glucose levels, and the modify button modifies the information of a selected receiver. The add button adds new information by entering a receiver name, affiliation, telephone number, email address, IP, and port information (Figure 6D).
3) Blood glucose measurement
The blood glucose measurement screen consists of an image and description for device usage for appropriate measurement of blood glucose, a ready button for communication with a glucometer, and an enter button for direct entry (Figure 6E). The ready button prepares the measurement of blood glucose by composing a health channel after selecting a glucometer paired with a cell phone. After the completion of blood glucose measurement, a dialog with the blood glucose level pops up, and the result can be saved by specifying the measurement time by using fasting and postprandial 2 hours buttons (Figure 6F). The input button displays a dialog, which can directly enter a blood glucose level measured with a non-standard glucometer.
4) Blood glucose results and transmit
The blood glucose results screen is composed of a list that displays fasting and postprandial selection for blood glucose measurement, levels, date and time of measurement; a start and end button, which limit the blood glucose levels to be displayed in a list and a chart; a delete button to delete the selected level; and a chart button, which displays the current list of levels into a bar chart (Figure 6G). For other select buttons, a dialog pop-up function to select the type of vital signs to be displayed will be added in the future.
The blood glucose transmit screen reuses the list, start and end, and select buttons from the display screen (Figure 6H). However, there are the following additional buttons: a connection button to access the web server by using the selected receiver's IP and port information and a transmit button to compose the CCD document with blood glucose level, user information and receiver information and to deliver the information to the web server.
2. Evaluation of Application
1) Evaluation of usability
As a result of the verification of usefulness of the mobile health application, the five healthcare professionals stated that the application is a useful tool to control blood glucose.
(1) Usability for healthcare
Doctor 1: "Blood glucose control of diabetic patients is the most basic and important intervention. I think the advantages that the measured blood glucose level is recorded in realtime by using Bluetooth and accumulated continuously are helpful for the basic health care of patients with diabetes."
Nurse 1: "As the hospital environment is becoming computerized rapidly, there are various software products being introduced to help the tasks of medical teams. After trying it, it was useful because of simple screen and easy record checking."
Advanced Practice Nurse 1: "It was comfortable because accumulated blood glucose levels by date could be checked at once, and also the automatic record with the separation of postprandial and fasting blood glucose was very convenient. Also, it is very helpful to observe the accumulated blood glucose levels at once or evaluate the progress of change in blood glucose level because it has a function to display the levels into a graph."
(2) Usability for improving patient safety
Doctor 2: "Besides the blood glucose information, it would be great to apply it to the bio-information frequently measured and collected from patients with chronic diseases, including blood pressure and pulse. It is very convenient because the degree of change in blood glucose can be observed at once when a patient transmits his/her bio-information to a medical team. Additionally, it would be a useful standard of judgment when tracing the previous blood glucose levels because fasting and postprandial blood glucoses are separated."
Nurse 2: "We mostly record the measured blood glucose levels in the blood glucose chart in the clinical field or during outpatient visit, but it was helpful because the discomfort from recording was decreased. I think it can be used without any doubt because there were no errors during transmission or misentries while I was using this device."
2) Evaluation of usage intention
As a result of the reliability, Cronbach's alpha values of all variables appeared greater than 0.8; the instrument used in this study can be seen to have secure reliability (Table 2). Also, all eigenvalues were greater than 1.0. The validity of the tool was tested by obtaining 73.878% of total variables, so the validity was verified. Moreover, the factor loading value was over 0.50 for each of the variables.
For the six variables regarding intention of usage of the mobile health application (usage intention, effort expectancy, social influence, facilitating condition, perceived risk, voluntariness) evaluated by the five healthcare professionals and 87 users, usage intention that the mobile health application is helpful for hospital tasks or health management scored 4.03 ± 0.44 points out of 5 points, which was the highest, and perceived risk, which includes risks or monetary loss from the mobile health application scored 2.78 ± 0.66 points (Table 3).
IV. Discussion
In this research, a standardized system based on a cell phone platform was designed for blood glucose self-monitoring by patients with diabetes. For the designed system, an application was developed to manage the blood glucose of diabetic patients, and a web server was constructed for the remote monitoring of the blood glucose levels of diabetic patients. The developed application can be used to measure blood glucose levels and communicate with a glucometer with the standard protocol implemented through ISO/IEEE 11073 and Bluetooth HDP. This is then converted into a CCD document and transmitted to the web server. The web server composes objects by analyzing the CCD document transmitted, and saves them in a database. Also, as a result of verification by five healthcare professionals, the accuracy and appropriateness of the mobile health proposed application was confirmed, and the function and usefulness of the application was found to be satisfactory with 3.52 ± 0.42 points out of 5 points on average. Therefore, it can be used to provide accurate feedback to healthcare professionals during the management of actual diabetic patients or education for glucose management because it was confirmed that the proposed application can be used and expanded as a mobile health application in the clinical field in the future.
The standardized service of the system implemented in this research can be independently used by diabetic patients with a specific glucometer produced by a specific company or the specific platform of a specific hospital or corporation. This service provides the right to one's own information to patients by enabling them to measure and manage their own health information; therefore, it will facilitate the shifting of medical service towards consumer-centered prevention. However, the management of various chronic diseases is difficult because the service implemented can only control the blood glucose levels by linking with a glucometer, and connection with various medical information systems is limited because CCD was the only standard information model used. Also, the expression range of the designed CCD schema is narrow because the information to be processed by an application was restricted due to the characteristics of cell phones. Therefore, future research is planned to link with four personal health devices (blood pressure monitor, weight scale, glucometer, and pulse oximeter) and to test-operate an interconnected PHR-type mobile health service by adding HL7 V2 and ASTM CCR.
XML Download