Assessing Hand Movement in Arthritic Patients Using Wearable Glove Technology

fencinghuddleAI and Robotics

Nov 14, 2013 (3 years and 7 months ago)

151 views



UNIVERSITY OF ULSTER
, MAGEE

Assessing Hand
Movement in Arthritic
Patients Using Wearable
Glove Technology




Roisin Lautman B00467127

03/05/2012

Supervisor: Dr Kevin Curran

Course: BSc Computer Science(Hons)


School of Computing and
Intelligent Systems

Faculty of Engineering

University of Ulster


Magee Campus

lautman
-
r@email.ulster.ac.uk




1



Abstract


In 2011 it has been estimated that in the UK alone there ten million sufferers of
arthritis and related conditions. The traditional means of evaluating the severity of a
patients conditions and their progress in rehabilitation involve lengthy tests carried

out by consultants and other healthcare professionals by using visual and touch
inspections.
Due to the rise in sufferers this

approach is becoming impractical.
Computerised systems have been developed
,

however, despite providing in depth
and accurate res
ults about the full extent of a patient's arthritis, are costly and are
therefore not widely available. This project
details the development of a low cost
alternative to the

system that will measure the movements of a patients hand
using
the Peregrine G
am
ing Glove which

will p
roduce accurate results that can be used

by
a clinician to assess a patient's condition.











2


Acknowledgements


I would like to thank the following individuals, without whom this project would not
have been realised:

Dr Kevin C
urran, Final Year Supervisor



For your advice, your insight and your patience throughout this project

Karen Murphy and Roisin McElhome, Occupational Therapists, Altnagelvin Hospital,
WHSST



For providing a medical insight into the requirements for this
system and a
wealth of material that provided the inspiration for my prototype

Dr Jose Santos, Lecturer, School of Computing and Intelligent Systems (Magee
Campus)



For your advice and guidance throughout my final year

My family

and friends



For your support

and encouragement throughout my final year, and
especially to my mum and boyfriend, for keeping me calm in the final
panicked weeks.



Aimee Bonner, Ayleen McCann, Matthew Gillespie and Amie Campbell, for
helping keep me on track and
sharing the stress.



Sen
der@Riptalon, for your insight and advice and for helping me keep my
focus

I would also like to acknowledge the community of StackOverflow, whose members
questions and answers helped clarify a lot of approaches taken in implementation of
the system.



3


D
ec
laration


“I declare that this is all my own work and does not contain unreferenced material
copied from any other source. I have read the University’s policy on plagiarism and
understand the definition of plagiarism. If it is shown that material has been
plagiarised, or I have otherwise attempted to obtain an unfair advantage for myself
or others, I understand that I may face sanctions in accordance with the policies and
procedures of the University. A mark of zero may be awarded and the reason for
that ma
rk will be recorded on my file.”


Roisin Lautman

Yr 4 BSc Computer Science

University of Ulster Magee




4


Table of Contents

Abstract

................................
................................
................................
................................
.............

1

Acknowledgements

................................
................................
................................
............................

2

Declaration

................................
................................
................................
................................
........

3

List of Figures

................................
................................
................................
................................
.....

7

List of Tables

................................
................................
................................
................................
......

8

Chapter 1: Introduction

................................
................................
................................
......................

9

Chapter 2: Hand Motion Detection Devices

................................
................................
.....................

11

2.1 Wearable Glove hardware

................................
................................
................................
..........

11

2.2 Glove Software

................................
................................
................................
...........................

14

2.3 Non
-
Glove Methods of Hand Motion Detection
................................
................................
...........

16

2.3.1 Microsoft Kinect

................................
................................
................................
...................

16

2.3.2
3Space Isotrak System

................................
................................
................................
..........

17

2.3.3 OpenSource Camera Based Motion Detection Programs

................................
....................

17

2.3 Existing Prototypes for Arthritis Assessment

................................
................................
...............

18

Chapter 3: Review of Assessment Techniques

................................
................................
..................

19

3.1 Manual Assessment Techniques

................................
................................
................................
..

19

3.2 Invasive Assessment Techniques

................................
................................
................................
..

22

Chapter 4: Requirements Analysis

................................
................................
................................
....

23

4.1 Problem Statement

................................
................................
................................
......................

23

4.2 Fu
nctional Requirements of Glove Interface

................................
................................
................

24

4.2.1 Requirements for Patient

................................
................................
................................
.....

24

4.2.2 Requirements for Clinician

................................
................................
................................
...

24

4.3 Non Functional Requirements of Glove Interface

................................
................................
........

24

4.3.1 Requirements for Patient

................................
................................
................................
.....

24

4.3.2 Requirements for Clinician

................................
................................
................................
...

25

4.4 System Requirements

................................
................................
................................
...................

25

4.4.1 Software Requirements

................................
................................
................................
........

25

5


4.4.2 Hardware Requirements
................................
................................
................................
.......

26

Chapter 5: Project Planning

................................
................................
................................
..............

27

5.1 Milestones and Deliverables

................................
................................
................................
........

27

5.2 Work Breakdown Structure

................................
................................
................................
..........

28

5.3 Time Management

................................
................................
................................
.......................

29

5.4 Risk Management

................................
................................
................................
........................

29

Chapter 6: Design

................................
................................
................................
.............................

31

6.1 Application Design

................................
................................
................................
.....................

31

6.1.1 Architecture Design

................................
................................
................................
..............

31

6.
1.2 System Interaction Design

................................
................................
................................
....

33

6.2.1 Database Design

................................
................................
................................
...................

36

6.3 User Interaction Design

................................
................................
................................
................

38

6.4 User Interface Design

................................
................................
................................
...................

40

Ch
apter 7: Implementation

................................
................................
................................
.............

4
5

7.1 Database Implementation

................................
................................
................................
...........

45

7.2 Login and Options Implementation

................................
................................
..............................

47

7.3 Create User Function
Implementation

................................
................................
.........................

48

7.4 Glove Keymap

................................
................................
................................
..............................

50

7.5 Hand Test Implementation
................................
................................
................................
...........

51

7.6 Results Report Implementation

................................
................................
................................
....

55

Chapter 8: System Interaction Testing

................................
................................
..............................

59

8.1: Login Interaction

................................
................................
................................
.........................

59

8.2 Pa
tient System Interaction

................................
................................
................................
...........

61

8.2.1 Kapandji Test Interaction

................................
................................
................................
......

62

8.2.2 Flexure Test Interaction

................................
................................
................................
........

64

8.2.3 Personal Patient Results Interaction

................................
................................
....................

66

8.3 Clinician System Interaction

................................
................................
................................
.........

66

8.3.1 Create User Interaction

................................
................................
................................
........

67

8.3.2 Results Report Testing

................................
................................
................................
..........

68

6


Chapter 9:
Evaluation and Conclusions

................................
................................
............................

71

References

