= CiviCRM =

[[Technical deployment tasks for CiviCRM]]

[[Use case description for Genvasc]]

Currently this page is a record of our deployment of CiviCRM - initially as a recruitment process manager for the GENVASC project.

briccsapp04.xuhl-tr.nhs.uk - test system[[BR]]
briccsapp05.xuhl-tr.nhs.uk - live system[[BR]]

=== CiviCRM Object Model ===


=== Contact Types ===

We can create sub-types which allow for specific custom fields and relationships to be built. This is most important to differentiate between LCBRU staff and those who might be study subjects, who we will call 'contacts'.

* Individual - Contact
* Individual - LCBRU staff
* Individual - Health worker

* Organisation - GP Surgery


=== Contacts ===
Contact entries for LCBRU staff are created automatically from the relevant drupal account. And the drupal account is created automatically at first log-in using LDAP. Smooth.

Non-staff will have contact records created for them separately and manually.

* Address
  * State / Province - is replaced by 'county' during localization to UK
  * County - do not use (this is a different division than UK County

Custom fields likely to be necessary for participants
* GP surgery - relationship to an organisational record
* NHS number
* UHL S number


=== Groups ===
* LCBRU staff (ACL group, to allow for ACL role of 'LCBRU staff' to have edit permissions on contacts etc) - could this be a 'SMART GROUP' based on the drupal account being in the associated drupal role 'LCBRU staff'. Needs to interact with the designated contact type.

=== Tags ===
How are we going to use 'tags'? For the time being delete all tags.

=== Case type ===
Represents the study.

Needs custom fields to represent the study ID number? Since 4.2.0 custom fields can be attached to a specific case type. This works quite nicely but will need the use of 'hooks' to intercept the data and validate it is unique before entry into the database.

Disable the sample case types. Create a new case type for 'GENVASC'.

Each case type requires an xml configuration file in /civicrm/CRM/Case/xml/configuration/


=== Cases ===
Represents the recruitment of a participant against a specific study.[[BR]]
Might need a revised webform template (profile) as some fields are not really relevant.[[BR]]

* Encounter Medium (represents the recruitment method) - needs an additional option for GP surgery.
* Location - not relevant, can be dropped.
* Details - not relevant, can be dropped.
* Subject - not relevant, can be dropped.
* Case type - drop down selection of study names (currently only GENVASC)
* Case status - defined four so far: recruited (opened), declined (closed), withdrawn (closed), excluded (closed).
* Duration - not relevant, can be dropped.


=== Case roles ===
Currently the following defined for GENVASC: recruiter, venepuncturist, study administrator, study manager, lab processor, principal investigator.

* Case roles are a sub-set of available relationships, as follows:
  * Recruiter - B is 'Study Recruiter' of A. A is 'Recruited By' B.
  * Venepuncturist - B is 'Venepuncturist' of A. A is 'Blood Samples Taken By' B.
  * Study administrator - B is 'Study Administrator' of A. A is 'Study Subject' B.
  * Study manager - B is 'Study Manager' of A. A is 'In study managed by' B.
  * Lab processor - B is 'Laboratory Processor' of A. A is 'samples processed by' B.
  * Principal Investigator - B is 'Principal Investigator' of A. A is 'In study for P.I.' B.
    
Note: When the case is displayed, each role which is vacant is labelled with the 'B' relationship label, e.g. "Study Manager". This label stays in place even if the role is filled. However when the case is reloaded later, the label is changed to be the 'A' label, e.g. "In study managed by". This is OK but very confusing.