Element description: Clinical data

7. CDISC ODM 1.3

7.8 Element description: Clinical data

The collected data of the study is exported in this part. The study name and meta data version under which

the export is performed is referenced here (this is not necessarily the version under which the data was col -

lected).

In secuTrial

_{the project version no and version label are stored in the form data, at least when they are set.}

So it could be referenced for every form data with which project version the data has been collected. In

CDISC there is no appropriate reference for this. So the reference to the correct "MetaDataVersionOID" is

exported as a form annotation if given.

<SubjectData>

As the form data of a single subject could be edited in different study meta data versions, the single patient

could be listed more than once. Therefore a transaction type is added to this element. Because the element

itself is not edited but only the included form data elements there is no direct audit record element attached

here.

SubjectKey

[

"SUBJECT." + patient.pid

] After the prefix the primary key of the DB patient ob-

ject is used. This is unique across all studies and does not represent any identifica-

tion information as presented to the user; hence anonymised patients or exports

without the pseudonym or additional id are still valid. As data for the same subject

could be edited in different study version a patient could be included in different

clinical data elements. In that case the subsequence listings have the transaction

type set to "Update".

LocationRef

Reference to the participant who entered the patient into the current project (either

by creating a new patient in a registry or by adding the patient into a part-project.

This reference is only given in the first (Insert) transaction.

SiteRef

Reference to the centre the patient is dedicated. This reference is only given in the

last transaction.

<Annotation> - Subject

For each patient, the information about his/her status (SeqNum=1) and the information about his/her status

within the project (SeqNum=2) are always exported. If the export of the pseudonym (SeqNum=3) and addi-

tional id (SeqNum=4) are also included depends on the export options. If these fields are not filled in, an

empty annotation is exported. The type and value of these annotations are decoded by the specified, fixed

code lists.

These subject annotations are only added to the last transaction representing the current subject status. The

annotations for the subject status (1 and 2) are only exported, if the option meta data option “Patient status”

has been selected.

<Comment>active</Comment> <Flag>

</Annotation>

Comment

[

patient.getCumulatedPatientStatusString(patient.patientenstatus)

] Textual

representation of the whole patient status as given in the AdminTool.

<Comment>active</Comment> <Flag>

</Annotation>

Comment

[

patient.getCumulatedPatientStatusString(casenode.cnstatus)

] Textual re-

presentation of the casenode status as given in the AdminTool under project

status.

</Annotation>

Comment

[

patient.pseudonym

] This is what is named "patient PID" in the secuTrial

refer-

ences; it is used to reidentify patients within all the different secuTrial

_{applications;}

this field is exported according to the selected export options; if the project config-

uration claims to hide this field, it can not be selected for export; in this case the an-

notation is omitted.

<Flag>

</Annotation>

Comment

[

patient.aid

] Additional id for patients; it can be empty depending on the project

configuration; if this field is not used in the project at all, it is not possible to be se -

lected for export and this annotation will be omitted.

<StudyEventData>

Visits, adverse events and the patient status matrix are handled as study events. Therefore, each visit, each

adverse event and the patient status matrix are exported as single study events. The number or visit events

depend on the visit plan of each patient.

As the form data of a single study event could be edited in different study meta data versions, the single

event could be listed more than once. Therefore a transaction type is added to this element. Because the

element itself is not edited but only the included form data elements there is no direct audit record element

attached here.

StudyEventRepeatKey

[

casevisitplan.visitno + "." + (i+1) | "AE." + adverseevent.aeno + "." + (i+1)

] If the visit is defined as repeating, the stored visitno is exported; this number

is set during the creation of each individual visit regardless if this is a repeating visit

or not; therefore it is possible that it does not start with "1"; for adverse events the

aeno is used which is calculated during the creation of the individual adverse

event; if adverse events may be created independent from the temporal sequence,

the order of time and repeat key may differ. Therefore additional the repetition in-

dex is appended, similar to the building of a visit. This should guarantee unique re-

peat keys even for merged patients.

<FormData>

The audit trail of eCRFs is exported as a sequence of transactions to the same form data element. The first

element has the transaction type set to "Insert", every following element is set to "Update". Every child ele-

ment will inherit the transaction type. Only if a new item group or item element is declared in a subsequent

meta data version element, the transaction type of an internal element could differ from the outer type. Each

transaction is listed in the clinical data element for the corresponding meta data version with which the form

was saved (in former secuTrial

_{version indicated by an annotation).}

The form is the basic element for collecting data in secuTrial

_{. For this reason the AuditRecord and Signa-}

ture element are only appended to this ODM element.

To export additional information from secuTrial

_{to CDISC annotations are used. The first annotation (Se-}

qNum=1) displays the document-ID. One annotation (SeqNum=2) provides the action for storage; this is the

same information as in the SignatureElement. As not necessarily all forms or actions have to be signed, the

reason for saving is backed up here, too.

The last annotation (SeqNum=4) is exported if the option for checking the signature validity is selected (only

available if the e-signature is configured in the project).

FormRepeatKey

[

"AE." + adverseevent.aeno + "." + (i+1) + ".FU."+ (j+1)

] If the form belongs

to an adverse event, then it is declared as repeating. In this case the ae event key

with the follow-up repetition index is used as the repeat key.

<AuditRecord>

<DateTimeStamp>2008-06-18T15:03:46.000+02:00</DateTimeStamp> <ReasonForChange>Query eingefügt</ReasonForChange>

<SourceID>mnpdid.2.mnpatdid.3</SourceID> </AuditRecord>

DateTimeStamp

[

document.mnpdate in ISO-format

] timestamp of storage, same content as in Sig-

nature.DateTimeStamp (see below).

ReasonForChange

[

document.sigtext + ": " + document.modifyreason

] reason for storage as

defined by action. This is stored textually in the field sigtext. If the action requires

signing, this text is presented to the user as legal reason (similar to signature ele-

ment). For the action of data modification after the status "data entry complete" has

been set (extended workflow) the participant has to supply a reason for changing

data. If this reason is set it is appended after the general text.

SourceID

[

"mnpdid." + mnpdid | "mnpdid." + mnpdid + ".mnpatdid." + mnpatdid

] primary

key of the tpxdocument and the attpxdocument for transactions from the audit trail.

<Signature>

<DateTimeStamp>2008-06-18T15:19:28.000+02:00</DateTimeStamp> <ias:Validity>gültig</ias:Validity>

<ias:Version>0</ias:Version> </Signature>

ias:Validity

[

"valid" | "invalid"

] As it is possible that only some actions require an e-signa-

ture the "not signed" is an allowed state but then the Signature element is not ap-

pended at all. The validation is done during export by new calculation of the hash

value across the stored data and comparison with the stored hash value.

ias:Version

[

"0" | "1" | "2"

] Displays the algorithm version with which the signature has

been generated.

<Annotation>

<Comment>Dokument-Nr. 2 - 1</Comment> </Annotation>

Comment

[

" Dokument-Nr. " + document.mnpdid + " - " + position in audit trail

] Docu-

ment-ID as presented in the DataCapture; the included mnpdid is the primary key

of the document object in the DB.

<Comment>Daten eingegeben</Comment> <Flag>

Comment

[

DocumentStore.decodeSigstatus(document.sigstatus)

] Textual representation of

the value of the Flag. (Could slightly differ to AuditRecord.ReasonForChange if the

LanguageBundle has been updated during data collection. The meaning should

nevertheless be similar.)

<Comment>unsigniert</Comment> <Flag>

</Annotation>

Comment

[

"not signed" | "valid" | "invalid"

] Status of the signature check: if the form

has not been signed, the first option is used and the signature is not checked; oth-

erwise a "valid" flag indicates that a recalculation of the signature hash value pro -

duces the same result as the stored hash value and therefore the signature is valid.

<Comment>ausgeblendet</Comment> <Flag>

</Annotation>

Comment

[

!form.isVisible

] Status of the 'hidden'-property: if set to "1" the form is hidden

from view in the DataCapture for data collecting and display. This annotation is

only exported if at least one element of the project-setup is set to 'hidden', these

elements shall be included in the export, the untyped data format is chosen and the

export does not use the secuTrial

_{extensions (see above). For more limitation see}

chapter: Hidden data.

<Comment>DDE original document: 5281</Comment> </Annotation>

Comment

[

tpxdocument.dderealdid | tpxdocument.ddeduplicatedid

] Document-ID of the

either the real document (if this is the duplicate) or of the duplicate (if this is the real

document) of the Double Data Entry. Which type of relation-id is used is described

by the label. Only exported if this is a DDE form.

<ItemGroupData>

The item group is an organization component for data. In secuTrial

_{this is matched to the form group level of}

the form setup.

Repetition groups with multiple subforms can be exported with a repeat key indicating the position of the sub-

form in the repetition. For these repetition groups the form group level of the contained subforms are ignored

an all contained subform-items are exported as items in this repetition group.

ItemGroupRepeatKey

[

repetitionindex

] Position in the repetition of a subform.

<Annotation>

<Comment>hidden</Comment> <Flag>

</Annotation>

Comment

[ !formgroup.isVisible ] If the form group is direct (property "hide") or indirect (by

form) hidden from view in the DataCapture for data collecting and display. This an-

notation is only exported if at least one element of the project-setup is set to 'hid -

den' and these elements shall be included in the export and the export does not

use the secuTrial

_{extensions (see above). For more limitation see chapter: Hidden}

data.

<ItemDataTyped>

IsNull

[

"Yes"

] If no value is stored (the DB column contains "null") this attribute is set;

these two attributes are mutually exclusive. If this attribute is set than the type

"ItemDataAny" is used.

ias:sdv

[

sdvstatus-bit

] Status of the SDV for this item. This attribute is only exported if

the project uses SDV and the export includes the secuTrial

_extension.

ias:ImageDataID

[

reference to the ImageData element

] The reference to the ImageDataElement

which describes the image file(s) in more detail.

text

[

patient.pseudnoym | formstatus-bit | mnplasteditdate | valueOf(mnprecord.- valueForKey (formfield.ffcolname)

] In this element the stored value for a column

is given; for simple number fields or text this is the exact DB value; if the item defin -

ition references to a code list, this code list is used to decode the exported value; if

no value is stored (the DB column contains "null") this attribute is not set.

For the additional items for the form status any value other than "null" implies that

the status described in this item is set; checkbox values are recoded during export;

in secuTrial

_{the non-checked box is stored as "null"; as this is a reasonable value}

it is exported as "0". (If it is crucial to distinguish whether the user has explicitly

chosen to answer "no" or if he/she hasn't answered at all, another item type such

as radio buttons should be used.)

All values are checked against the definition supplied in the item definition; if a

code list value is missing or the format does not match, the CDISC file is not valid.

<ItemData>

Value

[

formstatus-bit | timestamp |valueOf (mnprecord.valueForKey(formfield.ffcolname)

] In this element the stored value for a column is given; for simple number

fields or text this is the exact DB value; if the item definition references to a code

list, this code list is used to decode the exported value; if no value is stored (the DB

column contains "null") this attribute is not set.

For the additional items for the form status any value other than "null" implies that

the status described in this item is set; checkbox values are recoded during export;

in secuTrial

_{the non-checked box is stored as "null"; as this is a reasonable value}

it is exported as "0". (If it is crucial to distinguish whether the user has explicitly

chosen to answer "no" or if he/she hasn't answered at all, another item type such

as radio buttons should be used.)

All values are checked against the definition supplied in the item definition; if a

code list value is missing or the format does not match, the CDISC file is not valid.

IsNull

[

"Yes"

] If no value is stored (the DB column contains "null") this attribute is set;

these two attributes are mutually exclusive.

ias:sdv

[

sdvstatus-bit

] Status of the SDV for this item. This attribute is only exported if

the project uses SDV and the export includes the secuTrial

_extension.

ias:ImageDataID

[

reference to the ImageData element

] The reference to the ImageDataElement

<ImageData>

<ias:ImageData ID="mnpimgid.79" uploadedfilename="DSC_0189.jpg" contenttype="image/jpeg" imagesize="71130">

ID

[

"mnpimgid." + tpximage.mnpimgid

] The unique identifier for this image, build with

the primary key of the database object.

uploadedfilename

[

tpximage.uploadedfilename

] The plain (without path) filename from the upload

(=client filename).

contenttype

[

tpximage.contenttype

] The content specification as given from the browser dur-

ing upload (=mime type). This could be used as a hint to specify the application for

file handling.

imagesize

[

tpximage.imagesize

] The file size of the uploaded image measured in bytes.

<ImageFileData>

<ias:ImageFileData type="original" filename="patientimages/5/75/75/1218213324296- 192.168.101.144-7777-0.jpg" filestatus="valid"/>

type

[

"original" | "web" | "thumbnail"

] The type of the described file, this could

either be the uploaded "original", the displayed "web" image on the eCRF or the

minimized "thumbnail".

filename

[

tpximage.originalFullPathExport | txpimage.webFullPathExport | tpximage.thumbnailFullPathExport

] The name and path to the exported image file. This

is even set if the image does not exist. All images are exported in a separate "pa-

tientimages" folder. Inside this folder the images are evenly distributed into sub-

folders according patient id parts.

filestatus

[

"valid" | "invalid" | "nonexistent"

] Status if the named file exists (is included

into export), is valid (=unchanged since upload) or invalid (changed since upload).

For original file a nonexistent file has to be treated as an error since the uploaded

file has to exist. Because even non-image files can be uploaded in secuTrial

nonexistent web- and thumbnail images are no error.

<Annotation>

Queries and comments are exported as annotations to the item data. In the comment the text entered by the

user is given, whereas the flag value distinguishes between query and comment. The flag type for queries

defines the type of query entry. The transaction type of these annotations is always set to "Insert" regardless

of the transaction type of the enclosing item, item group or form.

When queries and comments are cumulatively appended to the last form transaction (when no audit trail is

exported this is only possible for untyped data, see chapter: Queries and Comments), they do not corres-

pond to the AuditRecord entry of the enclosing form. To distinguish this information the secuTrial

_extension

for "ias:UserEntry" gives information about the user who made the annotation and the timestamp of this ac-

tion. If the audit trail is exported too the element "ias:UserEntry" is omitted for the query- and comments an-

notation because the user of the current form data transaction is responsible for the annotation too.

The "ias:QueryID" is the query ID as displayed in the DataCapture. It allows subsuming several query-entries

to a single query (including the query, its answers, and finally the closing comment). Similar the comment ID

is given in the "ias:CommentID" element.

The attribute SeqNum only reflects the sequence of listing and has no further meaning.

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