................................
................................
................................
................................
.......

73

Appendix 1: Main Class Source Code

................................
................................
................................

76

Appendix 2: Login Form Source Code

................................
................................
...............................

78

Appendix 3: Patient Options Screen Source Code

................................
................................
............

79

Appendix 4: Clinician Options Screen Source Code

................................
................................
...........

80

Appendix 5: Kapandji ControlMapper Class Sourc
e Code

................................
................................
.

81

Appendix 6: FlexureControlMapper Class Source Code

................................
................................
....

82

Appendix 7: BaseTest Abstract Class Source Code

................................
................................
............

83

Appendix 8: Kapand
jiTest Class Source Code

................................
................................
...................

87

Appendix 9: FlexureTest Source Code

................................
................................
..............................

89




7


List

of Figures

Figure 1: Hand affected by advance Rheumatoid Arthritis

................................
................................
......

9

Figure 2: 5DT Dataglove Ultra

................................
................................
................................
................

12

Figure 3: Acceleglove

................................
................................
................................
..............................

12

Figure 4: HumanGlove

................................
................................
................................
............................

13

Figure 5: Peregrine Gaming Glove

................................
................................
................................
..........

13

Figure 6: Glovemanager GUI

................................
................................
................................
..................

14

Figure 7: Humanglove in use

................................
................................
................................
..................

15

Figure 8: Screenshot of GloveBox software showing tip of ring finger touched by thump tip activator
pad

................................
................................
................................
................................
..........................

15

Figure 9: Users
playing beach volleyball game in Kinect Sports using Microsoft Kinect

........................

17

Figure 10: Goniometer being used to measure angle of
fle
xure

of index finger

................................
...

20

Figure 11: Baseline
®

Standard Hydraulic dynamometer being used to measure grip strength in a
patient's rig
ht hand

................................
................................
................................
................................

20

Figure 12: Pinch Meter being used to measure lateral
pinch strength

................................
..................

20

Figure 13: A: Three Jaw Chuck pinch test B: Later
al pinch test C: Tip pinch test

................................
...

21

Figure 14: Work Breakdown Structure

................................
................................
................................
...

28

Figure 15: Microsoft Project Gantt Chart

................................
................................
...............................

29

Figure 16:
High Level View of System Architecture

................................
................................
................

31

Figure 17: Detailed Architecture of Proposed System

................................
................................
...........

32

Figure 18: System component interaction design for Patient interaction

................................
.............

33

Figure 19: System component interaction during Clinician interaction

................................
.................

34

Figure 20: UML Activity Model of User Interaction

................................
................................
................

38

Figure 21: UML Activity Model of Clinician Interaction

................................
................................
..........

39

Figure 22: Login Screen Design

................................
................................
................................
...............

40

Figure 23: Patient Options Form Design

................................
................................
................................

41

Figure 24: Clinician Options Form Design

................................
................................
...............................

41

Figure 25: Uncompleted Test Screen Design

................................
................................
..........................

42

Figure 26: Design of Completed Kapandji Test

................................
................................
......................

42

Figure 27: Proposed Create User Form Design

................................
................................
......................

43

Figure 28: Test Results Design

................................
................................
................................
................

44

Figure 29: Database Model

................................
................................
................................
....................

46

Figure 30: KapandjiTest Keymap
-

Th
ump tip Activator pad used

................................
.........................

50

Figure 31:
Flexure
Test Keymap
-

Palm
Activator pad used

................................
................................
....

50

Figure 32: Standard HandTest form in Visual Studio Design View

................................
.........................

52

Figure 33: Results Form in Visual Studio:

................................
................................
...............................

56

Figure 34: Login Screen

................................
................................
................................
..........................

59

Figure 35: Incorrect Login Entered

................................
................................
................................
.........

60

8


Figure 36: Patient Login Credentials Entered

................................
................................
.........................

60

Figure 37: PatientOptions Screen

................................
................................
................................
...........

60

Figure 38: Clinician Login Credentials Entered

................................
................................
.......................

61

Figure 39: Clinician Options screen

................................
................................
................................
........

61

Figure 40: Image of Physical Touch
-

Index Fingertip

................................
................................
.............

62

Figure 41: Image of On Screen Index Tip Activated

................................
................................
...............

62

Figure 42: Image of Physical Touch
-

Little Fingerti
p

................................
................................
..............

63

Figure 43: First and Last Touch Points Activated

................................
................................
....................

63

Figure 44: Completed Kapandji Test

................................
................................
................................
......

64

Figure 45: Image of Physical Touch
-

Ring Fingertip

................................
................................
...............

65

Figure 46: Ring Fingertip Touch Point Activated

................................
................................
....................

65

Figure 47: Completed Flexure Test
................................
................................
................................
.........

65

Figure 48: Results Reports Screen
-

Patient View

................................
................................
..................

66

Figure 4
9
: No Profile Information Entered
-

Create Button Disabled

................................
....................

67

Figure 50: No Report Data Loaded

................................
................................
................................
.........

69

Figure 51: Kapandji Test Results Report

................................
................................
................................
.

69

Figure 52: Palm Test Results Report

................................
................................
................................
.......

70







List of Tables

Table 1 Proposed User Data Table

................................
................................
................................
.........

36

Table 2 Proposed Test Sessions Data Table

................................
................................
...........................

36

Table 3: Proposed Measurement Data Table

................................
................................
.........................

37



9


Chapter 1: Introduction


Rheumatoid arthritis
(RA)
can affect a patient in a variety of ways, however the
condition largely affects the joints

in the patients hand
, causing them to become
swollen, stiff and
in many

causing the patient to lose the function in their joints

as
they become deformed (Fig 1
)
.

RA can be debilitating to many sufferers, with an
estimated 50% of diagnosed sufferers losing their jobs within 5
years of
their first
diagnosis (Curran, et al., 2011
).





Figure
1
:

Hand affected by advance Rheumatoid Arthritis

The traditional methods of evaluating patients with hand injuries and arthritis
related conditions have involved e
xtensive visual and touch inspections by a
healthcare professional which can produce inaccurate results and x
-
rays tests such
as arthrography which is quite an invasive process that can cause discomfort for
patients and bone density scans
which are very ti
me consuming (
OrthoInfo, 2011
)
.
With an estimated 10 million sufferers of arthritis and related conditions in 2011

(
Arthritis Care, 2011
)

these approaches are
arguably no longer

feasible for clinicians
or patients.

The cost of
RA
not only in terms of the
medical costs is

a driving force behind
research such as this project.
Rheumatoid arthritis

is estimated to cost the UK
economy £8.6 billion a year
(
NRAS, 2010
). Combine this estimate with the previous
estimate of 50% of sufferers losing their jobs it is s
ensible to suggest that a more
economically viable solution must be found, for both the benefit of the patient and
the health service.

10


