| Table of Contents |
|---|
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
The We offer a Jira Service Desk portal offers customers as a way for customers to submit and track any ClinSpark application issues with Foundry Health.
Jira Service desk Desk access is granted to site subject matter experts who are part of the 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 reach out to Foundry Health to receive request a list of currently registered portal users for their organization as needed. This may be helpful to do from time to time in order to confirm an accurate listing of team members who can collaborate on tickets.
Communication
The Foundry Health application support team is geographically diverse and subject matter experts in various topic areas of related to ClinSpark. Communication on tickets may come from several different members of the support team depending on the timezone topic and topictime zone.
| Note |
|---|
It is expected that all correspondence between IQVIA and customers |
...
will be reflected in service desk tickets wherever possible. Communication outside of the service desk - such as emails not originating from the service desk |
...
or |
...
messages received through other communication tooling - are not supported communication channels, as these |
...
messages are not visible to all team members. |
Customers who are in contact with a Foundry Health 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 business hours. All ticket correspondence is available to all service desk agents.A support phone number is listed on the landing page of the service desk portal, and is available for users to call and leave a message if desired. This messaging service is typically monitored from 07:00 GMT to 20:00 CST. However we still prefer all callers to raise a ticket to include essential details for follow up, in addition to leaving a voice message, as this increases the effectiveness of our support response.
Service desk agents are also capable of opening up 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
Foundry Health expects 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 out to the Foundry Health teamsomeone for a response.
...
Application Log Statements
ClinSpark was designed with a dynamic error log ‘appender’ to raise potential issues to Foundry Health support team members in near real-time. The ‘appender’ is 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 Foundry Health our personnel. Each environment server also maintains log files, which can be accessed by engineering and reviewed as needed for issue resolution.
When Foundry Health 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 the Foundry Health 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 details information received and assign tasks for follow up. To offer the best possible support experience, we ask for customers to consider providing several important details when creating tickets. This may include commonly includes requests for detailed screenshots or screen recordings of issues.
...
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, iPhonephone, 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 two 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.
Upon receipt and triage, a service desk agent may alter the ticket type and priority as appropriate upon investigation.
The SLA goals around target 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. However for For most standard agreements, our target response times depend on severity of the issue.
...
Severity Level
...
Description
...
Issue Type Default Priority
...
Target Response Time
...
Level 1
...
Critical incident causing the ClinSpark application to be completely down with a severe impact to customers. Loss of entire Service; or loss of critical application functionality by most users; or where data integrity is compromised.
...
Blocker
...
1hr
...
Level 2
...
High level incident causing the ClinSpark application to be degraded with a high impact to customers. The loss of non-critical application functionality; or loss of critical application functionality by a minority of users where the majority of users are still able to use the critical aspects of the Service; or low level of risk to data integrity is perceived.
...
Critical
...
6hr
...
Level 3
...
Medium level incident causing the ClinSpark application to malfunction with a moderate impact to customers. The loss of non-critical application functionality; or loss of critical application functionality by a minority of users where the majority of users are still able to use the critical aspects of the Service; or low level of risk to data integrity is perceived.
...
Major
...
8hr
...
Level 4
...
Low level incident causing the ClinSpark application to malfunction with a low impact to customers. Minor problems that influence use of the Service, with no major impact on critical business use.
...
Minor
...
24hr
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 request ticket types covering ClinSpark use in pre-production environments (a variety of topics such as feedback from UAT or testing), requests for new VAL environments to support upgrades, system configuration changes (reports, dashboard components, etc.), or just general questions about the product.
Standard SLA goals for non-incident tickets are a target response time of within 24hrs of receipt.
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. Foundry Health will not accept 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 Foundry Health considers 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.
...