A Flexible Framework for Managing Temporal Clinical Trial Data

Transcription

1 A Flexible Framework for Managing Temporal Clinical Trial Data Michael Souillard (1,3), Carine Souveyet (1), Costas Vassilakis (2), Anya Sotiropoulou (2) (1) Centre Recherche Informatique Universite Paris I Sorbonne 90, rue Tolbiac Paris France Tel. : (33) Fax : (33) (2) Department of Informatics University of Athens Panepistimioupolis, TYPA Build Athens Greece Tel : (30) Fax : (30) (3) Matra Systemes & Informations Parc d'affaire des portes BP Val de Reuil France Tel. : (33) Fax : (33) s: [email protected], [email protected], {costas, anya}@di.uoa.gr Abstract Clinical trials are processes that produce large volumes of complex data, with inherent temporal requirements, since the state of patients evolves during the trials, and the data acquisition phase itself needs to be monitored. Additionally, since the requirements for all clinical trials have a significant common portion, it is desirable to capture these common requirements in a generalised framework, which will be instantiated for each specific trial by supplementing the trial-specific requirements. In this paper, we present an integral approach to clinical trial management, using a temporal object-oriented methodology to capture and model the requirements, a temporal OODBMS for data storage and a generalised template application, through which trial-specific applications may be generated. Keywords Temporal databases, Object-oriented databases, Medical systems 1. Introduction During the last years temporal databases have attracted the interest not only of the database community, but also of certain application fields, such as economics or medicine, where requirements include time reasoning and representation of temporal information. This interest resulted to the organisation of two international Workshops (in Texas, June 1993 and in Zurich, September 1995), and one international seminar (in Dagstuhl, June 1997). Also a book was written (Tansel, Clifford et. al, 1993) and a number of proposals (Wu, Jajodia and Wang, 1997) and implementations (Boehlen, 1995) of temporal database systems have been presented in the literature. On the other hand, medical informatics is a field that exploits computer science results to facilitate the work of researchers in the different medicine areas. The requirements of those research areas include manipulation of highly complex information that may evolve with time. For this reason, temporal databases have had a number of applications in this field, as outlined in (Combi and Shahar, 1997) and in (Shahar and Combi, 1997). Additionally the complexity of the information indicates that a powerful and flexible data model, such as the object-oriented one, should be employed. 1

2 In this paper we present a temporal extension to an object-oriented database and a Temporal Object-Oriented Methodology (TOOM), that can be combined to support an application in the clinical research area. The temporal extension can be plugged into any ODMG-compliant OODBMS, formulating thus a TOODBMS, and it has been designed to handle non-temporal and temporal data in a uniform manner. TOOM which is compatible to the UML objectoriented methodology is powerful enough to capture and model the temporal requirements of such an application. The TOODBMS and the TOOM have been used to model and implement a template application that focuses on protocol-based research on drugs, but its scope can extend to cover most medical applications with temporal requirements. The template application is used to generate applications that are specific to the trial that is going to take place. That is, depending on the information supplied by the user, an application for asthma or for gastric trials may be generated. The remnant of this paper is structured as follows. In section 2, the test case, which has been implemented over the TOODBMS, is described and its temporal requirements are pointed out. In section 3, the TOODBMS components and the TOOM are described, and their suitability in meeting the application requirements is shown. Section 4 describes the template application and the generation of the trial applications. Finally, in section 5 the conclusions are drawn and future work regarding medical applications with temporal characteristics is outlined. 2. Clinical Research context Clinical Research is one of the medicine research fields where temporal requirements are of major concern (Shahar, 1997, Shahar and Musen, 1996). In the following sections we will describe the context and roles of the application, in the domain of clinical research. This application has been introduced in an earlier phase in (Souillard and Pollet, 1997) and its results have been presented in (Souillard, Vassilakis and Sotiropoulou, 1998). We also present the requirements regarding temporal data management and temporal reasoning Data Management of Clinical Trials Introduction of the Clinical Trial Management System The Clinical Research domain covers a large range of areas like cardiology, infectious diseases, paediatrics and so on, and thus a wide variety of applications. In this paper, the target area is the Clinical Trials where certain drugs are tested on selected patients, in order to evaluate the efficiency of certain treatments. 2

3 Trial Preparation Trial Planning Trial Monitoring Trial Management Trial Data Management Figure 1 - The Clinical Trial Management System The Clinical Trial Management System can be split in five parts as shown in Figure 1: The trial-planning phase is responsible for initialising the clinical trial, and it is followed by the trial preparation and the trial-reporting phase. The trial preparation phase includes the preparation of the products, the budget specification, the selection of the clinical centres where patients will be monitored, the finalisation of contractual documents as for instance the observation notebooks, and so on. The monitoring of the trial is composed of patients visits to the centres and their investigators, and the monitoring of the patients and the observation notebooks. The trial data management module is responsible for the management of data collected from the clinical trial: data is retrieved from the observation notebooks and its coherency is verified, in order to prepare a clean database for the evaluation and reporting of the trial. Finally, trial management is mainly responsible for the reporting of different previous modules, and the evaluation of the clinical trial. In the system presented here, we focus on the data management module in which data from the patients observation notebooks are inserted into the system and manipulated Overview of the data management module As previously stated, in the data management phase, data from the patients observation notebooks are entered into the system. Their correctness is verified, so as to produce a clean database, which is suitable for the biostatistic analysis and evaluation report tasks. Figure 2 presents an overview of the data management system. 3

4 Acquisition keyboarders double dependant acquisition acquisition data exportation SAS application observation notebooks feedback of consistency checks Management system of trial #xxx - clarification process - quality audit inputs - data consultation - coherency error - quality audit outputs - consultation results Biostatisticians Investigators & Patients DCF correction DCF emission DataManagement operator DCF: Data Clarification Form Figure 2 - Overview of the data management system The first task performed is the acquisition of the information collected in the clinical centres. This information has been written on the observation notebooks by the investigators and/or the patients. To store the information in the data management system, and to minimise the acquisition errors, two different keyboarders perform a double-dependent data entry. The second keyboarder performs his task with no knowledge of the values entered by the first keyboarder, but if the value he is entering is different from the one entered by the first keyboarder, then he has to choose which of the two values is correct. The second keyboarder chooses which value to keep in case of inconsistency between the first and second acquisition. When some data have been stored into the system, the data clarification process may start. Data management operators launch coherency checks. When incoherence errors are detected, Data Clarification Forms DCFs are emitted by the system. These DCFs are sent to the investigator responsible for the patient for whom the error has been detected, in order to resolve this incoherence. Subsequently, the corrected DCFs are returned to the system, and the information in the database is corrected, accordingly. When all the data have been acquired, and no more DCFs are emitted, then the trial database is declared clean. Some data management operators are also responsible of performing quality audits on the system regarding the inconsistency and incoherence errors detected, in order to improve the clinical trial management system by minimising such errors in subsequent trials. The biostatistic analysis and the trial evaluation tasks are performed using different software systems, as for instance the SAS software, which provides statistical tools; the data required for the different analyses are retrieved from the data management system. 4

