ODM Data structure

ODM v1.3 has the following main sections:



Study

allows the representation of various studies in one file. It contains the protocol and form-setup defini-

tions. The following sub-elements of "Study" are exported:



GlobalVariables

contains the study name.



MetaDataVersion

contains setup information regarding the study, including definitions of the visits, the eCRFs associ-

ated with each visit, the information collected on each eCRF, and code lists. For each project version

as created by a project release a corresponding MetaDataVersion element is exported when the ex-

port option "with Audit Trail" has been selected.



AdminData

includes administrative data such as references to the investigators and the trial centres. Also signature

definitions are exported here.



ClinicalData

contains the collected data items of the study. In the "ClinicalData" section, all study data is included.

The data is represented according to the hierarchy for each subject (StudyEventData, FormData, Item-

GroupData, ItemData), which in turn is equivalent to the meta-data hierarchy (StudyEvent, Form, Item-

Group, Item).

If the exported data include the audit trail then for each exported MetaDataVersion a corresponding Clin-

icalData element is exported if there has been any data changes in that setup version.

In CDISC and secuTrial

®

_{the wording for some elements are different. Both notations could be used in the}

following description. Some of the elements are listed below:

secuTrial

®

_CDISC

project

study

patient

subject

centre

location

location

address

Omitted information

The following sections are not included in the secuTrial

®

_{4.7 ODM v1.3 export:}



ReferenceData

gives information about the validity of data, such as value ranges not necessarily study-specific.



Association

for annotations across different elements.



ds:Signature

for signing the xml document itself. Do not mix up with the signature applied to an eCRF! The latter is

documented with the "Signature" element.

Besides the matching problems mentioned below some setup information are omitted in the export. They

may be included into future versions of secuTrial

®

_.



setup information about non stored forms (as used for printing or display only)



rules and checks, including error messages



measurement units for number fields

Artifical study elements

There are some articifical study elements introduced by secuTrial

®

_{to allow the export of meta information,}

that are related to the eCRFs but not directly entered:



Study event random: RANDOM

The assigned random group or random number of a patient is exported as an additional study event with

a single Form element, including a single ItemData element and one Item element for each randomisa-

tion button. The random button-items themselves are additionally exported as normal eCRF item data. If

unblinding during export has been selected than only the data in the artifical random form is unblinded.



Form visit date: F.VMI

Because the visit date can be changed independent from any eCRF handling, a separate form for this

date is used. The transactions of this form reflect the editing of the visit plan in the DataCapture.



ItemGroup patient identifier: FG.SUBJID

It was requested to include the patient pseudonym as an additional item into each eCRF form. So a new

ItemData and Item element has been created for this. As the pseudonyms cannot change, this item is

only inlcuded in the first INSERT transaction.

Normally the Pat-ID is used as the pseudonym. If this is not used in the project for patient identification or

the participant has no role right to see this, either the Add-ID or the Lab-ID is used, depending on project

and role configuration.



ItemGroup form status: FG.FS

The different form status are included in a separate form group on the beginning of each form. For every

single status (see table description for mnp-tables above), an own Item element “FF.FS” is created.

These elements are included into every transaction.



ItemGroup form saved timestamp: FG.MNP

The time stamp of eCRF editing is included as a separate ItemGroup element with a single Item “FF.MN-

PLASTEDIT” element. These elements are also included into every transaction.

Audit Trail

The secuTrial

®

_{-CDISC export is build as a single import file into other systems. In contrast to the other export}

formats of secuTrial

®

_{the audit trail is not handled with separate files (or tables) but with subsequent transac-}

tions to the same FormData element. The transaction type of the first statement is set to "Insert" whereas the

subsequent entries to the same eCRF are set to "Update". The current data of the eCRF is the last transac-

tion.

In the productive ExportSearchTool all existing project versions are exported as separate MetaDataVersion

definitions and corresponding ClinicalData elements. So every eCRF transaction is exported with the related

Meta DataVersion element (=project version), with which the transaction was made.

If no audit trail is exported all transactions are of type "Insert".

Queries and Comments

Queries and comments are exported as annotations to the single item data. If the "typed data format" has

been chosen than the AnnotationID is given as an attribute of the ItemData<Type> element, the annotation

itself will be listed in the Annotations element. With the "untyped data format" the Annotation will be included

directly as a sub element of the ItemData element.

If no audit trail is exported the complete list of queries and comments are added to the current data (=last

transaction) with the transaction type set to "Insert" if the format of the data is untyped. In this case the com-

plete list of queries and comments will therefore be exported (if the option is chosen) even if the audit trail is

omitted. If the audit trail is included the particular query or comment entry is added to the correct particular

transaction. In this case the element UserEntry will not be added to the annotation (if iAS extension has been

selected), because the user of the form data is responsible for the annotation too.

