Articles tagged with 'TrialGrid'

Export and Import direct to/from Rave Architect

The TrialGrid system is designed to be a single environment for all the activities of study build. Rave Architect gives you a tool to build studies but it is not designed to capture design notes about the study or anything more than rudimentary workflow for the current state of Forms and Edit Checks in a Draft. For example, in Architect you can't make a comment on a Form that will then be seen by other users and you can't apply a label to an Edit Check to signal that it is ready for testing.

In TrialGrid you can perform these actions but until now you were required to download Architect Loader Spreadsheets (ALS) from Rave Architect, work on them in TrialGrid and then export them back to an ALS and re-upload to Rave Architect.

This week we released an updated version of our Direct Import and Export functions in TrialGrid.

Direct Draft/Version Import

From the Drafts page you can now import an ALS file directly from Rave Architect. This works with Rave Classic accounts and with iMedidata accounts - even those that have two-factor authentication enabled:

Two Factor Challenge

You can choose to authenticate TrialGrid for 30 days or just for the remainder of your TrialGrid session. Once you have authenticated you can import Drafts or Versions from any URL and Project you have access to.

Selecting URL / Project / Draft

Direct Draft Export

Exporting a Draft from TrialGrid can now be done directly from the home page for a Draft. Authentication via Rave Classic or iMedidata is the same but for export you can choose whether to create a new draft, overwrite or merge an existing Draft. TrialGrid then exports the current Draft to Rave Architect and updates you on progress.

Exporting

Being able to work in one system while importing and exporting to Rave Architect makes for a much smoother workflow. Just one of the convenience features we are adding to TrialGrid. Watch this space for updates in the next few weeks.

User Acceptance Testing Released

This week we released version 1 of our Automated User Acceptance Testing (UAT) feature to Beta site users and we are starting to work with customers to implement this approach into their processes. Manually testing Edit Checks and other dynamic features of Medidata Rave studies is tedious, error-prone work that takes a long time. Organizations which adopt the Automated UAT approach can test their studies faster, gather better quality testing evidence and free up their skilled staff for higher-value work.

Need convincing? Here's a video which demonstrates in 1 minute 38 seconds:

  • Creating a test script for an Edit Check
  • Reviewing the test script
  • Executing the test and collecting screenshot evidence (also available in PDF)
  • Reviewing the results in Medidata Rave

This video shows the testing for a single Edit Check but the system is also able to create and run test cases for hundreds of Edit Checks at a time. It also works for Rave EDC as well as Rave Classic (shown in video).

If you are ready to accelerate your Edit Check testing. Get in touch!

User Acceptance Testing Part 3

In the last part we introduced the Given..When..Then structure for writing User Acceptance Tests and showed how TrialGrid automates execution of these tests against Medidata Rave and also how the tests can be checked for validity before they are even run. In this final part we'll look at automating the generation of tests for Edit Checks. This blog post is a bit technical but if you are curious (or skeptical) about our claim of generating tests for 1,000 Edit Checks in 60 seconds, this post explains how we do it.

Alternatively, you could sign up for our free webinar https://register.gotowebinar.com/register/2929700804630029324 and watch TrialGrid in action. Seeing is believing!

Solving Constraints

Before we start looking at Edit Checks let's first look at a little puzzle. Maybe you did this kind of puzzle at school.

1
2
3
4
5
6
I have two integer numbers (whole numbers) A and B. 
A is always a positive number 
A is always an even number 
A is always greater than zero
A is always less than B
If B = 10, what are the possible values for A?

The answer is that A can be 2, 4, 6 or 8. You probably solved this puzzle in seconds.

This kind of problem is known as a Constraint Statisfaction Problem and it is well studied in Computer Science circles. My computer solved this puzzle in 0.0007 seconds - though I helped it out a bit by telling it only to look at values for A in the range 1 to 100 since I didn't want to wait while it considered the infinite set of positive even numbers. Computers can be really good at solving these problems if the set of values to search in isn't too large.

Edit Checks are Constraint Problems

Now we've warmed up on a simple constraint problem lets look at another. This is an Edit Check that uses Systolic and Diastolic blood pressure to identify pre-hypertension:

1
2
3
4
5
6
7
 IF:
    field SYSBP in form VS in folder SCREEN is greater than or equal to 120
    AND field SYSBP in form VS in folder SCREEN is less than or equal to 129
    AND field DIABP in form VS in folder SCREEN is less than 80
 THEN:
    Open Query "Subject is pre-hypertensive (SYS 120..129 and DIA < 80). Please confirm." 
    on field SYSBP in form VS in folder SCREEN to Marking group "Site from System"

In TrialGrid CQL the logic test part would look like:

1
2
3
SCREEN.VS.SYSBP[0] >= 120 
AND SCREEN.VS.SYSBP[0] <= 129
AND SCREEN.VS.DIABP[0] < 80