5 2.2. Temporal Requirements In the following sub-sections the temporal requirements, in all three time axes (user-defined, valid and transaction time) are described User-defined time requirements The user-defined time dimension allows the representation and manipulation of time with semantics known to the application only. In the context of the clinical trials and patient observations, time quantities like birth dates, treatment periods, and so on, are examples of user-defined time. In addition, in the presented clinical trial system, visit planning is based on the first day of inclusion of the patient within the trial D0 and then relative time is used to plan the forthcoming visits and observations The valid time for the time of the patients In order to maintain the history of the changes of a patient status during a trial, valid time can be employed, either using time points (instants) as valid time timestamps if the observations are discrete, or using periods as valid time timestamps if the observation is continuous. Let us have a look at the following simple example. First, we take a patient that is selected to follow a clinical trial dealing with treatment of asthma on children. We can consider that the name of the patient is an invariant piece of information for the duration of the trial, which extends to several weeks. When the trial begins, the patient is assigned to an investigator. The investigator to whom a patient is assigned may change during the trial, but the patient is always assigned to only one investigator at any instant, throughout the trial. The investigator s information, from the patients point of view, is temporal information varying over valid time dimension and using periods as valid time timestamps. One of the main observations performed during an asthma-dedicated trial, is the Maximum (Blown) Expiratory Volume MBEV. This volume is measured several times to evaluate whether there is an improvement of respiration for the patient. The MBEV value is temporal information varying over valid time dimension and is timestamped using instants, which represent the time at which the expiratory volume was measured. The following figure illustrates these three attributes of the patient entity. The evaluation of the trial is based on main and secondary criteria, in order to assess its efficiency. In the example of the asthma trial, the MBEV values are used in such criteria as for instance: How long does it take to obtain a 10% increase of the MBEV, regarding theoretical values, since D0? or What is the percentage of patients having a 10% increase of the MBEV between D0 and D14? etc. 5

6 value MBEV time investigator name a patient Figure 3 - Time invariant, instant-timestamp and period-timestamped information Transaction time requirements In the clinical trial data management context, transaction time is used to satisfy the quality audit requirements and for explanation purposes. As presented before in the description of the clinical trial data management system, the data are stored into the system using double-dependent acquisition, and these data may be corrected later due to detection of incoherence. To keep track of all database modifications of the same entity, transaction time is used. A rollback or bitemporal entity allows maintaining the database history for these values, i.e. the sequence of updates to this entity, timestamped by the commit times of the corresponding database transactions. For legal purposes, in addition to the database transaction time, the identification of the person making the update must also be stored. Therefore, due to the double acquisition, each rollback or bitemporal entity will have at least two variants (states). After this, each database update corresponding to the correction of incoherence will insert one new state to the transaction time history of the entities. Quality audits are performed both while the trial is carried out and after it has been concluded, in order to detect weaknesses in the filling of the observation notebooks: faults and/or inadequate formulation of the questionnaires are monitored. The main goal is to improve the general management not only of future trials, but even of the current one, if recurrent weaknesses are detected early enough to be able to alert the investigators responsible of the other patients. These quality audits are based on the number and percentage of updates to given information, of DCFs emission, on the types of detected errors on patients under the responsibility of a given investigator, and so on. All these reports manipulate rollback and bitemporal entities, to restore a view of the database that was current at a certain transaction time, and to find the number of data updates. For example the user may want to retrieve the number of updates on the first value of MBEV for a particular investigator. This can be achieved using a TOQL query that will be submitted to the TOODBMS and evaluated by it. The actual TOQL query will be presented later in this paper. 6

7 The second benefit provided by the use of transaction time dimension management is that it allows to explain and justify why certain results obtained or reasoning made at different steps of the trial are different from the final results obtained or reasoning made on the clean system. Analysis and reports can be obtained by reasoning on data during the clarification process (when the data are not clean yet), or by reasoning on clean information available for a subset of the patients that have already followed the trial (which may differ from the complete set of patients). Therefore, timestamping these analyses and reports with transaction time, i.e. manipulating them as rollback entities, enables the data management and/or the trial management staff to review the results of reports and/or decisions, by being able to consult the current states of the database when the reasoning is performed. So, in this clinical trial data management, the use of the three different temporal dimensions is required: The user-defined time to deal with the representation and manipulation of time quantities like date of birth etc. The valid time to maintain the history of the patient status evolution during the trial. The transaction time enabling to maintain and consult the updated states of the database for explanation, legal and quality audit purposes Generic approach in trial systems Each clinical trial is different from another since it aims to the evaluation of different treatments on different categories of patients. However, the clinical trial management system presented above is generic enough to handle any trial. Additionally, the same kind of generality appears in the data management part of the clinical trials. Naturally, the manipulated data are different, since the observations carried out on the patients differ from one trial to another, but the tasks performed in the data management system are the same: Double dependent acquisition of the information, from the observation notebooks into the data management information system. Clarification process with emission of DCFs when incoherence errors are detected. Quality audit reporting to underline the weaknesses of the trial preparation or management. Extraction of data for the biostatistic and management reports. Therefore a requirement, different from time requirements presented in the previous part of this document, is to provide a generic way to manipulate the different trials within the clinical trial data management system. 7

8 Trial definition management of trial #a... management of trial #c management of trial #b Figure 4 - Managing trials using a template application In the context of the TOOBIS project, a solution has been proposed and implemented. The structure of a new clinical trial is captured into a meta-application, which will be used will generate applications specific to this trial. The generated applications implement the data management tasks for this trial. The approach undertaken and the meta-application are illustrated in Figure 4, and are described in more details in the following sections of this paper. 3. TOOBIS components and the application 3.1. Introduction TOOBIS is a European project (ESPRIT IV), during which a temporal object-oriented database system has been designed and implemented (Sotiropoulou, Souillard and Vassilakis, 1998). The TOODBMS modules (data model, definition language and query language) are extensions to the corresponding modules of the ODMG standard (Catel et al., 1997) for Object-Oriented databases, thus the resulting DBMS is an upwards compatible extension of any ODMG-compliant OODBMS. The TOODBMS consists of the following components: A Temporal Object Data Model (TODM) (Matra Systemes & Information and O 2 Technology, 1997, Matra Systemes & Information and O 2 Technology, 1998), which extends the Object Data Model (ODM) of ODMG by accommodating temporal entities that can evolve over valid and/or transaction time dimension. Temporal entities may be temporal objects or temporal instance properties (temporal attributes and temporal relationships). Moreover, TODM provides support for time quantities such as instants, periods, intervals and period sets, which may be expressed in various granularities and calendars. Support for the Gregorian calendar is built into TODM, and users may define additional, application-specific calendars. A Temporal Object Definition Language (TODL) (University of Athens et al. 1997a, University of Athens et al., 1998a), which extends the Object Definition Language (ODL) of ODMG. Through TODL the user may define classes (interfaces, in ODMG terminology). Each interface may have temporal characteristics as a whole (resulting to a 8