If the typed data format is chosen and the audit trail is omitted, than only those queries and comments will be

exported that has been added as the last transaction to the data.

Hidden data

As it is not allowed to delete any collected (productive) data, in secuTrial

®

_{it is possible to hide single items,}

item groups(=questions) or forms from view in the DataCapture if this information shall not be collected any

longer. This data could be included into an export.

If the iAS extensions are used than hidden data are denoted by the attribute "ias:hidden" in the study defini-

tion of the FormData, ItemGroupData or ItemData elements. Without the iAS extension this data is flagged

up by annotations added to the hidden data element (FormData, ItemGroupData or ItemData)

secuTrial

®

_{and CDISC}

There are some limitations in matching the data within secuTrial

®

_{data with the CDISC format:}



Signature, Queries/Comments and sequence of transactions

The action of making a query or comment to the data in secuTrial

®

_{could include the e-signature. Here}

the complete data of the made annotation and the referenced eCRF data are signed. If the audit trail is

omitted the annotation is not appended to the transaction statement where it was made, but all annota -

tions are appended to the last (current) data but only if the untyped data format is chosen. For typed data

export only a query or comment appended as a last transaction could be exported (see below).

So the e-signature is normally applied as a Signature element to a FormData element. If all queries are

appended to the single transaction for a snapshot export then the additional UserEntry is added when

the iAS extension has been chosen and the data is exported in the untyped data format.

To get a complete and exact impression of the query management we recommend using the typed data

export with included audit trail.



Queries and Annotations

For queries a series of related annotations belong to one discussion. This fact is not reflected in the

ODM definition. In the iAS extension therefore the QueryID element has been declared to allow the

grouping of annotations by the same QueryID. This query ID is displayed in the user interface of the sec-

uTrial

®

_{DataCapture module. As the comment IDs are displayed also, a corresponding CommentID ele-}

ment has been declared for that type of annotation too.

If the standard ODM version is used, only the AnnotationID indicates the grouping of related annotations

by using the query ID as the first number part.



Transactions and AuditRecord

If the audit trail is exported, the type of the ODM file is "transactional" and for every FormData element

an AuditRecord element is given. It contains the "ReasonForChange" where the content of the "sigtext"

and optional "modifyreason" column is exported. If the audit trail is not exported, no AuditRecord is giv-

en.

With multiple project setup versions and included audit trail multiple ClinicalData elements are exported.

Then the SubjectData and StudyEventData elements are included in different ClinicalData elements for

the same patient and visit when the save of an eCRF has been done with different project versions.

Therefore subsequent listings of such elements have applied "Update" transactions. But there could be

no AuditRecords given as the elements are not changing themselves but the included elements are

changing.



LocationRef in AuditRecord

The AuditRecord element of each form has a mandatory location entry. During the process of saving an

eCRF in secuTrial

®

_{the participant and time are stored for the action, but not the information about loca -}

tion. For the export the location of the patient is used here, as this should have been the location during

editing. However, as it is possible for patients to change their location (=centre) via the AdminTool this

information may not represent the correct former centre.

(Note: a location element in a web based application is as good as useless as a data entry could be

made from all over the world and do not necessarily reflect the physical location of the data entry point.)



Roles

In CDISC only three roles are defined without further information to the meaning of this definition. A role

can only be given directly to a participant. In secuTrial

®

_{the role concept is quite sophisticated. The roles}

are defined with dynamic rights concerning application functions. A participant can have different roles

dedicated to his participation in different centres (=locations). Therefore most times the role properties of

participants will be left empty for export. Only when participants are assigned directly to a project the role

property will be set. For matching this to the CDISC role specifications the role name in secuTrial

®

_{is liter-}

ally compared to the CDISC role names. If it does not match with any of these, the label "Other" is set.



Typed Item data and Annotations

As it is only allowed to add a single AnnotationID attribute to an ItemData<Type> element there are

some restrictions for this type of data format in the combination with other export options.

If the audit trail is omitted only a query or comment appended as a last transaction could be exported.

If hidden data are exported without iAS extension it could be possible that the AnnotationID for the hid-

den flag could not be added to a hidden ItemData<Type> element if the affected item has another an-

notation like a query, comment or sdv entry. For that case the more important information is added in the

hierarchy: query > comment > sdv > hidden.



Included data

Is it valid in the CDISC ODM definition to omit the part of the study definition or admin data as long as

former ODM files are referenced in the PriorFileOID attribute of the ODM element where all administrat-

ive or study OID referenced in the current file are declared.

As it is not possible in the ExportSearchTool application design to guarantee that such a former file is

available this option is not implemented in secuTrial

®

_{4.7 to assure the generation of valid CDISC ODM}

files. The former selectable option of including administrative and or setup data has therefore been dis-

abled.



Images

In contrast to all other items an uploaded image file contains more information than just a simple one-di-

