A GENERAL-PURPOSE TOOL FOR DOCUMENTING

DISTRIBUTED LABORATORY ASSAYS

Patrick Arnold, Oliver Kusche

Institute for Applied Computer Science, Forschungszentrum Karlsruhe, 76344 Eggenstein Leopoldshafen, Germany

Andreas Schmidt

Department of Computer Science and Business Information Systems, Moltkestrasse 30, 76133 Karlsruhe, Germany

Keywords:

Ad-hoc workﬂows, LIMS system, activity coordination.

Abstract:

In the context of a publicly funded cooperative project aimed at the assessment of potential risks related to

nanoparticles, a general-purpose system for documenting the laboratory assays is presented. The system is

designed to enable users distributed over various organizations to jointly document their activities, yielding a

data base that allows for the reproducibility of the entire lifecyle of any given specimen. As requirements and

activities are constantly evolving, the concept is focused on a ﬂexible approach where new activity types can

be added and conﬁgured at runtime.

1 INTRODUCTION

The Nano Care project funded by BMBF (Federal

Ministry of Education and Research) is aimed at gen-

erating new scientiﬁc ﬁndings with respect to poten-

tial impacts of nanoparticles on man and the environ-

ment. The participating research centres, universi-

ties, and industry partners study the toxicity of various

synthetic nanoparticles and develop highly innovative

applications and measurement methods for a preven-

tative and sustainable use of nanotechnology.

The Institute for Applied Computer Science sup-

plies the information technology platform for this

project. This platform shall ensure communication

and knowledge transfer both within the project and to

the public. The major component of this platform is

a web-based application that offers comfortable data

acquisition similar to a laboratory information man-

agement system (LIMS) in order to document the

complete lifecycle of the nanoscaled materials stud-

ied under the project.

2 REQUIREMENTS

The system should have a high ﬂexibility in meeting

new and changing requirements made by the individ-

ual project partners, in particular as far as newly de-

veloped measurement methods are concerned. Other

requirements result from the variety of laboratories

that are spatially distributed over a number of enter-

prises and research institutions. The application shall

be executed independently of the computer platform

used by the user and access a central database. As the

institutions compete with each other outside of this

joint project, authorisation and authentication are big

concerns and thus a mature and ﬂexible role concept

is required to restrict access to conﬁdential informa-

tion.

Research of already existing systems revealed that

most of the necessary functions are covered by com-

mercial and freely available software. However, no

system was found that meets all requirements, as

existing laboratory information management systems

mostly are centred in enterprises. It was therefore de-

cided to develop an own system. To the extent possi-

ble, existing components shall be applied to minimize

the time needed for implementation, as these compo-

nents have already been tested and, hence, are free of

defects.

Moreover, an appropriate framework shall be used

as the basic structure for development, which makes

available solutions for general routine tasks and,

hence, allows for the maximum attention being paid

to the implementation of the business logic.

301

Arnold P., Kusche O. and Schmidt A. (2008).

A GENERAL-PURPOSE TOOL FOR DOCUMENTING DISTRIBUTED LABORATORY ASSAYS.

In Proceedings of the Tenth International Conference on Enterprise Information Systems, pages 301-304

DOI: 10.5220/0001734303010304

 SciTePress

3 CONCEPT

A generic approach was chosen, where no predeﬁned

workﬂow templates are given, but activities can be

documented ﬂexibly in the form of ad-hoc workﬂows

with a few restrictions only, which can be formulated

at runtime (e.g. by an administrator). In line with

concepts known from LIMS, it is planned to design

a measurement line to acquire and store the measure-

ment values and a control line for assay management

and data evaluation.

Modelling shall focus on the activity that repre-

sents a concrete process step in the measurement line,

such as fabrication, separation, or characterization of

a specimen. By linking these activities, various types

of workﬂows can be generated. As already men-

tioned, there are no predeﬁned workﬂows. They are

created by user inputs during the runtime of the sys-

tem.

3.1 Deﬁnition of Activity Types and

their Properties

To generally describe an activity, an activity type is