9 temporal object of TODM), or may have instance properties with temporal characteristics (resulting to temporal attributes or temporal relationships). Through TODL, the signatures of the interfaces methods may also be defined, and operations are extended with the ability to accept as input or produce as output temporal entities. The body of the methods, however, must be implemented in a manipulation language such as C++ or Java, since TODL in accordance to ODL- is a pure definition language, independent of the manipulation language to be used. The user may also specify that certain attributes are used for user-defined time, by allowing them to have types like instant, period or interval. All time quantities may be expressed in any of the default or user-defined granularities and/or calendars. Finally, used-defined calendars may be defined through TODL. A Temporal Object Query Language (TOQL) (University of Athens et al., 1997b, University of Athens et al., 1998b), which extends the Object Query Language (OQL) of ODMG. TOQL introduces new operators that provide access to histories of objects, facilitate extraction of values with specific timestamps, allow for restructuring of data over the time axes etc. Methods that have been defined for an interface may be invoked within a TOQL query, providing thus more flexibility to the user. Finally, a C++ Binding for TOQL (University of Athens et al., 1998c) is available, allowing the user to submit TOQL queries from within any C++ program. The functionality of TOQL has been demonstrated using the TSQL2 (TSQL2 Language Design Committee, 1995) Benchmarks on Temporal Query Languages (Vassilakis and Sotiropoulou, 1998). Apart from the TOODBMS itself, a Temporal Object Oriented Methodology (TOOM), presented in (University of Paris 1, 1997a), has also been proposed The TOOBIS methodology The TOOBIS methodology (TOOM) has been derived from REMORA (Rolland 82) and O* (Brunet 93, Lee 94) and focuses on the design of temporal database application. These applications may be developed on temporal OODBMSs, such as the TOOBIS TOODBMS. Its main goals are to: provide advanced design features within a single model to support the design of the application s structural and behavioural aspects (University of Paris 1, 1997a), provide step-by-step guidelines to lead the developers from the conceptual schema to the full implementation of the application, over the TOODBMS platform (University of Paris 1, 1997b) Advanced features introduced by TOOM The TOOM targets on the following information system classes: temporal database applications requiring specific time management, reactive systems, able to trigger automatically operations, 9

10 workflow systems, which transfer messages among different actors within the system. Reactive systems need to model behaviour using a systemic approach, i.e. they consider dynamics as causal action-reaction principle (system reacts to stimuli). Workflow systems integrate the actors of the future system inside the system design. Our method follows this idea, but in addition it allows designing a system as distributed on actors which co-operate with each other to fulfil their mission inside an organisation. The required features for temporal database applications are expressed as follows: many applications require custom time measuring system; this implies the need to define application-specific calendars at the methodological level the methodology must be able to capture and represent the time semantics required for the modelled application. This includes usage of time axes to model data evolution through time and user-defined timestamps to model temporal semantics which are handled by the application. in addition to the temporal data itself, temporal behaviour must be captured and modelled. The features introduced by TOOM are described in the following two sections Non-temporal features The basic OO method is composed of a single model, which incorporates three abstractions: structural, functional and behavioural. The main concepts of this model, which are used to formalise real world phenomena, together with their underlying relationships are illustrated in Figure 5. aggregation association inheritance object event dependency class instanciation mechanism object Figure 5 - Main concepts of the OO Model Structural properties Two basic concepts of the model, namely objects and object classes, are adopted from the object-oriented paradigm. The aim of the model is to use the concept of the object from the analysis phase through the implementation phase. Objects represent real phenomena of the application and object classes describe and group sets of objects of the same nature in terms of the structural and behavioural characteristics (for instance, the patient Smith, the investigator Hawkins, the drug FLP1200 are examples of objects). In addition to the inheritance links of the object-oriented paradigm, the model takes into account the life cycles of objects for the determination of structural links (static links) between object classes. These structural links are distinguished formally into two categories: 10

11 associations and aggregations. An (observation notebook) object class (belongs) association to a (patient) object class is an example of association whereas an observation notebook is composed of Physical examination class is an example of aggregation An attribute is a characteristic of a class. The value set of an attribute is defined using the notion of domain (for instance, name, address etc. are examples of attributes of the Patient class. STRING is the domain of the name attribute, whereas ADDRESS is a structured domain associated to the address attribute) Behavioural properties Besides the structural aspects, the model also considers the concepts of event and operation to take into account the behavioural aspects of ISs at the conceptual level. The causal dependency of events is related to the cause and effect in the occurrence of events. This may be explicit by the fact that the occurrence of an event is due to the previous occurrence(s) of some event(s). The event concept is used to represent the reaction of a system to a particular stimulus. Events can be classified in three groups: external events, internal events and temporal events. External events correspond to the events occurring in the environment outside the IS. Internal events correspond to the internal state changes, or rather, the system responses to external changes. Finally, temporal events occur when a particular temporal assertion becomes true. Internal events occur when particular state changes are recognised. For instance, when the observed MBEV of a patient becomes 50% more than the theoretical value, a Critical MBEV message is sent to the investigator responsible for the patient is an example of an internal event. External events interact with the IS through messages initiated by an actor belonging to an actor class. For instance, automated measurement of the MBEV value of a patient implies the storage of this value in the patient s observation notebook is an external event triggered by the actor patient. Each external event is attached to an actor class, while all temporal events are attached to the calendar class. Internal events are attached to object classes. The concept of external event provides a more powerful way of communication than the message passing mechanism, by providing means for explaining when a certain phenomenon occurs. In addition, the IS can react to an event by sending a message to an actor via an external operation encapsulated in the actor class definition. For example, sending a critical MBEV message is an external operation assigned to the investigator actor class. Temporal events are helpful to trigger actions when their temporal assertions become true. For instance, every week a synthesis report on the MBEV evolutions of patients monitored by an investigator is sent to each investigator is an example of temporal event. 11

12 Operations are defined in object classes. They are classified under basic operations and queries. A basic operation defined in an object class represents an action that will act upon an object of this class causing a state change to that object. The execution of basic operations is triggered by events. Queries merely provide access services to other objects. Derived attributes are modelled as queries without input parameters. For instance age is a derived attribute of the patient object class, whereas recording the observed MBEV value of a patient into the database is a basic operation attached to the corresponding object class. Figure 6 summarises the integration of the different abstractions (structural, functional & behavioural). Functional Respiratory Test register Patient Each day Critical MBEV evolution of a patient Measuring the MBEV value using specific equipment Investigator [f1] CriticalMBEV_alert DailyPatient_report f1 : for each investigator involved in the clinical trial external event internal event temporal event Object class Actor class Calendar class operation trigger [f1] : For each element in F1 Figure 6 - Example of a dynamic schema A dynamic transition (Rolland, 1982) is composed of an event, a set of basic operations triggered by the event and a set of persistent objects manipulated by these operations. A dynamic transition is analogous to databases transaction, that is, it constitutes the unit of atomicity, consistency and integrity. In a wider perspective, a dynamic transition may be defined globally and explicitly by a sequence of event occurrences caused by the occurrence of an external or temporal event. The execution of a dynamic transition must lead the database from one coherent state to another. In a dynamic transition, the basic operations that manipulate persistent objects are triggered in parallel by the event and any creation, update or deletion of persistent objects within the dynamic transition must be completed before any other process can be carried out by/on any of these persistent objects. In this sense, a dynamic transition can easily be mapped into a runtime elementary transaction. For the medical information systems, the concepts presented above provide two main advantages: the event concept enables the system to undertake a reactive role, instead of a passive one. The system reacts when a particular external stimulus is received or when a particular state change of an object is recognised or when a temporal assertion becomes true. A medical information system can be designed as reactive instead of a mere data store. 12