The aim of this project is to develop an effective user interface for use by patients
which will allow them to perform pr
edefined exercises both at home and in the
presence of their clinician which will accurately record their hand movements using
an affordable wearable data glove. Although there are costly models of data glove
which can be seen as more accurate, the cost of

this equipment will mean that it will
not be widely available to patients for home use. This project will seek to develop a
system and a series of test that will allow the less expensive Pereg
r
ine Gaming Glove
to be used to accurately record hand movement
. This will greatly reduce the
workload of clinicians and also improve the quality of assessment for the patient.
The system will include a function for the patient’s clinician to access the patient’s
personal profile and view the results of their exercise
s. A reporting function has
been suggested which, it is hoped, will be incorporated which will provide the
clinician with a trending graphs which will allow them to evaluate if the patient’s
condition has improved.














11


Chapter 2:
Hand Motion De
tection Devices


The following chapter will discuss hand motion detection devices that are currently
available, covering both the hardware and software used.


2.1

Wearable Glove hardware


There are several wearable data gloves available for this style of project and indeed
some of them have been developed with similar uses in mind. As the basis of this
project is determining a low
-
cost solution that can be used widely by patients at
home ma
ny of these gloves are instantly excluded however the features and merits
of these gloves must be
discussed

in order to understand both the capabilities and
limitations of the chosen glove, the
Peregrine

gaming glove.

The gloves that will be
focused on for

discussion on their possible uses in hand measurement are the 5DT
Dataglove

14 Ultra
, the Acceleglove and the HumanGlove.

The 5DT Dataglove
14 Ultra

(Fig1
) c
onsists of a
lycra

glove with two sensors on each
finger which measure the
flexure

and abduction
of the hand. It is marketed at the
motion capture industry and animation professionals due to its capability at
generating accurate models of hand movement when used with studio software

(5DT, 1999)
. With its capabilities is it perfect for measuring hand m
ovement and
indeed
both prior and current research has soon that this glove
could be used
successfully in the analysis of arthritic pa
tients
. However the cost of this glove is too
excessive for use in this project as each glove costs

about £3000.

Another

glove with potential for implementation within the area of arthritis
diagnosis and evalua
tion is the Acceleglove (Fig 2
). The Acceleglove is a lycra glove
with 6 accelerometers, one on the back of each finger and one on the back of the
hand. The
Acceleglove has several suggested uses based on its movement recording
functionality such as a controller for a computer interface, a tool for learning and
interpreting sign languages and most important for this project, as a research tool
12


for monitoring h
and movement

(Acceleglove, 2011)
. Despite the suitability of this
product for this piece of research it must also be excluded for this project due to it
cost, $649 (£415) per glove.



Figure
2
:

5DT Dataglove Ultra


Figure
3
:

Acceleglove


The HumanGlove

(Fig 2
)

can
be considered as a suitable

glove
for

this research.
HumanWare
's
core activity
is
focused on the manufacturing of hi
-
tech advanced
devices for the Biomedical sector

including
Neuro and Orth
o Reh
abilitation
applications. T
he glove is specifically designed and marketed for use in medicine and
neurorehabilitation but can also be applied in virtual reality and telerobotics.
HumanWare state that the glove is able to detect hand posture and movements i
n
real time. The glove contains 22 depth of field sensors, three on each finger
(including thumb) to measure
flexure
-
extension and one to measure abduction and
adduction and two sensors on the wrist, one to measure
flexure
-
extension and the
other for abduc
tion and adduction

(Humanware, 2010)
. Unlike the previous gloves
the HumanGlove uses wireless technology to send the data its gathers to the
workstation. Again, despite the obvious suitability and effectiveness of this gl
ove for
this research, the glove is

costly and quotations are currently only available to those
working in the procurement of medical supplies.

13



Figure
4
:

HumanGlove


Figure
5
:

Peregrine Gaming Glove




The glove that has been chosen for this project is the
Peregrine

Gaming Glove.
Created by Peregrine in Canada, the Peregrine Gaming Glove has been designed for
and is marketed specifically at the gaming market, primarily the mmorpg (massively
multiplayer o
nline role playing game) market
. As its primary use would suggest, the
glove is not designed for nor does it have the obvious capability for accurate hand
movement measurement. The glove consists of three

activator pads, one on the tip
of the thumb, anothe
r on the centre and another on the palm of the hand. There are
stainless steel conductive traces which run around the glove, along the inside and
the front of each finger. These steel traces then connect to a gold plated connector
‘pod’. When the user touc
hes an activator pad to a point on these traces the ‘pod’
senses the electrical resistance to determine at which point on the wire the user is
touching.
The number of activator pads allow a variety of different tests to be
designed and performed, such as t
esting the movement range of the patients thumb
with exercises that the patient must complete by touching the thumb tip to each
fingertip and tests to determine the
flexure

of the patients fingers with exercises
where they must touch each fingertip to the
palm activator pad.
The cost of the
glove makes it extremely desirable for this research as the cost for each unit is
around £99 ($129.99)
.



14



2.2

Glove
Software


A key part of this project will be the interface that will be created for use with this
glove, which it is hoped will be able to evaluate the data sent from the glove and
return accurate results. To understand what is required from this software and to
formulate how, with its limited capabilities, it will be able to return relevant and
accura
te information for use by a healthcare professional.

The 5DT Dataglove 14
Ultra comes with its own glovemanager software which shows a real time analysis in
wave form of
the data from the glove (Fig 6
).


Figure
6
:

Glovemanager GUI

This software is suitable for use in calibrating the glove and assessing the accuracy of
the recordings. However this software cannot be classed as user friendly and would
be acceptable for use by a healthcare
professional

or home patient. The 5DT
Dataglo
ve 14 ultra is compatible with other software which will allow the creation of
a more user friendly interface, such as MotionBuilder, 3D Studio Max, Maya and
Softimage, however each of these pieces of software requires the purchase of a
15


single
user

license, which is provided by 5DT industries at a charge of $495

(Meta
Motion, 2011)
.

The Acceleglove is also provided with its own software development kit for use by
software developers and allowing them to adapt the glove for use in whichever area
the
y choose. Like the 5DT Dataglove 14 Ultra, the software provided with this glove
shows the raw data in a wave form and allows the user to create libraries of useful
gestures. The bespoke software provided with this glove is in no doubt useful for this
proj
ect however the interface is not user friendly as it requires development
knowledge to create the libraries and record gestures which is not expected to be
known by the target audience of this project.

Out of all the gloves discussed the HumanGlove softwar
e is provided with the most
user friendly interface, especially for use by the patient. It has been determined that
the user must be able to track the movements they are carrying out in an easily
understood view and the HumanGlove
software succeeds in this

providing an
interface with a simple 3D model of a hand which responds in real time to
movement from the patients actual hand while wearing the glove

(Fig 7
)
.



Figure
7
:

Humanglove in use


Figure
8
:

Screenshot of GloveBox software showing tip
of ring finger touched by thump tip activator pad



The Peregrine Gaming glove is provided with the bespoke GloveBox software which
has been developed for use in calibrating and mapping the controls to be used

by
the glove. As it has been designed for the gaming market it has quite a user friendly
interface, however it uses terms that would be recognisable to gamers and not
necessarily to patients and physicians, such as keymapping. The interface does not
16


conta
in a dynamic model of the hand, rather a static image with clearly defined
squares where the activation points are located, which will highlight when an
activation and touch
point have been touched (Fig 8
).

Despite the fact that some of these programs,
namely the HumanGlove and
GloveB
ox
software's

have been designed specifically for their gloves, none of these
programs have been designed with the option for use as a diagnostic tool. The
challenge for this project will be to create a diagnostic program th
at has the most
desirable features from the previous software, such as pleasing graphics, real time
response from the program when an action is performed and ease of use.


2.3 Non
-
Glove Methods of Hand Motion Detection

2.3.1 Microsoft Kinect


Glove based
solutions are not the only form of motion detection solutions available
on the market today. There are a variety of Open Source and indeed commercial
programs that allow for motion detection using camera technology.

The most commercially successful solely
camera based product for motion detection
is Mi
crosoft’s Kinect system (Fig 9
),

designed for the Xbox 360 gaming console. The
only hardware required by the user is the Kinect camera unit which detects whole
body motion and allows the user to use themselves

to control the system and play
games

(Microsoft, 2011)
. Kinect was designed
originally

for the purpose of gaming
however
have recently released a free software development to allow the Kinect
system to be used with Windows in conjunction with Microsoft Vi
sual Studio. The
use of Visual Studio allows the user a certain freedom with regards to the language
used to write the program as Visual Studio utilizes all .Net languages including C++
and VB, making it an excellent learning tool.

17









Figure
9
:

Users playing beach volleyball game in Kinect Sports using Microsoft Kinect

2.3.2 3Space Isotrak System


The 3Space Isotrak is an electromagnetic device that detects movement by tracking
the posi
tion of a sensor in open space. A
n extensive study
carried out to assess the
validity of
the 3Space Isotrak system as a measurement tool to assess the range of
motion in the
metacarpophalangeal (MCP) joints of the hand when compared
against measurements taken with a traditional protractor
.

The results of this survey
were positive,
showing a good correlation between both types of measurement
(Kulkarni
-
Lambore and Peat, 2000). Despite is proven ability as a measurement
device, the setup 3Space Isotrak system has been described as
unwieldy

an
d
therefore impractical as home assessment device (Condell et al, 2010).


2.3.3

OpenSource Camera Based Motion
Detection

Programs


The OpenCV (Open Source Computer Vision Library) was originally created by Intel as
a research initiative and was released to the public in 2000
(Wikipedia, 2011)

It is a
cross platform programming library
focused on real
-
time image processing and
computer

vision
and since its release has evolved to run on most modern mobile and
desktop operating platforms such as Android, iOS, Linux, Mac OS and Windows.

18


OpenCV software can also be used with any standard webcam, making it more
accessible to a wider audienc
e.

OpenCV has been applied in many areas of computer vision, from facial recognition,
hand gesture recognition and even in robotics control

(Wikipedia, 2011)
. Using the
OpenCV library, programs have been created that combine the hand gesture
recognition an
d tra
cking abilities, such as HandVu

which recognises and tracks key
gestures (
Kölsch

et al, 2004)
.
As the glove that has been chosen for this project, the
Peregrine Gaming Glove, has the obvious limitation of the lack of ability to track the
movement of t
he hand,
it may be possible in a future research project to
investigation the use of a hand gesture recognition interface in conjunction with the
glove
.


2.3 Existing Prototypes for Arthritis Assessment


A similar study to this project is currently being u
ndertaken in a joint collaboration
between D
r Kevin Curran, Dr Joan Condell and James Connolly of the University of
Ulster and Dr Philip Gardiner of Altnagelvin Hospital (part of the Western Health and
Social Care Trust in Northern Ireland) on the viabilit
y of a glove and 3d computer
interface system for measuring range of movement in the hand.

The glove used in this system, known as Digitease, can accurately measure the
flexure
, extension, abduction and adduction in the patients hand and is able to
determi
ne the minimum and maximum joint range of a patient.

The system has been well received, winning the Innovative Idea of the Year award
for 2010 from HSC Innovations, the Technology Transfer Office for Health and Social
Care in Northern Ireland, showing tha
t there is an interest in systems for the
measurement of RA

(Curran, et al., 2011)
.

This completes the discussion of existing hand motion detection devices.


19


Chapter 3: Review of
Assessment Techniques


In this chapter the current methods for assessing
hand motion and function will be
discussed and the ability for these tests to be transposed into a computerised
solution.

3.1 Manual Assessment Techniques


The majority of hand function assessment tests for rheumatoid arthritis are manual

and involve the u
se of a range of instruments, most commonly a goniometer and a
tape
measure. The goniometer (Fig 10
) serves to measure the angle at the joints of
the hand to assess range of movement

and studies have shown that it is a very
effective measurement tool (
Hass
elkus

et al, 1981)
).

The primary use of the tape
measure in assessing the impact of rheumatoid arthritis on the hand is to measure
the distance between the tip of the finger and the palm of the hand when the finger
is fully bent. The use of these instrumen
ts undoubtedly allow the physician accurate
results, the process can be time consuming
. There is also the possibility of inaccurate
conclusions as to a patient’s range of motion resulting from inconsistent evaluations
due to the fact that same clinician ma
y not always be assessing the patient (
Curran
and Condell, 2010
). The creation of a standardised set of tests using a wearable
glove interface

can eliminate this possibility, however, due to the limitations in the
Peregrine Gaming Glove’s ability to assess

the angle of joint movement another
measurement scale must also be discussed.

To fully evaluate the severity of arthritis in a patient there are also a number of other
tests to be carried out. Grip strength is measured through t
he use of a dynamometer
(Fi
g 11
) which the patient much grip with their full hand and squeeze as hard as they
can. Patients with arthritis will score low in this test. Along with grip strength, pinch
strength is also measured using a device

known as a pinch meter (Fig 12
). As patien
ts
can suffer from a range of deformities in the joints of the hand, three types of pinch
are generally tested which allow the clinician to assess the effect of the patients
arthritis on their ability to perform typical daily tasks.

20



Figure
10
:

Goniometer being used to measure angle of
flexure

of index finger



Figure
11
:

Baseline
®

Standard Hydraulic dynamometer
being used to measure grip strength in a patient's right
hand





The pinches that are assessed are the tip pinch; evaluating the pinch strength
between the tip of the thumb and the tip of the index finger, the lateral pinch;
evaluating the pinch strength between the pad of the thumb and the
lateral
pad of
the index finger and the three
-
jaw chuck or palmer pinch; evaluating the pinch
strength
between the pad of the thumb and the pads of the i
ndex and middle fingers
(Fig 13
)