deﬁned, which speciﬁes the properties and behaviour

of its later activity instances. A property is mod-

elled by the entity AttributeType (Figure 1) and, for

instance, contains information about the data type of

this property (text, number, Boolean value, or others)

and about whether it may assume multiple values or is

mandatory. With Unit, it is possible to choose a unit

for later values of this attribute type. In this way, an

attribute type named Temperature with the data type

Number be assigned the unit ”

◦

C ”. If user input from

a pre-deﬁned list is required as opposed to input of

arbitrary data for a certain attribute type, these values

may be deﬁned using the entity DefaultValues.

For a better handling, the attribute types may be

grouped into categories that are represented by the en-

tity AttributeCategory.

ActivityType

has

<0:n>

<1:1>

AttributeType

DefaultValue

has

<1:1>

AttributeCategory

belongs

<0:n>

Unit

<1:1>

has

<0:n>

<1:1>

is_multivalue

is_mandatory

data_type

<0:n>

Figure 1: ER model for activity type deﬁnition.

3.2 Deﬁnition of Specimen Types

An activity in the measurement line always is carried

out on an object, in this concrete project, a sample

of synthetically produced nanoparticles, for instance.

These are produced in larger amounts, but may be di-

vided into any number of, also divisible, sub-sets dur-

ing their lifecycle (Figure 2). The system allows for

the deﬁnition of any specimen types, e.g. a hierar-

chical structure of batches and subordinate lots and

assays.

Material A

Assay A

Batch A Batch B

Assay DAssay C

Assay B

...

Figure 2: Division of a batch into assays.

3.3 Rules for Linking Activities

Using activity and specimen types, it is now possi-

ble to formulate rules for the linking of activities.

Figure 3 shows the respective model. Depending on

these rules, a set of possible activities is generated,

which can be carried out on a certain specimen. From

the point of view of application, such a rule may be

as follows:

• Following the activity Shipping, an activity of Ac-

ceptance of the good is required, another succes-

sive activity is not considered.

• Shipping may only be accomplished for the spec-

imen type of Assay or Lot, as a complete batch

shall never be shipped.

3.4 Runtime

After having shown how the behaviour and the prop-

erties may be conﬁgured to create a workﬂow, it shall

now be dealt with the modelling of the components

required during runtime (Figure 4). These are real

instances of specimens and activities as well as a re-

lationship between the activity and the attribute type.

The relationship represents the value (e.g. recorded

measurement value) of a certain attribute type (e.g.

ICEIS 2008 - International Conference on Enterprise Information Systems

302

ActivityType

is possible

after

SpecimenType

<0:n>

is possible

<0:n>

Figure 3: Rules for linking activities.

temperature) that is speciﬁed by the activity (e.g.

characterization) using the specimen.

The input of the activity always is a specimen. The

output may include one or several (in case of a sepa-

ration) specimens. An exception is the initial activ-

ity which represents the starting point of the measure-

ment line.

An activity may be provided with any number

of attributes that have to correspond to a previously

deﬁned value range (string, decimal, selection list).

In addition, one or several documents and/or images

may be added to an attribute.

ActivityType

instance

Specimen

SpecimenType

instance

<0:n>

has

value

<0:n>

output

input

value

consists

<0:

<0:n>

<0:

Figure 4: Model-metamodel-relation.

Since activity, specimen and attribute types are ex-

plicitly modelled as entities, new ones can be created

and/or modiﬁed at runtime and thus new use cases can

be addressed just by conﬁguration without the need of

modifying the application code. In this way, require-

ments occurring in the course of the project only in

terms of new or existing activity types or their proper-

ties may be addressed easily e.g. by an administrator

via a specialised back-end.

4 IMPLEMENTATION

As the users of the application are distributed over

various sites and organisations, a web-based solu-

tion was chosen, which can be run nearly indepen-

dently of the user platform. The software is executed

on a web server within an Apache Tomcat servlet

container (Brittain and Darwin, 2007) and can be

accessed via the internet using a conventional web

browser.

The basic framework of the multi-layer software