mensional measurement. In CDISC ODM there is no option to include such multi-dimensional item data.

Here we decided to export the (server-generated) filename as the most unique identifier for the image. If

the iAS extension is chosen an additional ImageID allows to reference the separate information exported

in the ImageData elements (following the principle of Annotations).

Date Formats

All date fields edited in the eCRFs (iAS date components) are stored as strings in the database following the

pattern YYYYMMDDHHMISS.



YYYY is a four digit year value, e.g. 1956



MM is a month in number starting with 01 for January and 12 for December



DD is the day of the month



HH is the hour value of the time (in 24 hours-cycle)



MI is the minute value of the time



SS is the second's value of the time.

Other system-generated dates are stored in a real date format in the database.

CDISC formats for date and time are compliant with ISO 8601.

ODM demands the specification of the time zone. "Datetime" is the only format that is specified with a time

zone value. ODM 1.2 defines: “A missing time zone specification means that the relationship between the

local clock and Universal Time is not known.” In secuTrial

®

_{time zone is specified within the configuration file}

(default is CET / CEST).

Type iAS Format CDISC Format Description Example (typed data)

Type iAS Format CDISC Format Description Example (typed data)

time-

stamp DD-MM-YYYY HH:MM:SS (Z) datetime YYYY-MM-_{DDThh:mm:ss.n+hh:} mm <DateTimeStamp>2004-05- 19T18:05:44.000+02:00</DateTim eStamp> iAS date compo- nents

YYYY partialDate YYYY <ItemDataPartialDate

ItemOID="FF.birthdate_3">1974< /ItemDataPartialDate>

MM-YYYY partialDate YYYY-MM <ItemDataPartialDate

ItemOID="FF.birthdate_3">1974- 09</ItemDataPartialDate>

DD-MM-YYYY partialDate YYYY-MM-DD <ItemDataPartialDate

ItemOID="FF.pregdate_5">1998- 05-05</ItemDataPartialDate> DD-MM-YYYY HH:MM partialDatetime YYYY-MM-DDThh:mm <ItemDataPartialDatetime ItemOID="FF.pregdate_5">1998- 05- 05T10:09</ItemDataPartialDatet ime> HH:MM partialTime hh:mm <ItemDataPartialTime ItemOID="FF.birthdate_3">10:09 </ItemDataPartialTime> HH:MM:SS partialTime hh:mm:ss <ItemDataPartialTime ItemOID="FF.stopdate_7">20:17: 32</ItemDataPartialTime> MM:SS incompleteDatetime mm:ss <ItemDataIncompleteDatetime ItemOID="FF.startdate_7">--- - T-:17:32</ItemDataIncompleteDa tetime> iAS checked date compo- nents

YYYY partialDate YYYY <ItemDataPartialDate

ItemOID="FF.birthdate_3">1974< /ItemDataPartialDate>

MM-YYYY partialDate YYYY-MM <ItemDataPartialDate

ItemOID="FF.birthdate_3">1974- 09</ItemDataPartialDate>

DD-MM-YYYY date YYYY-MM-DD <ItemDataDate

ItemOID="FF.pregdate_5">1998- 05-05</ItemDataDate> DD-MM-YYYY HH:MM partialDateTime YYYY-MM- DDThh:mm <ItemDataPartialDatetime ItemOID="FF.pregdate_5">1998- 05- 05T10:09</ItemDataPartialDatet ime> HH:MM partialTime hh:mm <ItemDataPartialTime ItemOID="FF.birthdate_3">10:09 </ItemDataPartialTime> HH:MM:SS time hh:mm:ss <ItemDataTime ItemOID="FF.stopdate_7">20:17: 32</ItemDataTime> MM:SS incompleteDatetime mm:ss <ItemDataIncompleteDatetime ItemOID="FF.startdate_7">--- - T-:17:32</ItemDataIncompleteDa teTime> iAS date/time intervals compone nts

Y durationDatetime PnY <ItemDataDurationDatetime

ItemOID="ff.scoredate">P54Y6M< /ItemDataDurationDatetime> Y-M PnYnM Y-M-D PnYnMnD Y-M-D-H-M H-M PnYnMnDTnHnM H-M-S PnYnMnDTnHnMnS

Type iAS Format CDISC Format Description Example (typed data) M-S

The partial date and time types are new introduced in ODM v1.3. As the complete date or time information

are only guaranteed in the secuTrial

®

_{checked date components with "YYYY-MM-DD" or "HH:MM:SS"}

format, all other components are declared partial with exception of the date component type "MM:SS".

The new calculated date/time intervals are exported as date durations. Be aware that they do not represent

exact time length!

As there is no time zone information in the iAS eCRF date components this part is not exported in eCRF

data.

In document Documentation. secutrial Export Formats. Valid for Version 4.7 As of (Page 53-58)