(
Vining Radomski and Trombly Latham, 2002
)
.

Figure
12
: Pinch Meter being used to
measure lateral pinch strength

21




The Kapandji score index is
the m
easure of ability to oppose thumb (both base and
tip) to palm and tips of other fingers

(
Inside Surgery, 2011
)
.

Studies have found it to be
reliable in assessing the range of movement of hands
affected by rheumatoid arthritis and have recommended it for use with a clinical
setting (
Lefevre
-
Colau
, 2003
). The Kapandji
scale evaluates the range of movement
of the patients hand by grading their
ability to touch each fingertip to their thumb tip
on a scale of 0
-
10

(
Condell et al, 2010
). Although the interface that will be created
will not have the ability to assess this scale in such a way, the Kapandji score is
especially suited to the capabiliti
es of the Peregrine Gaming Glove.
The test that will
be

developed for use
with the prototype glove system

will be based upon the
Kapandji scale tests.




Figure
13
: A: Three Jaw Chuck pinch test B: Lateral pinch test C: Tip pinch test

22


3.2 Invasive Assessment Techniques


RA

is a systemic inflammatory disorder which affects the synovial

joints, such as in
the hand, causing swelling and stiffness and a gradual erosion of the cartilage of the
joints. The deformation caused by the erosion coupled with the swelling makes
advanced cases such as these difficult to fully assess manually. In the
se cases more
invasive forms of assessment are carried, primarily X=rays and blood tests.

To accurately assess the erosion of the patients joints an invasive examination must
be performed on the patients hand. Digital X
-
rays

have been found to be effective in
assessing the degree of damage to a patients joints (Jawaid et al.
,2006
)
.

However the
NHS notes that some people still have concerns about be subjected to X
-
rays,
despite the low risk factor (NHS, 2010).

As RA is an inf
lammatory disorder, its presence and severity can be measured, in
many cases, by the presence of certain proteins in the blood. Many of these blood
tests, such as CRP (C reactive protein) are used to detect the severity of
inflammation as CRP is produced i
n higher levels when inflammation is present
(Panayi, G., 2003).

Blood tests are also used to detect auto
-
antibodies that be
present in the blood when patient's are suffering inflammation of the joints, these
are the rheumatoid factor (RF) and anti
-
CCP ant
ibodies. However, not all patients
suffering inflammation will have these antibodies present and indeed they may be
present in individuals who are not suffering from inflammation, therefore these tests
are not completely conclusive.
It can be hoped that by

studying advanced computer
based measurement and assessment methods that
inconclusive invasive tests such
as these can be avoided.

This completes the review of existing arthritis evaluation techniques.





23


Ch
apter
4
: Requirements Analysis


This section
will state the prob
lem this project will address and define a clear
solution for this problem and details the requirements of this solution in terms of :



Functional and non functional requirements



User requirements for both Patients and Clinician



Hardware
and software requirements for the final prototype


4.1 Problem Statement


Having defined the problem domain, this chapter and the proceeding ones, will state
a concrete set of use cases that will then be analysed and extracted into interfaces,
classes and
entities and then implemented to the chosen standard into a functional
prototype able to demonstrate full functionality as described by use cases.

A review of the existing approaches to computerised hand measurement systems
showed that there is currently n
o affordable system that can assist in the assessment
of arthritis and provide meaningful results.
This project aims to develop a functional
prototype that will use the functionality of the low cost Peregrine Gaming Glove that
can be used to assess how a
Patient is affected by arthritis.

The solution must also aim to reduce the need for Patients to have to travel to the
Clinician's clinic for regular system. Patients should be able to use the system at
home to perform tests, the results of which can be st
ored in a database that can be
accessed by the Clinician.

The results of the tests should be presented in a way that aids the Clinician in
assessing the effectiveness of a current treatment that the Patient is receiving by
identifying whether their condit
ion is worsening or improving.


24


4
.2

Functional Requirements of Glove Interface

4
.2
.1 Requirements for Patient


As the Peregrine gaming glove cannot detect real time motion of the hand it is
important to create an interface that will still be able to
provide the user with real
time information on how they are performing.

The interface must show the touch
points of the glove being activated and inform the Patient of the status of the test
,
including a feedback function that will inform the user whether
or not they have
completed the test
.

To show the link between the touch points shown in the
interface and the touch points of the glove, images of the actual glove should be
used.

The system should be able to accurately
record
and assess
individual test se
ssions
for multiple users
and each Patient must be able to view their own results.




4
.2
.2 Requirements for Clinician


Clinicians should be able to access the system to create new Patient profiles and to
retrieve specific test session results for any Pati
ent. The results should be displayed
in a format that will allow them to analyse and track a Patients progress. The format
should allow Clinicians to easily determine whether a Patient's condition is
improving or worsening.


4.3

Non Functional Requirements

of Glove Interface

4.
3
.1 Requirements for Patient


As arthritis can affect can affect all demographics the system should have options for
users to personalise the systems appearance for themselves. Tests should also be
developed
in a way that they take in
to account different types of sufferers, such as
25


different age groups and also the ranging severity of arthritis.
Because of this wide
range of sufferers different glove sizes should also be
available.

4.
3
.2 Requirements for Clinician


As with the patient view, the clinician should also be able to personalize the system
view for themselves.
The system should contain guidelines related to the pre
-
defined exercises which will allow the clinician to judge the severity of the patients
arthri
tis based on their performance of the exercises.


4.4 System Requirements


This section will describe the system requirements for the final prototype, in terms
of both hardware and software.

4.4.1 Software Requirements


The glove to be used with this proje
ct, the Peregrine Gaming Glove, is provided with
its own configuration software, GloveBox, which is compatible with both Windows
and Mac OS operating systems. The GloveBox configuration software is used to map
keyboard inputs to the touch points of the glo
ve. An interface will then be created
that will translate the inputs from the glove to a visual representation of the touch
point being activated. The application will be created using Microsoft Visual Studio,
using forms to drive and create the test inter
face.


The software required to create the prototype are:



Peregrine Glovebox configuration software



Microsoft Visual Studio 2010


26


4.4.2 Hardware Requirements


As the Peregrine gaming glove is a USB device, a computer that contains USB 2.0
slots is
required. USB 2.0 is preferred as it will transmit the information from the
glove at best possible speed. To run all of the software at least Windows Vista
operating system is required. The computers available at the university will be

suitable for this pr
oject as they utilise USB 2.0

and run on Windows 7
. The university
computers also comply with the minimum require
ments required to run the
GloveB
ox
Software:



Net Framework 1.1



Intel/AMD Processor




512 MB Ram



USB 1.1 or higher



10 MB
free hard drive space











27


C
hapter 5
:

Project Planning


