Every participant entered into the system has all his or her assessment data stored in a record. Each record can be identified by its unique participant identifier, and contains multiple documents.
The record status reflects the progress of the participant through the study. The record status will update automatically when a study stage is completed.
A document contains participant data and is part of a record. Each document can be completed independently of other documents, and has its own status (see 'Document Status' definition below). Documents may have multiple sections. A document can only be saved as complete if all the data is entered and validated, but may be saved as incomplete at any time.
The point at which a document exists in the document work flow process. See the section called “Collect Document Work Flows” .
A document is incomplete if one or more mandatory data items have not been entered (i.e. validation would fail if you tried to save the document as complete). Documents can be saved to the database as incomplete, and then can be completed at a later time.
A document is complete when all mandatory data items have been entered. The data in the document may still be freely amended.
Pending documents are complete documents that have been committed to the database and are awaiting approval.
Rejected documents have been reviewed and are not considered acceptable. The reasons why the document has been rejected are stored in the rejected document.
Approved documents have been reviewed and are considered to be acceptable. No further changes to the data in the document is expected.
Controlled documents may only be edited by accompanying each change with a comment as to why the change has been made.
The Participant Identifier uniquely identifies a participant and their record in the system. The system automatically generates participant identifiers. The format of the participant identifier is PPP/GGGGGG-Z, where PPP is the 3-letter study code, GGGGGG is the 6-digit centre code and Z is the participant number.
The study code uniquely identifies the study within the openCDMS system e.g. OLK is Outlook, ED2 is EDIE2 etc.
The centre code identifies a subset of a whole study (see the section called “Study Centre” ).
The participant number is just a number that increments as records are added to a centre in a study.
As is discussed in the section called “Collect Document Work Flows”
The 'Participant Register' is an openCDMS facility that is provided in order to maintain a mapping between the system-generated 'participant identifier', and the participant's personal information (name, address, etc.).
The register stores this sensitive information in a separate database from that which holds particpant records. Not all studies are configured to use the register; if the register is not being used it is vital that users maintain their own mapping between the participant's identifier and identifiable details.
As described in the section called “Data Replication” section, data replication is a feature to help share information between similar studies (i.e. they have some of the same documents) that share some of their participants. By using this feature, data entered for a participant in one study may be automatically replicate to the other, thereby preventing redundant data entry.
Where potentially identifiable data is entered into the database it is transformed such that it cannot be recovered. The database to preserve anonymity transforms all participant’s initials, postcodes and NHS numbers. The picture of a “T” in a circle indicates a transformed value.
A study centre represents a geographical subdivision of the complete study. Each participant in the study will be associated with one study centre.
Collect is said to be off-line when the computer is not connected to the openCDMS server. All data is stored locally on the computer and it is not possible to access the central openCDMS database.
Collect is said to be on-line when the computer is connected to the openCDMS server. The user can interact with the database when on-line.
As explained in the glossary, a study is a collection of clinical research forms that will be populated with data about the study's participants.
Studies for openCDMS are highly configurable, and therefore each can have different features, resulting in some differences in the way that you use 'Collect'.
This section first surveys the features that most studies have in common, and then it lists various other study-specific configurations; it is advisable that you know which of these configurations that the study you are working on has been configured with.
A typical study will be organised into different centres, representing different geographical regions. As a collect user, you will have been assigned to one or more of these centres. Participant records 'belong' to a particular centre, and as a member of that centre, you will be able to view / amend all participant records that belong to the centre.
Practically speaking, this means that once you save a participant record to the database, any other member of that centre who has been given the necessary privileges can download, view, and amend that participant record.
Each participant within the study is assigned a unique identifier by the system. As detailed in the section called “Participant Identifier” , the unique identifier embeds the study that the participant is in, and the centre code to which they have been assiged. Each participant will be accessed in Collect by this anonymous participant identifier.
Typically, the documents that must be completed for each paricipant are grouped into different study stages, as explained in the glossary. These stages usually represent different time points in a study (e.g. at time of entry into study, six months later, etc.).
In order to track the degree of completeness of a particpant record, each record is assigned a 'record status'. The status names are study-specific, but they typically indicate the last study stage for which all documents have been completed. Typically the study is configured so that on completion of the last document in a study stage the record status is automatically changed to the equivalent status value e.g. complete the final document in the "Baseline" study stage and the status is changed to "Baseline completed".
Individual documents also have a 'status' which tells you where they are in the document work flow. As the document work flow varies per study, please see the section called “Collect Document Work Flows” . In brief, this status indicates how complete the data in the document is.
This section covers the various features that a study may be given at design time - it is highly recommended that you find out exactly how your study has been configured before reading any further. Knowing this info will make learning how to use the application much easier.
Integration with the Participant Register : if this option has been configured, the openCDMS system will maintain a mapping between patient-identifiable information and the anonymous, system-generated Participant Identifier. If your study integrates with the Participant Register then you will be asked to enter the Participant's identifiable personal details (name, address, etc.) when you enter a new participant using Collect. If you are not asked to enter this data then you must maintain a mapping between the openCDMS Participant Identifier and the Participant's personal details yourself.
Work Flow Type: It is important for you to know what type of document work flow your study employs, see the section called “Collect Document Work Flows”.
Randomisation: Some studies have been set up to randomise participants into an arm of a clinical trial. Upon completion of a designated document you will be asked whether you wish to randomize the participant or not.
The work flow stages that participants' documents go through depend on how the partcular study you are working on has been set up. Your study will use one of two work flows - one is called "Review and Approve" and the other is called "Implicit". The primary differences between the two is that "Review and Approve" requires a Clinical Study Manager (CSM) to review submitted documents and to either approve or reject them. The "Implicit" work flow is much simpler. It does not require a CSM to review submitted documents. As the name implies, data review is assumed to be carried out solely by the data entrant. This section documents the progress of documents through each type of work flow.
Please note that the following document work flows are with respect to documents that have been committed to the database. If you are NOT working in 'Always online' mode, you must remember to commit your records (which contain the documents) to the database before they enter the work flow.
See the section called “'Always Online' Mode” for an explanation of the benefits of using 'Always-online' mode.
These work flows share two stages, that of 'Incomplete' and 'Complete'. The following section clarifies the meaning of these.
If you are performing data entry on a document and you do not have all the required data to hand, you may wish to save the document as 'incomplete'. This saving option bypasses data validation.
The distinction between 'complete' and 'incomplete' documents is very helpful for managing a project and generally keeping track of how much data entry is left to be done. However, it is the responsibility of the user to maintain a meaningful distinction between the states.
The distinction may become blurred if you do either of the following:
- Complete the data entry for a document but save it as 'incomplete'
- Apply missing codes for the data in a document that you do not currently have and then save it as 'complete'.
The first scenario would make it appear that less data entry has been done that it actually has, and the second scenario would do the opposite - and make it look like much more work has been done than it actually has.
See the section called “Saving Documents” for information on how to save documents as 'complete' and 'incomplete'.
The diagram above shows the work flow of documents managed by the 'Review and approve' process. Note that the 'incomplete' state is shown by a dotted line, noting that it is not a mandatory part of the workflow, but is available as a matter of convenience when entering data. It is entirely possible to skip the incomplete step, and to immediately complete the document.
Once a document is completed, the user can then move it to the 'pending approval' stage so that the Clinical Study Manager (CSM) may begin the review process. (See the section called “'Review and Approve' Work Flow” for how to progress a document from 'complete' to 'pending approval').
The CSM may then either reject or approve the document. If the document is 'rejected', then the Clinical Research Officer (CRO) must address the reason the document has been rejected (see the section called “Working with Rejected Documents” for details on how to handle rejected documents).
After making the necessary corrections, the document can be moved back to 'pending approval' and the review cycle starts again.
Once the document has been 'approved' by the CSM, it is usually finished. But if the CSM learns after the fact that the document requires revision or additional information, the CSM can re-open the document for editing, which will move the document back to the 'pending approval' state, and further back then to 'Rejected' if required.
Studies that use this work flow place the onus of veriyfing document data on the CRO - essentially, the CRO acts implicitly as the CSM by self-assuring the validity of document data. This means that there are fewer work flow stages to complete, which makes the study less complicated to manage.
The most important aspect of the work flow to grasp is the difference the 'Complete' and 'Controlled' work flow state. 'Complete' means that all required fields have been populated in the document, but the data can still be changed and these changes are not recorded.
Once the CRO is confident that the data for a document is, complete and correct, they should then move the document to the 'Controlled' work flow state. See ??? for instructions on how to progress a document from the 'complete' to 'controlled' state.
This state is similar to 'Approved' in the 'Review and Approve' work flow, combined with the data editing provided by the 'Rejected' state .
Two different connectivity modes are provided to suit your working habits.
You should use 'Always Online' mode when you always have an active network connection (that allows you to connect to the openCDMS database) whilst you are entering data.
When a Document is completed (or you opt to save it as incomplete) it is saved to the openCDMS database immediately. When completing or amending the Document it is retrieved from the Database, you make the changes, then it is saved to the Database again.
'Always online' mode has many benefits over 'Online and offline' mode, but principally the security and integrity of your data is maximized by using this mode.
The 'Always-online' mode was introduced in Collect version 6.1. All users, whether they are installing 6.1 for the first time or upgrading from a previous version, will have their application set by default to use 'Always-online' mode.
This mode should only be used if you have a requirement to enter data on your computer in a location where you do not have a network connection (you are 'off-line'). Data entered is saved on your computer's hard disk (in an encrypted format), then you must manually choose to 'Commit' the data to the openCDMS Database when you are connected to the network (you are 'on-line').
You can tell if you are on'line or off-line by viewing the connectivity icon in the lower right-hand corner of the Status Bar. If the connectivity icon is red, it means that you are off-line. If it is green, you are on-line. When you are off-line Collect can only be used to enter data; when you are on-line all of Collect's functionality will be available.
We only recommend using this mode when it is absolutely necessary, as your data is considerably more vulnerable whilst it is stored on your computer's hard disk than when it is committed to the openCDMS Database. Even when using this mode you should commit data to the Database as often as possible; it is not good practice to have data stored on your hard disk for long periods of time.
