Signals Clinical: Which columns of a Study's domain should be designated as Key columns and as Monitoring columns for LLR?

Summary:

In an SCL study each of its domains can be configured and then enabled with Line Listing Review (LLR) functionality. It is critical to configure LLR correctly before end users review any study data, because changes to any Key Column or Monitoring Column designations result in SCL automatically resetting the status to 'New' for all rows of that domain, and history of past review events become no longer accessible, no longer viewable on-screen. Previously recorded review events are no longer visible since the rows are now identified differently.

Details:

To configure and enable LLR for domains in a study, the 'Study Information' box must indicate that the study is in a 'Draft' state and the lower right corner of the screen must have an 'Unload' button and a 'Publish' button. To configure and enable these columns, click on the Setup button in the Line Listing box; then you should see a list of your source data's columns that have been mapped to SCL measurement attributes, where each row can be designated as Key or Monitoring or neither.

The following Help content provides direction as far as steps but is light on insight: "Appendix B - Frequently Asked Questions" and "Setting Up Line Listing Review".

The ideal selection of Key columns and Monitoring columns requires understanding your study data's uniqueness qualities and its monitoring requirements. This article is not able to take into account the understanding that you have, so consider engaging with Revvity Services on a billable basis, if you feel this is necessary.

When a study is published with a new version of data, it tries to find a match to the previously published data, based on the set of key columns. 

• Key Columns:  For each row, when SCL cannot find a match then it creates a new row in your domain's listing. When all new data has been published, SCL removes any previously existing rows for which the new set of data has no match. 
• Monitoring columns: For each row during a Publish event, when SCL sees that the new value in any monitoring column differs from the most-previously-published value, SCL sets the review state to 'Amended'. 
• Other (non-selected) columns: For each row, when SCL sees that the new value in any other column differs from the most-previously-published value, SCL does not change the review state. Rows that were previously reviewed will remain as 'Reviewed'.

If your column selections result in unintended behavior from that noted above, then correcting your selections will cause SCL to identify your data as new rows such that your users' previous review entries will no longer be viewable.

Resolution:

Rave data contains a RecordId column and sometimes a DataPointId column; Veeva data may contain other Id columns. These columns contain unique integer values, and they are designed in the EDC to uniquely identify records, and technically they would be adequate key columns for your study domain. The downside with choosing columns with integer type Id values is that the values are not explanatory. A better choice (which requires a deeper understanding of your data) is to identify a set of values that uniquely define each row AND the values are also meaningful to the study.

A combination of Key Column values should identify one subject's visit and the data collected for a specific subject during that visit.  An example would be:  Subject ABC came in for their Cycle1 visit, and Labs X, Y and Z were recorded.  The Key Columns would be SubjectId+Visit+LabAnalyte.  If your study's Labs get recorded multiple times, you would need a column for a repeat value, so your Key Columns might need to be SubjectId+Visit+LabAnalyte+ItemRepeatKey.

Regarding your set of Monitoring columns, ask yourself questions such as: If a Medical Reviewer (MR) has reviewed a row of study data, then which modified values in a later reload of data should trigger the MR to repeat the review of that row?

In the Line Listing configuration when you hit Save and then get a message like “A unique key cannot be created”, SCL is telling you that your currently selected set of key columns does not uniquely identify all rows of your loaded data, so you need to select a set of columns that do.