body area network.pdf

Copyright © 2004 Freeband AWARENESS project partners

Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective

works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from or via AWARENESS

Project Management (http://awareness.freeband.nl).

D4.7: Modelling of Body Area Networks

From Technologies to Models to Components

Tom Broens, Aart van Halteren, Val Jones, Boris Shishkov, Ing Widya

{broens, halteren, jones, shishkov, widya}@ewi.utwente.nl

University of Twente

December 2005

Freeband/AWARENESS/D4.7

http://awareness.freeband.nl

Keywords: Body Area Network, Model, UML, SDBC

Abstract:

This paper describes a conceptual model of a Body Area Network (BAN). With this model we aim

to provide a design for BAN management functionality. We take a top down approach using

currently available modelling techniques. We develop higher level technology independent models

which are the basis for implementation. The final part describes a prototype using the BAN model

as foundation.

Freeband/AWARENESS/D4.7 2

1 Introduction This paper discusses a conceptual model of a Body Area Network (BAN). In this section we start this discussion by providing the motivation and scope of this research, and showing the structure of the rest of this paper.

1.1 Motivation Advances in computer technology (for example, increased processing power and memory, low cost and miniaturisation of devices, explosion of types and number of applications) together with developments in communication technologies (e.g. GPRS, UMTS), has resulted in almost universal dependency of business and society on increasingly complex distributed systems. Additionally, wireless and mobile technologies have brought ubiquitous access: today we may access all kinds of systems from anywhere and at any time. To be able to manage the complexity of engineering and deploying these highly complex distributed and heterogeneous systems, we need to apply sound software engineering principles at all stages of the software lifecycle. One method for managing complexity and do reasoning is to capture the design about it by using modelling techniques.

The AWARENESS project aims to exploit the evolutions in computer science and develops a service infrastructure that supports context-aware and pro-active applications. Telemonitoring and teletreatment applications are used to show the added value of context awareness. At the centre of telemonitoring and teletreatment applications is the Body Area Network (BAN), which is a network of devices worn on, around and/or in the body. Examples of these BAN devices are sensors, actuators, front-ends and communication gateways.

Body Area Networks are complex systems which, for instance, deal with:

• Reading, storing, processing and transmission of health data coming from sensors.

• Control of actuators.

• Configuration of BANs for particular patients.

• Discovery of BANs, or BAN components, as they come online.

In the AWARENESS application infrastructure, we strive to help the application developer in creating m-health applications that need BAN management functionality. To be able to robustly implement these functionalities we need a model of a BAN as foundation.

A model is a simplified representation of a system that accounts for some of its known, inferred or desired characteristics while purposely abstracting from other characteristics with the intent to further study or define system characteristics [1].

This model should capture the invariants (i.e. never changing properties) of such a BAN to provide a realistic and robust building block for application developers. In this paper we develop a BAN model which is general enough for future developments, however, also practical enough to develop a useful building block for the AWARENESS application architecture (see Figure 1). For further details on the application architecture see AWARENESS deliverable D4.5 [2].


Container

Generic containerfunctions

Applicationcomponents

Domain specificfunctions

Service infrastructure

Network infrastructure

BANManagement

Healthcare manager Healthcare customer

Healthcareprofessional

Figure 1: BAN Management functionality in the AWARE NESS infrastructure

The technology used to realize the AWARENESS telemonitoring and teletreament applications is an evolution of the technology used in the MobiHealth project [3]. However, in the MobiHealth project the configuration of a BAN took place at deployment time [4]. As a result, once a BAN was handed out to a patient the configuration of sensors and other devices in the BAN was fixed and could not be configured at runtime. In addition, the MobiHealth technology uses an XML schema (the latest version of this schema can be found at: http://www.mobihealth.org/schema/BANDescription.xsd) that is closely tied to one specific set of sensors available from Twente Medical Systems International (TMSi).

In previous AWARENESS deliverables (D4.2 [5]), we considered the MobiHealth technology and took a practical approach to get some hands-on experience implementing a BAN configuration model for AWARENESS. Given that experience, we now take a more rigorous approach in this paper by first developing a model that will then be used to derive software components.

Summarizing, this paper describes a conceptual model of a Body Area Network (BAN). With this model we aim to provide a design of BAN management functionality. We take a top-down approach using currently available modelling techniques. We develop higher level technology independent models which are the basis for implementation. The final part describes a prototype using the BAN model as a foundation.

1.2 Scope The scope of this paper relates to the acquisition system used for collection of medical data from body worn medical sensors. The purpose of the acquisition part is to enable remote monitoring and assessment of patients by health care professionals. The patient assessment process can be analysed in terms of tasks and resources [6].

In general, a healthcare professional assesses a patient’s condition by considering data collected from different sources, by forming one or more hypotheses. By seeking further information (resources) the doctor narrows the hypothesis set to achieve the clinical task in hand (arrive at a diagnosis). In face to face consultations, initial data is gathered from observation of the patient, and consideration of the signs and symptoms the patient presents with. This information may be augmented with measurement of vital signs (e.g. ECG, EMG, EEG, temperature) or other physiological parameters and by ordering laboratory tests. The data is taken together with the medical history of the patient (the doctor may take a history or consult the patient’s health record, which may be an electronic health record (EHR), also known as electronic patient record (EPR). If measurements are taken the required set of physiological measurements depends on the clinical specialty and the task of the healthcare professional. This set contains coherent vital signs which together form a unit of healthcare interpretation, suitable to check the diagnostic hypothesis of the professional. That is, these signs may collectively indicate a certain medical condition of the patient. This


means that vital signs are in general (tightly) coupled and may have an order of importance when determining a diagnosis. However, acquisition of vital signs does not need to consider this coupling between signs. However, the acquisition of some of the components of a vital sign may be characterized by dependencies between these components, for example in the case of acquiring the signals from the several leads of an ECG.

Additionally, a patient may have multiple morbidities and may therefore be receiving treatment from different medical specialists. Each specialty may require its own set of vital signs suitable as resources for the medical tasks of that clinical specialty. Repeating vital sign measurement sessions for different specialists is inefficient, if, as is often the case, there is overlap in the required sets of measurements.

Figure 2, expressed in information processors and information flows, elaborates the previously discussed issues with a situation of a patient that is enrolled in three care programs: (i) Cardio-care of cardiologists of a care centre, (ii) Epilepsy and (iii) Pain-treatment care programs of a rehabilitation institute which shares an M-health portal with the care centre. The measured vital signs of the patient are for example ECG (5 leads), (s)EMG, Oxygen saturation (O2Sat), Blood pressure (BP), temperature and also the patient’s physical activity (e.g. walking, lying). These measured data will be transferred to and optionally processed at the M-health portal (left part of Figure 2). An m-health portal is a functional entity that transforms raw vital signs to signs relevant for the task of the specialist. This corresponds with the concept of back-end system used in the remainder of this paper (e.g. see Figure 7). When the specialist finds it convenient, he can retrieve the appropriate sets of measurements to use as resources in his assessment tasks (right part of Figure 2).

M-Health Portal 5-ECG, BP,O2sat, BP, EMG temperature, activity -movement, …

activity movement

ECG (5leads), O2sat, EMG, BP, temperature

pain-treatment-care: <EMG, movement,..>

cardio-care: atomic set : <5-ECG, BP,O2Sat, ..>

cardiologist

vital signs acquisition part

processing & communication

shared vital sign task-oriented part

specialty specific task-oriented part

patient

epilepsy-care: <3-ECG, EMG, movement>

neurologist

fysiotherapist

D4.7 scope

Figure 2: Acquisition of vital signs and vital sign s as task resources [7].

To further elaborate the difference between the task and acquisition process, we show a vital sign dependency model in Figure 3. This model reflects the different perspectives of vital signs: (i) the acquisition perspective (left side) and (ii) the task-resource perspective (right side).


Figure 3: Vital sign dependency model [7].

At the right side of the figure, the class TaskResource represents the resources needed for a medical task in respect of the care program (e.g. a diagnostic task of a cardiologist) [8]. The class t_VitalSignSet represents the set of vital signs required as task resource and is a compositional aggregation (i.e. black-diamond symbol at the association end-point) of the vital signs (t_VitalSign). At the left side of the figure, the class a_VitalSignSet represents the set of measured vital signs of a patient, which possibly is enrolled in several care programs. This class is a shared aggregation (white diamond symbol) since its existence does not depend on the completeness of the measured vital signs, represented by the class a_VitalSign. The association class Assignment specifies the filtering (i.e. the configuration makings) of vital signs that are considered (not) relevant as resource for the specialist’s task of the care program. Refinements and details of the UML class diagram shown in the figure can be found in [7].

The BAN model addressed in this paper focuses on the acquisition-oriented part of the model at the left side of Figure 2 and is closely related to the classes at the left side of Figure 3. We consider BAN models for the task-oriented part as future work.

1.3 Structure The rest of this paper is structured as follows:

• Section 2 presents three BAN application scenarios to get a feeling of the usage of BANS. The first two indicate the role that BANs play in telemonitoring and teletreatment applications. The third scenario indicates the subject of usage of our BAN model: configuration, instantiation and management.

• Section 3 gives a state of the art on BANs. It discusses the history of BANs and gives related work. The final section presents our definitions of BAN terminology.

• Section 4 discusses the business process modelling of BANs. This is the foundation for the further software model to ensure that the application-to-be, based on the model, operates according to the business environment in which it should be integrated.


• Section 5 discusses the developed BAN model. It presents high-level UML models together with some examples of instantiations based on the scenarios presented in chapter 2.

• Section 6 presents the developed prototype based on the BAN model discussed in chapter 5.

• Section 7 presents conclusions and future work.

2 BAN application scenarios This section describes three scenarios that clarify the role of BANs in telemonitoring and teletreatment applications. The first two (see section 2.1 and 2.2) show how BANs are used for monitoring and treating patients (patient-centric view). While the last one (section 2.3) focuses on how professionals use BAN (professional-centric view). Further, these scenarios are used as running examples throughout this paper. The first two scenarios are adapted from the scope and scenarios from AWARENESS [9].

2.1 Telemonitoring scenario Mr. Janssen is a 46-year-old man who suffers from epilepsy. Epilepsy is a disorder in which nerve cells of the brain, from time to time, release abnormal electrical impulses; so-called seizures. Caused by his illness, Mr. Janssen is unemployed, home-bound and has to make sure that someone is nearby to contact a healthcare professional in case of a seizure. Currently, Mr. Janssen wears a 24-hours seizure monitoring system (coined Epilepsy Safety System – ESS). This enables him to live a more normal life. He is wearing a body area network on which the ESS is running. He attached sensors such that the ESS can measure his vital signs. Further, Mr. Janssen is connected to the healthcare support network which can contact healthcare professionals. Recently Mr. Janssen found a job to which he is travelling this morning. Suddenly, the ESS detects a possible seizure. The ESS tells Mr. Janssen to stop his car at the side of the road. In this way, it provides more safety to him and possible bystanders. Further, a healthcare professional is notified to start monitoring his vital signs. Then Mr. Janssen experiences a severe seizure which the healthcare professional is witnessing remotely. The system searches for available healthcare teams and directs them to the location of Mr. Janssen such that they can help or even possibly safe his life.

2.2 Teletreatment scenario Jitske is a 28 years old woman with serious chronic complaints in her neck and shoulder. After consulting her specialist, she volunteered to take part in a new teletreatment programme. At a visit to the rehabilitation centre she received the portable equipment. This means a Body Area Network which consists of a garment with integrated sensors which can be invisibly worn under her clothes. A portable computer is connected to these sensors and is able to collect the biosignals, to process them and to send them to the rehabilitation centre. In addition Jitske gets continuously feedback about her health status and how she should behave. It provides her with crucial information how to behave in the tight balance between under activity and over activity which are both harmful may have negative consequences for her experienced pain intensity level. At the rehabilitation centre, the specialists are able to monitor her health status and to adapt her treatment according to her particular abilities and progress she is making.

2.3 ‘BANs in practise’ scenario Doctor Johnson is a general practitioner responsible for treating Mr. Janssen and Jitske. Therefore, he collaborates with a neurologist to treat Mr. Jansen, and a rehabilitation specialist to treat Jitske. As traditional treatment did not have the expected effect, both Mr. Jansen and Jitske are equipped with a BAN. Before the BAN can be made operational, Dr. Johnson and the other specialists have to decide the treatment plan. Based on the treatment plan, they have to determine the appropriate signs to monitor (i.e. assignment, see Figure 3). For Mr. Johnson this is a 5-lead ECG and activity sensor and for Jitske this is a 4-lead EMG and activity sensor. This is modelled in a BAN template for epilepsy and chronic pain monitoring. A nurse is instructed to position the sensors correctly on the patient’s body and activate the


acquisition system. Both the nurse and the doctor complement the corresponding template of the patient’s disease with patient specific information (e.g. name, base heart rate etc). Remotely the monitoring session can be started and stopped and the vital signs can be viewed. Also, the doctor can change the patient specific parameters like increasing the sample frequency when it is needed for a better treatment.

3 State of the Art in Body Area Networks This section gives a general overview of BANs. It discusses the history of BANs and BAN concepts as used in this paper and AWARENESS in general. Section 3.1 discusses previous work on BANs and also illustrates some of the different ways of defining BANs. Furthermore, it gives reasons for distinguishing BANs from Personal Area Networks (PANs). Section 3.2 presents a description and definition of BAN concepts as used in the AWARENESS project and in the remainder of this paper. Section 3.3 shows how AWARENESS extends the work on BANs and the BAN service platform in new directions not addressed by our predecessor, the MobiHealth project [3]. Section 3.4 discusses the reasons for applying a modelling approach in the further development of Body Area Networks and the BAN service platform within the AWARENESS project.

First, we show in Figure 4 a simple schematic diagram of a Body Area Network, illustrating that a BAN consists of a number of communicating devices worn on the body. The devices within a BAN may be of different kinds. As well as communicating among themselves, the BAN devices may communicate externally, usually via wireless links.

Figure 4: a BAN is a network of body worn devices

3.1 Previous work on Body Area Networks The concept of Body Area Networks (BAN) arose out of recognising the possibilities offered by combining several technologies: short-range and long-range wireless communications, miniature wearable (or pocketable) computing devices (PDAs and mobile phones) and other wearable devices such as MP3 players and medical sensors. Historically, the concept was first discussed under the topic of Personal Area Networks (PAN) and only later distinguished by a separate term Body Area Network. The most important communications standards for PANs and BANs are Bluetooth, the IEEE 802.11 Wireless LAN standard, IEEE 802.15 Wireless Personal Area Network (WPAN) standard and Zigbee.

First it may be helpful to give a short explanation of Personal Area Networks. A Personal Area Network is a network of devices which are used by an individual. The devices are fairly close to the person. A PAN is usually taken to be wireless, although IEEE’s qualification of Wireless PAN implies the possibility of wired (or partially wired) PANs. A typical application of a PAN would be communication between the devices someone might use in their (home) office, such as a computer, printer, phones and fax machine, wireless audio, keyboards and mice. Several different definitions of PANs have been made. PANs may be defined by (i) distance or range (some sources cite tens of feet, or even more specifically, 10m) or by (ii) bandwidth (with PANs distinguished by having a lower data rate than WLANs) or by (iii) usage (a PAN is a network of devices used by a person).

One problem with the first and second options for defining PANs (by range or bandwidth) is that the limits are arbitrary or technology specific and new technologies will alter the boundaries. For example, with use of UWB the prospect of high data rate PANs opens up, and the distinction between PANs and LANs because of data rate blurs. The problem with the third way of defining PANs, that is by usage, lies in the


problem of how to define a person’s ownership of devices, for example in a home or office where some of the devices and appliances may be shared, leading to overlapping PANs.

BANS also relate to a single individual user but are in some sense ‘smaller’ than PANs and relate to the body of the user. In the next sections, we will see that there are also other ways of defining BANs.

Work at MIT and IBM

Zimmerman is credited with inventing the concept of Body Area Networks based on his work at MIT Media Laboratory in collaboration with Mike Hawley and Neil Gershenfeld, and later at IBM [10, 11]. In [11] he discussed the combination of “portable computing devices” and wireless short-range links as providing “a new paradigm for computing and communication”. This article is about Personal Area Networks (PANs), but he discusses combining devices worn or carried on the body with wireless personal area networks. In one example of a PAN he refers to his work with Gershenfeld on a “PAN” which uses the body itself as a wireless transmission medium for information. He says “electronic devices placed on and near the body modulate an electric field that induces small currents throughout the body.” Communication between individuals can be made by direct touch or by close proximity (within 2 m) and can be established through touch or handshakes. In [10] he had already described one application of this technology namely the exchange of electronic business cards via a handshake. He proposed that the” PAN” device be mounted in a shoe. This solution “provides low impedance paths from the device to the body and to the ground” and permits self-powering of the “PAN” by kinetic energy generated by walking. Zimmerman thus referred to the concept of BANs as far back as 1996, without however using the term BAN. He gives the range of a PAN as 10m (coinciding with the range of certain Bluetooth profiles).

Philips and Zigbee

Philips and other partners developed the Zigbee standard [12] to support low power, low cost, reliable short range communications. Zigbee was intended to interoperate with IEEE 802.15.4 and was seen as especially applicable for wireless sensor networks and control applications and for PAN and BAN communications in general. Different groups within Philips have participated in PAN and BAN research in the context of the WWRF and a number of projects including MobiHealth and BASUMA [13]. Range is defined as 2m, to accommodate the tallest wearer! Philips are one of a number of companies who are currently integrating BANs into clothing and bringing products to the market in the areas such as entertainment and health monitoring (‘intelligent biomedical clothing’) and for communication functionality for specific industry groups (eg. Industrial Clothing Division’s ICD+).

WWRF

From the initiation of the Wireless World Research Forum in 2001, WWRF members, including Philips [14] and University of Twente [15, 16] were working, amongst other things, on research into PANs. The multisphere model of wireless communications in the first version of the WWRF Book of Visions [17] showed PANS as the innermost sphere, nearest to the user. Work by Philips and University of Twente brought the term BAN into the picture and the PAN-BAN distinction was introduced the following year into the Book of Visions. There Jones and Bults defined a BAN as “a collection of (inter) communicating devices which are worn on the body, providing an integrated set of personalised services to the user” [17].

University of Twente

Thomas Zimmerman’s definition related to the use of the body as a ‘conduit’ for information. At the University of Twente Jones et al proposed an alternative definition of a BAN: “We see a BAN as a network which is literally worn on the body, as opposed to a PAN (Personal Area Network) which links devices close to the user but not necessarily (all) physically worn by him” [18]. In other words, the wearer is the unit of roaming. This pragmatic definition of a BAN relates only to physical location on the body, in contrast with Zimmerman’s and others’ definition of a BAN as using the body as a transmission medium. Furthermore we focus on BANs in healthcare applications since they provide the basis for total mobility for the patient. In a PAN at least some of the devices are part of a fixed environment and therefore the user may only use the PAN while they are in that environment. In a BAN all the nodes in the network are on the body of the user, therefore the whole network moves around with the user.


An architecture for a generic BAN was developed prior to the start of the MobiHealth project. In [18] we had described a BAN as consisting of a network of devices which, as well as a “hub”, might include sensors, audio video devices and actuators. The “hub”, later named MBU (Mobile Base Unit), takes care of computation and communication functions. Sensors measure some physical value (e.g. temperature or pressure) whilst actuators have some mechanical or electromechanical effect (e.g. operating a pump or a valve). In early modelling efforts this was expressed mathematically as:

BAN = pair(MBU, set(Device))

Device = Sensor | Actuator | MMDevice|…

This has to be read as “a BAN consists of an MBU and a set of devices, where Sensors, Actuators and MM-device are sub classes of Device”. This early definition of an abstract BAN hardware configuration does not explicitly include communication channels.

The generic BAN concept was specialized for the healthcare domain to give the concept of a generic health BAN. First applications explored were a trauma patient BAN, a paramedic BAN and a BAN for homecare for patients recovering from trauma. These represent further specialisations of a health BAN. This vision of BANs applied to healthcare applications was developed as concept before the beginning of MobiHealth. Later the concept was realised in the form of a prototype system when the MobiHealth project began in May 2002. Development of the BAN and supporting system by the University of Twente and partners was followed by a number of specializations of health BANs for different clinical applications during the course of the MobiHealth project [3, 8, 16, 19, 20].

Fraunhofer

Fraunhofer exhibited their BAN at CeBIT in 2002. They describe a BAN as “a system which surrounds the patient with an aura of data" [21] and define BANs as having exclusively wireless IntraBAN communication. “Body Area Network is standing for wireless communication between various components attached to the body, such as data spectacles, earphones, microphones or sensors” [22].

Medical applications include in-hospital telemetry for intensive care patients. The advantage there is to avoid the inconvenience of wired systems which can get entangled when the patient moves in their sleep; as well as being uncomfortable this can trigger alarms. Please see [23] for more information.

Other work

There is a huge literature on work related to BANs. Here we mention some interesting examples.

Over the past few years there has been much work in the healthcare domain on telemonitoring applications using wearable communicating devices. Although in many cases these applications are similar to Body Area Network not all of these developments make explicit reference to this term. In some cases they refer simply to remote telemonitoring. Other related terms are: HAN (Human Area Networks), IBN (Intra Body Networks) and as we have already seen, Zimmerman talked about Intra-Body Communication in the context of PANs. These are not domain specific terms but in most cases healthcare is among the application areas cited.

The term Intra Body Networks has been used (e.g.[24]) to mean a BAN where all the devices are implanted and communicate wirelessly through tissue with an external PDA .

NTT used the term Human Area Networking to refer to the same concept as Zimmerman’s, namely body worn networks using of the electric field emitted on the surface of the human body as a high-speed intra-BAN transmission path [25]. Data is transmitted over the surface of the human body at speeds up to 10 Mbps between any two points on the body. The transmission starts as and when Extra-BAN transmission paths are established via special transceivers, e.g. when the person touches a surface or device in the environment carrying a transceiver. Transceivers can be embedded in doorknobs, appliances, floors etc. or embedded in devices carried by the person. Thus the human body becomes a physical transmission path within a human centric LAN (yielding another definition of PAN?). Example medical applications cited include: Alert and contact records at medical, long-term care, and childcare facilities; and preventing a patient accidentally taking the wrong medicine. If the user touches the wrong medicine pack, an alarm is triggered on the terminal he is carrying.


These kinds of devices have been dubbed “Wrist Ware”, reminiscent of the so-called Wrist-Worn Device of the AMON project, which could be described as an early specialty-specific body worn monitoring device for cardiac patients and as such a precursor of health BANs. In AMON we see a body worn device which incorporates several sensors into one device so it cannot strictly be called a BAN as no network is involved (unless we include single node networks as networks…).

Another group in Italy is working on a similar concept to MobiHealth and AWARENESS, focusing on network and middleware layer support for sensor networks used for remote monitoring of mobile patients. Information from a body worn sensor network is transmitted via an external network such as the patient's domotic network to a hospital network [26].

A further networking innovation to consider in relation to BANs is Mobile ad hoc networking (MANETs). (See the book by Conti referenced at [27]).

3.2 The AWARENESS Body Area Network In AWARENESS, the starting point for Body Area Networks is the MobiHealth BAN system. Our initial definition of a generic BAN in the AWARENESS corresponds and is: “a network which is literally worn on the body”. Further, “a BAN incorporates a set of devices which perform some specific functions and which also perform communication, perhaps via a central controlling device. Devices may be simple devices such as sensors or actuators, or more complex multimedia devices such as cameras, microphones, audio headsets or media players such as MP3 players. The central controlling device (the MBU) performs computation, coordination and communication functions. Communication amongst the elements of a BAN is called intra-BAN communication. If the BAN communicates externally, i.e. with other networks (which may themselves be BANs), this communication is seen (from the point of view of the BAN itself) as extra-BAN communication" [28]. Figure 5 shows the architecture of the AWARENESS/MobiHealth BAN.

Figure 6 shows the components used in one of the MobiHealth BAN configurations, namely electrodes for measuring ECG, an activity sensor and a sensor front end (the gray box). Here the MBU is implemented on a PDA – a Compaq iPAQ.

��

��

��

��

��

��

��

��

��

��

Figure 5: BAN architecture Fi gure 6: Some BAN components

The BAN operates in a service environment with two main categories of users: the patient users and the professional users. Patients are equipped with Body Area Networks which are customized to their needs. A patient wearing a BAN has a set of services available to them, varying with their current set of needs and their clinical conditions(s). Some of the services may be transparent to the patient and fully automatic (e.g. telemonitoring, automatic alarms) others are patient driven (e.g. patient initiated alarms). Some patients may be unable to interact with the BAN at all (e.g. a patient with dementia or an unconscious patient). Patients’ families and other members of their informal network of carers may also be involved but can be classed as patient users. Patient BANs may have many different specialisations having different functionality sets, hardware and applications.


The professional users are the consumers of BAN captured data such as biosignals and alarms. They may be health professionals or other categories of professional care providers. The (health) professional/(health)care provider interacts with their patients’ BANs via a client running on their own professional system. The client gives access to BAN specific services. In future the health professional systems may also exchange BAN data with the healthcare provider’s system such as a GP practice administrative system or clinical information system (CIS) or a Hospital Information System (HIS), possibly including linking to the EMR. The health professional’s system may itself be a mobile system (e.g. running on a laptop or PDA.) Services for professionals include access operations (e.g. retrieving and viewing biosignals) but also control operations such as remotely activating a BAN, or a BAN device, or altering sampling frequencies of sensors.

The BAN services are supported by a BAN server known as the Back End System. Together we refer to the BANs and the Back End System as the BAN system.

The BAN system

A great many individual patient BANs and professional BAN systems may be in operation out in the field at any time. These components are supported by a server which knows about management of BANs and BAN applications and mediates between the patients and the professional users. We refer to this server as the BAN Back End System BESys. Together the BANs and the BESys comprise a distributed system which we refer to as the BAN system. Communication between the components is effected by communications channels. At the most abstract level we do not distinguish further (e.g. into wired/wireless channels). Figure 7 illustrates these components. The components to the right hand side of the dotted line are in the domain of the healthcare provider and are outside the scope of the BAN system, but interface to it.

Figure 7: Physical components of the BAN System and its interface to the healthcare service provider domain.

In the next section we examine the main differences between the MobiHealth and AWARENESS projects and show how AWARENESS addresses important aspects which were outside the research domain of the MobiHealth project.

3.3 Innovation in AWARENESS BAN development The objective of the MobiHealth project was to explore the potential of 2.5 and 3G technologies to support useful mobile applications and services. It was therefore a communications project rather than an ehealth project per se. Mobihealth chose to perform this exploration of 2.5/3G technologies in relation to the domain of healthcare. The outcomes of the project included a prototype BAN (several variants for different clinical applications) and a prototype system to support a population of BANs in the field. Several

Patient BANs

Health Professionals’

mobile systems

BAN Back End System (BESys)

Health call

centre

Hospital

MBU

BAN System Access Systems

BAN


development cycles were completed and the system was used and evaluated by patients and health professionals during a series of multi-centre trials. Development of end user applications was not an objective of MobiHealth, although of course some application functionality had to be developed in order to conduct the trials. In contrast the AWARENESS project aims to research and design a service and network infrastructure to support context-aware and proactive mobile applications. In relation to further development of BANs and the BAN system, the AWARENESS project goes beyond the goals of MobiHealth by:

• focusing on application development rather than on wireless communications.

• adding context awareness to enable intelligent applications.

• extending the portfolio of clinical applications to include epilepsy, spasticity and management of chronic pain.

• addressing not only telemonitoring but also teletreatment.

• re-engineering with attention to software engineering methodologies utilizing modelling.

In the next section we examine the motivation for the use of modelling in AWARENESS.

3.4 Motivation for the use of modelling The modelling activity described in this paper is part of the systematic software engineering methodology being applied in AWARENESS. The use of modelling in design and development is aimed at making the design process clear, formal, explicit and transparent such that high quality components may be designed and integrated and so reuse may be facilitated. High-level modelling at an abstract level allows a generic design and architecture to be developed. High-level models may then be refined towards conformant implementations. The high level design, because it is a technology independent model, is also intended to be future proof and to be re-used in future evolutions of the BAN and BAN system. Modelling also enables reasoning about the design in a platform independent way and formal expression of designs enables testing of equivalence between the models and the many possible implementations now and in future, even if different technology platforms are used. The following sections describe our BAN modelling efforts. The scope of the modelling effort in this paper is the BAN, specifically the acquisition system. However we first discuss the overall system and the business model.

4 Business Process Modelling Among the challenges concerning current application development is the (frequently observed) mismatch between the original (business/user) requirements and the actual functionality of the delivered application [29]. We actually observe two opposite phenomena [30]: either software is designed without prior adequate consideration of the business processes to be supported by it, or business-modelling-driven software specification takes place where the business modelling output is inadequately transformable into an input for the specification of software.

Therefore, the two tasks: the business process modelling and the specification of applications for the support of the business processes, need to be better aligned. They should be considered as one integrated task [31].

This is particularly valid for the modelling of Body Area Networks (BANs). Since, as discussed in previous chapters, a BAN comprises hardware, software, netware, and middleware aspects which are to be coherently reflected in models that are consistent with the BAN’s business environment.

For brevity, we will not discuss in detail some hardware/netware/middleware issues (we will refer readers instead), putting the stress on the essential BAN-related challenges in specifying the BAN software-driven automation.

Therefore, this section will firstly elaborate on the difference between business process modelling and software specification (section 4.1), secondly consider a relevant business-software alignment approach (section 4.2), and finally we will build a business process model of the BAN, using that approach (section


4.3), and reflect it (on high level) in corresponding (BAN-related) functional blocks (section Error! Reference source not found. ).

4.1 Business Process Modelling and Software Specifi cation It is widely acknowledged that:

• business process modelling is about the business context in which the software application-to-be would operate.

• software specification is about the functionality of the application.

Both these aspects are usually considered from three perspectives, namely structure, dynamics, and data:

• What are the statics of the system under study (entities and their inter-relationships)?

• What are the dynamics of the system under study (the events flow)?

• What are the data types and instances concerning the studied system?

However, software systems are not as simple as they were 10 years ago and it is therefore essential to properly integrate them within the broader business context. In order to achieve this, we need a sound business process modelling background. With respect to this, we argue that the semantic and pragmatic richness of a business system could not be grasped just by considering entities, events, and data.

Information, for example, is insufficient as a modelling notion since usually meanings are based also on signs [32]. Consider a bank note. It is actually more than just coloured paper with digits on it. It stands for a person’s ability to pay, for the authority of an issuing institutions, and so on. Thus, reflecting only the information would lead to significant loss of modelling representativeness.

Further, the way in which entities relate to each other in reality is also much more complex than often modelled. The Semantic Analysis Method [32] indicates on this and relates agents/roles on the basis of their affordances (this is a term coined by Gibson [33], which indicate the characteristics of an object or device that present its uses) – abilities of conducting particular behaviour patterns. To illustrate: a book affords to be borrowed (in the context of a library). We have a potential for a behaviour pattern. If realized, it creates other such potentials – a borrowed book affords to be returned. And again, if we follow modelling steps that lead to oversimplification of such issues, we would ignore, for sure, essential information concerning the business context.

And finally, the language and actions should be grasped adequately. We argue that language is not only used for exchanging information, as in reports, for example, but also to perform actions, as in promises and orders, for instance [34]. If we consider the delivery of a pizza to a client, it is obvious that it is insufficient capturing only the fact that a pizza has been delivered; it actually might be that negotiations had taken place prior to this fact: ‘We are closing now, only Prosciutto is possible, is that OK?’; ‘Yes, it is OK’; ‘Here we go, this is your pizza’; ‘No, Sir, in my opinion it is insufficiently baked, could you put it for several more minutes in the oven?’, and so on. Hence, we cannot oversimplify such issues because our application would need to adequately operate in a business environment.

For this reason, we consider also the so called ‘Communication perspective’ – which is about the semantics, pragmatics, and related communication actions. This perspective concerns the business process modelling and (although) partially - the software specification. In software systems, we have rules rather than real-life communication. However, in order to adequately base a software specification on a business process model and also to allow for a proper integration of the application-to-be in its corresponding business environment, we have to keep (even in our software specification and realization) attention on the semantic/pragmatic/communication aspects, as above discussed. All this is summarized in Figure 8:


�

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

√√√√ √√√√ √√√√ √√√√

��

√√√√ √√√√ √√√√ √√√√

Figure 8: High-level modelling perspectives [30]

About the software specification layer, we have one additional perspective, however. This perspective does not concern the business process modelling background and for this reason is not depicted in the figure above. It is the Realization perspective (user requirements and design constraints).

Further, taking a slightly different vision on the Business process modelling layer, considering it as concerning the environment of the application-to-be rather than a source of deriving its structure and behaviour, we identify another perspective, namely the ‘Business context perspective’. Hence, we arrive at Figure 9 that depicts the specification viewpoints of a software (application) component.

software application/component

statics

dynamics information

communication

realization context

Figure 9: Specification viewpoints of an applicatio n component

Our viewpoints are thus:

• Statics: entities and their interrelationships.

• Dynamics: events flow, provided/required interfaces with constraints and coordination-related aspects.

• Information: semantics, statics, and dynamics of information the component deals with.

• Communication: related communication actions which concern semantic and pragmatic aspects.

• Realization: user-defined requirements and technology (project-driven) constraints.

• Context: purpose, scope, and policies of the system in context as well as issues on integration of the application-to-be in its business environment.

The viewpoints ‘Information’ and ‘Context’ are marked because we present them in a way which is consistent with the way in which ODP considers the so called ‘Information’ and ‘Enterprise’ viewpoints, respectively. However, in addition to our perspectives, ODP considers also implementation-related perspectives. For this reason, the ‘Engineering’ and ‘Technology’ viewpoints in ODP partially overlap with the ‘Realization’ viewpoint on Figure 9. Hence, for the purpose of this paper, we propose to consider an integrated realization + implementation modelling layer that addresses: the issues specified in the


‘Realization’ viewpoint on Figure 9; the distribution of system components (if we view our component as a system); the implementation mechanisms and constraints.

Therefore, we propose the following viewpoints in the paper:

• Business process modelling viewpoint.

• Statics viewpoint.

• Dynamics viewpoint.

• Information viewpoint.

• Realization & Implementation viewpoint.

Actually, because of their indirect influence on the software specification activities (Figure 8), the communication aspects have their indirect effect within the business process modelling viewpoint; thus, we have put together ‘context’ and ‘communication’, forming a Business process modelling perspective. This is illustrated in Figure 10:

c o m p o n e n t

dynamics

realization & implementation

information

business process modeling

statics

Figure 10: ��

The Business process modelling viewpoint is highlighted because it is being addressed in the current section. As already discussed, in a business process study, we would provide structural/dynamic /factual/communicative elicitation regarding the environment in which the application-to-be is to operate. The Static viewpoint as well as the Dynamics viewpoint and the Information viewpoint are highlighted as well because, by considering at the business process modelling level the statics, dynamics, and information aspects, we would achieve the actual foundations of the software application-to-be. ‘Information’ is not bold on the figure, indicating that we will not elaborate on information modelling aspects in this paper. The reason is that another AWARENESS deliverable is eliciting this [35]. A possible approach for accomplishing this is the SDBC approach. It is going to be considered in the following section as the approach of our choice not only because it soundly aligns business process modelling and software specification, but also because of its consistency with current relevant design methods and techniques, referred to as 'Generative Programming (GP)’ [36].

4.2 The SDBC Approach The SDBC approach concerns a business process-modelling-driven software specification; SDBC stands for Software Derived from Business Components. Introducing the approach is beyond the scope of the current paper; for information about SDBC interested readers are referred to [30]. Nevertheless, we will just mention the 4 essential SDBC fundaments:

• Integrated view over business process modelling and software specification.

• Business process modelling embracing the communication perspective (see the previous section).

• Component-based business-software alignment.


• Re-use.

However, we will use SDBC only partially in our current work. We will benefit from the approach, in particular, in building up a sound foundation for the further application design (addressed in the following section). We will briefly present the approach outline below.

Outline of SDBC

The outline of SDBC will be presented with the help of Figure 11. We have used the following abbreviations there: bc – Business Component (a business sub-system that comprises exactly one business process); bk – Business CoMponent (a model of a Business Component, which is elaborated in terms of structure, dynamics, communication, and data); glbk – general Business CoMponent (which is re-usable by extension); gcbk – generic Business CoMponent (which is re-usable by parameterization); ssm – software specification model; sc – Software Component (an implemented piece of software, representing a part of an application); sk – Software CoMponent (a conceptual specification model of a Software Component). For more information on these concepts, the reader is referred to [37].

Figure 11: The SDBC approach – outline [30]

The figure shows that SDBC is about a business-process-modelling-driven specification of software. The starting point is a consideration of a business system. Business Components are identified from it. This is done by applying an OS-driven analysis [32] leading to the derivation of the so called ‘SCI modelling output’ [30, 31]. The Business Components should be then reflected in corresponding Business CoMponents, in supplying an adequate modelling foundation for the further software specification activities. Another way for arriving at a Business CoMponent is by applying re-use: either extending a general Business CoMponent or parameterizing a generic Business CoMponent. DEMO [38] and other LAP-driven modelling tools [34] are relevant as far as Business CoMponents are concerned. Each Business CoMponent should be then elaborated with the domain-imposed requirements, for the purpose of adding elicitation on the particular context in which its corresponding Business Component exists within the business system (from which it has been identified). Then, a mapping towards a software specification model should take place, driven by a DEMO-UML transformation mechanism [29, 30]. The mentioned requirements as well as the user-defined requirements are to be considered here, since the derived software model should reflect not only the original business information but also the particular user demands towards the software system-to-be. The (UML-based) software specification model [39] would then need a precise elaboration so that it provides sufficient elicitation in terms of structure, dynamics, data, and coordination [31, 37]. The model needs also to be decomposed into a number of Software CoMponents reflecting functionality pieces. Then these Software CoMponents are to undergo realization and implementation, being reflected (in this way) in Software Components. The final set of components might consist of such components which are implemented (using software component technologies, such


as .NET or EJB, for instance) based on corresponding Software CoMponents and (possibly also) such components which are purchased. Finally, the (resulting) component-based application would support informationally the target business system, by automating something that concerns the initially considered Business Component(s) identified from the system.

Modelling process

We will partially re-use the design trajectory proposed in [30], according to which:

• We first conduct an information structuring and requirements study.

• On this basis, we identify a multi-aspect Business CoMponent; in our case this would be the BAN Business CoMponent elaborated just in terms of structure and dynamics.

• We elaborate these (in our case structural and dynamic) business process models with the user requirements (which often do not relate directly to the business modelling foundation) and the design constraints (which are usually project-driven).

• We reflect these inputs (the business process modelling input, the requirements input and the design constraints input) in the derivation of corresponding software specification models, in this case these are to be static and dynamic software specification models; however, since such behavior aspects are considered by AWARENESS and A-Muse together (in studies on aligning SDBC and ISDL), we are going to address in this paper just the software specification statics, which would be expressed in the notations of UML (see the next chapter).

• An finally, we face the realization and implementation (Chapter 6).

4.3 Modelling the BAN Following SDBC, and relying also on other relevant theories and tools, such as DEMO, Petri Net, LAP, Semantic Analysis, and so on, we will apply the above outlined modelling process, by limiting ourselves to just the identification of the BAN Business CoMponent, elaborated in terms of statics and dynamics.

Hence, our first task is to identify roles – as the output of our initial business/requirements analysis.

Roles

We identify user roles and technology roles. The user roles include Patient and Carer. Carer includes Health Professional (further categorised as doctor, nurse etc) and Informal Carer. Figure 12 shows possible distributions of user roles related to the high level system components shown in Figure 7.


Figure 12: Business User Roles

We can see from Figure 12 that at certain times the health professionals may be co-located with the patient (eg a home visit by a nurse) or they may be monitoring their patient remotely, either from a fixed healthcare location such as a hospital, or when they are on the move and equipped with a mobile system. The User roles and some of the associated functionalities are listed below.

User roles:

• Patient (be monitored, start BAN, stop BAN, press alarm…).

• Nurse (fit BAN(co-located), verify operation of BAN, view BAN data (co-located or remotely located), start BAN, stop BAN, press alarm…).

• Doctor (fit BAN (co-located), verify operation of BAN, view BAN data (co-located or remotely located), start BAN, stop BAN, press alarm…).

• Other carer (e.g. informal carer) (start BAN, stop BAN, press alarm…).

We can also identify roles associated not with human actors but with different elements of the technology.

Technology element roles:

• Data acquisition (BCDSs).

E.g. Biosensors measuring physiological measurements from patient’s body.

E.g. Positioning devices registering location info from external source.

• Data store (MBU).

• Data management (MBU).

• Signal Processing (Mobi).

Signal conditioning: ADC, sampling, filtering.

Signal synchronization (Mobi or MBU?).

• Processing (MBU).

BAN Back End System (BESys)

Health call centre

Hospital

MBU

Doctor Patient Nurse Informal caregiver


Signal interpretation (e.g. auto detect pattern indicating emergency) (running on MBU).

Encryption.

User application functions.

(For Local application functions - see user manual).

Local feedback of info to patient or co-located carer (eg nurse, family member).

E.g. Signal viewer (viewer application on BAN).

Alarm …..

• Communicate with remote network (extra BAN) (MBU)

(see BANIP (BAN Interconnect Protocol)).

• Communicate locally (intra BAN) (MBU, Mobi, BCDSs).

Hence, we identify the essential BAN role types as follows:

1. Patient.

2. Carer – an aggregated role type (doctors, nurses, and other carers have the same attitude towards the BAN).

3. Data acquirer – gets vital sign data and location data, delivering it for further processing.

4. Data acquisitor – biosensors measuring physiological measurements from patient’s body, and the corresponding sampling.

5. Locator – positioning, registering location information from external source.

6. Processing Unit – processing the data (which is delivered by the Data Manager) and also adding user management and security aspects.

7. Synchroniser – synchronizing the processed data.

8. Interpreter – responsible for the delivery (to the Carer) of appropriately interpreted data concerning the Patient.

The first two role types are of course external for the BAN. The other 6 role types are shown on the Figure 13:

��

��

��

��

��!�"#$ �

�� %��

&�� &��

&��

�'��( ")�#$ �

��* ��+��

� ��,�-#�

-�#� � �#� �

&�� &��

��

.$��#$ �

Figure 13: Basic role types within the BAN

Then we continue with the identification of LAP-driven Transactions, the elementary business process modelling building blocks in SDBC [30]. Due to the limited scope of the current paper, we will not elaborate on the identification of transactions and will instead present just the set of our identified 7 Transactions, in consistency with the discovered role types, Figure 13. These Transactions, together with their corresponding fact types, are presented below:

T1 (Interpret and) Deliver data; F1 data <D> is delivered

T2 Perform processing; F2 processing concerning data D is made


T3 Synchronize data; F3 data D is synchronized

T4 Manage data; F4 inputs regarding data D are managed and handled accordingly

T5 Register location; F5 location information regarding data D is provided

T6 Acquire data; F6 acquisition and sampling concerning data D is realized

T7 Provide biodata; F7 inputs concerning data D are provided.

Based on the identified Transactions, we build a coordination structure model, using the notations of DEMO [38]. Our BAN DEMO coordination structure model is depicted in Figure 14:

��

��

!

T4

��

��"��#$��

%

&

'

�

�'

(��

�/01��

�%

��"��)��

�&

*�"��

�+

��,��#��

�-

�� "./��

-

��%

��

Figure 14: Coordination structure model of the BAN

As seen from the figure, there are 8 role types (which have been identified (6 of which are internal with respect to the system under study (the BAN). These role types concern the 7 Transactions (which have been identified as well). The black boxes indicate which is the Transaction executing role.

Following the Transaction concept [37], we straightforwardly reflect the model (consider the above figure) into a process-step one, as depicted on Figure 15, offering elicitation on the particular Transaction performance:


Figure 15: Process step model of the BAN

On the figure, 4 abbreviations reflect the essential communication illocutions used: rq (request), pm (promise), st (state), and ac (accept).

And finally, by adding dynamic elicitation based not only on the (above-presented) model but also on a further consideration of the BAN Telemonitoring case, we build a Petri Net workflow model (Figure 16), as a reflection of a possible scenario:


� �

��

� � �2�31��./��

��1��/"��"/��"��"0�

�1��/12��./��"�3�"��

��

��1��"0/12��3��2��

��

��1��/"��2��#� ��1��"��"��

��2�31��

��1�4��"��35�

��1��"��35�

��

��1�6��/��

��1��/"��"��)��

��

��1��

��1��3��2��"��#�

Figure 16: Process step model of the BAN

4.4 Mapping of roles to functional blocks The discovery of roles should provide the foundation for the identification of the pieces of functionality characterizing the system-to-be. What role types represent is the abstract, technology-independent competences that correspond to any future technical realization. In that sense, the core of the built business process model reflects invariance.


We are to consider now a particular technical realization of the business process model (elaborated in 4 aspects) that has been presented in the previous sections. This realization concerns the MobiHealth-BAN technological heritage which was discussed in previous chapters.

From the BAN perspective: the Interpretor, between transactions 1 and 2 (Figure 13), is to be about the preparation of the data distribution, using a network channel; the Processing Unit, between transactions 2 and 4, should be about the actual data processing; the Synchronizator, concerning Transaction 3, must be about the activity of joining of several data streams and synchronizing them; the Locator, concerning Transaction 5, is to be about identifying location; the Data Manager, between transactions 4 and 6, should be not only for collection, sampling, and serialization of data but also about its storing in repositories; the Data Acquisitor is about the capturing of vital signs. We have depicted all this in the following table.

Table 1: Roles

Role types BAN-related competences Pieces of functi onality

Interpretor Preparation of the data distribution, using a network channel

COMMUNICATOR

Processing Unit Processing of the data PROCESSOR

Synchronizator Joining of several data streams (vital signs) and synchronization of the data

JOINER

Collection, sampling, and serialization of sense data

AGGREGATOR Data Manager

Storing the data in repositories STORE

Locator Identifies the location of a person or other entity

Data Acquisitor Captures vital signs

SENSOR

As seen from the table, it is possible that:

• more than one technology-driven functionality pieces are derived based on one role. • more than one roles are combined in one technology-driven functionality piece.

That is because the bottom line in identifying role types is a pure business-driven study that has nothing to do with the eventual possibilities to apply IT automation to the business system, while the derived technology-driven pieces of functionality that concern the IT system-to be, are specified on the basis of a consideration of one (possible) technical realization or another.

In Chapter 5, we continue with a further elaboration regarding the identified BAN-driven pieces of functionality. We are going to study their statical/structural interrelationships, with the help of UML in general, and the UML Class Diagram, in particular.

5 BAN models This chapter discusses the developed BAN models using a UML profile [39] to address families of BANs. It starts with a basic description of the BAN model in terms of UML stereotype classes. It continues then with refined descriptions of parts of the basic model.


5.1 Basic BAN model Detailed properties of BANs in M-Health typically dependent on the problem domain specialty (e.g. neurology, cardiology or obstetrics); however these BANs also share common features. In this chapter, we derive a generic device BAN model that captures and expresses the invariant properties of healthcare BANs for vital sign sensing and actuator-based treatment feedback. We express the generic model in UML stereotyped class diagrams to get correct (by construction) refinements of specialty specific device BAN models, which are expressed in UML class diagrams [39, 40].

As a network of devices worn on the body, a device BAN has the general structure of a graph, which itself is a generalization of a network. Figure 17 shows a UML (stereotyped) class diagram of a graph, defined by nodes (represented by the (stereotyped) class Node) and associated by the association class Edge.

«stereotype»Node

«stereotype»Edge

*

*

Figure 17: A graph defined by nodes Node and edges Edge.

As was discussed earlier, the nodes of an M-health device BAN can be categorized into two kinds. The devices of the first kind are the simple end-devices like vital sign sensors or medical actuators (if appropriate, including the more complex multimedia end-devices like cameras). The devices of the second kind are for example intermediary processing, aggregating, storing or communication devices that facilitate applications by bringing sensed vital signs to healthcare tasks or by bringing control commands from healthcare tasks to the actuators (see e.g. Section 5.2 for the descriptions of these devices). These intermediating devices will be represented by intermediary nodes and analogously the end-devices by end-device nodes (see e.g. Figure 20).

In the M-Health domain, we may further constrain the graph due to the following observed properties:

• Nodes adjacent to end-device nodes are intermediary nodes. That is, sensors are not interconnected in a producer-consumer sense and neither are actuators. In healthcare moreover, attaching a sensor directly to an actuator is not considered appropriate due to healthcare safety constraints. For interface matching and safety reasons, at least one intermediary node goes between a sensor and an actuator.

• Since our M-Health applications target for use in a wide-area by using (third-party) network infrastructures, we typically have to put processing and computing intelligence on the end-nodes of the distributed environment rather than within the (third party) network infrastructures. Consequently, the nodes of the graph represent the devices (both the end and the intermediary devices) rather than resources in general, like for example network resources.

• We further have the option to allow a hierarchy of intermediary nodes in our BAN model, but we may also constrain the model to one level intermediary nodes.

The previous discussions yields the following generic device BAN models:

• generic BAN model for one-level intermediary nodes: If the intermediary nodes are not hierarchically related, the graph associated to a device BAN is bipartite (also called a bigraph, see e.g. Figure 18).


«stereotype»Node

«stereotype»Edge

-intermediate*

-end-device*

End-device = sensory or actuator device node types.Intermediate = intermediary node type.

Figure 18: Bigraph model of a generic device BAN

• generic device BAN model for hierarchical intermediary nodes: If intermediary nodes may form a hierarchy (e.g. Front-ends connected to MBUs), we have to relax the bipartite property of the generic device BAN model. In this case, adjacent nodes of intermediates may either be sensory or actuator end-device nodes or (another) intermediary nodes. In the latter case, a constraint will be needed to prevent self referring intermediates, which is not relevant in healthcare (cf. the constraint in Figure 20).The model of these BANs (Figure 19) is a relaxed form of the model shown in Figure 18. Subtle difference is the role of one of the association end-points.

«stereotype»Node

«stereotype»Edge

Intermediate = intermediary node type.

-intermediate*

*

Figure 19: Model of a generic device BAN enabling n ested intermediaries.

A further refined form of the model shown in Figure 19 but which includes end- and intermediary- nodes is shown in Figure 20.

«stereotype»Edge

«stereotype»Node

«stereotype»End-device

«stereotype»Intermediate

-son

1 *

-son-edge*

-father

1

End-device = sensory or actuator device node types.Intermediate = intermediary node type.

{context Intermediate inv: not(self.son-edge.son -> includes(self)}

Figure 20: A refined model of a generic device BAN enabling nested intermediaries.


5.2 Constraints and refinements We may include additional design choices for our M-Health BAN model, each of them influences the class diagram shown in Figure 20:

• We may specialize an edge (i.e. class Edge) into the following:

o an edge representing intermediary – intermediary relation (e.g. called II_Edge in Figure 21),

o an edge representing a sensor (set) - aggregator relation (e.g. called SI_Edge in Figure 22), and

o an edge representing a controller – actuator relation (e.g. called IA_Edge in Figure 24).

• We also may constrain the graph to prevent that aggregators become father nodes of other intermediary nodes. This is relevant if an aggregator is strictly defined as a collector of sensed data; that is, the son nodes of an aggregator are only sensors. In this case, we may have the following OCL constraint (Figure 21):

{context II-Edge

inv: not father.oclisTypeOf(Aggregator)}.

• In M-Health, we may add the constraint that vital sign sensors should not be shared by multiple intermediary nodes. In this perspective, sensed vital signs may only be collected by one aggregator, for instance to enable vital sign data distribution in a controlled way. That is, devices that distribute vital sign data need to have (adjacent father node) processing resources for example to enable the computation of the distribution conditions (e.g. expressed by policies). In this case, we have two options to model vital sign sensors and to specify this constraint. The first option is to specify the attribute sensor type of enumerated data type (e.g. vital-sign, location, etc.) and to constraint (e.g. using OCL) the multiplicity of the association to the class SI_Edge to [0..1] (cf. Figure 22). For readability, we define the class VitalSignSensor in Figure 22 explicitely.

Similarly, we also may model wired-sensors by class wiredSensor as a specialization of class Sensor Figure 23).

5.3 Attributes of the generic BAN model The attributes of the nodes of the generic device BAN model identified so far are:

• node_id : to denote the serial number of AWARENESS intermediary device or the factory version or serial number of sensors or actuators;

• node_subtype1: to discriminate between sensor types (e.g. ECG, finger clip, etc.) or intermediary device types or versions (e.g. Mobi4 aggregator, QTec HS24 R2.0 communicator, etc.);

• node_characteristics: this is a collection of attributes that denote the characteristics of the nodes including the input and output characteristics. Characteristics identified so far are for example:

o node_stubs_in: the set of input interface signatures of intermediary nodes. Stubs may be simple signatures (e.g. specifying the jack of a wire end point), or complex ones which specify the (wireless) technology and parameters (e.g. the slots, throughput and other relevant QoS parameters), the access providers and their parameters (e.g. subscription identifier and type). Examples are <Vodafone,UMTS(args)>. <KPN,GPRS(2,4) /-- 2 slots uplink, 4 slots downlink --/>, <Hs24,BTooth(serial mode)>);

Note: an associated method is for instance IsInterconnectStubCompatible(..,..,..) which arguments also refer to edge_stub attribute of edges;

o node_stubs_out: the set of output interface signatures of intermediary nodes;

o node_specref: the (location) reference to the specification definition of the intermediary node;

1 Node types are the intermediary and end-device.


o node_spec: to denote the specification definition of the intermediary node;

o sensitivity: to denote the sensitivity of sensor nodes;

o precision: to denote the precision of sensor nodes;

o priority: to denote the priority of the sensed data of this sensor;

o state: to denote the state of the node, e.g. the state of an actuator;

The edge attributes identified so far are:

• edge_stub: see e.g. node_stub description;

• edge_ISP: the communication service provider (This attribute may be combined with the stub attribute);

• edge_agent: the role/agent that makes the attachment (auditable aspect) or the component that establishes the edge or instructs the creation of the edge;

• edge_epoch: the period of being an edge, typically represented as a tuple of start and end dates and times.

The attributes discussed previously are further elaborated in the class diagrams shown in the next figures.

5.4 Edge types In Section 5.2, we discuss about edges which associate exactly two nodes and edges which represent 1:many or many:1 relations between son and father nodes. Edges which represent 1:1 relations are more simple and suitable to represent the various choices of network connectivity (including the different ISPs or cellular providers).

On the other hand, sensed data are typically collected as a set by an aggregator. In M-Health moreover, a controller may govern a set of actuators. In the next sections, we investigate 1:1 edges in M-Health device BAN models. Models with 1:1 typed edges but combined with the notion of sensor sets is a possible topic of study. However, the concept of a 1:N typed edge is more complex and applying these type of edges will result in a more complex UML class diagram. In this paper, we therefore use 1:1 typed edges.

5.5 Generic BAN model with 1:1 edges This section refines the generic device BAN model shown in Figure 20. In this section, we address edges which associate exactly two nodes. First we specialize edges by edges which associate two intermediary nodes, then we include edges which represent sensors to aggregator relations. We also specify wired sensors and refine the model with actuator relations.

Generic BAN model with intermediate-intermediate ed ges

As was discussed in Section Error! Reference source not found. , we may distinguish between the following intermediary nodes (Figure 21 and Figure 22):

• joiner: a functional entity which joins (i.e. serialize or marshall) several data streams. An aggregator is a specialized joiner which collects sensed data (e.g. vital signs) from sensors. An aggregator typically includes pre-conditioning filters (e.g. vital sign bandpass filters) to enable correct data processing in the sequel of the BAN data provisioning chain.

• processor: a functional entity which processes actuator related data or sensed data. In the case of vital sign processors, the input and output formats of the data should fulfil the format specification described in AWARENESS D4.9 deliverable [41]. An Acontroller is a specialized processor that controls actuators.

• communicator: a functional entity which prepare the data for distribution using network channels, which typically are pipes that stream bits or ASCII characters. Multiplexing and demultiplexing of sensed data (sets) or splitting and joining of streams are elements of a


communicator. A network gateway is for example a specialized communicator device that bridges two networks.

We may further refine nodes, for example to specify classes to represent surrogate objects; however, this level of details is considered beyond the scope of this paper.

Figure 21 shows a refined device BAN model that the previously described intermediary nodes. The class II_Edge represents the earlier mentioned specialized edges between two intermediary nodes (cf. Section 5.2).

+IsStubsCompatible() : bool

+edge_agent : Agent+edge_epoch : Epoch

«stereotype»Edge

+node_id : NodeId+node_subtype : NodeSubType

«stereotype»Node

*

-son

1

-node_stubs_in : StubArray-node_stubs_out : StubArray


-father1

*

-manufacturer : string-manufacture_id : string-priority : int

«stereotype»End_device


+edge_stub : Stub-edge_ISP : EnumIsp

«stereotype»II_Edge

-son

1 *

-sensitivity-precision

«stereotype»Sensor

-ctrl_setting-state

«stereotype»Actuator

-userprofileref : URL-userprofile : UPSpec

«stereotype»Communicator

-demuxspecref : URL-demuxspec : MxSpec

«stereotype»Store

-procspecref : URL-procspec : PrSpec

«stereotype»Processor

-transcode : TrSpec

«stereotype»Gateway

«derived»

{context II-Edgeinv: not father.oclisTypeOf(Aggregator)}

-muxjoinspecref : URL-muxjoinspec : MxSpec

«stereotype»Joiner

-muxjoinspecref : URL-muxjoinspec : MxSpec-node_stubs_in : ChanArray

«stereotype»Aggregator

Figure 21: Generic device BAN model with 1:1 edges including II-Edge class

Generic BAN model with sensor-intermediate edges

Figure 22 includes the class SI_Edge which represents the sensor to aggregator edges described in Section 5.2.

We specify the following additional constraints in the class diagram:

• In line with the given description of aggregators, aggregators may only have sensors as son nodes. In this case, we have to exclude aggregators as father intermediary nodes of II_Edge.

In M-Health applications, it is considered not appropriate to share sensors (cf. discussion in Section 5.2). This means that in the context of the VitalSignSensor class the multiplicity of the association endpoint to the SI_Edge should be set to 0..1 (instead of *). As discussed earlier, an alternative is to specify a sensor type in the class Sensor and to constrain the endpoint multiplicity using OCL instead of introducing the class VitalSignSensor. This alternative is more flexible from an implementation point of view, but we choose to use the class VitalSignSensor for clarity.


+node_id : NodeId+node_subtype : NodeSubType

«stereotype»Node



«stereotype»Edge-son

1*





*

-father1

-muxjoinspecref : URL-muxjoinspec : MxSpec

«stereotype»Joiner



+IsStubsCompatible()

+edge_stub

«stereotype»SI_Edge

*

-father

1



*-son 1

-type : EnumVS

«stereotype»VitalSignSensor

-son

1

0..1

«derived»

«derived»

«derived»

Figure 22: Generic device BAN model with SI edges

Wired-sensor model

In line with the discussion in Section 5.2, we may model non-shareable wired and dumb sensors as shown in Figure 23. The classes dumbSensor and wireSI_Edge are specializations of the classes Sensor and SI_Edge, respectively. Stub definition and compatibility checking is overridden and adapted to the jacks of the sensor and Mobi4 specified by the manufacturer.



+edge_stub[1]

«stereotype»wireSI_Edge

«stereotype»dumbSensor

1 1 *

-father

1






+edge_stub

«stereotype»SI_Edge

*

-son

1

*

-father1

«derived»«derived»

Figure 23: Wired Sensor specification in the generi c device BAN model

Actuator model

In case of a wired and dumb actuator, we may use the model shown in Figure 24. In this model, a controller (class AController) may control several (dumb) actuators, but an actuator may only be controlled by one controller. The stereotype class IA-Edge is a specialization of the abstract stereotyped class Edge and discussed in Section 5.2.



«stereotype»Edge


+edge_stub

«stereotype»IA_Edge

«stereotype»dumbActuator

1 1-state

«stereotype»AController

*

-father

1

-procspecref : URL-procspec : PrSpec

«stereotype»Processor

«derived»

-ctrl_setting-state

«stereotype»Actuator «derived»




«stereotype»Intermediate-son

1 *

<<derived>>

*

-father

1

Figure 24: Actuator specification in the generic de vice BAN model

M-health Mobi4-based example:

Figure 25 illustrates the use of the generic device BAN model (shown in Figure 21, Figure 22 and Figure 23). Sensors are wired and have a 1:1 relation to the wired-si-edge MHMb4Attach. Besides an aggregator, the Mobi4 also deploys a store (represented by class MHLocalAreaStore) and communicator (represented by class MHMb4Com). The class MHGtway is deployed on the MBU and the class MHRemoteStore is deployed on the Back-End system. The class MHConnect represents internal connections within the


Mobi4s, MBUs and Back-End system and also the network channels, like the BlueTooth connection between the Mobi4s and MBUs, the cellular link and the Internet connectivity between the MBUs and the Back-End system.

The association end point of the class MHMb4Attach to the aggregator is limited to 5 sensors and is ordered due to the different stub-jacks of the Mobi4.

Additionally, this model enables the registration of the agent (or role) that attaches the sensors to the Mobi4 aggregator in the operational phase.

«dumbsensor»EMG

«dumbsensor»SpO2 «intermediate»

MHInterm

«dumbsensor»MHSensor

«dumbsensor»ECG

«aggregator»MHMb4Agg

«si_edge»MHMb4Attach

-son

1 1 0..5{ordered}

-father

1

«ii_edge»MHConnect

«gateway»MHGtway

«store»MHLocAreaStore

«store»MHRemoteStore

*

-father

1

*

-son

1

{in MobiHealth: fixed multiplicity & no-sharing}

«communicator»MHMb4Com

«processor»MHmedProc

Figure 25: M-health device BAN model based on Mobi4

The deployment of the M-health BAN model (Figure 25) onto the components and the M-health system nodes is illustrated in Figure 29 and Figure 30.

6 Implementation This section describes the software design of the MBU-BANware. As indicated in section 3.2 the MBU is the central controlling device of the AWARENESS BAN that performs computation, coordination and communication functions. The BANware is a software layer, which corresponds with our notion of BANManagement, deployed on the MBU that is responsible for coordinating the BAN configuration and manages communication sessions with the back-end system.

Section 6.1 positions the MBU-BANware layer as a coordinator between the Mobile Service Platform (MSP), the graphical user interface and the physical sensor devices. Section 6.2 discusses the structure of the MBU-BANware in more detail and identifies the responsibilities of the key Java classes involved. Section 6.3 describes the implementation of MBU measurement profiles. These profiles provide a partial implementation of the models defined in chapter 5.


6.1 The role of MBU-BANware The MBU-BANware layer is a software layer that coordinates between the graphical user interface (GUI), the sensor devices and the Mobile Services Platform (MSP) [42]. Figure 26 depicts the coordinating role of the MBU-BANware.

GUI layer

MBU-BANware layer

MSP layer

Sensor Devices

Figure 26: MBU-BANware acts as a coordinator

Decoupling the BANware from the GUI, sensors and MSP allows for independent developments in each of these parts of the system. The GUI can be tailored to specific needs of the patient that uses the BAN. Sensor devices can communicate with the MBU using an application protocol that is specific, and possibly optimized, for a specific sensor device. The MBU-BANware layer allows specific device drivers to be plugged into the system. The MSP layer provides an abstraction of the underlying network and offers support for request/response and streaming (i.e. continuous data flow) interactions.

6.2 MBU-BANware structure Figure 2 shows a more detailed picture of the structure of the MBU-BANware software. The squares with a bold title inside depict Java classes. The grey squares indicate a group of related classes. Arrows with a solid line indicate an owner-creator relation. Arrows with a dotted line indicate the flow of commands and channel data through the system. We discuss the responsibility and interactions of the most relevant classes of this structure below.


ChannelSet service provider

Transcoding Chain

Signal Monitoring

MBUController system

setup/teardown

Data source(s)

DeviceManager centralized device

subscr. / broadcasting

Device Monitors buffering /

basic filtering

Device Impls proxy

MBUServiceManager services setup

Interconnect service provider

SurrogateHostConnection

SurrogateConnection

StorageManager disk record /

playback

active channels

MBU System Configuration

MBUDesc top level XML

element, modified with patient ID

MBU Measurement Profiles

SignalMonitorManager centralized monitor

creation / notification

system creation message exchange

GUIInteraction identifiers and utility

methods (e.g. queueing)

GUI layer MBU-Banware layer GUICommandListener

MBU-Banware layer MSP layer

signal processing input

SignalMonitors monitoring /

GUI notification

SignalProcessors utility filters for

monitoring / channel data generation

responsibility link flow of commands/channel data

Figure 27: Structure of MBU-BANware Java implementa tion

The MBUController is a singleton class that is responsible for the MBU system configuration and creates the data sources, the signal monitoring classes and the ChannelSet service provider. It is the main system control component that knows how to boot up and shut down measurement sessions, and knows how to translate events that occur during measurement sessions to (external) GUI events / user notifications.

The MBUDesc is the top-level class of a Java representation of the BAN configuration. This configuration is discussed in more detail in the next section.


The data sources of the MBU are the software representations physical devices, such as the TMSi Mobi5. DeviceImpls are proxies to specific devices. These proxies implement a Device interface and can be seen as a driver that encapsulates the specific (application) protocol needed to interface with a physical device.

The DeviceManager provides centralized access and control of Devices in the system. All known devices (specified in a XML configuration file) are instantiated during initialization time. A device implementation is activated when another object in the system subscribes to the channel data it produces.

Every Device receives its own DeviceMonitor that buffers incoming data and filters out all non-active channels. This information is then passed on by a consumer thread to all subscribers.

Channel data then flows to the signal monitors and the ChannelSet service provider. The next section discusses this provider in more detail. The SignalMonitorManager creates SignalMonitor objects. A SignalMonitor subscribes to channel data that the DeviceMonitor objects produce and maps this to GUI output / actions.

The StorageManager is responsible for recording all device channels for a given channel set to disk and is also able to playback previously stored data. The method used for storage is periodic blocks of compressed data, whereby a separate header file indicates for each period the data location in the data file for quick access.

6.3 MBU Measurement Profiles The relation between the data that physical sensor devices produce and the data that eventually flows from the MBU to the back-end system is captured in a measurement profile. A measurement profile is created by a healthcare professional. Each device produces data for one or more channels. These channels may run at different sampling frequencies. The purpose of a measurement profile is to indicate which of the device channels must be forwarded to the back-end and also which channels must be processed locally (e.g. to drive the GUI). Figure 28 shows the Java classes that are used to construct a run-time representation of a measurement profile on the MBU.

MBU Measurement Profiles (one ChannelSet is one profile)

ChannelSetDesc subscribeable

element

DeviceDesc device config

ChannelDesc channel format

*

*

*

SignalProcessorDesc signal analysis &

output

SignalMonitorDesc monitor device

output for GUI/alarms *

*

0..1 0..1

Figure 28: Java structure of measurement profiles

The ChannelSetDesc is the top-level class of a measurement profile. It may contain one or more DeviceDesc objects and one or more SignalMonitorDesc objects.


The DeviceDesc class represents a physical device. This corresponds to an End_device in chapter 5. A DeviceDesc object knows specific details of a physical device, such as type, number of channels, number of active channels and number of bytes in a sample.

A ChannelDesc object provides configuration details of a single channel. This corresponds to the Sensor stereotype in chapter 5. Typical configuration information is the sample frequency of the channel, the resolution, the byte length of a sample and unit of measurement.

A SignalMonitorDesc object represents the list of SignalMonitors attached to a set of channels. A SignalMonitor uses the input of one or more channels to drive the GUI.

A SignalProcessorDesc object represents a list of signal processors. A signal processor uses the input of one or more channels to produce a derived signal. For example, derive the heart rate from a set of ECG channels. A signal processor corresponds to a Processor stereotype in chapter 5.

6.4 Relation with the BAN models This section presents the relation of the implementation with our developed the BAN models.

The bottom part of Figure 29 shows the relations between these subcomponents and the classes described in Section Figure 30.

Datasources

«executable»FrontEnd


systemcreation

GUIcommand

listenerGUI

display

MBUstorage

MBU

Datasources

/*local*/monitor

controller

MBUSysConfig

ChannSetSP

input fromFrontEnd

output to BEsystem

monitorcontroller

MBUSysConfig

MBUstorage

ChannSetSP

«gateway»MHGtway

«communicator»MHMb4Com


Figure 29: MBU represented in sub-components.

Figure 30 illustrates how the classes described in Section 5.5 have been deployed in the Mobihealth telemonitoring system [8] (see also Figure 7; the component Front End is however not shown in this figure). In AWARENESS, the component Network1 represents the BlueTooth serial mode channel and Network2 represents the communication channel to the BackEnd system over GPRS, IEEE 802.11 or UMTS.


«executable»MBU

PDA

«executable»FrontEnd

ECGSensor BESystem

Mobi4 Backend serverSensornode

«dumbsensor»ECG

«si_edge»MHMb4Attach

«aggregator»MHMb4Agg

-father «communicator»MHMb4Com


«gateway»MHGtway


«store»MHRemoteStore

«ii_edge»MHConnect

Network1 Network2wires

Figure 30: AWARENESS nodes, networks, components an d associated classes.

7 Conclusions This paper presents a conceptual model of a Body Area Network (BAN). This model enables the implementation of robust BAN management functionality.

We started this paper with a state of the art of BANs. We indicate that the difference between a PAN and a BAN lies in the limited target scope of BANs. A BAN focuses on devices worn on the body of single patient or devices in very close proximity to single patients. BANs are researched by different parties, ranging from Philips, WWRF to Fraunhofer and the University of Twente. The University of Twente did its first (pragmatic) BAN research in the Mobihealth project. In AWARENESS we extend this BAN research by shifting some of our core focus to BANS, increasing our target applications and incorporating context-awareness. Furthermore, we create a robust BAN model by using software engineering modelling approaches.

The second part of this paper researches the business context of BANs. This is the foundation for our BAN software model to ensure that the application-to-be, based on this model, operates according to the business environment in which it should be integrated. The business process modelling is performed using the SDBC approach which concerns a business process-modelling-driven software specification. This analysis resulted in a definition of BAN roles and corresponding pieces of functionality which are incorporated in our BAN model.


The third part of this paper presents our BAN model, expressed in UML profiles. This model is build up from the fact that a BAN is a kind of network (i.e. devices are connected with connections) which is a kind of graph (i.e. nodes are connected with edges). Increasingly this model is detailed to incorporate all the invariants posed by BANs. Figure 31 presents our basic BAN model. This model states that a BAN is a graph of nodes connected by edges. These nodes can be intermediate nodes (e.g. processor, storage) or end-devices (e.g. sensors, actuators). The model constraints that end-devices can not connect to other end-devices, only to intermediate devices. Some of the invariants are encapsulated by the model, when this was not possible OCL constraints are added.

«stereotype»Edge

«stereotype»Node

«stereotype»End-device


-son

1 *

-son-edge*

-father

1

Figure 31: Basic BAN model

Finally, the last part of this paper presents an implementation based on our BAN model. This implementation is the BANware implementation for AWARENESS BANs, which resides between the GUI and the supporting infrastructure. We indicate the structure of this BANware and clarify the relation of our BAN model with this implementation

7.1 Future work The defined BAN model provides a sound foundation for BAN management implementations. However, there are some aspects we want to explore further in the future:

• Task oriented BAN models: Our model focuses on the acquisition part of the overall patient treatment process. Also models on the task part of the treatment process are needed. These models should incorporate the fact that different types of vital signs form a coherent set for making a diagnosis. Furthermore, if a patient has multiple morbidities which may imply overlapping vital sign types, sub-sets of vital signs become relevant. Additionally, quality of signs becomes important. Integration of the task-oriented model with the, here discussed, acquisition model is also considered future work (see Section 1.2).

• 1:N edges: Our current model consists of 1:1 relations between sensors/actuators and intermediate devices. This is a simple representation that is suitable for BANs. However, real BANs also consist of 1:N relations (see Section 5.4).

• Implementation: The current implementation is a static implementation based on our BAN model. We plan extend this implementation such that BANs can be managed dynamically at run-time (see Section 6.2).

Acknowledgements We like to thank Alfons Salden for his useful comments in creating the foundations for this paper. Also, we are grateful for the guiding remarks of Anneke Kleppe on the UML modelling techniques and our modelling approach. Furthermore, we want to thank Liu PuMing and Bert Jan van Beijnum for their information on the task oriented vital sign viewpoint. Finally, we want to thank the reviewers of this paper, Gerlienke Voerman and Johan de Heer, for their quality improving comments.

This work is part of the Freeband AWARENESS project (http://awareness.freeband.nl). AWARENESS stands for Context AWARE mobile NEtworks and ServiceS. The Freeband AWARENESS project focuses


on service and network infrastructures that are needed to support context aware and pro-active applications on heterogeneous mobile networks. Particular attention is paid to mobile health applications for tele-monitoring and tele-treatment. The following organizations participate in Freeband AWARENESS: Lucent Technologies, Centre for Telematics and Information Technology, Telematica Instituut, Roessingh R&D, Ericsson, Twente Institute for Wireless and Mobile Communications, Yucat and TMS International.

Freeband AWARENESS is part of the Freeband program (www.freeband.nl). Freeband is a large national research program in the field of 4G telecommunication, in which fixed, mobile and wireless connections are integrated. Key research questions take place in three main themes: (1) enabling technology, (2) service provisioning, networking and access, and (3) society, users and applications. Freeband comprises over 30 organizations and is sponsored by the Dutch government under contract BSIK 03025."

References 1. van Halteren, A., Towards an adaptable QoS aware middleware for distributed objects. 2003,

Univesity of Twente: Enschede. 2. Broens, T. and R. Huis in't Veld, Tele-monitoring and Tele-treatment applications: problems and

the awareness approach, in Freeband AWARENESS D4.5, T. Broens, Editor. 2005. 3. Mobihealth, Mobihealth project webpage, 2004, Available from: http://www.mobihealth.org. 4. Bults, R., et al., Trial specific Mobihealth BAN, in IST Mobihealth D2.3, A. Halteren, Editor. 5. Broens, T., et al., Context-aware application components, in Freeband AWARENESS D4.2. 2004. 6. Hobsley, M., Pathways in Surgical Management. 1979, London: Edward Arnolds Pub. Ltd. 7. Liu, P., SLA's in the Healthcare Domain. 2005, University of Twente: Enschede. 8. Widya, I., et al., Telematic Requirements for a Mobile and Wireless Healthcare System derived

from Enterprise Models, in Proceedings IEEE ConTel 2003: 7th International Conference on Telecommunications. 2003: Zagreb, Croatia.

9. Batteram, H., et al., AWARENESS Scope and Scenarios, in Freeband AWARENESS D1.1v2, M.v. Sinderen, Editor. 2005.

10. Zimmerman, T., Personal Area Networks: Near-field intrabody communication. IBM System Journal, 1996. 35(3/4): p. 609.

11. Zimmerman, T., Wireless networked digital devices: A new paradigm for computing and communication. IBM System Journal, 1999. 38(4).

12. Zigbee Alliance, Wireless control that simply works, Available from: http://www.zigbee.org/en/index.asp.

13. Basuma, Body Area System for Ubiquitous Multimedia Applications, Available from: http://www.basuma.de/.

14. Dam, K.v., S. Pitchers, and M. Barnard, Body Area Networks: Towards a Wearable Future, in Proc. WWRF kick off meeting. 2001: Munich, Germany.

15. Jones, V., et al., Body Area Networks for Healthcare, in Wireless World Research Forum. 2001: Stockholm.

16. Jones, V., R. Bults, and P. Vierhout, Virtual Trauma Team, in Wireless World Research Forum. 2001: Helsinki.

17. Wireless World Research Forum, The Book of Visions 2001: Visions of the Wireless World, 2001, Available from: http://www.wireless-world-research.org/.

18. Jones, V., et al., Healthcare PANs: Personal Area Networks for trauma care and home care, in Proceedings Fourth International Symposium on Wireless Personal Multimedia Communications (WPMC). 2001: Aalborg, Denmark.

19. Konstantas, D., et al., MobiHealth - Wireless mobile services and applications for healthcare, in International Conference On Telemedicine - Integration of Health Telematics into Medical Practice. 2002: Regensburg, Germany.

20. Dokovski, N., A.v. Halteren, and I. Widya, BANip: Enabling remote healthcare monitoring with Body Area Networks, in FIDJI'03. 2003.

21. Fraunhofer, BAN - Body Area Network, Available from: http://www.iis.fraunhofer.de/pub_rel/presse/2002/cebit/ban.html.

22. Fraunhofer, BAN - Wireless communication between man and machine, Available from: http://www.iis.fraunhofer.de/ec/drahtlos/body_com/index.html.


23. Fraunhofer, Body Area Network. 24. Baskiyar, S., A Real-Time Fault Tolerant Intra-Body Network, in 27th Annual IEEE Conference on

Local Computer Networks (LCN'02). 2002: Tampa, Florida. 25. Redtacton, Redtacton, Available from: http://www.redtacton.com/en/index.html. 26. Amato, G., et al., Health Care Monitoring of Mobile Patients, Available from:

http://www.ercim.org/publication/Ercim_News/enw60/amato.html. 27. Conti, M., Body, personal, and local ad hoc wireless networks, 2003, Available from:

http://portal.acm.org/citation.cfm?id=989713. 28. Jones, V., et al., Remote Monitoring for Healthcare and for Safety in Extreme Environments, in M-

Health: Emerging Mobile Health Systems, R. Istepanian, S. Laxminarayan, and C. Pattichis, Editors. forthcomming.

29. Shishkov, B. and J. Dietz, Aligning Business Process Modeling and Software Specification in a Component-Based Way, The Advantages of SDBC, in Proceedings of the 6th International Conference on Enterprise Information Systems (ICEIS). 2004: Porto, Portugal.

30. Shishkov, B., Software specification based on re-usable business components. 2005, Delft University.

31. Shishkov, B. and J. Dietz, Design of Software Applications Using Generic Business Components, in Proceedings of the 37th Hawaii International Conference on System Sciences (HICSS). 2004: Big Island, Hawai.

32. Lui, K., Semiotics in Information Systems Engineering. 2000, Cambridge, UK. 33. Gibson, J., The Ecological Approach ot Visual Perception. 1979: Boston: Houghtpn Miffin. 34. Winograd, T. and F. Flores. Understanding Computers and Cognition: A Foundation for Design. in

Ablex, Norwood, NJ. 1986. 35. Shishkov, B., et al., Information architecture, in Freeband AWARENESS D1.4v2. 2005. 36. Czarnecki, K. and U. Eisenecker, Generative Programming: Methods, tools, and applications.

2000: Addison-Wesley. 37. Shishkov, B. and J. Dietz, Applying Component-Based UML-Driven Conceptual Modeling in

SDBC, in proceedings of the 7th International Conference on Enterprise Information Systems (ICEIS). 2005: Miami, Florida.

38. Dietz, J., Understanding and Modeling Business Processes with DEMO, in Proceedings of the 18th International Conference on Conceptual Modeling (ER'99). 1999: Paris, France.

39. Fowler, M., UML Distilled Third Edition. 2004: Addison-Wesley. 40. Booch, G., J. Rumbaugh, and I. Jacobson, The Unified Modelling Language User Guide. 1999:

Addison-Wesley. 41. Mei, H., I. Widya, and A.v. Halteren, Vital Sign Model, in Freeband AWARENESS D4.9. 2005. 42. Halteren, A.v. and P. Pawar, Mobile Service Platform: a Middleware for Nomadic Mobile Service

Provisioning, in Freeband AWARENESS D2.19. 2005.

body area network.pdf

Documents