Data from any source can be stored into PEP by manually uploading it, e.g. using the pepcli utility. Users can automate the invocation of pepcli, e.g. to upload data that becomes available periodically or that can otherwise be processed algorithmically. Such automation and other integrations are provided out of the box by PEP for the Castor Electronic Data Capturing (EDC) system.

Overview

When the Castor EDC is used in a (scientific biomedical research) study to gather data on subjects, PEP can be configured to assist in several tasks. With proper configuration:

• PEP ensures that Castor records are created for participants when they are registered into PEP.
• The pepAssessor GUI application provides buttons to access participants' Castor records without needing to look them up manually.
• Data entered into Castor can be automatically and/or periodically imported into PEP.

The first two aspects ensure that assessors create and find proper Castor records for participants during data gathering. This minimizes manual work, and helps ensure that data entered into Castor ends up in the correct record, improving data quality. This can be achieved with minimal configuration by the PEP (support) team. The import facility requires more attention and will be discussed separately.

Import

PEP can import several types of data from the Castor system:

• Clinical Research Form (CRF) or "study" data entered by assessors.
• Report data entered by assessors.
• Surveys completed by participants.

The PEP (support) team can configure the type or types of data to import from Castor into PEP, as well as some parameters on how to import these data.

Data format

Castor data are stored in PEP as JSON, which is a data format that associates keys with values. Imported Castor JSON data always consist of a crf and a reports node at the top level.

• The crf node's value is an object containing the data entered into Castor.
  • Keys in this object correspond with Castor question IDs.
  • Values contain the (raw) answer entered into Castor.
• The reports node contains (a JSON array containing) any Castor reports associated with the imported data, e.g. due to a CRF containing repeated measurements.

For example, the following data might be stored in PEP:

{
  "crf": {
    "DiagParkYear": "1960",
    "PrefHand": "##USER_MISSING_97##",
    "FirstSympYear": "1950",
    "DiagParkMonth": "3",
    "WatchSide": "1",
    "PreferLeg": "3",
    "FirstSympMonth": "3",
    "MostAffSide": "2",
    "WalkingAid": {
      "0": "true",
      "1": "false",
      "2": "false",
      "3": "false",
      "4": "false",
      "5": "false",
      "6": "false"
    },
    "DiagParkNeurologist": "Piet Paulusma",
    "DiagParkDay": "3"
  },
  "reports": ""
}

In the sample data:

• the DiagParkYear node contains a value of 1960, indicating that the answer 1960 was entered for a question with this ID.
• the WalkingAid node (apparently) contains the answers to a checkbox-type question.
• the reports node contains no entries, indicating that no repeated measurements are associated with these Castor data. Perhaps the Castor configuration contained no questions of that type, or zero repeated measurements were taken.

Castor steps as a unit

PEP imports data for individual Castor (CRF) steps into separate PEP columns. Since access to PEP is controlled at the level of columns, the implication is that PEP can distribute Castor data with a granularity of CRF steps. PEP users can be granted access to (answers to) individual Castor steps, but not to smaller units (e.g. individual questions). This should be taken into account when configuring a Castor study meant for PEP integration. Questions should only be put together into a single step if their answers should always be distributed together.

An equivalent principle applies to the import of Castor survey data: answers to a single survey step end up in a single PEP column. Surveys should therefore also be configured in such a way that their data are chunked appropriately.