13 Considering that patients suffering from illnesses that require long-term treatment, such as asthma, have specific equipment at home for distant monitoring, investigators can be alerted distantly when a critical evolution is ascertained. The reaction of the system to a critical evolution can generate an immediate reaction of the investigator. introducing actor classes in the system specification level allows defining the role of each actor, as well as the role of the system itself. This means that actors interact with the system in order to enter or obtain information, but, inversely, the system can also act upon actors by sending them messages, when necessary Temporal features The temporal extension of the OO method targets the design of: custom time measurement, attributes with user-defined time semantics, temporal data, behaviour related to time Custom time measurement A calendar is a metric system applied on the time line. TOOM provides a predefined calendar: the Gregorian. The static properties of this calendar are encapsulated in its definition and its behavioural properties are the temporal events that are based on the Gregorian calendar. More generally, a calendar is defined by a name, an origin (instant), a basic unit (granule) and a list of granules, ordered by the is-finer-than relationship. A calendar definition also includes an operation for translating an instant to a period, operations for converting between granules of the same calendar and two conversion operations, from and to the Gregorian calendar (these two operations facilitate conversions between calendars). This definition represents the properties and operations of the calendar class. If the application requires a specific time calendar, the application engineer has to define it, through the concept of calendar class. For example, the observation of a patient in a hospital is scheduled every 6 hours. A specific calendar called ObservationCalendar can be defined as follows: 13

14 Calendar class ObservationCalendar origin ="1/01/01/0000" basic unit = hour of Gregorian calendar granules turn : { 6 basic unit, basic unit = 6 turns} day : { 4 turns, turn=1/4 day} month : { irregular} year : {12 months, month=1/12 year} operations instant<observationcalendar, *> operator + (instant<observationcalendar, *>, interval<observationcalendar, *>); interval<observationcalendar, *> operator + (instant<observationcalendar, *>, instant<observationcalendar, *>); instant<observationcalendar, *> operator - (instant<observationcalendar, *>, instant<observationcalendar, *>); instant <Gregorian, *> conversion (<instant<observationcalendar>); instant ObservationCalendar *> conversion (<instant<gregorian>); EndClass Figure 7 - Definition of the ObservationCalendar calendar class Application engineers may specify as many calendars as their applications need, provided that they supply the appropriate conversion operations to map time quantities to/from the Gregorian calendar User-defined time Three new domains are used to represent attributes with user-defined time semantics: instant, period and interval. An instant represents a point on the time line (e.g ). A period represents a segment of the time line, with well-defined beginning and end (e.g. [ , ) 1 ). An interval, on the other hand, is an unanchored quantity of time (e.g. 3 months). These three types are expressed using a granularity of a calendar. Consequently, they are types parameterised by granularity and calendar. These generic temporal domains (INSTANT<calendar, granule>, PERIOD<calendar, granule> and INTERVAL<calendar, granule>) replace the classical types: date, time and datetime found in the classical DBMS. The observation instant in the hospital may be represented by the following attribute: observationdate: INSTANT<ObservationCalendar, turn>; A patient s treatment period begins at the instant of the first observation, and extends to the instant of the last observation. In this case the corresponding attribute treatmentperiod is defined using the domain PERIOD<ObservationCalendar, turn>. The number of days that a patient was hospitalised is stored in the attribute nightsinhospital, which is defined using the domain INTERVAL<Gregorian, Day>. The domains INSTANT-A<calendar, granule> and PERIOD-A<calendar, granule> are used to specify absolute time domains. Relative time is introduced through two new temporal domains: INSTANT-R<calendar, granule> and PERIOD-R<calendar, granule>. Relative time appears as a derived temporal attribute: instead of the time value, a temporal expression used to derive the value of the attribute is stored. 1 [1996/12/12, 1996/12/15) expresses a period including the beginning of the period and excluding the end of the period. 14

15 Visit scheduling in clinical trials is modelled using relative time, since each visit is defined in terms of the previous one. Thus, the attribute visitdate is defined with the domain INSTANT-R<Gregorian, Day>. In the same way, the end of the trial for a patient is expressed according to its beginning date. Thus, the trial period is a relative time period expressed in the domain: PERIOD-R<Gregorian, Day> Designing Temporal Data A temporal DBMS is able to manage different kinds of objects: snapshot, valid time (historical), transaction time (rollback) and bitemporal. A snapshot object may be managed by a non-temporal DBMS. Historical, rollback and bitemporal objects are specific to temporal DBMSs. Valid time is managed in historical and bitemporal objects, whereas transaction time is included in rollback and bitemporal objects. This section presents how the valid and transaction time dimensions are introduced in object classes, by introducing two new sub-classes: snapshot class and temporal class. A snapshot class is a class that does not require time management. The properties of such classes are not related to time. For instance, the Patient class provides general properties of a patient. Since the evolution of these properties is not significant for the application, class Patient is a snapshot class. Note that Patient in our design is considered both an actor and an informational object. This is why it appears as an actor class and as a snapshot class. A property of a snapshot class may be a relationship to another class or an attribute defined in the object class. Methods of a snapshot class can be queries or basic operations, and they can be applied at instance or class level. The types of basic operations are create, update, delete and erase. Two deletion methods are introduced because of consistency rules that are specific to temporal databases. The delete operation handles logical deletion, whereas physical deletion is handled by the erase operation. Finally, internal events can be expressed on snapshot classes. Figure 8 illustrates the definition of the snapshot class Patient. Snapshot class Patient extent Patients properties patient-number : INTEGER; name : STRING; first-name : STRING; birthday : INSTANT <Gregorian, Day>; age : derived attribute; address : STRING; investigator : assoc (one, INVESTIGATOR); operations INTEGER age (); create_patient(...); affect_investigator (...); internal events EndClass Figure 8 - Definition of the Patient snapshot class 15

16 A temporal class is a class with time management (historical, rollback and bitemporal objects). For instance, the FunctionalRespiratoryTest is a temporal class because its evolution has to be kept in the database. This class is considered as a temporal element of the ObservationNotebook snapshot class. Also, the Investigator class used in an association in the Patient snapshot class is also a temporal class, with only one attribute named Investigator. As it will be presented later, this will be mapped to a temporal relationship. Temporal classes permit to integrate valid and/or transaction time management into the class definition. The state of a temporal object is composed of a set of values (a value for each property) at a given point of time. A state is associated to a timestamp (valid and/or transaction time). A state is called valid when it is associated to the valid time, whereas it is named database state when it is related to the transaction time. Finally, a bitemporal state of an object integrates its valid and transaction time. A temporal class is used to group properties that evolve together over time and are linked to the same temporal dimension. It describes properties of a snapshot class that vary over time. A snapshot class can be linked to more than one temporal classes and the link between a temporal class and its snapshot class is called a temporal variation. For instance, an employee can be characterised by some permanent properties and some properties that evolve in the course of time and for which we need to store their evolution. Figure 9 shows two temporal variations of the ObservationNotebook snapshot class, namely functionalrespiratorytest and physicalexam. Patient has Observation Notebook Functional Respiratory Test <VT,TT> PhysicalExam <VT,TT> MBEV value Snapshot class Temporal class temporal variation association Figure 9 - Example of temporal classes The notion of history permits to keep all states of an object in order to have its evolution over time. The valid history of an object reflects its evolution from the real-world point-of-view (valid time management). The database history of an object represents its evolution according to the database viewpoint (transaction time management). Finally, a bitemporal history of an object combines the real-world and database viewpoints. The temporal class is characterised by the time dimension it manages. For each time dimension, two possibilities are offered: last state or history. The possible combinations from the temporal class concept are summarised in the following table. Note that classes without time dimensions are modelled through the snapshot class concept and not through temporal class. 16

