CiviCRM GENVASC Use case description
GENVASC CiviCRM Use Case Meeting 27 July 2012
Nick, Chris, Gav (part), Rob, Olly, Jeff, Will
Tags: CiviCRM Legacy GENVASC Study
Objective
To support and monitor the Genvasc recruitment process with CiviCRM
Workflow
Genvasc ID labels will be produced prior to recruitment, using an approach similar to BRICCS Study, but written as a php library to facilitate later integration with CiviCRM. The output of this process should be a series of single barcode labels, each one guaranteed unique, with human readable and barcode representation of a unique identifier of the form: LCBRU-Gxxxxxxxx (where x represents a random integer). A database of used identifiers will be maintained to ensure no duplication.
Note: GENVASC ID and label generation now being written as a drupal module.
Participants will be recruited in primary care setting. The GP surgery will -complete- print a consent form populated with participant demographics within their practice IT system, and including -print out- copies for local records and one copy to be signed and then attached to the sample bag. If the participant has given consent for Genvasc specific study samples, these will be in the sample bag. If not, the bag will be empty. Vascular Health Check samples for processing will travel in a separate bag, even where the participant has given permission for the residue of these samples to be used for the Genvasc study. The GP surgery will submit via iLab details of the samples being submitted, either Genvasc study specific samples or VHC samples with permission for residual use.
At the UHL, the pathology department will produce from iLab a daily output file containing details of all patients for whom Genvasc specific study samples, or Genvasc residual use of VHC samples have been entered. This output file will be loaded into CiviCRM, checking for duplicates and ensuring that demographic data (including the recruiting centre ID) for all participants is stored in CiviCRM appropriately. Loading the file will create a scheduled task in CiviCRM for a specified point in time, provisionally 4 days, to validate the participant's consent into Genvasc. Any participant whose record is not updated in that way within the four day window would be highlighted as overdue and the situation can be checked with the lab and the recruiting centre.
If the participant submits Genvasc study-specific samples these will be available for collection essentially on a same-day basis from the pathology lab, as they require no processing in the pathology lab. If the participant submits residual use consent for VHC samples, the bag and consent form will wait in the pathology lab while the samples are processed, and ultimately placed in the waiting Genvasc bag, at which point Genvasc staff can collect them.
Either way, therefore, the samples, bag and consent form will be collected by a Genvasc user,and brought to the BRU. A Genvasc barcode ID label should now be attached to the consent form [-bag-].
At this point the participant record in CiviCRM can be accessed, and their Genvasc consents noted. CiviCRM should be used to record their entry into Genvasc, their sample route, and their Genvasc specific ID, scanned from the barcode placed on the consent form [-bag-].
Once the participant record has been updated in CiviCRM, the bag, consent form and samples are passed to the BRU lab.
In the lab, the lab staff create a participant record in CaTissue, scanning in the barcode ID label, and register the participant to the appropriate Genvasc collection protocol (CP). The samples can then be processed in accordance with the CP, with appropriate records being kept in CaTissue, either through the GUI (to begin with) or via a specific API client for Genvasc (later).
Note: As lab staff will also be working on other projects, they will only be able to processes 2-4 patients per day using the standard GUI.
Reporting
From within CiviCRM it should be possible to review participants with overdue Genvasc consent processing (to be followed up with the lab and the recruiting centre as an exception report), and also overall recruitment numbers, by recruiting centre.
Notes
There is no requirement to validate identity against the UHL PMI, as ILab entries will already be validated.
Subsequent versions of this workflow may involve the participant details being passed electronically from CiviCRM to CaTissue, as per the BRISSkit model. But that is not required in the first implementation.
