ICPSR first launched its Restricted Contract System (RCS) more than two years ago. Since that initial launch we've learned a lot: who actually uses the system to apply for access to data; how they experience the system; how ICPSR contract administrators use the system; and, how to build in workflow to make it a smoother experience for all parties.
We relaunched the RCS last week, but with a new name: the ICPSR Data Access Request System (DARS). I suspect a lot of us will continue to call it the RCS, but it is the same system, but with a very different look and flow.
The DARS home page is the same as the old RCS system, and the most typical access method for initial use is from the home page of a study. If a version of a study is available through a data-use agreement, then a link appears on its home page, and clicking that link navigates the visitor to the DARS.
Once there the visitor can initiate the data-use agreement process, going through the same general steps as before. However, it is now much clearer when the agreement process has been completed, and the ball is now in ICPSR's court for review. We've also worked hard to distinguish between essential elements of the agreement (e.g., if it changes, then the agreement must be reviewed and signed again), and which are more tangential (e.g., if it changes, ICPSR will be notified, but the agreement need not be signed off on again).
One element of the redesign is an explicit acknowledgement that this system may be used for any data-use request, and is not limited to only restricted-use requests. We based this change on feedback from an internal team of reviewers who thought that the system should be able to work for any type of content that requires an agreement, even if it isn't particularly sensitive or confidential.
This design also recognizes that the applicant using the system may not necessarily be the PI who is requesting access to the data. (In fact, we suspect that most applicants are not the PI.) We therefore built views and rules to make it easier for, say, a population center data coordinator who may be working on several request for several PIs to get a better view of status across all requests.