17 valid time transaction time None state history none No time management Last database state of an Database history of an object (snapshot class) object state Last state of an object with Last bitemporal state of an Database history of an object its valid time object and its last valid state history Valid history of an object Valid history of an object Bitemporal history of an object and its last database state The MBEV value of a patient evolves over time, and the investigator monitoring this patient studies this evolution to decide the treatment. Consider the following example: Patient N o 123 had initially an MBEV value equal to 12. This was subsequently changed to the erroneous 15 and then corrected to 30. In the following table we see how these changes are modelled in the combinations presented in the previous table. State History Valid 30, VT[ , forever) 12, VT[ , ) 30, VT[ , forever) Database 30, TT[ :00:15, 'now') 12, TT[ :20:15, :56:50) 15, TT[ :56:50, :00:15) error Bitemporal 30, VT[ , forever), TT[ :00:15, 'now') 30, TT[ :00:15, 'now') 12, VT[ , forever), TT[ :20:15, :56:50) 12, VT[ , ), TT[ :56:50,'now') 15, VT[ , forever), TT[ :56:50, :00:15) - error 30, VT[ , forever), TT[ :00:15, 'now') The characteristics of each time dimension are defined depending on the needs for information retrieval. Definition of valid time: The following characteristics need to be determined: the nature of the valid time (instant or period), the granularity and the calendar of the valid time, the type of management (state or history), the completeness of the history (complete or partial) and the extrapolation function if the history is partial. Definition of transaction time: the type of management (state or history) has to be determined Design behaviour related to time The dynamics of the application are modelled using the event concept Three events types are defined: An external event models the emission of a message by an actor. The trigger part of this event represents the action to perform when such messages arrive to the system. This action is the response of the IS to this message. The valid time of an external event is the valid time associated to the message, whereas its transaction time is the time when the message is received. External events are further classified in terms of the relation between their valid and transaction time: An event in time is an event whose valid time is equal to its transaction time. For example, the (automated measurement of the MBEV value of a patient using specific equipment) event implies (the storage of this value in the patient s observation 17

18 notebook) operation event has a negligible delay between observation and message reception time. An a priori event has future valid time, allowing action specification in advance. In order to avoid problems related to the management of post-actions, the message is received in advance, but the action associated to the event is executed in time. An a posteriori event has past valid time. An a posteriori event is limited to exceptional cases aiming at correcting the database image of the modelled real world. For instance, in a manual acquisition, errors in the acquisition phase can be made or input for an observation may be forgotten. Therefore, an event called acquisition of an observed MBEV for a patient for correction or for regularisation is an example of an a posteriori event. The reaction associated to this event has to correct the situation by undoing actions performed using the wrong value and applying actions using the right one. An internal event acknowledges a noteworthy state change of an object. Internal events based on snapshot classes can only be ascertained on the change of the current state of an object. Classically, the predicate of an internal event expresses the state change of an object. For instance, when the observed MBEV of a patient becomes 50% more than the theoretical value, a Critical MBEV message is sent to the investigator responsible for the patient. This event is called event on object because it is based on the current state change of the FunctionalRespiratoryTest object. The extension of object classes to temporal ones implies a new class of events based on the state of the history instead of the state of an object. For instance, if an MBEV value of a patient went over 30% of the theoretical value four times during a week his investigator is alerted. This event is called event on history. A temporal event is a particular state change of the clock. A temporal event is a temporal expression based on one of the calendars of the application. Each temporal event is associated to a calendar. Three types of temporal events are defined: absolute, relative and periodic events. For instance: the 25 th of December 1998 is an absolute event, every week a synthesis report on the MBEV evolution of the patients monitored by an investigator is sent to each investigator is a periodic event, and 1 week before the beginning of the clinical trial, the visit schedule and the list of patients is sent to each investigator is a relative event Conclusions The temporal concepts allow the design of advanced situations useful in medical information systems. 18

19 The calendar class concept supports user-defined calendars. In a medical organisation, several calendars are often used to schedule activities of the organisation. The relative time domain is often useful to schedule a medical treatment that is based on the beginning date of the treatment. Temporal data facilitate the storage of time-evolving medical indicators of patients, which is the essential mission of the medical information systems. Therefore, historical data using the valid time dimension allow storing all the observed values with its observed time. However, the registration time of these values can be also useful. The delay of refreshment of data of a patient may have impact on the decisions of the investigator made according to data registered in the medical information system. If an erroneous piece of data is corrected, or if the acquisition of a data is actually delayed, the investigator should be alerted in order to update his decision according to the new situation. Events on the state of the data evolution allow alerting the investigator when the evolution of data over time appears critical. Periodic time events can be used to acquire values automatically for hospitalised patients. The patient state is observed automatically using specific equipment Use of TODL and TODM After the application has been modelled using TOOM, the information captured is mapped to TODL, following the guidelines that can be found in (University of Paris 1, 1997b), in order to create the database. In the following paragraphs we present some of the TODL interfaces derived using the mapping Patient Interface The Patient interface is used to model the information needed for each patient that takes part in the trial. Besides standard information, like the name and the number of the patient, each instance of the Patient interface has an association with an instance of the Investigator interface. It also has aggregations of zero or one instances of the ObservationNotebook interfaces. All this information captured and modelled by TOOM is mapped to the following TODL interface declaration 2 : interface Patient (extent Patients) { attribute Short number; attribute String name; relationship Investigator investigator valid granularity day inverse Investigator::patients; relationship ObservationNotebook on inverse ObservationNotebook::ofPatient; relationship HealthHistoryContainerB healthhistorycontainerb inverse HealthHistoryContainerB::ofPatient; relationship PeriodicIndividualNotebook periodicindividualnotebook inverse PeriodicIndividualNotebook::ofPatient; } Figure 10 - The Patient interface TODL declaration 2 For brevity reasons, only a subset of the instant properties is presented. 19