architecture was generated with the help of the web

framework AppFuse (Raible, 2007), which in turn

heavily relies on the Spring (Walls and Breidenbach,

2007) and Hibernate (Bauer and King, 2006) frame-

works. Its prototyping functionality allows to most

rapidly implement requirements and to early and per-

manently verify features of the software by test-driven

methods. The generated, but already executable arte-

facts are used as a basis of the implementation of the

business logic. For managing row-level security, the

Spring Security framework (Interface21, 2007) has

been employed.

5 USE CASES

Figure 5 shows a typical case of application in a sim-

pliﬁed manner. Partner A produces a batch of a ma-

terial that shall be studied within the project. This

is documented by the creation of the initial activity

Manufacturein the system. Doing this, a unique batch

number is given (BH-1). Of this batch, three samples

shall be separated ﬁrst, one of which shall be shipped

for being investigated. The execution of the activ-

ity Shipping generates an e-mail to the recipient of

the sample, partner B, who documents the receipt of

the good in the system. For the characterization of

the material, another sample is separated. The data

obtained by the characterization are recorded as at-

tributes of the activity Characterization. Then, the

original sample is shipped further to partner C, where

a biological investigation is made that is also docu-

mented as an activity with the respective attributes.

By recording all relevant activities, the corre-

sponding attributes as well as the relationships of the

specimens to each other, the lifecycle of each individ-

A GENERAL-PURPOSE TOOL FOR DOCUMENTING DISTRIBUTED LABORATORY ASSAYS

303

Manufacture

BH-1

Separating Shipping Receipt

SP-2

SP-4

Charakter-

isation

Separating

SP-3 SP-7

SP-8

Tox

Evaluation

is Input

or Output of

is Predecessor of

Specimen

Activity

Material

Sender Date ...

Attribute

Partner A Partner B

Separating

SP-5

SP-6

Shipping

Sender

Receipt

Date

Partner C

...

Specimens

Receiver Receiver

Figure 5: Example workﬂow.

ual specimen can be reproduced at any time, including

its origin from a certain batch or assay.

6 SUMMARY AND OUTLOOK

The system described allows for a generic documen-

tation of the complete lifecycle of a material sam-

ple. By the ﬂexible modelling of the system, it is

possible to rapidly respond to changing requirements

and to quickly supply extended functions. For exam-

ple, new activity types can be added during runtime

and conﬁgured with the corresponding attributes and

rules, which are then available immediately. Within

the NanoCareproject, this system will be used to doc-

ument the activities with respect to the investigation

of materials and, hence, to support the reproducibility

of the scientiﬁc results obtained from the physical and

biological studies.

For further enhanced ﬂexibility, it is foreseen to

add scripting capabilities (Kearns, 2002) in order to

enable customising of new activity types with speciﬁc

behaviour.

To allow for a largely intuitive operation of the

system, further efforts are currently underway to op-

timise the user interface in terms of usability (Betche,

2008).

REFERENCES

Bauer, C. and King, G. (2006). Java Persistence with Hi-

bernate. Manning, Greenwich, CT.

Betche, K. (2008). Gegen¨uberstellung etablierter

Methoden zur Evaluation der Gebrauchstauglichkeit

von Software-Anwendungen sowie Konzeption einer

Usability-Studie anhand einer gegebenen Software.

Master’s thesis, University of Cooperative Education,

Karlsruhe.

Brittain, J. and Darwin, I. (2007). Tomcat: The Deﬁnitive

Guide. O’Reilly, Sebastopol, CA.

Interface21 (2007). Acegi security [computer software].

http://www.acegisecurity.org/.

Kearns, D. (2002). Java scripting languages: Which is right

for you? http://www.javaworld.com/javaworld/jw-04-

2002/jw-0405-scripts.html.

Raible, M. (2007). Appfuse [computer software].

http://www.appfuse.org/.

Walls, C. and Breidenbach, R. (2007). Java Persistence with

Hibernate. Manning, Greenwich, CT.

ICEIS 2008 - International Conference on Enterprise Information Systems

304