Evaluating online research compliance software can be sometimes be daunting – especially if you’re not a “technology person.” But, like any Software-as-a-System (SaaS) there are some basic steps that can help structure your evaluation process. You’ll want to ensure that you’re taking into account issues ranging from the underlying infrastructure of the SaaS solution to the overall rationale your institution has for implementing this solution. Where a small or mid-size college might emphasize minimizing the effort and costs associated with research compliance processes, a hospital may focus on the SaaS’s ability to promote collaboration across multiple sites. In either case, it is important to have a good understanding of your goals to narrow your possible vendors and ease the implementation of your SaaS integration.
Once your organization has a very good understanding of its goals, there are five main points that must be considered in evaluating SaaS technologies:
- Identify the scope that the SaaS solution needs to address
- Determine if the disaster recovery implementation is acceptable
- Ensure that the SaaS solution is sufficiently robust
- Evaluate the Service Level Agreement (SLA) first to avoid contractual issues
- Consider the level of IT support needed for the SaaS solution
Quite often an organization focuses on the benefits of an online solution without having a good idea of what is actually needed from it. For example, a largely customized online IRB software solution is optimal for an organization that performs a great deal of data analysis and will be accessed by only a few select users at any one time. However, this solution may be unsuitable for a smaller, more collaborative organization where a variety of users will be accessing the system anytime and where efficiency is prioritized.
Although uptimes for cloud sites are extremely high due to multiple levels of redundancy, the possibility exists for a catastrophic failure having far-reaching adverse consequences for the organization. When evaluating an SaaS technology, the disaster and recovery process along with the anticipated recovery time from a failure are important points to consider before selecting a solution.
When evaluating the robustness of an online research compliance solution, focusing on the overall requirements is of critical importance to make sure you get all the features you need – and not a lot of features that you don’t need. An enterprise-level SaaS solution must meet complex requirements of advanced integration and support for numerous users across a large number of projects. For most organizations, a research compliance system will have a smaller user base, more focused requirements and should have the ability to be rolled out quickly and with comparably minimal cost. For instance, if your IACUC is doing 20 protocols a year, the solution should be very easy to implement and not require a great deal of local tech support.
Detailed understanding of the SaaS provider capabilities is required as a SaaS solution provider that has limited capabilities often produces a solution that has great difficulty integrating with the department’s existing system or lacks the services and storage required for future organizational growth. Integration of some SaaS solutions are often done over the public Internet and, occasionally, across an unsecured port raising a number of security concerns although these security concerns are more prevalent in an enterprise-level SaaS.
The Service Level Agreement (SLA) is an important consideration in evaluating potential SaaS solutions. This agreement spells out what services a SaaS provider is obligated to perform and the consequences that the provider will face if these services are not delivered. A SaaS provider that balks at signing a SLA before a contractual agreement is in place should be viewed with a certain level of suspicion. This agreement ensures that an organization’s needs have primacy as opposed to needs of the software vendors or other provides.
Finally, consideration of the level of IT support needed for a SaaS solution is critical for an organization. In some cases, two SaaS solutions that are otherwise similar in function and scope may require different levels of staffing as one solution may permit an organization to continue operating at its current staffing level while the other will require one or more additional IT professionals. A SaaS solution that provides little in the way of support or documentation will place a significant burden on the technical capabilities of the organization’s workforce while a solution that has clear and understandable documentation mitigates the overall load on the workforce.
These five important criteria mentioned above allows an organization to make an informed decision on what SaaS solution best meets its needs.