20 This declaration is mapped to a TODM class 3, sub-class of the Snapshot_Object class used to model objects with no temporal information as a whole, but which may contain temporal attributes or relationships. As stated earlier, a patient is always associated with exactly one investigator. However, the investigator responsible for a patient may change during the trial, and this information must be maintained. For this reason, the relationship defined in TODL towards the Investigator interface is actually a historical relationship, allowing us to keep track of this history. One of the most important relationships this interface has is towards the ObservationNotebook from which we can get all the information needed for the different visits, along with all the temporal information available ObservationNotebook Interface and Semantic Containers The ObservationNotebook interface is also modelled through TOOM as a snapshot class. The observation notebooks are used to keep track of the information gathered at each visit the patient makes during the trial. The TOOM class that is mapped to this TODL interface contains temporal aggregations to all the Semantic container classes. Also as pointed out in the Patient interface it is associated to the Patient TOOM class. The TODL interface declaration 4 is presented in Figure 11. interface ObservationNotebook { relationship List<Visit> visits; relationship Patient ofpatient inverse Patient::on; relationship DemographicCriteria demographiccriteria inverse DemographicCriteria::on; relationship IllnessHistory illnesshistory inverse IllnessHistory::on; relationship PhysicalExam physicalexam inverse PhysicalExam::on; relationship FunctionalRespiratoryTest functionalrespiratorytest inverse FunctionalRespiratoryTest::on; relationship StatementOfTreatmentForOneWeek statementoftreatmentforoneweek inverse StatementOfTreatmentForOneWeek::on; relationship Set<UndesirableEvent> undesirableevents inverse UndesirableEvent::on; relationship VisitSummary visitsummary inverse VisitSummary::on; } Figure 11 - The ObservationNotebook interface Note that the ObservationNotebook interface also maps to a sub-class of the Snapshot_Object TODM class. The temporal aggregation is hidden in the semantic container classes, such as PhysicalExam or FunctionalRespiratoryTest. The idea behind the use of such containers is that regardless of the kind of trial, almost the same kind of information is needed to be kept in the observation notebooks. That is the results of a physical exam are needed in both an asthma trial and cardio-vascular one. Each container class has a relationship towards its observation notebook and also an attribute towards a value class. All the values that form a physical exam or a functional respiratory test etc. can be found in such classes. These classes are bitemporal, 3 For more information about the mapping from TODL declarations to TODM classes the reader is referred to (Matra Systemes & Informations and O 2 Technology, 1998). 4 For brevity reasons only a subset of the instance properties are given in each definition. 20

21 that is we keep track of the changes in their values and of when these changes were registered in the database. The TODL declarations of the FunctionalRespiratoryTest interface, and of the FunctionalRespiratoryTestValue interface are presented in Figure 12. interface FunctionalRespiratoryTest { relationship ObservationNotebook on inverse ObservationNotebook::functionalRespiratoryTest; attribute FunctionalRespiratoryTestValue value; }; interface FunctionalRespiratoryTestValue transaction valid event granularity day { attribute Float observedmbev; attribute Float theoreticalmbev; attribute Float percentagetheoreticalmbev; attribute Float reversibilityofmbev; attribute Short MBEVAfterVentoline; }; Figure 12 - The FunctionalRespiratoryTest (container and value) The FunctionalRespiratoryTest interface declaration will be mapped to a Snapshot_Object sub-class of TODM, while the FunctionalRespiratoryTestValue interface declaration will be mapped to a Bitemporal_Object sub-class and an Object_State sub-class of TODM. The Bitemporal_Object sub-class will be the container of the Object_State sub-class. The visits relationship of the ObservationNotebook interface associates the observation notebooks with the different visits of the patient, modelled using the Visit interface. This interface is not temporal, neither does it have any temporal instance properties. Instead it presents the date of the visit using user-defined time. The declaration of this interface is presented in the following figure. interface Visit (extent visits) { attribute String name; attribute Instant date; }; Figure 13 - The Visit interface Note that only the value of the first visit (D0) is given as an absolute value; all subsequent visits are given as a relative instant based on the first visit value Querying the Trial Data Data that have been collected during the acquisition phase and have been stored in the database may be retrieved by a user or an application via TOQL queries. TOQL (University of Athens, 1997b) is an upwards compatible extension of OQL 1.2 (Catel et al., 1997), which is the ODMG standard for querying object-oriented databases. The trial data management module described in section 2 uses TOQL queries to extract information that will be used to evaluate the different aspects of the clinical trial, such as the acquisition phase and the treatment efficiency. In the following paragraphs, we will use examples of such queries to illustrate the syntax and the expressive power of TOQL. All queries are evaluated on the database schema presented in sections 3.2 and

22 3.4.1 Evaluating the acquisition phase The evaluation of the acquisition phase consists of the production of metrics on the number of errors that were traced and corrected, the reasons for which these errors were introduced, the persons involved in them, the time taken to correct them and so on. These queries usually involve both the valid and transaction time dimensions, since they need data from past states of the database, as illustrated in the following examples: 1. Fetch the data for the i-th visit for a patient, if these data have been corrected for any other reason than a typing error 5 : select p, on.physicalexam.value[valid at on.visits[$1].date] as firstvisit from patients as p where exists exam in on.physicalexam.value[valid at on.visits[$1].date]: (not(exam.comment like "*Initial value*") and not(exam.comment like "*Typing error*")) This example demonstrates that temporal data (such as the physicalexam.value attribute of a patient s observation notebook) can be treated as indexed collections, which can be subscripted using time quantities (the day of the i th visit in this case). The result of this expression is a list of records (structures, in ODMG terminology), where each record contains the actual data coming from examination that was performed on the specified date, its valid timestamp (in this case it coincides with the visit date), its transaction timestamp and a comment field. The value of the comment field is specified when the data are inserted in the database, and in the clinical trial application it is set to reflect the reason for the update and the updating user s identity. 2. Find the average delay for correcting errors that are associated with a given investigator and pertain to physical exams: avg(select duration(transaction(exam)) from investigators as i, i.patients as p, p.on.physicalexam.value as exam where i.name = $1 and end(transaction(exam))!= now()) In this example a variable is defined over a temporal piece of data (p.on.physicalexam.value). In such a case, the variable iterates over the different states stored in the temporal datum. The valid and transaction timestamps associated with each state may be extracted by applying the valid and transaction functions respectively on the variant. Here, the transaction time is used to filter out the current data (the end of their transaction timestamps will be equal to the time point now(), thus they will not satisfy the criteria in the where clause) and to compute the time taken to correct the error (the duration of the transaction timestamp). Finally, aggregate functions may be computed on collections of time quantities. 3. For a given investigator, compute the number of updates on the first value of the MBEV observed? 5 The $i notation in queries designates the i th parameter of the query. 22

