Support SLA

The provision of support services is dependent on the creation and agreement of a support Service Level Agreement (SLA) with our customers. The SLA may be part of or independent from a contract, or statement of work.

This article covers common aspects of our support services and agreements.

Service Desk Portal

We offer a Jira Service Desk portal as a way for customers to submit and track any application issues.

Jira Service Desk access is granted to site subject matter experts who are part of each site’s core ClinSpark team, and who deliver first line support to end users. This group of SMEs may change over time, so it’s important that customers ensure there is adequate coverage in the necessary functional groups and across geographies.

Registered service desk users can request a list of currently registered portal users for their organization as needed. This may be helpful from time to time in order to confirm an accurate listing of team members who can collaborate on tickets.

Communication

The application support team is geographically diverse and subject matter experts in various topic areas related to ClinSpark. Communication on tickets may come from different members of the support team depending on the topic and time zone.

Customers who are in contact with a project manager / account manager may seek clarification on support topics through those resources. The PM/AM will ensure proper parties are notified on the support team for any particular topics that require attention or follow up.

Ticket responses are provided during contractually agreed upon hours. All ticket correspondence is available to all service desk agents.

Service desk agents may also determine if video/voice calls if necessary to walk through any challenging and urgent issues. This need is determined on a case-by-case basis.

Proactive Issue Resolution

Self Help

We expect sites to work with their ClinSpark subject matter experts to deliver first line support to end users. Customers are encouraged to try and solve issues that arise on their own first, seeking the answers in the available Help site documentation. If issues cannot be resolved through self-help methods, then the service desk portal is the best way to reach someone for a response.

Application Log Statements

ClinSpark was designed with a dynamic error log ‘appender’ to raise potential issues to support team members in near real-time. Logging features are designed to notify our support team when messages surface, and in addition, display the logging details in a specific support module available in ClinSpark to our personnel. Each environment server also maintains log files, which can be accessed by engineering and reviewed as needed for issue resolution.

When our team members notice a log statement that indicates a potential issue, a service desk agent may reach out to site SMEs to acknowledge that something was noticed and attempt to gather more information. When this happens, a ticket may also be raised on behalf of the customer and assigned for follow up.

Our goal with these efforts is to be proactive and resolving issues as they emerge, before customers notify our team. We want to try and address certain issues as they arise immediately, and when necessary, help customers in creating and following up on service desk tickets proactively as part of our overall support efforts.

Ticket Management

Ticket Triage

Service desk agents will perform ticket triage to review information received and assign tasks for follow up. To offer the best possible support experience, we ask customers to consider providing several important details when creating tickets. This commonly includes requests for detailed screenshots or screen recordings of issues.

As part of triage we often verify the following:

• Full context of the issue, summarizing any steps that may have been taken or need to be taken to reproduce

• Environment details, including the URL of the environment the issue is related to

• Study, epoch, cohort, study event, and subject details wherever applicable

• Component/module of ClinSpark the issue relates to; referenced via left menu item (such as Samples > Processing)

• A specific date/time the issue started happening or reoccurring

• The usernames of any ClinSpark users experiencing or impacted by the issue

• Device details such as the type of device being used (laptop, phone, etc.) and browser type/version

• Attachments that are related to the request, such as example reports or related documents that are directly applicable to the request

We may also update the ticket summary, ticket type, ticket description, etc. to ensure that all necessary information is captured accurately on the ticket.

Providing timely feedback

Most tickets will require feedback or follow-up action by the customer. This interaction is required for timely investigation, scoping, and resolution. It is the customer’s responsibility to routinely check the service portal and provide timely responses to analysts' follow-up questions or comment.

Failure to provide a timely response may significantly delay the investigation and resolution of tickets. As needed, service desk agents may attempt to reach out to customers to gather information or confirm the status of an open ticket. After repeated failed documented attempts to contact a customer to regarding follow-up actions, an agent may close the issue due to inactivity.

Customers should not follow up with additional comments on tickets that are closed. Closed tickets leave actively monitored queues and follow up may not be available to all team members. If a ticket which was closed due to inactivity needs to be re-opened, the customer can request this by submitting a “Ask us a question” ticket and referencing the original ticket.

Ticket Follow Up & Closure

Standard procedure for ticket closure is for the customer, or service desk agent, to acknowledge that no further actions are needed and the ticket can be closed.

As needed, service desk agents may attempt to reach out to customers to verify the resolution status of an open ticket. After repeated failed documented attempts to contact a customer to close an issue, an agent may close the issue.

Customers should not follow up with additional comments on tickets that are closed. Closed tickets leave actively monitored queues and follow up may not be available to all team members. Instead, for the highest visibility and potential to receive prompt follow up support, customers should raise a new ticket as needed for follow up. When doing so, referencing any previously closed ticket IDs will help establish links and context for reply.

Incident Tickets

Tickets that are classified as Incidents are established with a priority level to apply SLA goals applicable to response times. Incidents are often classified as significant application malfunctions or overall loss of availability. SLA goals are established via customer specific contract or statement of work. For most standard agreements, our target response times depend on severity of the issue.

Upon receipt and triage, a service desk agent may alter the ticket type and priority as appropriate upon investigation.

Non-Incident Tickets

Customers can also raise non-incident tickets to gain general support as needed. These may be ticket types covering a variety of topics such as feedback from testing, requests for VAL environments to support upgrades, system configuration changes (reports, dashboard components, etc.), or just general questions about the product.

Issues Not Eligible for Support

Requests to “Fix” data or report outputs after an error in study conduct

Sites may occasionally experience operational errors in study conduct. For example; data collection might be made against the wrong study event, or, subjects might be activated against an incorrect cohort. IQVIA may reject these requests to alter data or reporting outputs to “correct” such errors. Instead, these sorts of errors will need to be addressed by the customer’s Data Management team.

The reason for this is that we consider the integrity of the study data to be of the highest importance and a founding principle of eSource systems. We want both customers and Sponsors to trust that data is preserved as collected and with all audits accurately reflecting the original data lifecycle. For similar reasons, reporting from ClinSpark must reflect the actual state of this data in order for these outputs to be transparent and trustworthy.