And in Medidata Rave QuickEdit:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
||StandardValue|VSORRES|SCREEN|VS|SYSBP|0||||||
|120|3|||||||||||
IsGreaterThanOrEqualTo|||||||||||||
||StandardValue|VSORRES|SCREEN|VS|SYSBP|0||||||
|129|3|||||||||||
IsLessThanOrEqualTo|||||||||||||
And|||||||||||||
||StandardValue|VSORRES|SCREEN|VS|DIABP|0||||||
|80|2|||||||||||
IsLessThan|||||||||||||
And|||||||||||||

Now if we wanted to work out what values would fire this Edit Check we can formulate it as a Constraints problem using the variables SYSBP and DIABP and quickly come up with a truth table of possible values and their results:


SYSBP SYSBP 120..129? DIABP DIABP < 80? Expected
120 Yes 79 Yes Fires
122 Yes 80 No Does not Fire
129 Yes 66 Yes Fires
0 No 500 No Does not Fire
125 Yes -90 Yes Fires

Okay, the last two are not likely ones you would come up with but the way we have this Edit Check formulated these are valid values. The SYSBP and DIABP Fields are defined in this study with a DataFormat of 3 which means maximum value 999 and minimum value -999. For the computer trying to solve this problem to work out which values will fire the Edit Check the constraints are:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
From Data Format:
    SYSBP must be >= -999
    SYSBP must be <= 999
    DIABP must be >= -999
    DIABP must be <= 999

From Edit Check:
    SYSBP must be >= 120
    SYSBP must be <= 129
    DIABP must be < 80

That gives us ranges for SYSBP of (120..129) and for DIABP of (-999..79) When values are within those ranges, the Edit Check will fire. The system can also work out what values will cause the Edit Check not to fire.

Solving the Constraint Problem

So if Edit Checks are just a type of Constraint Problem, how does TrialGrid solve them?

We said already that the definition of our example edit check in TrialGrid is:

1
2
3
SCREEN.VS.SYSBP[0] >= 120 
AND SCREEN.VS.SYSBP[0] <= 129
AND SCREEN.VS.DIABP[0] < 80

This format is generated automatically on import of Checks from Medidata Rave but users can also create Edit Checks using this format directly. In order to convert it to QuickEdit or back into the Architect Loader Spreadsheet format we have to parse this syntax. That turns the text into a tree-like structure in-memory:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
   - LogicalOperator("AND") 
       - LogicalOperator("AND") 
            - Expression
                - DataPoint(folder="SCREEN", form="VS", field="SYSBP" recordposition=0)
                - Comparator(">=")
                - Value("120")
            - Expression     
                - DataPoint(folder="SCREEN", form="VS", field="SYSBP" recordposition=0)
                - Comparator("=<")
                - Value("129")
        - Expression     
            - DataPoint(folder="SCREEN", form="VS", field="DIABP" recordposition=0)
            - Comparator("<")
            - Value("80")

And by examining this tree we can generate a constraint formula by looking at the DataFormats of Fields. For numeric Fields this is simple but for other types of Field this is not too hard. Checkbox fields can only have a value of 1 or 0. Computers already store dates/times as the number of seconds since January 1 1970 and fields with Data Dictionaries are already constrained to a limited set of values (e.g. "YES", "NO", "UNKNOWN")

For any Edit Check there are likely hundreds of value combinations that will fire the check and hundreds more that will not fire the check. For now TrialGrid is set to generate a single positive and a single negative test for each Edit Check using constraints that we feel are reasonable. For example, the range of future dates is infinite but the system won't generate dates out in the year 9800.

Finding invalid Edit Checks

Medidata Rave will allow you to write Edit Checks which are valid but which will never fire. A simple example:

1
SCREEN.VS.SYSBP[0].IsEmpty AND SCREEN.VS.SYSBP[0] > 100 

The SYSBP value can never be both Empty and > 100. Nobody sets out to write a check like this but in a complex Check it can happen. The constraint solver won't be able to find a solution to this problem and will fail with a warning.

Generated test case

The TrialGrid constraint solver can solve many Edit Checks and generate a positive (Check fires) and negative (Check does not fire) testcase for each in the Given..When..Then syntax.

Here is a testcase generated by TrialGrid for our example Edit Check:

Generated Test Case

TrialGrid has a batch-create option which allows you to select as many Edit Checks as you like and generate tests for them. This generally takes less than a minute for 1,000 Edit Checks.

Running tests can also be done in batch so you can take a study with no tests, generate tests and start looking at the results in about 5 minutes.

Summary

In this mini-series of blog posts we've tried to show the basics of our Automated User Acceptance Testing system. We've described what UAT is, how we format UAT tests so that they are meaningful to humans and can be executed by a computer and finally shown how the system can generate tests to get you started quickly.

That's the high level view, if you want to see this system in action please sign up for our Free Webinar on January 10 2019.

Registration at https://register.gotowebinar.com/register/2929700804630029324