| 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.
Service Desk Portal
The Jira Service Desk portal offers customers a way to submit and track any ClinSpark issues with Foundry Health.
Service 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 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 support team is geographically diverse and subject matter experts in various areas of ClinSpark. Communication on tickets may come from several members of the support team depending on the timezone and topic.
| Note |
|---|
It is expected that all correspondence between ourselves 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, Basecamp ‘pings’, or 1:1 messages received through other communication tooling - are not supported communication channels, as these topics 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.
...
Service desk agents are also capable of opening up 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 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 teamus.
ClinSpark 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 designed to notify our support team when messages surface, and in addition, display the logging details in a 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 Triage
Service desk agents will perform ticket triage to review details and assign tasks for follow up. To offer the best possible support experience, we ask for several important details when creating tickets. This may include 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, iPhone, 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
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.
...
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.
...
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 |
Non-Incident Tickets
Customers can also raise non-incident tickets to gain general support as needed. These may be request types covering ClinSpark use in pre-production environments (feedback from UAT or testing), requests for new environments, 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 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. 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.