- Email: [email protected]
THE-MUSS: Mobile u-health service system
c o m p u t e r m e t h o d s a n d p r o g r a m s i n b i o m e d i c i n e 9 7 ( 2 0 1 0 ) 178–188
journal homepage: www.intl.elsevierhealth.com/journals/cmpb
THE-MUSS: Mobile u-health service system Dongsoo Han ∗ , Minkyu Lee, Sungjoon Park Department of Computer Science, Korea Advanced Institute of Science and Technology, 119, Munjiro, Yuseong-gu, Daejeon, Republic of Korea
a r t i c l e
i n f o
a b s t r a c t
Article history:
In this paper, we introduce a mobile u-health service system called THE-MUSS. THE-MUSS
Received 19 September 2008
supports the development and running of u-health services with functions, modules, and
Received in revised form
facilities that are commonly required for various mobile u-health services. Aiming to achieve
22 June 2009
reusability and evolvability design goals, basic modules to support bio-signal capturing,
Accepted 21 August 2009
processing, analysis, diagnosis, and feedback are developed and stacked in the layered architecture of THE-MUSS. A U-health service platform, design tool, portal, and matrix-based
Keywords:
disease group identification method are the major components constituting the THE-MUSS
THE-MUSS
architecture. We confirmed that THE-MUSS is practically useful for mobile u-health ser-
DCAP
vices by developing mobile stress and weight management services on THE-MUSS. The
Mobile u-health
more u-health services are developed in THE-MUSS, the better services it can provide in the
Service platform
future. © 2009 Elsevier Ireland Ltd. All rights reserved.
Prediction method Data mining
1.
Introduction
A ubiquitous health (u-health) service is a health service in a ubiquitous environment using broadband and wireless mobile technologies. It enables us to receive health services in mobile situations with or without the intervention of medical experts. Bio-signals and symptom information of a user are captured and gathered by mobile bio-sensors and delivered to a remote server for analysis, and the results of the analysis are returned to the user for treatment. A mobile u-health service is a uhealth service in which a mobile phone plays a key role, such as relaying captured data or information to a remote server as a gateway and providing user interfaces at the same time [1,2]. With the wide spread use of mobile phones and the announcement of new mobile bio-sensors attached to them, there are many attempts for the development of mobile u-health services on mobile phones both in research and
∗
commercial areas [1,3]. Diverse forms and types of mobile uhealth services will be available on mobile phones in the near future. However, most u-health services on current mobile phones have been developed conforming to specific sensors or devices. That is, when new bio-sensors become available, services for them should be developed from scratch, and thus the functions and modules developed for one service are difficult to reuse in other services. If services are developed on a commonly available u-health service platform, a more efficient and systematic u-health service development will be possible [4]. In this paper, we introduce a mobile u-health service system called Total Health Enriching-Mobile U-health Service System (THE-MUSS), which supports u-health service development and execution, with functions, modules, and facilities that are commonly required for various mobile u-health services. Basic primitive modules and services for bio-signal capturing, processing, analysis, diagnosis, and feedback are prepared and provided in the system in a highly sharable manner. Ordinary u-health ser-
Corresponding author. Tel.: +82 42 350 6280. E-mail address: [email protected] (D. Han). 0169-2607/$ – see front matter © 2009 Elsevier Ireland Ltd. All rights reserved. doi:10.1016/j.cmpb.2009.08.004
c o m p u t e r m e t h o d s a n d p r o g r a m s i n b i o m e d i c i n e 9 7 ( 2 0 1 0 ) 178–188
vices are developed by integrating the modules and services equipped in the system. Understanding u-health services is essential for the setting of design goals for a u-health service system. For example, the understanding that u-health services may look different from a service point of view, they often share many common features at various levels such as service structure, unit service, and data. This leads us to emphasize the reusability design goal. Thus, we analyze the characteristics of u-health services to elicit the design goals of THE-MUSS. Evolvability is also set up as another primary design goal for THE-MUSS after understanding the u-health service characteristics. A business process management system [5,6] (BPMS)-based u-health service platform, u-health ontology incorporated u-health service design tool, matrix-based disease group identification framework, mobile client, and u-health portal are the major components constituting THE-MUSS’s layered architecture. Each of the components has some roles and functions to achieve the reusability and evolvability design goals. THE-MUSS has several unique features. First, it interprets and treats mobile u-health service as a service process and extends the BPMS to the healthcare service area. Business process management (BPM) is a field of management aligning workers and organizations to achieve their business goals [7]. Process or workflow automation is often involved in a BPM. A BPMS is a software system to support such BPM activities [6]. Process definition tool, process enactment service module, process monitoring and administration tool are the typical components of a BPMS. Unlike health areas, BPMS has been extensively used in general business sectors such as banks, insurance companies, etc. to improve the productivity of general service processes. Consequently, THE-MUSS provides the general functions and facilities of a BPMS. Regarding the uhealth service process, we define a typical mobile u-health service process template and deploy it on THE-MUSS. Second, THE-MUSS is equipped with a very unique matrixbased patient group identification method. Statistical data of patient and normal groups are accumulated in the matrix for learning. When we consider that we can gather less precise bio-signals more frequently via mobile sensors from a large number of users in a u-health environment, the method can be used effectively for mobile u-health services. Third, the platform provides several advanced features and functions by incorporating ontology technologies [8] in defining mobile u-health services and inferring or analyzing diseases. We implemented THE-MUSS and then developed mobile stress and weight management services on it to confirm and evaluate its usefulness in developing mobile u-health services. Especially we implemented the mobile stress service twice with and without THE-MUSS, respectively. The implementation time is drastically reduced and much less effort is required on THE-MUSS. We confirmed that the matrix-based disease group identification method and BPMS-based service platform were very useful in developing the stress and weight management services. In addition, many functions and modules developed for the mobile stress service were reused for the weight management service as well. This indicates that THE-MUSS was successful in achieving the evolvability and reusability design goals that occupy the core software quality attributes of a u-heath service system [9].
179
2. U-health service characteristics and design goals In this section, we describe the characteristics of u-health services with the design goals, technologies, and core components adopted in designing and implementing THE-MUSS. Like the services in other business sectors, most u-health services are process oriented as well. That is, a complete u-health service process is constructed by connecting and integrating small service units and the associated data. Many u-health services can be constructed as variants of a commonly sharable u-health service scenario. Moreover, many units of one u-health service are reusable by other u-health services. In other words, u-health services often share many common features with each other at various levels, such as their service structure, unit service, and data levels. This strongly supports the adoption of BPMS as a base system for a u-health service system because BPMS is one of typical approaches to accomplish reusability at various levels among the processes [5,6]. THE-MUSS is built on Web Vine BPMS [10]. In addition, the quality and completeness of u-health services should be continuously improved as more user feedback data are accumulated and better services become available. In that sense, a u-health service must evolve and a u-health service system should be able to support the evolving nature of u-health services. Ontology technology is one of the techniques to support the evolving features of u-health services because the newly available services and knowledge for uhealth are usually reflected to the system through ontology. It is desirable if a u-health service can be developed not only by programmers but also by medical experts such as doctors and nurses. A u-health service system should provide a service development environment and guidelines for medical experts to develop their own u-health services. THE-MUSS provides a u-health ontology incorporated u-health service design tool to cope with this requirement. Last, the advantage of a u-health service is due to its capability of obtaining a user’s bio-data from mobile bio-sensors continuously. But the bio-sensors for u-health services are inevitably limited in terms of their size and precision against off-line high cost biomedical sensors. That is, unlike the biodata obtained using the sensors in conventional hospitals, less precise bio-signals are obtained more frequently from a large number of users in a u-health environment. A u-health service system must compensate for such drawbacks of u-health services while taking advantage of their benefits. THE-MUSS provides a matrix-based disease group prediction method for the requirements. The method is devised to deal with a less precise but larger amount of data with a feedback mechanism, and it supports incremental learning. Since newly obtained data are reflected in the method, it can be considered as supporting the evolving features of u-health services.
3.
THE-MUSS
THE-MUSS is a total mobile u-health service system that provides developing and running environments of
180
c o m p u t e r m e t h o d s a n d p r o g r a m s i n b i o m e d i c i n e 9 7 ( 2 0 1 0 ) 178–188
Fig. 1 – Mobile u-health service scenario.
u-health services for service developers and users. The system integrates various components such as bio-sensors, cellular phones, associated software, and devices that are essential for u-health services. In this section, we describe the details of the core components that constitute THE-MUSS.
3.1.
BPMS based u-health service platform
The BPMS-based u-health service platform is an extension of BPMS for u-health services. Shareable service units, modules, and functions among u-health services are deployed on the platform so that they can be reused in other u-health services. In order to identify such sharable parts among u-health services, we need to understand the core activities for u-health services. In this section, we explain the core activities for u-health services and then illustrate the architecture of our u-health service platform.
3.1.1.
Mobile u-health service scenario
Fig. 1 illustrates a generic service scenario for mobile u-health services. In the first step of the service scenario, users fill out questionnaires to provide information about their physical symptoms and environment, which cannot be obtained from bio-sensors. The sensors embedded in cellular phones capture the necessary bio-signal and relay the data to the u-health server. After gathering bio-data from the questionnaires and sensors, a mobile u-health service process is initiated. The next activity of the scenario is to store the relayed data into a database so that the history of bio-data of the person can be persistently kept for further analysis. In the data analysis and decision support steps, the data ontology manager, which keeps semantically structured data for a specific set of diseases, plays a key role in identifying potential diseases based on the symptoms and bio-signals. For each symptom and bio-signal, the data ontology manager
assigns a weight value that represents the degree of association between the symptom or bio-signal and a certain disease. The final diagnosis decision is made by some mechanisms or methods for the service. If there is a general disease group prediction method for u-health services it would be helpful for this step. The last step of the scenario is the step for user feedback. Users may response to the diagnosis result positively or negatively. The users may even adjust the result according to their experiences or conditions. The feedback data is accumulated for the continuous improvement of the data analysis and decision support steps.
3.1.2.
Bio-data gathering and management
A mobile u-health service starts its function with periodically or randomly gathering input data, i.e., capturing the bio-signal data from users. We use some bio-sensors that are wearable by users or embedded into cellular phones. Thus, the bio-sensor devices and cellular phones, which act as a gateway between the bio-sensors and the u-health server, are the essential components for gathering input data. In addition, questionnaires that can be provided via cellular phones are necessary to obtain information that cannot be gathered from bio-sensors. The physical symptoms that a user has, the location of the user, and weather information are examples of such information that should be obtained directly from the users by using the questionnaires. We have developed a generic questionnaire composer to support the building of questionnaires that can gather various symptom and environmental information from users. In the future, some of information in the above might be automatically gathered without the intervention of users if more sensors are embedded or attached to a cellular phone. Our mobile u-health service platform provides the sensing modules and questionnaire interfaces independently from the core functionality of u-health services. This improves the reusability of the sensing modules and questionnaires for different healthcare services.
c o m p u t e r m e t h o d s a n d p r o g r a m s i n b i o m e d i c i n e 9 7 ( 2 0 1 0 ) 178–188
181
Fig. 2 – Mobile u-health service platform architecture.
Since a huge amount of bio-data need to be gathered and analyzed in mobile u-health services, it is essential to have an efficient data structure that allows the system to effectively store and manage bio-data. We found that a matrix is one of the good candidates for storing and analyzing a large quantity of data. We devised a bio-signal and symptom combination matrix, in which the appearances of bio-signal and symptom combination pairs of a normal group and a patient group are registered. We call the matrix a Disease Combination Appearance Probability (DCAP) matrix. Two DCAP matrices are created, one for a normal group, and another for a patient group. The accumulated data in DCAP matrices become the basis of the next step of the u-health service process, knowledge extraction and decision support.
3.1.3.
Knowledge extraction and decision support
Once a large amount of bio-data is accumulated, knowledge extraction and decision support for diagnosis become possible through data mining techniques, such as fuzzy sets, neural networks, genetic algorithms, and rough sets [11–14]. Sometimes, we can use well-established health indices to diagnose certain diseases for u-health services. However, in many cases, new health indices may need to be developed through machine learning or pattern recognition on the accumulated data. For the accumulation and management of bio-data and information obtained from questionnaires, we have developed data ontology. Based on this data ontology, symptom, disease, and bio-signal data can be archived in a structured manner. Some additional information such as a weight value to represent the degree of association between each input data and a certain disease type is assigned to the data ontology. Note that the weight values are not defined by users but by domain experts. The data ontology grows as new services and/or disease information are incorporated, and this contributes to make our platform evolvable.
3.1.4.
Platform architecture
The enactment service for u-health service processes is performed by the service platform. The mobile u-health service platform is a middleware that enables the integration of diverse services on BPMS. It serves as a hub to integrate modules and functions encompassing mobile u-health services, and provides an environment to develop and run the u-health services. Fig. 2 shows the architecture of the platform with the major components and connections to the surrounding elements in the u-health service framework. Since cellular phones play the role of a gateway between bio-sensors and servers, mobile message handling is essential for the platform. The mobile message-handling module relays all messages from bio-sensors to a server. There are several ways for connecting a bio-sensor with a cellular phone. Some bio-sensors are embedded in a cellular phone or are connected with a wired line. When bio-sensors detached from a cellular phone are used, a wireless communication such as Bluetooth and ZigBee is required for communications between the biosensors and cellular phone [15]. Communications between a cellular phone and a server are dependent on types of cellular phones and locations. Battery powers and computing capacities of the cellular phone are primary factors in deciding the types of cellular phone and wireless communications. CDMA or wireless LAN are the common technologies for communications between a cellular phone and server. Not only the bio-signal data but also service request messages are delivered to the server packed in XML messages by the message-handling module. Sometimes, it contributes to filter out some noise signals from the received messages. The bio-data delivered to a server is stored and managed by the huge temporal data management module in a secure manner. The bio-data is stored in diverse forms so that various services can utilize the data to perform their functions. Data mining and pattern recognition techniques are used to identify the health index from the accumulated bio-data. Also, an external or internal expert system may refer to
182
c o m p u t e r m e t h o d s a n d p r o g r a m s i n b i o m e d i c i n e 9 7 ( 2 0 1 0 ) 178–188
the data as feedback information. In order to support this, the database schema of the temporal database needs to be designed to satisfy the requirements of data mining or pattern recognition techniques and expert systems. As explained in Section 3.1, in order to develop a mobile u-health service on the service platform, the u-health service should be defined in a form of process containing steps such as bio-data gathering, storing, analysis, and result reporting. The u-health process block in Fig. 2 denotes a set of mobile uhealth processes derivable from the u-health service scenario process explained in Section 3.1. The u-health process definition tool enables developers to easily define new mobile u-health services. Mobile uhealth services defined in a process form are controlled and enacted by the u-health process management module. The u-health process management module provides not only the enactment function but also monitoring and administration functions for u-health processes. The mobile u-health management module and u-health process definition tool play a key role in making the platform evolvable. When a new mobile u-health service process is defined, reusable process templates, steps, and data structures are identified and registered to the server for later use. The management module ties together a set of u-health services into a group by specifying execution dependencies and the dataflow between services. There may be also some constraints that prevent a particular service from being started until some other services finish their functions. The user management module is essential for providing personalized service to individual users. The user management module stores user profile information such as age, gender, and occupation. Since a user is a participant in a mobile u-health process, this module is closely connected to the participant information in the u-health process management module. The dynamic service coordination module ensures reliable u-health service execution by replacing one service with an alternative one when a fault occurs in the service or the user’s requirements are changed. Data mining and pattern recognition modules may need to be developed for specific u-health services. Whenever such modules become available, they are placed on the data mining/pattern recognition module. A DCAP-based disease group prediction system can be one such module. An expert system engaged with a u-health service may need to access the functions in the data mining/pattern recognition module for decision-making.
3.2. DCAP matrix-based disease group prediction method In this section, we describe the DCAP matrix-based disease group prediction method, which is one of the unique features supported only by THE-MUSS. The method is hinted from the two-category classification method for the prediction method proposed by Han et al. [16]. Since the method includes a feedback mechanism and the newly obtained user data is reflected to the method, it makes our system evolvable in terms of learning and prediction. One assumption that we have made is that a disease group and a normal group can be classified based on the
combination of bio-signal and symptom information for the sake of explanation. Another assumption is that bio-signals and the symptom data of normal and patient groups can be obtained through mobile sensors and questionnaires. However our method is not necessarily confined to handling only bio-signal and symptom information. Other features can be accommodated in our method as well as long as the features are valid in discerning differences between patient and normal groups. Note that a bio-signal captured in an active state is usually different from one captured in other states for the same subject. Thus in gathering the learning data, the bio-signal capturing status of the groups should be the same as or similar to that of the prediction stage. Anyway, if the differences between the data gathered from the normal group and the patient group are obvious, the interrelation patterns between bio-signals and symptoms provide good criteria to classify users into the two groups.
3.2.1. The big picture of DCAP matrix-based prediction method A DCAP matrix is a core data structure for our disease group classification method, which largely consists of a learning stage and prediction stage. In the learning stage, members of normal and patient groups are characterized in terms of bio-signals and symptoms. The characterized results of each group are summarized and stored in DCAPnormal and DCAPpatient matrices, respectively. That is, the appearance probability of every bio-signal and symptom pair in each group is stored in DCAPnormal and DCAPpatient . Then, we merge the two matrices into a DCAP matrix so that each element of the DCAP matrix contains the relative appearance probability of the specific bio-signal and symptom pair in the patient group. The value of each DCAP element is computed by Eq. (2) in Section 3.2.2. Then, a probabilistic equation is developed based on the DCAP matrix to distinguish the normal group from the patient group. Once a DCAP matrix and the weight vectors for biosignals and symptoms are prepared, we can predict if a user with specific bio-signals and symptoms belongs to a disease group or not using Eq. (3) in Section 3.2.3. The obtained prediction results by applying Eq. (3) are delivered to the corresponding user. Then, the user confirms the results and gives feedback information to the system. The feedback information from the users are accumulated and reflected to the system. The feedback information is handled in two different ways: individual feedback and group feedback. The individual feedback is reflected by changing the corresponding weight vectors of a user, and the group feedback is reflected to the DCAP matrix. Fig. 3 shows the big picture of the method. Below, we describe the details of constructing DCAP, a result analysis, and feedback.
3.2.2.
Construction of DCAP matrix
In order to construct a DCAP matrix, we need to choose the bio-signals and symptoms to be used for the prediction. Once the bio-signals and symptoms are determined, we choose the degrees or ranges of each bio-signal or symptom. Suppose that we use two bio-signals, v1 and v2 , and two symptoms, s1 and s2 , and each bio-signal and symptom have two degrees or ranges.
c o m p u t e r m e t h o d s a n d p r o g r a m s i n b i o m e d i c i n e 9 7 ( 2 0 1 0 ) 178–188
183
Fig. 3 – The big picture of matrix-based disease group prediction method.
Then, we can represent all bio-signals and symptoms using vectors (v11 , v12 , v21 , v22 ) and (s11 , s12 , s21 , s22 ), respectively. The bio-signal and symptom vectors correspond to the row and column elements of DCAP. So, in this case we need a 4 × 4 DCAP matrix. Note that each bio-signal or symptom may have different number of degrees or ranges. Suppose further that there are learning sets {p1 , p2 , p3 } from a patient group, and {p4 , p5 , p6 } from a normal group with the following bio-signal, symptom pair information; Pair (p1 ) = {v11 , s11 , v11 , s22 , v22 , s11 , v22 , s22 } Pair (p2 ) = {v11 , s11 , v11 , s21 , v21 , s11 , v21 , s21 } Pair (p3 ) = {v12 , s12 , v12 , s22 , v22 , s12 , v22 , s22 }
and the members of the patient group have the following biosignal, symptom pairs; Pair (p4 ) = {v12 , s12 , v12 , s21 , v21 , s12 , v21 , s21 } Pair (p5 ) = {v12 , s12 , v12 , s21 , v22 , s12 , v22 , s21 } Pair (p6 ) = {v11 , s11 , v11 , s22 , v21 , s11 , v21 , s22 } Prior to the construction of the DCAP matrices, we build Vital-sign Symptom Pair Appearance (VSPA) matrices whose structures are the same as that of a DCAP matrix. The appearance frequencies of bio-signal, symptom pairs are counted and registered in a VSPA matrix. Since there are two groups, we build two VSPA matrices; VSPAnormal for the normal group and VSPApatient for the patient group. Fig. 4 shows VSPA matrices
Fig. 4 – Examples of VSPApatient and VSPAnormal matrices.
184
c o m p u t e r m e t h o d s a n d p r o g r a m s i n b i o m e d i c i n e 9 7 ( 2 0 1 0 ) 178–188
Fig. 5 – DCAP matrix for the example case (a) and DCAP(p) when a user p has a set of bio-signal and symptom pairs, {v11 , v11 , v11 , s21 , v22 , s11 , v22 , s21 } (b).
obtained by registering the bio-signal, symptom pair information above. Once the VSPAnormal and VSPApatient matrices are prepared, the construction of DCAPnormal and DCAPpatient is rather straightforward. All we need to do is to change the values of the elements in the VSPA matrices using equation (Eq. (1)). = DCAPnormal i,j
VSPAnormal i,j |normal|
, (1)
patient
patient DCAPi,j
=
VSPAi,j
P(p ∈ Patient group|CP(p))
|normal|
In Eq. (1), |normal| and |patient| denote the number of members in the normal and patient groups, respectively. In our example, both of the values for |normal| and |patient| have the same value of 3. The construction of DCAP from DCAPnormal and DCAPpatient is straightforward as well. We use Eq. (2) to construct DCAP. patient
DCAPi,j =
cpatient · DCAPi,j patient
cpatient · DCAPi,j
+ cnormal · DCAPnormal i,j
(2)
where cpatient = |patient|/(|patient| + |normal|) and normal = |normal|/(|patient| + |normal|). In our example, c cpatient and cnormal have the same value, 0.5. We must be careful when both of the DCAP values for the normal and patient groups equal 0. This indicates the training data is not sufficient. The cpatient value can be used instead for such cases. When we consider only one DCAP element, DCAPi,j , its value represents the probability of a person with an ith bio-signal and jth symptom pair to be in the patient group. Fig. 5 shows the DCAP for the example case. Note that we stored 0 when both of the DCAP values for the normal and patient groups equal 0 for convenience.
3.2.3.
the value of each DCAP element is related with the probability of a person with a corresponding bio-signal and symptom pair to be in the patient group. When we consider that a person is usually associated with multiple bio-signal and symptom pairs, the equation should reflect the probabilities of every bio-signal and symptom pairs pertaining to the person with weight information. We use Eq. (3) to predict if a person with a specific set of bio-signal and symptom pairs belongs to a disease group or not.
Prediction and result analysis
Once the DCAP for a certain disease is prepared, and the weight vectors for the bio-signals and symptoms are available, we can devise a probability equation to predict the possibility that a user with a specific set of bio-signal, symptom pair information belongs to the disease group. As explained above,
=
m i=1
X(p)i
m
j=1
X(p)j
n Y(p)u · DCAP(p)i,u · n u=1
v=1
Y(p)v
(3)
In Eq. (3), CP(p) denotes a set of bio-signal and symptom pairs of person p, and X(p), Y(p) denote bio-signal and symptom weight vectors of person p, respectively. Eq. (3) computes the conditional probability of person p to be in the patient group, when person p has CP(p). DCAP(p) is a matrix constructed by choosing the elements pertaining to person p. Thus, the equation computes the weighted average of all the elements of DCAP(p). As explained in Section 3.1.3, the weight vectors are usually defined by domain experts. So at the beginning, all of the users share the same weight vectors. But Eq. (3) assumes that each individual may have his/her own weight vectors to provide personalized services. Actually, we use weight vectors to support a personalized user feedback mechanism in the service process. Now suppose that user p has a set of bio-signal and symptom pairs, {v11 , v11 , v11 , s21 , v22 , s11 , v22 , s21 }. Suppose further that X(p), the bio-signal weight vector for p, is (0.6, 0.4), and that Y(p), the symptom weight vector for p, is (0.8, 0.2). Then, DCAP(p) of person p is constructed with the circled elements of the DCAP matrix in Fig. 5(b). In this example, we obtain the result probability, 66.75, by applying Eq. (3) to the above DCAP(p) and the weight vectors. That is, person p belongs to the patient group with a probability of 66.75. As illustrated in Fig. 5(b), from DCAP(p), we can easily figure out the degrees of each bio-signal and symptom pair’s influ-
c o m p u t e r m e t h o d s a n d p r o g r a m s i n b i o m e d i c i n e 9 7 ( 2 0 1 0 ) 178–188
ence on the computation. This enables us to deliver not only the prediction result, but also the analysis result, to the users. For example, we can inform the user of the primary bio-signal and symptom pairs in the prediction. The result analysis and the analysis information is important because if we can provide more information to users, the users can return more precise and meaningful feedback to the system.
3.2.4.
User feedback
User feedback is an essential step in a u-health service process because we can gather additional learning data and adjust the prediction result through the feedback. When we consider that the prediction accuracy is inevitably limited due to the constraints of mobile sensors and the uncontrolled states for capturing user data in a u-health environment, it is desirable if we can adjust the prediction result with the help from users. Such an adjustment is particularly useful for providing personalized services when handling complex diseases such as stress in u-health environment. There are many different ways for receiving feedback information from users and reflecting it to the prediction system. Since a DCAP matrix can provide information of the primary bio-signal and symptom pairs and associated weight vectors, we can ask if the users agree with the prediction result or let them adjust their weight vectors. The change of prediction result is dynamically displayed to the users according to the adjustment of the weight vectors so that they can understand the result of the adjustment. When user feedback data is sufficiently accumulated in the system, the system improves itself using the feedback data. Note that enormous amount of feedback data is usually generated in a u-health environment. We treat feedback in two different ways in reflecting it to a DCAP matrix. When a user’s feedback influences only the user’s prediction, we call it an individual feedback, whereas if the feedback data influences the entire prediction, we call it a group feedback. Individual feedback is supported by preparing and changing the individual weight vectors or by preparing a private DCAP matrix for each user. If a user’s feedback data is sufficiently accumulated in the user’s DCAP matrix, it can be used in the later prediction with the original DCAP matrix. The reflection of a private DCAP to the prediction is dependent on the diseases and domain experts, and the developing of general methods for this is an open issue. Group feedback is supported by changing the values of the DCAP matrix. Group feedback is performed once in a while when the system collects a sufficient amount of feedback data. Since group feedback results in a change of the prediction results for all users, we must be careful in performing it. We need not necessarily use all the feedback data for a group feedback. We remove some of feedback data that is revealed to be unreliable. In order to confirm the reliability, trust checking is performed for a user’s sequence of feedback data. Consistency is a primary factor in trust checking.
3.2.5.
Rationales of using DCAP
The DCAP matrix-based prediction method is general in the sense that it can be used for any disease as long as the disease group can be distinguished by the bio-signals and symptoms. The types of bio-signals and symptoms are decided on in a
185
flexible manner by medical experts according to the types of diseases. They can easily add or eliminate new bio-signals or symptoms if necessary. In addition, the DCAP matrix-based prediction method has several benefits against conventional machine learning techniques. First, compared with other conventional machine learning methods, incremental learning can be performed relatively easily in the method. That is, the new data obtained while running the prediction system is easily reflected back to the system by just changing the values of the DCAP matrix. Continuously generated data is the source for improving prediction accuracies in a u-health environment, and incremental learning is an appropriate approach for this situation. Second, the DCAP matrix-based prediction method provides a good means to analyze the prediction results by investigating the decisive elements of a DCAP matrix, i.e., the key factors in yielding a certain prediction result. As illustrated in Fig. 5(b), the symptom and bio-signal pairs of a subject are highlighted in a DCAP matrix in shadow with the degree of contributions of each pair on the results. Note that the prediction system for u-health services needs to explain the prediction results in detail to the users for as long as possible. Third, since a matrix is a relatively simple data structure, it is comprehensive to medical experts and easy to handle in the prediction system. When we consider that medical experts may take a look at the matrix to get insight and make improvements on the method for the disease they are dealing with, a matrix is an adequate data structure for this situation. Last, our DCAP matrix-based probabilistic approach is not vulnerable to erroneous learning data. Even if a small number of error data is included in the learning data, only a fraction of the DCAP matrix values are changed, and thus the influence on the prediction result is marginal in most cases. That is, the influences of error data for training are limited in our prediction method. When we consider that we usually deal with many erroneous data in a u-health service environment, error resiliency of the DCAP matrix-based prediction method is a desirable feature for u-health services.
3.3. U-health ontology incorporated u-health service design tool Eventually, u-health services should be designed by medical experts without help from programmers. A conventional process-modeling tool for BPMS is not sufficient to meet such requirements. THE-MUSS provides a u-health ontology incorporated u-health service design tool for this. Although the tool is indispensible for domain experts to design services, there is a long way to go for developing a full-fledged u-health ontology incorporated u-health service design tool. In this section, we briefly introduce a u-health ontology manager and the uhealth ontology incorporated u-health service design tool.
3.3.1.
U-health ontology manager
As explained earlier, in our platform, u-health data such as symptoms, diseases, and bio-signals, are systematically managed by constructing their ontology. In addition, services are classified and managed based on their functional ontology. The ontology manager provides modules and interfaces for experts to construct a u-health service and data ontology. Fig. 6
186
c o m p u t e r m e t h o d s a n d p r o g r a m s i n b i o m e d i c i n e 9 7 ( 2 0 1 0 ) 178–188
Fig. 6 – Ontology manager interface.
shows a case of u-health ontology for stress defined by the ontology manager. Using the ontology manager, experts can browse, add, remove, and search the u-health ontology.
3.3.2. U-health ontology incorporated u-health service design tool The u-health ontology incorporated u-health service design tool is an extension of the conventional process-modeling tool for BPMS. The ontology information constructed through the u-health ontology manager is merged in the processmodeling tool with service recommendation mechanisms. With service and data ontology, the service recommendation mechanism becomes the basis for a semi-automatic u-health
service design for medical experts. For the complete support for medical experts to develop their own services without programmers’ help, we need to define a complete and systematic u-health service development process. The mobile u-health service scenario shown in Fig. 1 is the starting point for the definition.
4.
Implementation and evaluation
We implemented TFIE-MUSS comprising the DCAP matrixbased prediction system, a communication server, a portal server and a client for a cellular phone. The client is deployed
Fig. 7 – Layered structure of THE-MUSS.
c o m p u t e r m e t h o d s a n d p r o g r a m s i n b i o m e d i c i n e 9 7 ( 2 0 1 0 ) 178–188
on a SAMSUNG BlackjackTM cellular phone with Windows CE that supports wired and Bluetooth [15] wireless communications with mobile sensors. THE-MUSS deals with various components such as biosensors, gateways, cellular phones, and service modules to support the construction of service processes. The functions, modules, and facilities described in this paper are developed and deployed in the layered architecture of THE-MUSS. Fig. 7 shows the layered structure of THE-MUSS. As illustrated in Fig. 7, essential primitive services for the design of complete u-healthcare services are developed in the form of Web services. The services are registered using the ontology-based BPMT in the process layer. Vital signal capturing, questionnaire design, vital signal and questionnaire input data analysis, diagnosis result delivery, and user feedback processing are currently available as primitive services in the component layer. Since rich sets of primitive services are essential for the construction of rich sets of service scenarios, we need to continue stacking more primitive services on THE-MUSS. Several filtering modules that receive vital signs from designated sensors are implemented, and the interfaces for calling the modules are registered in the form of Web services in THE-MUSS. Access to the obtained vital signs is performed by calling the registered interfaces. THE-MUSS provides UIs for doctors and medical experts to select sensors and the type of vital signs, and the actual invocation of the Web services and vital signal data capturing is then done by THE-MUSS. For the support of a questionnaire design, THE-MUSS provides a design facility for doctors and medical experts to develop questionnaires. Since the questionnaire design facility is implemented in the form of Web services and the underlying layers support the incorporation of Web services in a process, the designed questionnaires are easily incorporated within a u-health service process. Users access the designed questionnaire and provide input into the service process. Two mobile u-health services were developed on THEMUSS to confirm and evaluate its usefulness. One is a mobile stress management service and the other is a mobile weight management service. DCAP and questionnaire facilities were actively used for the development of the stress management service. The mobile weight management service was developed in a similar manner to the stress service except for the diagnosis part. A Baysian network [17] is used instead for diagnosis because we understand the weight management better than the stress management. Most parts of the stress service, such as capturing, delivering, and processing bio-signals, are reused in the weight management service, and only small parts of the service are added and modified to the stress service because the service structures of stress and weight management are similar to each other.
5.
Conclusion
In this paper, we developed a mobile u-health service system, THE-MUSS. The system supports the development and running of u-health services with functions, modules, and facilities that are commonly required for various mobile uhealth services. We identified u-health service characteristics
187
to elicit reusability and evolvability as its primary design goals. We developed several core components for THE-MUSS, which are integrated into its architecture. THE-MUSS is unique in the sense that it adopts BPMS as its underlying platform, provides a DCAP matrix-based prediction framework and ontology incorporated u-health service design tool, etc. In addition, the u-health service scenario template in THE-MUSS provides a guideline to uhealth service developers. Service developers can modify or extend the service scenario to develop their own u-health services. We confirmed that THE-MUSS is practically useful in developing mobile u-health services by developing mobile stress and weight management services on THE-MUSS. However, THE-MUSS is not a complete system yet, and it is still evolving toward a full-fledged u-health service system. The more u-health services are developed on THE-MUSS, the better services THE-MUSS can provide. There is some pending work to make THE-MUSS more secure and reliable. We are currently pursuing supporting a secure personal healthcare data management and enhancing the performance by adopting advanced techniques and mechanisms to exchange messages between mobile devices and a u-health server.
Conflict of interest There is no conflict of interest.
Acknowledgements We would like to thank Professor Inyoung Ko and Professor Daeseok Kim of Korea Advanced Institute of Science and Technology (KAIST) and Dr. Suntae Chung, Dr. Jaegul Cho, and Dr. Cheolho Cho of Samsung Electronics Ltd., for providing invaluable comments and advices for this research for over the past 3 years. We are grateful to the members of Intelligent Service Integration Laboratory of KAIST who participated in the implementation of THE-MUSS. This work is supported by Samsung-KAIST joint research center, and partly by the Ministry of Education and Science Technology (MEST) of Korea and Korea Industrial Technology Foundation (KOTEF) through the Human Resource Training Project for Regional Innovation.
references
[1] R.S.H. Istepanian, S. Laxminarayan, C.S. Pattichis (Eds.), M-Health: Emerging Mobile Health Systems, Springer, 2005. [2] R.S.H. Istepanian, E. Jovanov, Y.T. Zhang, Guest editorial introduction to the special section on M-Health: beyond seamless mobility and global wireless health-care connectivity, IEEE Transactions on Information Technology in Biomedicine 8 (4) (2004) 405–414. [3] J.M. Quero, C.L. Tarrida, J.J. Santana, V. Ermolov, I. Jantunen, H. Laine, J. Eichholz, Health care applications based on mobile phone centric smart sensor network, in: Proceedings of the 29th International Conference on Engineering in Medicine and Biology Society, August, 2007, pp. 6298–6301.
188
c o m p u t e r m e t h o d s a n d p r o g r a m s i n b i o m e d i c i n e 9 7 ( 2 0 1 0 ) 178–188
[4] D. Han, I. Ko, S. Park, An evolving mobile e-Health service platform, in: Proceedings of the IEEE International Conference on Consumer Electronics (ICCE 2007), USA, January, 2007, pp. 337–338. [5] H. Smith, P. Fingar, Business Process Management: The Third Ware, Meghan-Kiffer Press, 2003. [6] F. Leymann, D. Roller, M.T. Schmidt, Web services and business process management, IBM Systems Journal 41 (2) (2002). [7] W.M.P. van der Aalst, A.H.M. ter Hofstede, M. Weske (Eds.), Business Process Management, Lecture Notes in Computer Science, vol. 2678, Springer-Verlag, Berlin, 2003. [8] M. Uschold, M. Gruninger, Ontologies: principles, methods and applications, Knowledge Engineering Review 11 (2) (1996). [9] K.E. Wiegers, Software Requirements, 2nd ed., Microsoft Press, 2003. [10] D. Han, S. Song, J. Koo, WebVine Suite: a web services based BPMS, Lecture Notes in Computer Science 3841 (2006).
[11] S. Mitra, S.K. Pal, P. Mitra, Data mining in soft computing framework: a survey, IEEE Transactions on Neural Networks 13 (January (1)) (2002). [12] U. Fayyad, R. Uthurusamy, Data mining and knowledge discovery in databases, Communications of the ACM 39 (1996) 24–27. [13] J.P. Shim, M. Warkentin, J.F. Courtnay, D.J. Power, R. Sharda, Ch. Carlsson, Past, present, and future of decision support technology, Decision Support Systems 33 (2002) 111–126. [14] R. Duda, P. Hart, D. Stork, Pattern Classification, 2nd ed., John Wiley & Sons, Inc., 2001. [15] M.F.A. Rasid, B. Woodward, Bluetooth telemedicine processor for multichannel biomedical signal transmission via mobile cellular networks, IEEE Transactions on Information Technology in Biomedicine 9 (1) (2005) 35–43. [16] D. Han, H. Kim, W. Jang, S. Lee, S. Jung, PreSPI: a domain combination based prediction method for protein–protein interaction, Nucleic Acids Research 32 (21) (2004) 6312–6320. [17] F.V. Jensen, Introduction to Bayesian Networks, 1st edition, Springer-Verlag New York, Inc., Secaucus, NJ, USA, 1996.
journal homepage: www.intl.elsevierhealth.com/journals/cmpb
THE-MUSS: Mobile u-health service system Dongsoo Han ∗ , Minkyu Lee, Sungjoon Park Department of Computer Science, Korea Advanced Institute of Science and Technology, 119, Munjiro, Yuseong-gu, Daejeon, Republic of Korea
a r t i c l e
i n f o
a b s t r a c t
Article history:
In this paper, we introduce a mobile u-health service system called THE-MUSS. THE-MUSS
Received 19 September 2008
supports the development and running of u-health services with functions, modules, and
Received in revised form
facilities that are commonly required for various mobile u-health services. Aiming to achieve
22 June 2009
reusability and evolvability design goals, basic modules to support bio-signal capturing,
Accepted 21 August 2009
processing, analysis, diagnosis, and feedback are developed and stacked in the layered architecture of THE-MUSS. A U-health service platform, design tool, portal, and matrix-based
Keywords:
disease group identification method are the major components constituting the THE-MUSS
THE-MUSS
architecture. We confirmed that THE-MUSS is practically useful for mobile u-health ser-
DCAP
vices by developing mobile stress and weight management services on THE-MUSS. The
Mobile u-health
more u-health services are developed in THE-MUSS, the better services it can provide in the
Service platform
future. © 2009 Elsevier Ireland Ltd. All rights reserved.
Prediction method Data mining
1.
Introduction
A ubiquitous health (u-health) service is a health service in a ubiquitous environment using broadband and wireless mobile technologies. It enables us to receive health services in mobile situations with or without the intervention of medical experts. Bio-signals and symptom information of a user are captured and gathered by mobile bio-sensors and delivered to a remote server for analysis, and the results of the analysis are returned to the user for treatment. A mobile u-health service is a uhealth service in which a mobile phone plays a key role, such as relaying captured data or information to a remote server as a gateway and providing user interfaces at the same time [1,2]. With the wide spread use of mobile phones and the announcement of new mobile bio-sensors attached to them, there are many attempts for the development of mobile u-health services on mobile phones both in research and
∗
commercial areas [1,3]. Diverse forms and types of mobile uhealth services will be available on mobile phones in the near future. However, most u-health services on current mobile phones have been developed conforming to specific sensors or devices. That is, when new bio-sensors become available, services for them should be developed from scratch, and thus the functions and modules developed for one service are difficult to reuse in other services. If services are developed on a commonly available u-health service platform, a more efficient and systematic u-health service development will be possible [4]. In this paper, we introduce a mobile u-health service system called Total Health Enriching-Mobile U-health Service System (THE-MUSS), which supports u-health service development and execution, with functions, modules, and facilities that are commonly required for various mobile u-health services. Basic primitive modules and services for bio-signal capturing, processing, analysis, diagnosis, and feedback are prepared and provided in the system in a highly sharable manner. Ordinary u-health ser-
Corresponding author. Tel.: +82 42 350 6280. E-mail address: [email protected] (D. Han). 0169-2607/$ – see front matter © 2009 Elsevier Ireland Ltd. All rights reserved. doi:10.1016/j.cmpb.2009.08.004
c o m p u t e r m e t h o d s a n d p r o g r a m s i n b i o m e d i c i n e 9 7 ( 2 0 1 0 ) 178–188
vices are developed by integrating the modules and services equipped in the system. Understanding u-health services is essential for the setting of design goals for a u-health service system. For example, the understanding that u-health services may look different from a service point of view, they often share many common features at various levels such as service structure, unit service, and data. This leads us to emphasize the reusability design goal. Thus, we analyze the characteristics of u-health services to elicit the design goals of THE-MUSS. Evolvability is also set up as another primary design goal for THE-MUSS after understanding the u-health service characteristics. A business process management system [5,6] (BPMS)-based u-health service platform, u-health ontology incorporated u-health service design tool, matrix-based disease group identification framework, mobile client, and u-health portal are the major components constituting THE-MUSS’s layered architecture. Each of the components has some roles and functions to achieve the reusability and evolvability design goals. THE-MUSS has several unique features. First, it interprets and treats mobile u-health service as a service process and extends the BPMS to the healthcare service area. Business process management (BPM) is a field of management aligning workers and organizations to achieve their business goals [7]. Process or workflow automation is often involved in a BPM. A BPMS is a software system to support such BPM activities [6]. Process definition tool, process enactment service module, process monitoring and administration tool are the typical components of a BPMS. Unlike health areas, BPMS has been extensively used in general business sectors such as banks, insurance companies, etc. to improve the productivity of general service processes. Consequently, THE-MUSS provides the general functions and facilities of a BPMS. Regarding the uhealth service process, we define a typical mobile u-health service process template and deploy it on THE-MUSS. Second, THE-MUSS is equipped with a very unique matrixbased patient group identification method. Statistical data of patient and normal groups are accumulated in the matrix for learning. When we consider that we can gather less precise bio-signals more frequently via mobile sensors from a large number of users in a u-health environment, the method can be used effectively for mobile u-health services. Third, the platform provides several advanced features and functions by incorporating ontology technologies [8] in defining mobile u-health services and inferring or analyzing diseases. We implemented THE-MUSS and then developed mobile stress and weight management services on it to confirm and evaluate its usefulness in developing mobile u-health services. Especially we implemented the mobile stress service twice with and without THE-MUSS, respectively. The implementation time is drastically reduced and much less effort is required on THE-MUSS. We confirmed that the matrix-based disease group identification method and BPMS-based service platform were very useful in developing the stress and weight management services. In addition, many functions and modules developed for the mobile stress service were reused for the weight management service as well. This indicates that THE-MUSS was successful in achieving the evolvability and reusability design goals that occupy the core software quality attributes of a u-heath service system [9].
179
2. U-health service characteristics and design goals In this section, we describe the characteristics of u-health services with the design goals, technologies, and core components adopted in designing and implementing THE-MUSS. Like the services in other business sectors, most u-health services are process oriented as well. That is, a complete u-health service process is constructed by connecting and integrating small service units and the associated data. Many u-health services can be constructed as variants of a commonly sharable u-health service scenario. Moreover, many units of one u-health service are reusable by other u-health services. In other words, u-health services often share many common features with each other at various levels, such as their service structure, unit service, and data levels. This strongly supports the adoption of BPMS as a base system for a u-health service system because BPMS is one of typical approaches to accomplish reusability at various levels among the processes [5,6]. THE-MUSS is built on Web Vine BPMS [10]. In addition, the quality and completeness of u-health services should be continuously improved as more user feedback data are accumulated and better services become available. In that sense, a u-health service must evolve and a u-health service system should be able to support the evolving nature of u-health services. Ontology technology is one of the techniques to support the evolving features of u-health services because the newly available services and knowledge for uhealth are usually reflected to the system through ontology. It is desirable if a u-health service can be developed not only by programmers but also by medical experts such as doctors and nurses. A u-health service system should provide a service development environment and guidelines for medical experts to develop their own u-health services. THE-MUSS provides a u-health ontology incorporated u-health service design tool to cope with this requirement. Last, the advantage of a u-health service is due to its capability of obtaining a user’s bio-data from mobile bio-sensors continuously. But the bio-sensors for u-health services are inevitably limited in terms of their size and precision against off-line high cost biomedical sensors. That is, unlike the biodata obtained using the sensors in conventional hospitals, less precise bio-signals are obtained more frequently from a large number of users in a u-health environment. A u-health service system must compensate for such drawbacks of u-health services while taking advantage of their benefits. THE-MUSS provides a matrix-based disease group prediction method for the requirements. The method is devised to deal with a less precise but larger amount of data with a feedback mechanism, and it supports incremental learning. Since newly obtained data are reflected in the method, it can be considered as supporting the evolving features of u-health services.
3.
THE-MUSS
THE-MUSS is a total mobile u-health service system that provides developing and running environments of
180
c o m p u t e r m e t h o d s a n d p r o g r a m s i n b i o m e d i c i n e 9 7 ( 2 0 1 0 ) 178–188
Fig. 1 – Mobile u-health service scenario.
u-health services for service developers and users. The system integrates various components such as bio-sensors, cellular phones, associated software, and devices that are essential for u-health services. In this section, we describe the details of the core components that constitute THE-MUSS.
3.1.
BPMS based u-health service platform
The BPMS-based u-health service platform is an extension of BPMS for u-health services. Shareable service units, modules, and functions among u-health services are deployed on the platform so that they can be reused in other u-health services. In order to identify such sharable parts among u-health services, we need to understand the core activities for u-health services. In this section, we explain the core activities for u-health services and then illustrate the architecture of our u-health service platform.
3.1.1.
Mobile u-health service scenario
Fig. 1 illustrates a generic service scenario for mobile u-health services. In the first step of the service scenario, users fill out questionnaires to provide information about their physical symptoms and environment, which cannot be obtained from bio-sensors. The sensors embedded in cellular phones capture the necessary bio-signal and relay the data to the u-health server. After gathering bio-data from the questionnaires and sensors, a mobile u-health service process is initiated. The next activity of the scenario is to store the relayed data into a database so that the history of bio-data of the person can be persistently kept for further analysis. In the data analysis and decision support steps, the data ontology manager, which keeps semantically structured data for a specific set of diseases, plays a key role in identifying potential diseases based on the symptoms and bio-signals. For each symptom and bio-signal, the data ontology manager
assigns a weight value that represents the degree of association between the symptom or bio-signal and a certain disease. The final diagnosis decision is made by some mechanisms or methods for the service. If there is a general disease group prediction method for u-health services it would be helpful for this step. The last step of the scenario is the step for user feedback. Users may response to the diagnosis result positively or negatively. The users may even adjust the result according to their experiences or conditions. The feedback data is accumulated for the continuous improvement of the data analysis and decision support steps.
3.1.2.
Bio-data gathering and management
A mobile u-health service starts its function with periodically or randomly gathering input data, i.e., capturing the bio-signal data from users. We use some bio-sensors that are wearable by users or embedded into cellular phones. Thus, the bio-sensor devices and cellular phones, which act as a gateway between the bio-sensors and the u-health server, are the essential components for gathering input data. In addition, questionnaires that can be provided via cellular phones are necessary to obtain information that cannot be gathered from bio-sensors. The physical symptoms that a user has, the location of the user, and weather information are examples of such information that should be obtained directly from the users by using the questionnaires. We have developed a generic questionnaire composer to support the building of questionnaires that can gather various symptom and environmental information from users. In the future, some of information in the above might be automatically gathered without the intervention of users if more sensors are embedded or attached to a cellular phone. Our mobile u-health service platform provides the sensing modules and questionnaire interfaces independently from the core functionality of u-health services. This improves the reusability of the sensing modules and questionnaires for different healthcare services.
c o m p u t e r m e t h o d s a n d p r o g r a m s i n b i o m e d i c i n e 9 7 ( 2 0 1 0 ) 178–188
181
Fig. 2 – Mobile u-health service platform architecture.
Since a huge amount of bio-data need to be gathered and analyzed in mobile u-health services, it is essential to have an efficient data structure that allows the system to effectively store and manage bio-data. We found that a matrix is one of the good candidates for storing and analyzing a large quantity of data. We devised a bio-signal and symptom combination matrix, in which the appearances of bio-signal and symptom combination pairs of a normal group and a patient group are registered. We call the matrix a Disease Combination Appearance Probability (DCAP) matrix. Two DCAP matrices are created, one for a normal group, and another for a patient group. The accumulated data in DCAP matrices become the basis of the next step of the u-health service process, knowledge extraction and decision support.
3.1.3.
Knowledge extraction and decision support
Once a large amount of bio-data is accumulated, knowledge extraction and decision support for diagnosis become possible through data mining techniques, such as fuzzy sets, neural networks, genetic algorithms, and rough sets [11–14]. Sometimes, we can use well-established health indices to diagnose certain diseases for u-health services. However, in many cases, new health indices may need to be developed through machine learning or pattern recognition on the accumulated data. For the accumulation and management of bio-data and information obtained from questionnaires, we have developed data ontology. Based on this data ontology, symptom, disease, and bio-signal data can be archived in a structured manner. Some additional information such as a weight value to represent the degree of association between each input data and a certain disease type is assigned to the data ontology. Note that the weight values are not defined by users but by domain experts. The data ontology grows as new services and/or disease information are incorporated, and this contributes to make our platform evolvable.
3.1.4.
Platform architecture
The enactment service for u-health service processes is performed by the service platform. The mobile u-health service platform is a middleware that enables the integration of diverse services on BPMS. It serves as a hub to integrate modules and functions encompassing mobile u-health services, and provides an environment to develop and run the u-health services. Fig. 2 shows the architecture of the platform with the major components and connections to the surrounding elements in the u-health service framework. Since cellular phones play the role of a gateway between bio-sensors and servers, mobile message handling is essential for the platform. The mobile message-handling module relays all messages from bio-sensors to a server. There are several ways for connecting a bio-sensor with a cellular phone. Some bio-sensors are embedded in a cellular phone or are connected with a wired line. When bio-sensors detached from a cellular phone are used, a wireless communication such as Bluetooth and ZigBee is required for communications between the biosensors and cellular phone [15]. Communications between a cellular phone and a server are dependent on types of cellular phones and locations. Battery powers and computing capacities of the cellular phone are primary factors in deciding the types of cellular phone and wireless communications. CDMA or wireless LAN are the common technologies for communications between a cellular phone and server. Not only the bio-signal data but also service request messages are delivered to the server packed in XML messages by the message-handling module. Sometimes, it contributes to filter out some noise signals from the received messages. The bio-data delivered to a server is stored and managed by the huge temporal data management module in a secure manner. The bio-data is stored in diverse forms so that various services can utilize the data to perform their functions. Data mining and pattern recognition techniques are used to identify the health index from the accumulated bio-data. Also, an external or internal expert system may refer to
182
c o m p u t e r m e t h o d s a n d p r o g r a m s i n b i o m e d i c i n e 9 7 ( 2 0 1 0 ) 178–188
the data as feedback information. In order to support this, the database schema of the temporal database needs to be designed to satisfy the requirements of data mining or pattern recognition techniques and expert systems. As explained in Section 3.1, in order to develop a mobile u-health service on the service platform, the u-health service should be defined in a form of process containing steps such as bio-data gathering, storing, analysis, and result reporting. The u-health process block in Fig. 2 denotes a set of mobile uhealth processes derivable from the u-health service scenario process explained in Section 3.1. The u-health process definition tool enables developers to easily define new mobile u-health services. Mobile uhealth services defined in a process form are controlled and enacted by the u-health process management module. The u-health process management module provides not only the enactment function but also monitoring and administration functions for u-health processes. The mobile u-health management module and u-health process definition tool play a key role in making the platform evolvable. When a new mobile u-health service process is defined, reusable process templates, steps, and data structures are identified and registered to the server for later use. The management module ties together a set of u-health services into a group by specifying execution dependencies and the dataflow between services. There may be also some constraints that prevent a particular service from being started until some other services finish their functions. The user management module is essential for providing personalized service to individual users. The user management module stores user profile information such as age, gender, and occupation. Since a user is a participant in a mobile u-health process, this module is closely connected to the participant information in the u-health process management module. The dynamic service coordination module ensures reliable u-health service execution by replacing one service with an alternative one when a fault occurs in the service or the user’s requirements are changed. Data mining and pattern recognition modules may need to be developed for specific u-health services. Whenever such modules become available, they are placed on the data mining/pattern recognition module. A DCAP-based disease group prediction system can be one such module. An expert system engaged with a u-health service may need to access the functions in the data mining/pattern recognition module for decision-making.
3.2. DCAP matrix-based disease group prediction method In this section, we describe the DCAP matrix-based disease group prediction method, which is one of the unique features supported only by THE-MUSS. The method is hinted from the two-category classification method for the prediction method proposed by Han et al. [16]. Since the method includes a feedback mechanism and the newly obtained user data is reflected to the method, it makes our system evolvable in terms of learning and prediction. One assumption that we have made is that a disease group and a normal group can be classified based on the
combination of bio-signal and symptom information for the sake of explanation. Another assumption is that bio-signals and the symptom data of normal and patient groups can be obtained through mobile sensors and questionnaires. However our method is not necessarily confined to handling only bio-signal and symptom information. Other features can be accommodated in our method as well as long as the features are valid in discerning differences between patient and normal groups. Note that a bio-signal captured in an active state is usually different from one captured in other states for the same subject. Thus in gathering the learning data, the bio-signal capturing status of the groups should be the same as or similar to that of the prediction stage. Anyway, if the differences between the data gathered from the normal group and the patient group are obvious, the interrelation patterns between bio-signals and symptoms provide good criteria to classify users into the two groups.
3.2.1. The big picture of DCAP matrix-based prediction method A DCAP matrix is a core data structure for our disease group classification method, which largely consists of a learning stage and prediction stage. In the learning stage, members of normal and patient groups are characterized in terms of bio-signals and symptoms. The characterized results of each group are summarized and stored in DCAPnormal and DCAPpatient matrices, respectively. That is, the appearance probability of every bio-signal and symptom pair in each group is stored in DCAPnormal and DCAPpatient . Then, we merge the two matrices into a DCAP matrix so that each element of the DCAP matrix contains the relative appearance probability of the specific bio-signal and symptom pair in the patient group. The value of each DCAP element is computed by Eq. (2) in Section 3.2.2. Then, a probabilistic equation is developed based on the DCAP matrix to distinguish the normal group from the patient group. Once a DCAP matrix and the weight vectors for biosignals and symptoms are prepared, we can predict if a user with specific bio-signals and symptoms belongs to a disease group or not using Eq. (3) in Section 3.2.3. The obtained prediction results by applying Eq. (3) are delivered to the corresponding user. Then, the user confirms the results and gives feedback information to the system. The feedback information from the users are accumulated and reflected to the system. The feedback information is handled in two different ways: individual feedback and group feedback. The individual feedback is reflected by changing the corresponding weight vectors of a user, and the group feedback is reflected to the DCAP matrix. Fig. 3 shows the big picture of the method. Below, we describe the details of constructing DCAP, a result analysis, and feedback.
3.2.2.
Construction of DCAP matrix
In order to construct a DCAP matrix, we need to choose the bio-signals and symptoms to be used for the prediction. Once the bio-signals and symptoms are determined, we choose the degrees or ranges of each bio-signal or symptom. Suppose that we use two bio-signals, v1 and v2 , and two symptoms, s1 and s2 , and each bio-signal and symptom have two degrees or ranges.
c o m p u t e r m e t h o d s a n d p r o g r a m s i n b i o m e d i c i n e 9 7 ( 2 0 1 0 ) 178–188
183
Fig. 3 – The big picture of matrix-based disease group prediction method.
Then, we can represent all bio-signals and symptoms using vectors (v11 , v12 , v21 , v22 ) and (s11 , s12 , s21 , s22 ), respectively. The bio-signal and symptom vectors correspond to the row and column elements of DCAP. So, in this case we need a 4 × 4 DCAP matrix. Note that each bio-signal or symptom may have different number of degrees or ranges. Suppose further that there are learning sets {p1 , p2 , p3 } from a patient group, and {p4 , p5 , p6 } from a normal group with the following bio-signal, symptom pair information; Pair (p1 ) = {v11 , s11 , v11 , s22 , v22 , s11 , v22 , s22 } Pair (p2 ) = {v11 , s11 , v11 , s21 , v21 , s11 , v21 , s21 } Pair (p3 ) = {v12 , s12 , v12 , s22 , v22 , s12 , v22 , s22 }
and the members of the patient group have the following biosignal, symptom pairs; Pair (p4 ) = {v12 , s12 , v12 , s21 , v21 , s12 , v21 , s21 } Pair (p5 ) = {v12 , s12 , v12 , s21 , v22 , s12 , v22 , s21 } Pair (p6 ) = {v11 , s11 , v11 , s22 , v21 , s11 , v21 , s22 } Prior to the construction of the DCAP matrices, we build Vital-sign Symptom Pair Appearance (VSPA) matrices whose structures are the same as that of a DCAP matrix. The appearance frequencies of bio-signal, symptom pairs are counted and registered in a VSPA matrix. Since there are two groups, we build two VSPA matrices; VSPAnormal for the normal group and VSPApatient for the patient group. Fig. 4 shows VSPA matrices
Fig. 4 – Examples of VSPApatient and VSPAnormal matrices.
184
c o m p u t e r m e t h o d s a n d p r o g r a m s i n b i o m e d i c i n e 9 7 ( 2 0 1 0 ) 178–188
Fig. 5 – DCAP matrix for the example case (a) and DCAP(p) when a user p has a set of bio-signal and symptom pairs, {v11 , v11 , v11 , s21 , v22 , s11 , v22 , s21 } (b).
obtained by registering the bio-signal, symptom pair information above. Once the VSPAnormal and VSPApatient matrices are prepared, the construction of DCAPnormal and DCAPpatient is rather straightforward. All we need to do is to change the values of the elements in the VSPA matrices using equation (Eq. (1)). = DCAPnormal i,j
VSPAnormal i,j |normal|
, (1)
patient
patient DCAPi,j
=
VSPAi,j
P(p ∈ Patient group|CP(p))
|normal|
In Eq. (1), |normal| and |patient| denote the number of members in the normal and patient groups, respectively. In our example, both of the values for |normal| and |patient| have the same value of 3. The construction of DCAP from DCAPnormal and DCAPpatient is straightforward as well. We use Eq. (2) to construct DCAP. patient
DCAPi,j =
cpatient · DCAPi,j patient
cpatient · DCAPi,j
+ cnormal · DCAPnormal i,j
(2)
where cpatient = |patient|/(|patient| + |normal|) and normal = |normal|/(|patient| + |normal|). In our example, c cpatient and cnormal have the same value, 0.5. We must be careful when both of the DCAP values for the normal and patient groups equal 0. This indicates the training data is not sufficient. The cpatient value can be used instead for such cases. When we consider only one DCAP element, DCAPi,j , its value represents the probability of a person with an ith bio-signal and jth symptom pair to be in the patient group. Fig. 5 shows the DCAP for the example case. Note that we stored 0 when both of the DCAP values for the normal and patient groups equal 0 for convenience.
3.2.3.
the value of each DCAP element is related with the probability of a person with a corresponding bio-signal and symptom pair to be in the patient group. When we consider that a person is usually associated with multiple bio-signal and symptom pairs, the equation should reflect the probabilities of every bio-signal and symptom pairs pertaining to the person with weight information. We use Eq. (3) to predict if a person with a specific set of bio-signal and symptom pairs belongs to a disease group or not.
Prediction and result analysis
Once the DCAP for a certain disease is prepared, and the weight vectors for the bio-signals and symptoms are available, we can devise a probability equation to predict the possibility that a user with a specific set of bio-signal, symptom pair information belongs to the disease group. As explained above,
=
m i=1
X(p)i
m
j=1
X(p)j
n Y(p)u · DCAP(p)i,u · n u=1
v=1
Y(p)v
(3)
In Eq. (3), CP(p) denotes a set of bio-signal and symptom pairs of person p, and X(p), Y(p) denote bio-signal and symptom weight vectors of person p, respectively. Eq. (3) computes the conditional probability of person p to be in the patient group, when person p has CP(p). DCAP(p) is a matrix constructed by choosing the elements pertaining to person p. Thus, the equation computes the weighted average of all the elements of DCAP(p). As explained in Section 3.1.3, the weight vectors are usually defined by domain experts. So at the beginning, all of the users share the same weight vectors. But Eq. (3) assumes that each individual may have his/her own weight vectors to provide personalized services. Actually, we use weight vectors to support a personalized user feedback mechanism in the service process. Now suppose that user p has a set of bio-signal and symptom pairs, {v11 , v11 , v11 , s21 , v22 , s11 , v22 , s21 }. Suppose further that X(p), the bio-signal weight vector for p, is (0.6, 0.4), and that Y(p), the symptom weight vector for p, is (0.8, 0.2). Then, DCAP(p) of person p is constructed with the circled elements of the DCAP matrix in Fig. 5(b). In this example, we obtain the result probability, 66.75, by applying Eq. (3) to the above DCAP(p) and the weight vectors. That is, person p belongs to the patient group with a probability of 66.75. As illustrated in Fig. 5(b), from DCAP(p), we can easily figure out the degrees of each bio-signal and symptom pair’s influ-
c o m p u t e r m e t h o d s a n d p r o g r a m s i n b i o m e d i c i n e 9 7 ( 2 0 1 0 ) 178–188
ence on the computation. This enables us to deliver not only the prediction result, but also the analysis result, to the users. For example, we can inform the user of the primary bio-signal and symptom pairs in the prediction. The result analysis and the analysis information is important because if we can provide more information to users, the users can return more precise and meaningful feedback to the system.
3.2.4.
User feedback
User feedback is an essential step in a u-health service process because we can gather additional learning data and adjust the prediction result through the feedback. When we consider that the prediction accuracy is inevitably limited due to the constraints of mobile sensors and the uncontrolled states for capturing user data in a u-health environment, it is desirable if we can adjust the prediction result with the help from users. Such an adjustment is particularly useful for providing personalized services when handling complex diseases such as stress in u-health environment. There are many different ways for receiving feedback information from users and reflecting it to the prediction system. Since a DCAP matrix can provide information of the primary bio-signal and symptom pairs and associated weight vectors, we can ask if the users agree with the prediction result or let them adjust their weight vectors. The change of prediction result is dynamically displayed to the users according to the adjustment of the weight vectors so that they can understand the result of the adjustment. When user feedback data is sufficiently accumulated in the system, the system improves itself using the feedback data. Note that enormous amount of feedback data is usually generated in a u-health environment. We treat feedback in two different ways in reflecting it to a DCAP matrix. When a user’s feedback influences only the user’s prediction, we call it an individual feedback, whereas if the feedback data influences the entire prediction, we call it a group feedback. Individual feedback is supported by preparing and changing the individual weight vectors or by preparing a private DCAP matrix for each user. If a user’s feedback data is sufficiently accumulated in the user’s DCAP matrix, it can be used in the later prediction with the original DCAP matrix. The reflection of a private DCAP to the prediction is dependent on the diseases and domain experts, and the developing of general methods for this is an open issue. Group feedback is supported by changing the values of the DCAP matrix. Group feedback is performed once in a while when the system collects a sufficient amount of feedback data. Since group feedback results in a change of the prediction results for all users, we must be careful in performing it. We need not necessarily use all the feedback data for a group feedback. We remove some of feedback data that is revealed to be unreliable. In order to confirm the reliability, trust checking is performed for a user’s sequence of feedback data. Consistency is a primary factor in trust checking.
3.2.5.
Rationales of using DCAP
The DCAP matrix-based prediction method is general in the sense that it can be used for any disease as long as the disease group can be distinguished by the bio-signals and symptoms. The types of bio-signals and symptoms are decided on in a
185
flexible manner by medical experts according to the types of diseases. They can easily add or eliminate new bio-signals or symptoms if necessary. In addition, the DCAP matrix-based prediction method has several benefits against conventional machine learning techniques. First, compared with other conventional machine learning methods, incremental learning can be performed relatively easily in the method. That is, the new data obtained while running the prediction system is easily reflected back to the system by just changing the values of the DCAP matrix. Continuously generated data is the source for improving prediction accuracies in a u-health environment, and incremental learning is an appropriate approach for this situation. Second, the DCAP matrix-based prediction method provides a good means to analyze the prediction results by investigating the decisive elements of a DCAP matrix, i.e., the key factors in yielding a certain prediction result. As illustrated in Fig. 5(b), the symptom and bio-signal pairs of a subject are highlighted in a DCAP matrix in shadow with the degree of contributions of each pair on the results. Note that the prediction system for u-health services needs to explain the prediction results in detail to the users for as long as possible. Third, since a matrix is a relatively simple data structure, it is comprehensive to medical experts and easy to handle in the prediction system. When we consider that medical experts may take a look at the matrix to get insight and make improvements on the method for the disease they are dealing with, a matrix is an adequate data structure for this situation. Last, our DCAP matrix-based probabilistic approach is not vulnerable to erroneous learning data. Even if a small number of error data is included in the learning data, only a fraction of the DCAP matrix values are changed, and thus the influence on the prediction result is marginal in most cases. That is, the influences of error data for training are limited in our prediction method. When we consider that we usually deal with many erroneous data in a u-health service environment, error resiliency of the DCAP matrix-based prediction method is a desirable feature for u-health services.
3.3. U-health ontology incorporated u-health service design tool Eventually, u-health services should be designed by medical experts without help from programmers. A conventional process-modeling tool for BPMS is not sufficient to meet such requirements. THE-MUSS provides a u-health ontology incorporated u-health service design tool for this. Although the tool is indispensible for domain experts to design services, there is a long way to go for developing a full-fledged u-health ontology incorporated u-health service design tool. In this section, we briefly introduce a u-health ontology manager and the uhealth ontology incorporated u-health service design tool.
3.3.1.
U-health ontology manager
As explained earlier, in our platform, u-health data such as symptoms, diseases, and bio-signals, are systematically managed by constructing their ontology. In addition, services are classified and managed based on their functional ontology. The ontology manager provides modules and interfaces for experts to construct a u-health service and data ontology. Fig. 6
186
c o m p u t e r m e t h o d s a n d p r o g r a m s i n b i o m e d i c i n e 9 7 ( 2 0 1 0 ) 178–188
Fig. 6 – Ontology manager interface.
shows a case of u-health ontology for stress defined by the ontology manager. Using the ontology manager, experts can browse, add, remove, and search the u-health ontology.
3.3.2. U-health ontology incorporated u-health service design tool The u-health ontology incorporated u-health service design tool is an extension of the conventional process-modeling tool for BPMS. The ontology information constructed through the u-health ontology manager is merged in the processmodeling tool with service recommendation mechanisms. With service and data ontology, the service recommendation mechanism becomes the basis for a semi-automatic u-health
service design for medical experts. For the complete support for medical experts to develop their own services without programmers’ help, we need to define a complete and systematic u-health service development process. The mobile u-health service scenario shown in Fig. 1 is the starting point for the definition.
4.
Implementation and evaluation
We implemented TFIE-MUSS comprising the DCAP matrixbased prediction system, a communication server, a portal server and a client for a cellular phone. The client is deployed
Fig. 7 – Layered structure of THE-MUSS.
c o m p u t e r m e t h o d s a n d p r o g r a m s i n b i o m e d i c i n e 9 7 ( 2 0 1 0 ) 178–188
on a SAMSUNG BlackjackTM cellular phone with Windows CE that supports wired and Bluetooth [15] wireless communications with mobile sensors. THE-MUSS deals with various components such as biosensors, gateways, cellular phones, and service modules to support the construction of service processes. The functions, modules, and facilities described in this paper are developed and deployed in the layered architecture of THE-MUSS. Fig. 7 shows the layered structure of THE-MUSS. As illustrated in Fig. 7, essential primitive services for the design of complete u-healthcare services are developed in the form of Web services. The services are registered using the ontology-based BPMT in the process layer. Vital signal capturing, questionnaire design, vital signal and questionnaire input data analysis, diagnosis result delivery, and user feedback processing are currently available as primitive services in the component layer. Since rich sets of primitive services are essential for the construction of rich sets of service scenarios, we need to continue stacking more primitive services on THE-MUSS. Several filtering modules that receive vital signs from designated sensors are implemented, and the interfaces for calling the modules are registered in the form of Web services in THE-MUSS. Access to the obtained vital signs is performed by calling the registered interfaces. THE-MUSS provides UIs for doctors and medical experts to select sensors and the type of vital signs, and the actual invocation of the Web services and vital signal data capturing is then done by THE-MUSS. For the support of a questionnaire design, THE-MUSS provides a design facility for doctors and medical experts to develop questionnaires. Since the questionnaire design facility is implemented in the form of Web services and the underlying layers support the incorporation of Web services in a process, the designed questionnaires are easily incorporated within a u-health service process. Users access the designed questionnaire and provide input into the service process. Two mobile u-health services were developed on THEMUSS to confirm and evaluate its usefulness. One is a mobile stress management service and the other is a mobile weight management service. DCAP and questionnaire facilities were actively used for the development of the stress management service. The mobile weight management service was developed in a similar manner to the stress service except for the diagnosis part. A Baysian network [17] is used instead for diagnosis because we understand the weight management better than the stress management. Most parts of the stress service, such as capturing, delivering, and processing bio-signals, are reused in the weight management service, and only small parts of the service are added and modified to the stress service because the service structures of stress and weight management are similar to each other.
5.
Conclusion
In this paper, we developed a mobile u-health service system, THE-MUSS. The system supports the development and running of u-health services with functions, modules, and facilities that are commonly required for various mobile uhealth services. We identified u-health service characteristics
187
to elicit reusability and evolvability as its primary design goals. We developed several core components for THE-MUSS, which are integrated into its architecture. THE-MUSS is unique in the sense that it adopts BPMS as its underlying platform, provides a DCAP matrix-based prediction framework and ontology incorporated u-health service design tool, etc. In addition, the u-health service scenario template in THE-MUSS provides a guideline to uhealth service developers. Service developers can modify or extend the service scenario to develop their own u-health services. We confirmed that THE-MUSS is practically useful in developing mobile u-health services by developing mobile stress and weight management services on THE-MUSS. However, THE-MUSS is not a complete system yet, and it is still evolving toward a full-fledged u-health service system. The more u-health services are developed on THE-MUSS, the better services THE-MUSS can provide. There is some pending work to make THE-MUSS more secure and reliable. We are currently pursuing supporting a secure personal healthcare data management and enhancing the performance by adopting advanced techniques and mechanisms to exchange messages between mobile devices and a u-health server.
Conflict of interest There is no conflict of interest.
Acknowledgements We would like to thank Professor Inyoung Ko and Professor Daeseok Kim of Korea Advanced Institute of Science and Technology (KAIST) and Dr. Suntae Chung, Dr. Jaegul Cho, and Dr. Cheolho Cho of Samsung Electronics Ltd., for providing invaluable comments and advices for this research for over the past 3 years. We are grateful to the members of Intelligent Service Integration Laboratory of KAIST who participated in the implementation of THE-MUSS. This work is supported by Samsung-KAIST joint research center, and partly by the Ministry of Education and Science Technology (MEST) of Korea and Korea Industrial Technology Foundation (KOTEF) through the Human Resource Training Project for Regional Innovation.
references
[1] R.S.H. Istepanian, S. Laxminarayan, C.S. Pattichis (Eds.), M-Health: Emerging Mobile Health Systems, Springer, 2005. [2] R.S.H. Istepanian, E. Jovanov, Y.T. Zhang, Guest editorial introduction to the special section on M-Health: beyond seamless mobility and global wireless health-care connectivity, IEEE Transactions on Information Technology in Biomedicine 8 (4) (2004) 405–414. [3] J.M. Quero, C.L. Tarrida, J.J. Santana, V. Ermolov, I. Jantunen, H. Laine, J. Eichholz, Health care applications based on mobile phone centric smart sensor network, in: Proceedings of the 29th International Conference on Engineering in Medicine and Biology Society, August, 2007, pp. 6298–6301.
188
c o m p u t e r m e t h o d s a n d p r o g r a m s i n b i o m e d i c i n e 9 7 ( 2 0 1 0 ) 178–188
[4] D. Han, I. Ko, S. Park, An evolving mobile e-Health service platform, in: Proceedings of the IEEE International Conference on Consumer Electronics (ICCE 2007), USA, January, 2007, pp. 337–338. [5] H. Smith, P. Fingar, Business Process Management: The Third Ware, Meghan-Kiffer Press, 2003. [6] F. Leymann, D. Roller, M.T. Schmidt, Web services and business process management, IBM Systems Journal 41 (2) (2002). [7] W.M.P. van der Aalst, A.H.M. ter Hofstede, M. Weske (Eds.), Business Process Management, Lecture Notes in Computer Science, vol. 2678, Springer-Verlag, Berlin, 2003. [8] M. Uschold, M. Gruninger, Ontologies: principles, methods and applications, Knowledge Engineering Review 11 (2) (1996). [9] K.E. Wiegers, Software Requirements, 2nd ed., Microsoft Press, 2003. [10] D. Han, S. Song, J. Koo, WebVine Suite: a web services based BPMS, Lecture Notes in Computer Science 3841 (2006).
[11] S. Mitra, S.K. Pal, P. Mitra, Data mining in soft computing framework: a survey, IEEE Transactions on Neural Networks 13 (January (1)) (2002). [12] U. Fayyad, R. Uthurusamy, Data mining and knowledge discovery in databases, Communications of the ACM 39 (1996) 24–27. [13] J.P. Shim, M. Warkentin, J.F. Courtnay, D.J. Power, R. Sharda, Ch. Carlsson, Past, present, and future of decision support technology, Decision Support Systems 33 (2002) 111–126. [14] R. Duda, P. Hart, D. Stork, Pattern Classification, 2nd ed., John Wiley & Sons, Inc., 2001. [15] M.F.A. Rasid, B. Woodward, Bluetooth telemedicine processor for multichannel biomedical signal transmission via mobile cellular networks, IEEE Transactions on Information Technology in Biomedicine 9 (1) (2005) 35–43. [16] D. Han, H. Kim, W. Jang, S. Lee, S. Jung, PreSPI: a domain combination based prediction method for protein–protein interaction, Nucleic Acids Research 32 (21) (2004) 6312–6320. [17] F.V. Jensen, Introduction to Bayesian Networks, 1st edition, Springer-Verlag New York, Inc., Secaucus, NJ, USA, 1996.