Who? When? What? Why? As a Clinical Programmer assigned to maintain an existing Rave study these are all questions you will be asking yourself. Who last modified this study build? When did they change it? What did they change and perhaps most important, Why did they change it?

Here's a Form in the TrialGrid Form Editor:

This is not dissimilar to the Form Editor in Rave Architect except for the small side-bar on the right showing some additional state information. If we expand that:

Now we can see that:

1. There is a Ticket (#8) associated with this Form and the ticket is in an Open state
2. The Form has been labelled as "Blocked"
3. The user Ian Sparks has performed some activities which changed the state of this Object - this Activities view shows all changes made to the object over time. We can also see that Ian made a comment, referencing the user @anewbigging1 and explaining why it is blocked
4. The user has commenting permission on this object and can add additional comments

This is all important contextual information that would normally exist in some other system - a tracking spreadsheet, an Issue management or workflow system like Jira or in the worst case an email thread between the participants.

By including the ability to label objects with workflow state (Labels), to link with work to be done (Tickets) and to talk about the work item (Comments) we enable a team to collaborate more easily to get the study build done. The end result is faster development of your study build.

Of course, comments aren't helpful if nobody is reading them. That's why, every time you @mention another team member in a comment (or ticket, or wiki page) in TrialGrid, that user gets a notification email with a link to take them direct to the comment (via login of course):

These capabilities are just the latest addition to TrialGrid, we're continuing to work on features that bring all aspects of Rave Study Build into a single, unified environment. This is important because although we can provide tools (like Form and Edit Check editors) which are more efficient, much of the time spent on study build is in the gaps between tools where it can't be measured such as the communication between team members.

Having team communication in email is inefficient because you have to repeat all the context i.e. what URL, what Project, what Draft, what object is this question about? It also means that decisions aren't automatically documented because they are hidden in emails.

In contrast, comments in TrialGrid are attached to the object they reference so that discussion about an object is documented alongside that object. Decisions are captured for the whole team to see now and in the future which is especially important for long-running studies where the maintenance team is likely to change.

How much could your organization save by centralizing study build workflow in a tool that centralizes both the build activities and the team communication?