23 sum(select count(p.on.functionalrespiratorytest.value[ valid at p.on.visits[0].date]) from investigators as i, i.patients as p where i.name = $1) Evaluating treatment efficiency The evaluation of the treatment efficiency includes the comparison of the exam results against the theoretical values, the production of analytical reports for the patients progress during the clinical trial, the correlation of different parameters of the patient s record and so on. Most of these queries access only the current state of the database, but in certain cases previous database states are recalled, so as to associate the decisions taken at various time points with the data that were actually available at that time. The following queries are some examples of queries used to assess the treatment efficiency: 1. For each patient, find the times that examinations showed MBEV values that exceeded the theoretical values by more than 30%. select p, (select frt.value.observedmbev, frt.value.theoreticalmbev, ftr.vt from p.on.functionalrespiratorytest.value[current at now()] as frt where frt.value.observedmbev > 1.3 * frt.value.theoreticalmbev) as highmbev from patients as p In this example, the most recent data for each patient s examination data are extracted by using the current instant as a subscript on the transaction time axis, and then the exams meeting the specified criteria are filtered, in order to compute the final query result. 2. For each patient, list the weekly averages of his/her value of the MBEV, for the most recent version of the trial data. select p, (select timeslice as weeklyperiod, avg(select resptest.value.observedmbev from partition as resptest where resptest.tt contains now()) as avgmbev from (partition valid as interval '7' granularity Day) (p.on.functionalrespiratorytest.value) as resptest) as weeklyavg from patients as p This example illustrates the temporal grouping functionality, which is provided by TOQL and invoked using the partition syntactic construct. The partition construct splits the designated time axis (the valid time axis, in this case) to fragments with a specified duration (here, 1 week) and for each such fragment it formulates a collection containing the values pertaining to the specific fragment. Partitioning of valid time data over the valid time axis (using fragment size = 1 week) is illustrated in the following figure. value /12 18/12 22/12 27/12 time (a) Original data result fragment #1 timeslice: [15/12-22/12) partition (value: 1, VT: 15/12) (value: 2, VT: 18/12) fragment #2 timeslice: [22/12-29/12) partition (value: 1, VT: 22/12) (value: 3, VT: 27/12) (b) Partitioned data Figure 14 - Partitioning temporal data 23

24 3. Which are the undesirable events that occurred within one week from the second visit, as recorded in the database during that week, along with the statement(s) for weekly treatment for that week. select p, p.on.undesirableevents.value[current at period(visits[1].date, visits[1].date + interval '7' granularity day)] as UndesEvents p.on.statementoftreatmentforoneweek.value[ valid at period(visits[1].date, visits[1].date + interval '7' granularity day), current at period(visits[1].date, visits[1].date + interval '7' granularity day)] as Treatment from patients as p This example illustrates indexing of temporal data using periods, rather than instants, in which case all states having timestamps overlapping with the subscripting timestamp are retrieved. We can also see that bitemporal data (such as the p.on.statementoftreatmentforoneweek.value attribute) can be indexed on both time axes simultaneously, using the valid at and current at qualifiers to designate the time axis to which each subscript applies. 4. Clinical Trial Data Management Applications In this part, we will describe the meta-application that enables the designer to capture the structure of a new trial, and to generate an application specific to the data management of this trial. We will also present an example of such a generated application, in the context of a clinical trial about asthma treatment on children introduced previously. The context and requirements of these applications have been presented previously in this document The Overall Approach The overall approach undertaken in the TOOBIS project to deal with the management of data coming from clinical trials in a generic way is presented in Figure 15. The first step to perform is the extraction of the generic features that can be found in any trial, both at the data schema level and the dynamics of the data management tasks. To ensure that we cover the characteristics of any trial, a wide set of major clinical trials has been explored, along with inputs from expert people working on clinical trials. This generic analysis has been performed using TOOM, the temporal methodology. Three components have been produced: A data schema of a generic trial, which may be instantiated to produce the data schema of any new trial. This data schema contains only snapshot information that describes the structures of trials. Consequently, only the object-oriented part of TOOM has been used here. Mapping rules, which transform the description of a trial structure to the data schema for this trial, which will accommodate the data resulting from the observations of patients. By applying these rules, trial-specific schemata are created. These trial data schemata are temporal schemata where the temporal data coming from the trial observations will be 24

25 managed. The TOOM methodology was used for the definition of these rules, the selection of the temporal structures to be used and the generation of the TODL statements, which are fed to the TOODBMS, in order to create the schema for the new trial. The last point is the dynamic view of the clinical trial data management applications. A clinical trial data management application is mainly responsible for the acquisition and the coherency of the trial data, which incorporate temporal semantics. The dynamics (or behaviour) of such applications have been explored using TOOM, in order to extract the generic dynamics of trial data management applications. With these three components a data management application for the target trial can be generated. trial #xxx trial #yyy trial #zzz... Generic analysis of clinical trials trial #... clinical trial experience TOOM TOOM TOOM schema of a generic trial generic dynamics of trial management mapping rules definitions of clinical trials TODM TODL TODM TODL schema of trial #aaa schema of trial #xxx TODM - TOQL application trial #xxx... TODM TOQL application trial #aaa Figure 15 - Generic management of clinical trial data Figure 15 illustrates the overall approach, beginning from the clinical trial generic expertise and up to the generated applications, which are specific to given trials. The meta-application, described in the next part, begins with the definition of a new trial and goes down to the generation of the data management application for this new trial. An example of such a generated application will be described Section The meta-application The usage of the meta-application can be split in two steps: first, the description of the target trial has to be acquired and be incorporated into the meta-application. Afterwards, the various components to be generated should be modelled. The description of a clinical trial contains the planning of regular and supplementary visits of investigators to patients, the observations to perform and the information to collect on each visit, the different observation notebooks, and so on. To define all these structures, the metaapplication provides a facility to clone structures from other trials. For instance the physical 25

26 exam to perform in the asthma trial is not so different from the physical exam of another trial; so we may clone it into the definition of this new trial, and modify just a few things. This feature allows the user who defines a new trial to reuse any components at any level from other observation notebooks or trials that have already been defined in the system. When all the information required for a complete description of the new trial has been acquired into the meta-application, the generation step shall be launched. The first component to generate is the TODL statements that will be passed to the TOODBMS and will create the new temporal data schema specific to the data of this trial. These TODL definitions are generated using the mapping rules defined in the generic analysis phase of the project. When the new schema has been created, the meta-application starts to populate it with information that has been given in the description of the trial, as for instance the planning of the trial, the coherency checks to perform, etc. The API of TODM classes is used here to populate the temporal database associated with the trial schema. The last step is the generation of the application that will deal with the data management of the trial. Using the generic rules about the application dynamics and the trial schema, the trial application is generated. This application will communicate with the temporal database using the TODM API and the TOQL query language. Figure 16 depicts a screenshot of the meta-application, illustrating the duplication/cloning feature of a container, the PhysicalExam, which is a set of semantically linked information within the main observation notebook of the asthma trial. Figure 16 - Meta-Application: duplication of a container (PhysicalExam) 26

