Volunteer Credentialing System (VCS)



The Volunteer Credentialing System (VCS) is part of the Sahana Volunteer Management module. Developed in collaboration with Prof.Frank Fiedrich of the Institute for Crisis, Disaster and Risk Management (ICDRM) at George Washington University, the VCS will enable volunteer organizations a means to easily verify and document a volunteer's professional credentials.

This document serves as the resource for information pertaining to building a basic credentialing capability into sahana volunteer module.


Many occupations are guided by certain professional and technical standards. The process of meeting these standards and earning official recognition (in the form of credentials– licenses or certificates) is called credentialing. This project is focused on developing a system to track and verify the professional skills of volunteers in a volunteer registry. The credentialing system will be built into the Sahana Volunteer Management Module.


The system should provide credential reporting and approval functionality. A volunteer should be able to present his/her credentials (degrees, diplomas, certificates, experience, etc.) by submitting a credential verification request. A credential manager or administrator should be able to review credential verification requests, verify the information presented by the volunteer, and approve or deny the request based on the results of the verification processes.


Software Requirements for the Sahana Volunteer Management Module Credentialing System (K. Gochev et al.)

Developer Open Discussion

Comments from Prof.Frank Fiedrich extracted from email following initial discussions July 07

If you want to add a credentialing section volunteers must have the possibility to add professional information (e.g. current employment, licenses, certificates, etc.). You have to define something generic if you do not want to limit yourself to medical volunteers. You can take a look at our system or ESAR-VHP for credentialing principles. ESAR-VHP is probably simpler and sufficient for your purposes. See http://www.hrsa.gov/esarvhp/guidelines/guide_4-0.htm for some examples. They define 4 different levels of credentialing for each position and they define what information must be verified for each level. You can implement something generic like that. The hardest part for the users of Sahana is that they have to define these sets themselves. In the position descriptions for the volunteers (in the projects) they also have to define the minimum credentialing requirement for a specific job.

More on credentialing This is really a complex field and doing it well requires the use of a well defined process. I assume that Sahana should just include the most important features. You have to define which ways of credentialing are accepted: Presenting an original document, presenting a photocopy, calling the employer, contacting the issuer of a certificate, etc. We define 1st degree, 2nd degree and alternate credentialing. 1st degree is contacting the issuer, employer, etc. directly, 2nd degree is contacting a trusted organization which checks the credentials (this might not be applicable outside the United States) and alternate credentialing can be defined flexible by the user. Credentialing information can not be edited by volunteers and credentialing must be done prior assignments. Usually only credentialed volunteers should be available for the search for volunteers. We have a special user role which handles the credentialing.

Requirements Ideas

The following are just some preliminary ideas about what implementing this would require:

  • Have a separate user type (other than volunteer, site manager, or mainops) called Credential Manager (or something like that) to verify credential information
  • Other users who have access to this personally sensitive information should also be able to verify the credentials (MainOps)
  • Volunteers can make Credential Applications in which they input credential information, but cannot assume those responsibilities (ie, will not show up in a volunteer search) unless their application has been approved. So, a Credential Application will have one of three states Approved, Denied, or Processing (the last case is before it has been reviewed).
  • Credential Applications should never be deleted.
  • Also, a Credential Application should be able to be approved after it has been denied or vice versa.

Design Ideas

The following are just some preliminary ideas about how we might go about implementing this:

  • We're starting to have more and more user types in the VM. Should we start organizing them? For example, have a vm_role table with an id and role_name with roles volunteer, site manager, and credential manager. Then we could have a vm_user_role table with just two columns fk_user and fk_role, which are foreign keys to a user and his role. This would make it easier to keep track of ACL as well as add more user types as the module grows.
  • We need to allow for the possibility for a volunteer to have more than one credential. So, it may be best to have the volunteer input the credential information after volunteer registration:
    • We can display all Credential Applications on the Volunteer Information page.
    • On the Edit Info page for a volunteer, we could allow a user to edit his credential information with the warning that doing so will put his credential into the Processing state.
    • Also on the Edit Info page, we could allow the addition of a single credential application. Multiple credential applications can be added by repeatedly adding single credential applications.
  • We also need to store credential information, possibly in a vm_credential database table. Besides a volunteer's p_uuid and the status (approved, denied, processing), what else should go into this table? It seems like the credentials from the HRSA example all share some type of:
    • degree/diploma
    • certification/license
    • some measure of experience in the field
    • We may also want to include a column for the specialties of that volunteer's credential. For example, a physician may be a pediatrician.
    • Besides storing credential information, we should probably try to generalize credentials by making each fit into a particular category (maybe from the skills list).
    • We may want to give a ranking to credentials as well, so that we can operate on classes of roles rather than searching/defining access/what have you on a role-by-role basis
    • We also need the date and time (DATETIME) that the credential application was last put into the Processing state. The Credential applications will thus form sort of a virtual queue, whereby they need to be processed by processing the earlier ones first. The queue is simply built by selecting on the vm_credential table where the status is processing and ordering by date ascending.
    • Since Volunteer and Credential Application is a Many-to-1 relationship, we can get away with using just this table to store the info with a foreign key to the volunteer's p_uuid
  • In terms of the interface for a Credential Manager, we may want to consider the following:
    • As mentioned above, the applications should be handled as a queue
    • Providing a list of credential applications (with possible paging mechanisms) is probably the best approach, that way the credential manager sees the queue in the order that it's meant to be processed, but also has the option of going out of order
    • The list could be simply links with basic information (maybe just volunteer's name and degree) that point to the details of the credential application
    • Once a credential manager follows one of those links, he will be presented with the full information of the credential and with a button that says Approve or Deny
  • Once an application has been approved or denied, it will then disappear from our virtual queue of unprocessed applications, so we may also want to consider viewing already processed applications and changing their status.
    • So, perhaps two menu items would be necessary for a credential manager: Process Credential Applications and Search for Credential Application.
    • The first will bring the user to a page as described above, the second will bring the user to a page where searching for a credential application can be done by volunteer, by application status, and by the other information given in an credential application.
    • These two menu items should probably be in their own submenu category, which could be something like Credentialing.