As there are many different stages and components within this project, to ensure
timely and effective completion a project plan has been devised and will be adhered
to.

5.1 Milestones and Deliverables


To track the
progress of the overall project and to ensure that deadlines defined
within the project plan are being adhered to, key milestones have been set. The
milestones for the project are as follows:



Completion of review of existing literature



Completion of analys
is product requirements



Completion of design of measurable tests



Completion of design of interface



Completion of interim project report



Completion of prototype



Completion of testing of prototype



Analysis and evaluation of completed tests



Completion o
f final project report with conclusion

The milestones for the project will ensure that deadlines have been met however to
fully assess the project progress a set of deliverables have also been defined;



Interim project report including initial design



Workin
g prototype



Final project report



Presentation of report



28


5.2 Work Breakdown Structure


In order to improve time management, the milestones and deliverables must be
clearly designed to ensure that tasks are completed correctly and on time. To
understand
the structure of the project, a work breakdown structure has been
created.















Figure
14
:

Work Breakdown Structure



Interim Report


(Task 1)


Final Project Report

Background review
(Task 1.1)

(

Design (Task 1.2)

Develop prototype

(Task 2)

Evaluation (Task 3)


Review of
existing research
(Task
1.1.1)


Review of

existing methods
(Task 1.1.2)

Design of
measuring
techniques

(Task 1.2.1)

Design of user
interface

(Task 1.2.2)

Research and
choose
application
language and
development
environment


(Task 2.1)

Develop user
int
erface

(Task 2.3)


Develop
measurement
exercises

(Task

2.2.)

Test accuracy of

measurement


(Task 3.1)

Evaluate against
requirements


(Task 3.2)

29


5.3 Time Management



Figure
15
:

Microsoft Project Gantt Chart


Figure 15 reflects how the Tasks defined in the Work Breakdown Structure (Fig 14)
will be managed with the

time available.


5.4 Risk Management


To ensure the delivery of my project on time I must identify and analyse the impact
of any potential risks and plan how to manage these risks. There are two types of
risks that must be considered during this project,
event
-
driven risks and evolving

risks.

Examples of event
-
driven risks and their management are:



Computer malfunction resulting in loss of work: To manage this risk I will
ensure to save my work often and make up
-
to
-
date copies in several
locations



Persona
l illness: As I cannot foresee an event like this I will try to ensure I
remain ahead of schedule to ensure I do not lose too much time if this event

30


occurs

Examples of evolving risks and their management are:



Falling behind on schedule: Continually missi
ng deadlines. To avoid this I will
attempt to stick as closely as possible to my project plan and if this does
occur I will
re
-
evaluate

the scope of my projects and adjust my tasks
accordingly.






31


C
hapter
6:

Design


The following chapter will cover the
design

of the final prototype, both in terms of
application and interface design.
The application is designed using

an object
orientated approach
with a reusable set of base test classes and interfaces that can
be utilised for any test configuration that i
s within the scope of the Peregrine Glove.

The types of tests that will be performed on the prototype system will also be
designed in order to ensure that the tests provide a sufficient overview of the
capabilities of the Peregrine Gaming Glove as a clinic
al tool and also provide relevant
results.

6.1

Application Design


The application will be
outlined in a high level architecture
which

will then be
decomposed into an overall view

of the classes and interfaces that will make up the
system. Individual use c
ases will be drawn up for each interaction that the proposed
prototype will offer, describing how the classes and interfaces are used.


6.1.1 Architecture

Design




Figure
16
:

High Level View of System Architecture


Glove

PC running
Glove system


DB

PC running
Database

32



Figure 1
6

shows a high level architecture view comprising of the core components of
the application. To summarise this diagram, the glove will be attached to a PC (or
laptop) on which the system is installed. User profiles and test results will be stored
on a datab
ase that will be stored on a SQL server which each PC will be connected
via a network. Users that are unable to connect to the network locally will be able to
connect to the network via the internet.




Figure
17
:

Detailed Architecture

of Proposed System


Figure 1
7

provides a view of the architecture of
the
proposed prototype. The
application will consist of 3 distinct layers, a data layer which will contain the
Data Layer

Backend

Frontend

33


database and the
DbModel
class that will create the tables on the database using
the entities
which communicate directly with the backend. The backend contains the
methods and classes that are used to communicate User interactions from the
frontend
forms
of the system to the datab
ase.

Detailed descriptions of how these
components will interact with each other in the final prototype are contained in the
following section, System Interaction Design.


6.1.2

System Interaction Design


This section contains UML system interaction
diagrams which will demonstrate how
the components contained within the system architecture diagram interact.


Figure
18
:

System component interaction design for Patient interaction


34


Figure 1
8

shows the system components interact during the Patient interactions. The
test interface will contain the required entities and methods that will be used by any
test that can be designed for the Peregrine Glove system. The KanpandjiTest:GUI will
be a form

that will display the Patient's actions as they perform the test on the
Glove. All the measurements recorded during the session will then be processed by
the TestInterface methods and entered into the database as a new Test Session.


Figure
19
:

System component interaction during Clinician interaction

Figure 1
9

shows the interaction of the system components during a Clinician
Interaction. Once the Clinician Login credentials have been validated by the
LogonHelper Logon method they

will presented with the ChooseAction Form
(ChooseActio
n:GUI) from which

they can choose from the following options:



Create a new user



View test results

The CreateUser:GUI form will utilise the LogonHelper class which will contain
s

the
create and delete me
thods required.

35


Selecting the View Results option will load the Reports:GUI form which will contain
options for defining the parameters of the results the Clinician wishes to view, i.e.
Patient username and date range. The form will contain a method which

will query
the database with the selected parameters and return these for the Clinician to
examine.

The Login
screen

will allow users to enter their user credentials, a username and
password, the Backend will then call
the logon manager

that will compare
the user
credentials against the Database. If the credentials entered are invalid the user will
be prompted to create a new user if they do not have a user profile. Once a new user
is created the user
must then return to the Login
screen
.
If the credential
s entered
are correct, functions in the Backe
nd will then call the relevant Options component

based on the user type. If the user is a Patient then the user will be directed to the
Patient Options component where they can choose a test
, if the user is a Cl
inician
then they will then be directed to the
Clinician Options component which will allow
them to access the Create User
and Results form
.

The Kapandji Test Component will accept the actions performed on the Glove and
pass these to the Backend which wil
l use the measurement evaluation method to
evaluate the results which will then be sent to the database.

The Create User component will send the user information entered into the form to
the Backend which will then save the information as a new User entry.

T
he Reports component allows a Clinician
to view results of stored tests by
defining
parameters with
in

which to query the database.






36


6.
2.1

Database Design


This section discusses the design of the database, detailing what information it must
contain and any restrictions that must be placed on it.

The database is modelled via the entity framework CF (Code First) approach,
meaning that the entities c# represen
tation will form the direct basis for EF
to create
the database on demand
.

The
database will be required to store all user profiles and all test results created by
Patients. It must be stored on a server to allow users to connect to the database to
both s
tore and retrieve results from their chosen location.

The tables below detail
the tables that will be created in
t
he database.

User Table:

Column Name

Data Type

Description

ID {Primary Key}

GUID

The system will use this to identify users
-

this will be
unique for each user

First name

String

Users
first name

Last name

String

U
sers last name

Username

String

Username

the user has created
-

part of the users log
on credentials and used to validate an existing user
profile

Password

String

P
ass word the user has created
-

part the users log on
credentials that will validate the users log on

T
able
1

Proposed User Data Table

Test Sessions Table

Column Name

Data Type

Description

ID {Primary Key}

GUID

Uniquely identifies

each test performed

Start Time

Date/Time

Date and time at which the test was performed

Completed Time

Date/Time

Date and time
at which the test was completed

User ID

{Foreign
Key}

String

ID of the user performing the test
-

this column will be
related to the ID column of the Users table and will be
populated with the ID of the current user

Table
2

Proposed Test Sessions Data Tab
le





37


Measurements Table

Column Name

Data Type

Description

ID {Primary Key}

GUID

Uniquely identifies each measurement

Time

Date/Time

Date and time at which the measurement was recorded

Value

Int

Numeric value which
identifies measurement types
such as start time and end time measurement

Session ID

String

ID of the session to which the measurement belongs




Table
3
: Proposed Measurement Data Table


38


6.
3

User
Interaction

Design


The
system architect
ure gives a high level
view of navigation through the application
.
However the key requirement of the prototype was that it contained different views
of the system for the Patient and Clinician users. Both user types perform different
inter
actions with the
application
. T
his section will provide

UML diagrams
that
describe the different functions of the
application

for each interaction

type
.



Figure
20
:

UML Activity Model of User Interaction



39


Figure
20

shows a typical Patient user interaction. The system will evaluate the user
type on login and if the profile is identified as user type Patient the test screen will
appear.

The Patient then perform
s

a test and the results from this session will be
saved t
o the database.


Figure
21
:

UML Activity Model of Clinician Interaction

Figure

2
1

shows a typical Clinician interaction. The system will evaluate the
credentials on login and if the profile is identified as user type Clinician the results
screen will appear.

40


6.4

User Interface Design


This section will cover the design of the user inte
rface and will discuss aspects of HCI
(Human Computer Interaction) that must be considered.

A
well designed user
interface is
crucial
to the success of the project. The proposed system must be
suitable for use by both Clinicians and Patients who are assumed

to have no
technical background. Therefore it must be easily understood and friendly to both
user types.


Figure
22
:
Login Screen Design


Figure
2
2

shows the proposed design for the Login screen. The user is given the
choice to either enter their user credentials to access the system, create a new user
profile if they do not have one, or leave the system without logging in. Once the user
enters their

user credentials and presses the 'Login' button the system will validate
these and perform one of 3 actions:



If the combination is invalid the user will be asked to make a new user profile
or re
-
enter their credentials in case of typing errors



If the prof
ile is validated as a Patient profile the user will be granted access to
the system and the
Patient Options
form

will appear

Please Enter Your Username and Password to Proceed

Username

Password

Login

Exit

41




If the profile is validated as a Clinician profile the user will be granted access
to the system and the
Clinician Options
form

wil
l appear







Figure
23
:
Patient Options Form Design

Figure 2
3

shows the design for the Patient Options form. This form will allow the
Patient to either select a test to perform or view their previous test results.







Figure
24
:
Clinician Options Form Design

Figure 2
4

shows the design for the Clinician Options form. This form will allow
the Clinician to:



O
pen the Create User form and create a
new
Patient profil
e




Open the View Results form and view res
ults for a selected Patient and
date range


Welcome

Select an Option

Create User

Delete User

View Results

Kapandji Test

View Results

Welcome

Select an Option

42



Figure
25
:
Uncompleted Test Screen Design











Figure
26
:
Design of Completed Kapandji Test


Figures 2
5

and 2
6

shows the proposed design for the
Glove

T
est screen before and
after a test has been performed
. It is assumed that Patient
s will have been instructed
on how to perform the tests before they receive the system and therefore will not
need any

further
instr
uct
ions.

To conform to HCI standards colours have been used
Exit

00:00

[Patient name]

Exit

00:00

[Patient name]

43


to indicate status changes, in this instance the status change is from red for 'not
touched' and gre
en for 'touched'
.

Figure
27
:
Proposed Create User Form Design



Figure 2
7

shows the design for the Create User form. To ensure only authorised
Patients have access to the system Create
User form will only be able to accessed by
a Clinician with an existing profile. The form will allow a Clinician to create a Patient
profile and set a username and password for the profile.



Create a New User

First Name

Last Name

Username

Password

44











Figure
28
:
Test Results Design

Figure 2
8

shows the proposed design for the View Results form. The proposed
system must allow Clinicians to view specific Patients' data in a easily understood
and
us
eful

format.

The amount of time the Patient uses the system is determined by the Clinician and
could be for an indefinite period, therefore an indefinite number of test sessions
may be performed. Clinicians may not wish nor need to see every test that the

Patient has performed and this data could also result in a difficult to view report.

To allow Clinicians to only view the test s
ession results that they feel are

relevant,
the Clinician will be able to choose a range of session results from a dropdown me
nu
listing the dates of every session performed by each Patient.







Patient Name

Start Date

End Date

Exit

Update

Patient Name

0
1
2
3
4
5
6
7
Time Taken

45


Chapter 7: Implementation


The prototype was developed
follow
ing

the standard c# naming and coding stan
dard
(Cwalina et al
-

2008),
to adhere to a separation of concerns while designing
a robust
prototype, that can later form the basis of a real world production software.

Tools available

from the Microsoft palette

were used
,
however
the application could
have been developed using

any group of tools offering the functionality of Database,
Managed, Persistence
, Reporting and Frontend that were

obtained here from Sql
Server, .Net, Entity Framework, SSRS and WinForms.

7.1 Database Implementation


It was decided before the design was created that the application would

use an o
bject orientated approach.
This approach has been maintained throughout
the implementation, including in the creation of the database. The database makes
use of Microsoft's Entity Framework, using entities within the application to create a
database model
that can be implemented on
most

database management system
s
.


For the Peregrine

Glove

Arthritis

Treatment

Assessment System

(referred to from
this point as PGATAS)

prototype the model has been implemented on SQL Server
Management Studio 2012.


46



Figure
29
:
Database Model


Figure
29

shows the

database model generated from SQL Management Server 2012
.
The model
consists
of
4
tables

each one with a primary key

and
foreign key

that is
used to relate the table
s

to one another
.



GloveProfiles
Id
uniquei...
No
Name
nvarcha...
Yes
GBProfile
nvarcha...
Yes
GBKeymap
nvarcha...
Yes
ActivatorPad
nvarcha...
Yes
Column Name
Data Type
Nullable
Measurements
Id
uniquei...
No
Time
datetime
No
Value
int
No
Session_Id
uniquei...
No
Column Name
Data Type
Nullable
TestSessions
Id
uniquei...
No
CompletedTi...
datetime
No
StartTime
datetime
No
User_Id
uniquei...
No
GloveProfile_...
uniquei...
No
Column Name
Data Type
Nullable
Users
Id
uniquei...
No
FirstName
nvarcha...
Yes
LastName
nvarcha...
Yes
TypeValue
int
No
UserName
nvarcha...
Yes
Password
nvarcha...
Yes
Column Name
Data Type
Nullable
47


The aim of the
PGATAS

is to store and present comprehensive test data that can be
used to assess the se
verity of a patients arthritis.T
ables

shown

in
Figure
29

contain
all the data that is required to produce accurate measurements.



The User table contains
all the data that is used to create a login that is
unique to each User and also contains a unique key that can be used to
identify Test Sessions performed by a specific Patient.



The Measurements table collects data about each measurement taken during
a te
st which is then evaluated to ensure that all measurements are valid (this
will be further explained in the Test Implementation section. Valid
measurements are then analysed and sent to the TestSessions table.



The GloveProfiles table identifies what profil
e and keymap have been used to
create the keys for the test in the GloveBox configuration software. This will
be further explained in the Glove Implementation section.


7.2 Login and Options Implementation


One of the key requirements of the

PGATAS
is that

the system must be able to
identify a user not only by their login credentials (username and password) but also
by their type and present different usage scenarios for each type. The section will
explain how a successful login is performed, both in terms
of the users visible
interactions and the entities and classes used by the system.

When the application starts up the Main form, which contains
the
Main

class,

which

in turn

contains the

navigat
ion methods for the application.

F

ull source code
of th
e
Main

class

is in

Appendix 1.

Main

opens
a new
Login form. The Login form is a Windows form that contains
textboxes for the user to enter their Login credentials and an 'Ok' button to confirm
the details entered. The form
has

an 'Exit' button to allow the

user to quit the
application.

48


If the details are correct the user will be presented with the relevant options screen,
if not then the user is prompted to re
-
enter their credentials
, if they are correct they
will be directed to the PatientTestOptions scree
n
. The following code provides
this
functionality to the Login Form
:

User user = LogonHelper.LogonUser(usernameTb.Text, passwordTb.Text);

if (user == null)


MessageBox.Show("Username password combination invalid
-

Please re
-

enter your user credentia
ls");

else

{


Task.Factory.StartNew(_action, user);


Close();

}


Login profile types are indentified and the correct Options screen loaded within the
Main

form The following code fragment is the method which controls the options
the application that

the User is presented with.

switch((user as User).Type)

{


case UserType.Patient:


new PatientOptions(OnPatientOptionSelection).ShowDialog();


return;


case UserType.Clinician:


new ClinicianOptions().ShowDialog();


r
eturn;


default:


throw new NotImplementedException(string.Format("Did not implement
handling of userType:{0}", (user as User).Type));

}


To see the full source code
f
or

the L
ogin form, see Appendix 2
.


7.3 Create User

Function

Implementation


This section shows how the Create User function has been implemented. The
CreateUser Form will be accessible by Clinician Users, who will be able to create a
full Patient profile.

49


The
CreateUser
form will contain
textboxes

into which the Clinician will ent
er the
information required to create a User profile. Each User profile must have a
Username and Password, which will become th
e Users login credentials and a f
irst

name and l
ast

name. Clicking 'Create' button will not be enabled until all the
textboxes ha
ve been populated.

The following code provides this function
, which prevents an incomplete User profile
being added to the database.


private void InputTextChanged(object sender, EventArgs e)


{


okB.Enabled = !(string.IsNullOrEmpty(use
rnameTb.Text) ||
string.IsNullOrEmpty(passwordTb.Text));


}


When the 'Create' button is clicked, the
SaveUser

method is called from the
LogonHelper

class to save the new User profile to the database. If the username
entered by the Clinician already exists, an exception will be throw
n
, stopping the
duplicate username being added to the database and prompting the Clinician to
create a new username. The

following code excerpt demonstrate
s

this functionality.

private void createB_Click(object sender, EventArgs e)


{


User user = new User();


user.FirstName = firstnameTb.Text;


user.LastName = lastnameTb.Text;


user.Password = passwordTb.Text;


user.UserName = usernameTb.Text;


user.Type = (UserType) Enum.Parse(typeof(UserType),
(userTypeCb.SelectedItem as string));



try


{


LogonHelper.SaveU
ser(user);


User = user;


DialogResult = System.Windows.Forms.DialogResult.OK;


Close();


}


catch (ArgumentException)


{


MessageBox.Show("A user with that name a
lready exists
-

try
another");


}


}


50


7.
4

Glove
Keymap



The Peregrine Gaming Glove is packaged with a bespoke software called GloveBox
Configuration. This software allows a user to create 'keymaps' by assigning keyboard
inputs to each
touch
point on the glove
and assign these points to an activation pad.
When the touch point is connected to the activation pad the keyboard inputs will be
registered by the computer.

To create the two tests that the prototype will contain, two separ
ate key
maps have
been created

assigned to two separate activator pads
.






Figures
3
0

and 3
1

show the GloveBox configuration software with the keystrokes
assigned to the relevant
touch points
. The KapandjiTest keystrokes
, 'q, w, e, r, t, y, u,
i'

are activated using the '
thump tip
' activator pad and the
Flexure
Test

keystrokes
,
'a, s, d,

f'

are activated using the 'palm' activator pad.

As both
hand tests

simply use a slightly different mapping but in a similar way,
mappings
key presses

to the visible
touch points

in each test, the
IControlMapper

interface has been created.

Figure
30
:
KapandjiTest Keymap
-

Thump tip Activator pad used

Figure
31
: Flexure
Test Keymap
-

Palm
Activator pad used

51


Each test will contain a definition of the method
LookupControl(char c)

where
c

can
be overwritten

when the
IControlMapper

is implemented
.
The

LookupControl()

method is then inherited by the
Flexure
ControlMapper

and the
KapandjiControlMapper

which assign t
heir own values to c. When a test it
instantiated by the user,
the test code is able to use the value for
char c

to map each
keystroke value to the relevant
touch points

visible to the User.
The below code
excerpt

shows the declaration of
LookupControl(char c)

in the
IControlMapper

interface.

T
he keymaps defined in the
ControlMapper

classes match their relevant
Glove
B
ox keymaps.

For full source code of both
ControlMapper

classes see
Appendi
ces 5 and 6
.

public interface IControlMapper


{


Control LookupControl(char c);


}



7.
5