Research Facility and Study Management Software

The Vendor is required to provide s for a research facility and study management software such as equivalent.
- General Specifications:
•    Must be web-based frontend and be accessible by authorized users from within and outside the agency network.
•    The application needs to use agency single sign-on for user authentication
•    The application may be hosted by the vendor, or by agency 
- Study Participant Management:
•    Must maintain a list of study participants
•    Participants may be enrolled in more than one research study
- Study Management:
•    Must maintain a list of research studies
•    Each research study is associated with a principal investigator (pi) (i.e., pi name, institution, college, department), an institutional review board (IRB) number, and funder information (i.e., funder name, grant number, start/end dates)
•    Must include robust mechanisms to support study participant management to include:
•    Master participant database
•    Ability to select participants from the master database and enroll participants in specific studies
•    Ability to track enrollment of participants across multiple studies (e.g., study name, enrollment date, participant start/stop date for each study, reporting on assessments/study procedures in which each person participated)
•    Ability to provide a list of all participants enrolled in a study must be able to develop study-specific research visit schedules with related assessments (ex: visit 1 to include blood draw and MRI; visit 2 to include EEG and 6-minute-walk test, etc.)
•    Ability to schedule both research resources (e.g., MRI, instrumented treadmill, MRI) and room reservations within the same scheduling system, and related to specific study visits.
- Room and Resource Management:
•    The application must maintain a list of all rooms and resources that can be scheduled.
•    Must support categorization of the resources (e.g., when there are multiple units of the same piece of equipment, they would all be assigned to the same category)
•    Certain resources may be tied to a specific room/space. In this case, booking that resource should also block all other resources tied to that room from being booked by other studies.
•    Certain resources may be tied to another resource, in which case booking one of them should also book the other.
•    Ability to schedule both research resources (e.g., MRI, instrumented treadmill, MRI) and room reservations within the same scheduling system, and related to specific study visits (see the bullet above) – more details in the room and resource management.
•    Must have the ability to see these combination scheduling of resources/room simultaneously on a calendar, and must be able to “block move” schedule resources/rooms on the calendar from one time or day to another without having to cancel the original reservations and rebuild them
- User Management:
•    The application must be able to maintain a list of all users
•    System administrators must be able to add users, assign permissions and revoke access
•    User permissions must exist on multiple levels (e.g., super users, front-end users, reporting user, able to restrict access to user specific studies, etc.)
•    Users must also be allowed to schedule outside the context of a study (e.g. for testing equipment rather than for a research visit).
•    The application must include communications capabilities to email all or part of the user database (based on their role, such as all PIS, research coordinators, study-specific affiliations, etc.) To facilitate communication when resources are unavailable for maintenance, for required federal reporting, etc.
- Appointment Management:
•    Users may schedule appointments for studies for which they have appropriate permissions
•    Must have the ability to configure the system to designate users that can directly book resources/rooms, and designate users that can book requested resources/rooms but which require center approval before confirming those appointments
•    Users may also schedule ad hoc appointments that are unrelated to a specific study
•    Must be able to schedule appointments without associating them with a room or resource. Appointments may be associated with one or more staff members.
•    For research visits, appointments will be associated with a participant, a study, and a time point
•    The application must have a user-friendly interface for adding appointments by frontend users and for viewing the availability of resources/rooms (or seeing that resources/rooms are not available)
•    Once an appointment is created, the application must send a calendar invite (e.g. In .ICS format) to the user that created the appointment and to all staff members associated with the appointment.
•    When an appointment is modified or canceled, the application must send updated calendar information to users.
- Data Queries and Report Generation:
•    The application must provide a way to query the database and generate reports – this includes building custom reports.
•    Data queries may be prepared by system administrators and then shared with users, or written directly by non-administrators.
•    If the bidder can implement this in a user-friendly way, queries may also be prepared through a graphical user interface.
•    Some example reports needed are:
o    Resource utilization by each research study within a given time period
o    Utilization of each resource category by each research study within a given time period
o    Number of unique research participants that visited our center within a given time period
o    Number of visits run by our center within a given time period – in total and by category (e.g. Assessment or intervention visits)
o    Number of hours each resource was used during a given time period.