Overview

Here is the graphical representation of this subsystem which handles particulars about the deployment of a given Assessment as well as its use by the target subjects.

Specific Entities

• Assessment-Policies (as_assessment_policies) abstract out from Assessments a variety of attributes that describe deployment particulars. This allows multiple users of an Assessment to define beginning and ending dates, eg:
  • policy_id
  • policy_name
  • start_date
  • end_date
  • anonymous_p - whether anonymous subjects are allowed
  • repetition_interval_granularity - minutes, hours, days
  • repetition_interval - an integer that (along with the granularity) defines the minimum interval between sequential assessments by a subject; an interval of zero means that only a single time through is allowed
  • editable_p - whether user can alter submitted responses
  • max_edits_allowed - optional max number of times subject can change responses
  • max_time_to_complete - optional max number of seconds to perform Assessment
  • interruptable_p - whether user can "save&resume" session
  • data_entry_mode - (presumes that the necessary UI output procs are implemented in the APIs) to produce different deployment formats: standard web page, handheld gizmo, kiosk "one question at a time", AVR over phone, etc etc
  • consent_required_p - whether subjects must give formal consent before doing Assessment
  • consent - optional text to which the subject needs to agree before doing the Assessment (this may be more appropriate to abstract to Assessment-Events)
  • logo - optional graphic that can appear on each page
  • electronic_signature_p - whether subject must check "attestation box" and provide password to "sign"
  • digital_signature_p - whether in addition to the electronic signature, the response must be hashed and encrypted
  • shareable_p - whether Policy is shareable; defaults to 't' since this is the whole intent of this "repository" approach, but authors' should have option to prevent reuse
  • feedback_text - where optionally some preset feedback can be specified by the author
  • double_entry_p - do two staff need to enter data before it's accepted?
  • require_annotations_with_rev_p - is an annotation required if a user modifies a submitted response?

• Assessment Events (as_assessment_events) define an planned, scheduled or intended "data collection event". It abstracts out from Assessment Policies details that define specific instances of an Assessment's deployment. Attributes include:
  • event_id
  • name
  • description
  • instructions
  • target_days_post_enroll - an interval after the "enrollment" date which could be the time a subject is enrolled in a trial or the beginning of a term
  • optimal_days_pre - along with the next attribute, defines a range of dates when the Assessment should be performed (if zero, then the date must be exact)
  • optimal_days_post
  • required_days_pre - as above, only the range within which the Assessment must be performed
  • required_days_post