Onyx to CiviCRM

There are three options available to get BRICCS data from Onyx into CiviCRM:

1. Load from an Onyx extract.
2. Load directly from the Onyx database.
3. Load from the data already loaded into i2b2.

The 2nd option is the most desirable, if possible.

BRICCS Study Enrollment (Case) Type in CiviCRM

I have created a new briccs Drupal module to contain code specific for the BRICCS study. The module creates the BRICCS case type and all custom values specific for the study when it is enabled, and deletes them when it is disabled. The module WILL also contain the cron hook that loads the participants and their data from the Onyx database.

Data Requirements

The following data will be copied from the Onyx database to CiviCRM (the question name within Onyx is shown in brackets):

• Date and Time of Interview {?}
• Partiticant Number (Admin.Participant.barcode)
• Interview Status (Admin.Interview.status) Values of
  • IN_PROGRESS
  • CLOSED
  • CANCELLED
  • COMPLETED
• Title (Admin.Participant.pat_title)
• First Name (Admin.Participant.firstName)
• Surname (Admin.Participant.lastName)
• Address
  • Admin.Participant.pat_address1
  • Admin.Participant.pat_address2
  • Admin.Participant.pat_address3
  • Admin.Participant.pat_address4
  • Admin.Participant.pat_postcode
• Date of Birth (Admin.Participant.birthDate)
• Gender (Admin.Participant.gender)
• Participant NHS Number {Admin.Participant.pat_nhsnumber}
• Participant UHL System Number {Admin.Participant.enrollmentId}
• Consent Values
  • Understands the request for consent (consent_q1)
  • Consents to donate blood and urine (consent_q2)
  • Consents to entry in the BRICCS database (consent_q3)
  • Consents to possible further contact from BRU (consent_q4)
  • Understands the rules for withdrawal (consent_q5)

Additional Requirements

• All interviews will be extracted, regardless of their status.
• Since interviews can be updated if they have not been completed, the procedure will have to cope with updates as well as inserts.
• Since the cron jobs are run in a user's request, make sure that only a few participants are processed for each request.