|Value||Description||Use Case (Why is this useful/needed? How would it be used?)||Desired action by SP?||Entitlement or Affiliation?|
Institutional Signing Official
The label, "Signing Official," is used in conjunction with the NIH eRA Commons and refers to the individual that has institutional authority to legally bind the institution in grants administration matters. The individual fulfilling this role may have any number of titles in the institution, but is typically located in its Office of Sponsored Research or equivalent. The Signing Official for the Requester reviews Data Access Request, Project Renewal, and Project Close-out applications submitted by Principal Investigators and legally binds the Requester to agree to adhere to the terms described in this Agreement if the application is submitted to NIH. The Institutional Signing Official for the Submitting Institution enters into the Institutional Certification and signs on behalf of the Submitting Investigator(s) who has submitted data.
NIH needs to figure out who they can define as a researcher for the data. Initially senior level person in employment at a university or company
could be Affiliation
The investigator who prepares Data Access Requests (DARs), Project Renewals, and Project close-outs. The Principal Investigator plays a lead role in ensuring that management and use of controlled-access data remains consistent with the terms in the Data Use Certification Agreement. To be able to submit a DAR, a Principal Investigator must be designated as such by their institution in eRA Commons and be a permanent employee of their institution at a level equivalent to a tenure-track professor or senior scientist with responsibilities that most likely include laboratory administration and oversight.
|attribute to be released to identify a PI (a term known by NIH) for them to undertake required actions at the SP||if the SP has a service covering multiple projects/grants etc then the attribute cannot state which project/grant||Entitlement|
A user approved by the relevant Data Access Committee(s) to access one or more datasets for a specified period of time and only for the purposes outlined in the Principal Investigator (PI)’s approved Research Use Statement. The Information Technology (IT) Director indicated on the Data Access Request, as well as any staff members and trainees under the direct supervision of the PI are also Approved Users and must abide by the terms laid out in the Data Use Certification Agreement.
|Consultant||non-employee needing access to multiple institutional information resources;|
typically needs to "log in" via institutional central authn / SSO
|external auditor; |
vendor configuring a deployment of their software;
|Pre-registrant||prospective students (completed some but not all steps to be considered a student with no explicit block to completing those steps to become a student); eligible for some but not all information resources available to students||provide access to course pre-registration, email forwarding, but not licensed software or email account for example (no specific roster of permitted or denied services implied by the ePA value itself; each SP must consume and determine authorization based on institutional policy or service contract)|
|Researcher||Research and education workers at laboratories and institutes; e.g. professors, researchers, lecturers, assistants, whether or not they actually have a contract of employment with the organisation.||Affiliation|
|Pre-Higher Ed||Value indicating the individual is a member of the institution, but below the undergraduate education level.||Some institutions (such as The University of Chicago) are N (newborn)-PhD. Yes, you can literally be born at The University of Chicago (we have a hospital) and the next day be registered for infant care, and stay with us through your PhD and beyond to the grave (yes, we have a crypt too if you're that important). This presents a challenge in the general case whereby services offered to K-12 are different than those offered to what most places would provide to the traditional "student" population. This includes issues, admittedly local to the US, regarding COPPA as well as general service bundles offered to students via the Federation (remember MSFT Dreamspark?). The intended case here is to enable signaling to SPs a more granular approach to "student" so they can apply appropriate controls (in cases like COPPA) or an appropriate age-level experience.||Tailor experience and/or provide guidance to SP-side ACIs.||Affiliation|
|student-employee||Person with primary role of student, but also holding a job that is dependent on their being a student (might, for example, be a component of student aid or receive tax exemption)||While student-employees may have a position title, job-related office and phone, these may be considered part of their student record for purposes of disclosure; if not explicitly designated "directory information" per U.S. FERPA, that data cannot be published in employee directories or phonebooks.||restrict or withhold such data as job title, office location, phone; do not list for unauthenticated access in employee directories|