Acknowledgements and Certifications Service

Owned by mhodges
Last updated: Jun 18, 2012Version comment
3 min read

Early Draft of the Specifications for community review

Presented to UH developers on 9/16/2011

  1. Version 1.0 Specifications:
    1. Desirable Objects
      1. Acknowledgements - as in I hereby acknowledge that I have read and understand E2.214.
      2. Certifications - as in successfully demonstrating via test questions that I have read and understand E2.213 (not a Phase I deliverable).
    2. Audiences (types of users)
      • Users have UH Credentials and can assert acknowledgements and pass certifications; no role-based access controls are required at this time.
      • Policy Representatives can create and manage their own certifications.
        • Acks and certs must be owned by either someone(s), group/dept accounts are eligible.
        • Multiple apps can reference a single acknowledgement or certification, and a single app can reference multiple acknowledgements or certifications.
        • Clarify the purpose of acknowledgements and certifications for continued access to apps; to convey responsibilities.  Not an authorization or provisioning tool.
        • Explain certifications as demonstrated knowledge.
      • Admins can provision and de-provision owners.
    3. GUI
      • Web-enabled self-service tool for end-users to be merged with the new /username redesign.
      • Requires UH credentials to use
      • Users can view all certifications and acknowledge any of them.
      • User is informed of which certifications have been acknowledged and when.
      • User can easily distinguish which certifications should be acknowledged in the near future so as not to have to come back very soon.
      • Email notifications for pending expirations
        • allow policy owner to select notification schedule; develop selection parameters; for now we only need two patterns, short and long, one month and one week with weekly reminders
      • Policy Reps can create, update, enable/disable, delete, reassign or extend ownership requires a request being sent to an admin; 
        • deleting and disabling has potential ramifications.
        • API to pass if the application reference an acknowledgement or certification that is missing or disabled
      • Admins can provision/deprov and enable/disable Policy Reps; 
        • must a person be fac/staff to be authorized?  no, admins determine this
        • are grouper groups appropriate for tracking Policy Reps?  tbd
        • UHIMS Life Cycle should also trigger deprovisioning
    4. Data Storage
      • Set this up as a separate service with its own database.
      • Data tracks each user's acknowledgements and certifications and the date last updated successfully.
      • Expiration dates are NOT by definition in scope. It is up to the consumer of the info to apply business rules.
      • Life Cycle: Data is removed when the user no longer has an active affiliation with UH.  Returning to UH imposes a fresh start.
    5. Data Retrieval during authentication to determine authorization
      • LDAP
      • CAS - upgrading to CAS 3.x may be a prerequisite (not a Phase I deliverable)
      • Shibboleth via attribute release policy
    6. Development Phases
      • Phase I: Acknowledgements, single check box
      • Phase II: Certifications, pass/fail testing process
        • Requirements for building questions and answers and answer keys need to be defined.
      • Phase III: not planned, only to be considered if sufficient demand for expansion of functionality
    7. Parkinglot
      1. tracking who took which online quizzes, etc and reporting back to a dept, unit, etc.
      2. support for UH related organizations; for more general use
      3. POs may want to track who amongst their staff have done the confidentiality agreement
      4. Departments may want to impose their own acknowledgements on their own staff or on their own guests.
  2. Version 2.0 Specifications:
    ACER 1.0 lacks a reporting mechanism, but 1.0 by design provides the barest functionality possible to get started as a useful service that we can then share with others to see what should be in ACER 2.0.
    1. Compliance requirements established by EAC.
      1. Require specific groups to perform specific Acknowledgements and Certifications.
    2. Compliance reporting organized by EAC.
      1. Provide PO's reports on who has and hasn't done their Acknowledgement or Certification.
      2. Provide PO's with the history of previous acceptance of Acknowledgements and Certifications.
        1. It is believed that a history helps establish that the University has consistently required acceptance and this is blameless.
    3. Automated annual and biennual renewal email reminders for initial and renewal of compliance.
      1. New attribute required to indicate that a Acknowledgement or Certification must be renewed.
      2. New attribute required to indicate the renewal frequency.
      3. New subsystem required to handle automation of the generation of the email reminders.
    4. Candidate for pilot: OHR Substance Abuse Notification