27 4.3. A trial-specific application Recalling the main tasks that the data management module of a trial has to perform, these are: the acquisition of the data from the observation notebooks into the system, the clarification process to detect and correct incoherence errors, and the quality and audit reporting. All these tasks handle temporal data, either via the TODM class API, or using TOQL queries. The application is split into modules that take into account these different tasks. The access rights are granted according to the identification of the user, since different persons are responsible for the different actions. Additionally, the system keeps track of the users who make any update to the database, as required for legal purposes. The same graphical interfaces are used for the two acquisitions, the visualisation and the correction of data. However, the functionality available through the interfaces differs, depending on the current phase of the trial and the role of the current user. For instance, during the second acquisition checks are performed regarding the value entered during the first acquisition, whereas such checks are not performed elsewhere. A piece of data may be corrected only if a DCF about an error on this piece of data has already been issued and not yet archived, as explained in the following paragraphs. These interfaces follow the look and feel of the paper version as closely as possible, in order to facilitate the acquisition tasks. The temporal features are encapsulated in series of tabs and sheets. The coherency check module enables to launch checks on a specific piece of data, such as a given set of patients, the data for given visits or specified observation notebook pages, and so on. Therefore, the clarification process can be launched, even if the acquisition phase has not been completed for all patients or all visits. When errors are detected by these checks, DCFs are emitted by the system and are forwarded to the investigators that are responsible for the patients on whose data incoherence is detected. A DCF is called current from the time is has been generated by the system until the time is has been returned by the investigator and the correction to the database has been performed. As soon as the database is updated, the DCF is archived. The system keeps track of the full life cycle of each DCF, starting by registering its creation time when the DCF is emitted. If the DCF has not been returned to the system after a specified time interval, a temporal event is raised, causing the system to issue a warning to the data management operator that the return delay for the specified DCF has expired, so that the responsible investigator has to be contacted. This feature allows for the minimisation of the delay and the overall duration of the clarification process. A similar kind of warning is raised by the system when the theoretical end of the trial is arriving, so that personnel responsible for delayed tasks is notified to speed up their activities. The quality audit and reporting module allows for selection of the target subset of data, similarly to the coherency check module. This way, audit reports may be generated before the end of the trial and feedback to investigators may be produced, so as to improve various 27

28 processes of the trial. These reports are timestamped using transaction time or machine time. This timestamping enables the operator to evaluate the reports and the decisions that may have been taken, in relation to the state of the database that was current when the report was generated or the decision was taken. Since all the database updates are maintained by the system using the transaction time dimension, it is possible to access all the past states of the database, and then to justify and explain past decisions and reports. Figure 17 presents a screenshot of a data management application, specific to the asthma treatment on children, showing an example of the interface used for the acquisition, visualisation and modification of data and more specifically the demographic criteria tab of the first visit of the asthma trial. 5. Conclusions / Future work Figure 17 - Application interface In this paper we presented an integral approach to clinical trial management. This approach includes the following modules: A temporal object-oriented methodology, which is used to capture the data management requirements of clinical trials both at a generalised level (i.e. requirements that apply to any clinical trial) and at trial-specific level. A complete temporal OODBMS which allows the storage and querying of temporal data. Valid time support allows to following up the patient s state during the trial, whereas transaction time facilitates quality audits and evaluation of decisions using the data that were available at decision time. A powerful query language allows for retrieval of the 28

29 necessary information and provides support for method invocation, leading thus to seamless integration of temporal reasoning and temporal maintenance, as proposed in (Shahar and Combi, 1997). A generalised template application, through which trial-specific applications may be generated. This minimises the work that must be performed in order to build an application for a new clinical trial. The application supports the concept of temporal events, which allows for automatic scheduling of tasks and employs graphical user interfaces to facilitate the visualisation and manipulation of temporal data. Future work will include support for uncertain information and provision of graphical query language tools, to support ad-hoc querying. 6. References Boehlen, M.H., (1995). Temporal Database Implementations, SIGMOD Record, Vol. 24, Number 4. Brunet, J. (1993). Analyse Conceptuelle orientee-objet, PhD Thesis, University of Paris 6. Cattell, R.G.G, Barry, D., et al (Eds.) (1997). The Object Database Standard: ODMG 2.0. The Morgan Kaufmann Series in Data Management Systems, Jim Gray, Series Editor. Combi, A. and Shahar, Y. (1997). Temporal reasoning and temporal data maintenance in medicine: Issues and challenges, Computers in Biology and Medicine, Vol. 27-5, pp Lee, S.P. (1994). Formalisation et aide outillee a la modelisation conceptuelle, PhD Thesis, University of Paris 1. Matra Systemes & Informations and O 2 Technology (1997). TODM Specification and Design, TOOBIS Project Deliverable TR Matra Systemes & Informations and O 2 Technology (1998). TODM Manual, TOOBIS Project Deliverable TR Matra Systemes & Informations, 01-Pliroforiki, GlaxoWellcome and Delta Dairy S.A. (1997). Pilot Applications Design, TOOBIS Project Deliverable T43TR.1. Rolland C., Richard C. (1982). The REMORA methodology for Information systems Design and management, in Olle T.W, Sol H.G., Verrijn-Stuart A.A. (eds) Information Systems Design Methodologies: a comparative Review, North-Holland Publications. Shahar, Y. and Combi. C. (1997). Timing is Everything: Time oriented Clinical Information Systems, to appear in Western Journal of Medicine. Shahar, Y. and Musen, M.A. (1996). Knowledge-Based Temporal Abstraction in Clinical Domains. Artificial Intelligence in Medicine Vol. 8, pp All TOOBIS project deliverables are available from 29

30 Shahar, Y. (1997). A Framework for Knowledge-Based Temporal Abstraction. Artificial Intelligence in Medicine vol. 9(1-2), pp Sotiropoulou, A., Souillard, M. and Vassilakis, C. (1998). Temporal Extension to ODMG, to appear in Proceedings of the International Workshop on Issues and Applications of Database Technology IADT 98, Berlin, Germany. Souillard, M. and Pollet, Y. (1997). Toobis: une approche pour la gestion de donnees evolutives et temporelles dans la Recherche Clinique. in Proceedings of 6th International Interfaces'97 Conference, Montpellier, France, pp Souillard, M., Vassilakis, C., and Sotiropoulou, A. (1998). TOOBIS: application de la gestion de donnees temporelles dans le domaine de la recherche clinique, to appear in Proceedings of XVI e Congres INFORSID 98, Montpellier France. Tansel, A.U., Clifford, J. et al. (1993). Temporal Databases: Theory, Design and Implementation. Benjamin/Cummings Publications. TSQL2 Language Design Committee (1995). The TSQL2 Temporal Query Language. R.T. Snodgrass (editor). Kluwer Academic Plublishers. University of Athens, 01-Pliroforiki and O 2 Technology (1997). TODL Specification and Design, TOOBIS Project Deliverable TR University of Athens, 01-Pliroforiki and O 2 Technology (1998). TODL and Metadata Manual, TOOBIS Project Deliverable TR University of Athens, 01-Pliroforiki and O 2 Technology (1997). TOQL Specification and Design, TOOBIS Project Deliverable TR University of Athens, 01-Pliroforiki and O 2 Technology (1998). TOQL Manual, TOOBIS Project Deliverable TR3.6.2a. University of Athens, 01-Pliroforiki and O 2 Technology (1998). TOQL C++ Binding Manual, TOOBIS Project Deliverable TR3.6.2b. University of Paris 1 (1997a). Temporal Object Oriented Methodology TOOBIS Deliverable T23D11. University of Paris 1 (1997b). Guidelines for Developing Temporal Applications TOOBIS Project Deliverable T32D2. Vassilakis, C., and Sotiropoulou, A. (1998). Functionality of TOQL Application of Temporal Benchmarks. Technical Report. Available from Wu, Y., Jajodia, S. and Wang, X. S. (1997). Temporal database bibliography update. Available from 30