EHR Service Level Agreement (SLA)

This Service Level Agreement Addendum (“SLA”) represents Prime DataQ Health, LLC’s (“DataQ”) promise to provide support and maintenance services for our 360 DaVinci clients (“Client”).  This does not include training, customization or technical assistance to address specific challenges that a Client may experience or answering questions related solely to the operating systems, hardware, or any other programs operating on a Client’s hardware. By utilizing DataQ’s support and technical services, Client agrees to be bound by the terms of this SLA.

1. Definitions

As used herein, the following terms have the following meanings:

“Impact” is the duration of minutes that Service is adversely impacted due to a Service Incident, and begins when a Service Incident is reported to DataQ by the Client and ends when the Service Incident is resolved.

“Issue(s)” means an unscheduled or unanticipated incident that adversely affects the delivery of the Services by DataQ.

“Planned Maintenance” means the time required to maintain, repair or upgrade infrastructure, application or related components of DataQ’s technology stack for optimal functioning.

“Resolution” means that DataQ has resolved an Issue to reasonable satisfaction.

“Response” means DataQ’s response to Client regarding an Issue, beginning as soon as receipt of notice of an Issue.

“Services” means support and maintenance services for clients using 360 DaVinci.

“Services Request” means any request made to DataQ by Client for the purpose of invoking DataQ assistance and engagement for any service and support-related activity.

2. Responsibilities

  1. Client
    1. acknowledges that, in connection with the testing of new software, software patches, pre-release environments, or reoccurrences of incidents raised from time to time, DataQ may require the technical assistance and cooperation of Client. The Client agrees to provide, at no charge to DataQ, such technical cooperation within a reasonable time to resolve the issue at hand.
    2. shall provide all the necessary information and assistance related needs for Service performance that allows DataQ to meet the service level standards as outlined in this SLA.
    3. shall promptly notify DataQ of any business or operating changes that may require a review, modification, or amendment of this SLA.
  2. DataQ
    1. will include support services to Client as part of the Services at no additional cost, except for the following which may give rise to extended services billing:
      1. Issues arising as a result of changes made to the equipment and/or software by Client.
      2. If, in the reasonable opinion of DataQ, any particular user’s requests exceed a normal and reasonable frequency, DataQ may advise Client that the user’s requests are excluded from the SLA metrics until the user has received adequate additional training. DataQ will provide reasonable documentation as requested by the Client to illustrate this.
      3. Abnormally repetitive requests.
      4. Scheduled training and coaching sessions.
      5. Suspension of the account for non-payment.
      6. Events outside of the control of DataQ, including without limitation force majeure, internet bandwidth or connectivity problems beyond the demarcation point on DataQ, denial of service attacks (DoS), phishing, ransomware, malware, and hacking.
      7. Issues resulting from content uploaded by the Client which adversely affect the DataQ platform/environment.
      8. Events resulting from the Client’s failure to make modifications to their content to ensure compatibility with upgrades being applied to the environment.
      9. interruptions, deficiencies, degradations, or delays not reported by Client to DataQ.
      10. where the Client reports an SLA failure, but DataQ does not find any SLA failure.
      11. when Service is dependent upon some other service with a third-party vendor.
      12. during planned maintenance, emergency maintenance, or global events beyond the control of DataQ.
      13. data recovery when:
        1. data has been corrupted prior to back up by Service;
        2. opening files that cannot be successfully backed up;
        3. data backed up as part of a failed backup job or transient data structures such as but not limited to Windows registry files, swap files or Unix device files;
        4. any data offloaded to external media at the request of Client and then taken offsite, such as but not limited to tape or external disk drive; and
        5. to any data impacted that is the result of issues caused by third-party vendors or sources. i.e. CMS, ADT, Lab, Pharmacy feed owners.
    2. DataQ has the right to change the SLA from time to time and will inform the Client of any material changes affecting the Services.

3. Maintenance, Support, and Commitments

  1. Planned Maintenance: Planned Maintenance that is expected to impact Service Delivery will be limited to maintenance windows. Response and Data Recovery Service Level Commitments will apply during Planned Maintenance.
  2. Emergency Maintenance: Major Incidents may require immediate maintenance. Any such maintenance will be considered “Emergency Maintenance”. Emergency Maintenance may occur outside Scheduled Maintenance windows. DataQ will make a reasonable effort to notify the Client if feasible under the circumstances prior to Emergency Maintenance.
  3. Support Coverage: Coverage parameters specific to the service(s) covered as follows:
    1. DataQ service desk is staffed from Monday through Friday, 8:00 A.M. to 5:00 P.M. CST for the management and support of all Services for calls and emails.
    2. Emails received outside of office hours will be collected; however, no action can be guaranteed until the next working day unless there is a major system outage. Issues can be escalated to the Account Manager for immediate action if required. Client support is located in offices in both the United States and Pakistan.
  4. Types of Service Level Commitment
    1. Availability Commitment: “Availability” refers to the total amount of time during a contract month that Service is available for use by the Client. “Downtime” is the total accrued minutes that Service is unavailable for the Client due to a complete Service outage. Downtime does not include Service performance degradation that might make Service unavailable to Client, such as, but not limited to, network congestion or CPU contention. DataQ monitoring systems measure downtime in real time.
    2. Performance Commitment: “Performance Incidents” refers to the amount of time Service is degraded due to a problem related to the Services. “Impact” is the duration of minutes that Service is adversely impacted due to a Service Incident. Impact begins when a Service Incident is reported to DataQ by the Client and ends when the Service Incident is resolved.
    3. Response Commitment: “Response Incidents” refers to the amount of time taken to respond to Service Incidents after a Service Request is received. Response Incidents are measured by the duration of time elapsing between when the Service Request is first received (e.g. the timestamp of the Client ticket request via the Service Portal) and the time when the ticket has been assigned to a DataQ service desk resource for handling.
    4. Data Recovery Commitment: “Data Recoverability Incidents” refer to the integrity of the data being stored or protected by Service. DataQ guarantees that data backed up by Service shall be recoverable without data corruption. A file shall be considered corrupt if the restored file does not match original file.
      The Data Recovery Commitment shall not apply:

      1. to data that has been corrupted prior to back up by Service;
      2. to open files that cannot be successfully backed up;
      3. to data backed up as part of a failed backup job or transient data structures such as but not limited to Windows registry files, swap files or Unix device files;
      4. to any data offloaded to external media at the request of Client and then taken offsite, such as but not limited to tape or external disk drive; and
      5. to any data impacted that is the result of issues caused by third-party vendors or sources. i.e. CMS, ADT, Lab, Pharmacy feed owners.

4. Service Level Commitment (“SLC”) Metrics

  1. Response Metrics -SLC – DataQ commits to providing the below FRT (First Reply Time) as per the below incident management framework.
    Priority Severity Level Initial Response Time Standard Support Time Monday – Friday (CST)
    Emergency Level 4 < 2 Hours 8 AM – 5 PM
    High Level 3 < 1 Business Day 8 AM – 5 PM
    Medium Level 2 < 2 Business Day 8 AM – 5 PM
    Low Level 1 < 2 Business Day 1  AM – 5 PM
  2. Availability Metrics -SLC: DataQ will use commercially reasonable efforts to make the DataQ Services available with a Monthly Uptime Percentage of at least 99% during any monthly billing cycle (the “Service Commitment”) except for excluded periods/events.
  3. Performance Metrics -SLC: DataQ will use commercially reasonable efforts to ensure that the latency related to the loading of applications does not exceed the below benchmarks during the availability commitment period below.
    1. Dashboard Response Time: 10 secs (initial load time)
    2. Page Response Time : < 10 secs with 90th percentile < 5 secs
  4. Data Recovery Metric – SLC: DataQ will use commercially reasonable efforts to recover data from our applications within six (6) business days at the maximum.

5. Process for Handling Issues/ Concerns

  1. Problem/Incident Resolution Process: DataQ has structured support in four levels for allocating resources, creating escalation pathways, and giving each Client’s service challenge the right level of attention.
    Severity Level Classification
    Severity Level 4

    Critical

    		 An Incident which:

    a)       Severely impacts use of the Software Product in a production environment.

    b)      Demonstrates total failure of the Software Product (impossible to install or access the Software Product or impossible to access one or more key functionalities).

    c)       Halts Licensee’s Software Product related business operations and no Workaround yet exists.
    Severity Level 3

    High

    		 An Incident:

    a)       where the Software Product is functioning but its use in a production environment is substantially reduced.

    b)      Where the situation is causing a high impact to portions of Licensee’s Software Product related business operations and no Workaround yet exists.
    Severity Level 2

    Medium

    		 An Incident:

    a)       where at least one Software Product’s functionality does not operate or is not robust but where a Workaround exists, and the majority of Software Product functions are still useable.

    b)      Minor function/feature failure that Licensee can easily circumvent or avoid.

    c)       Licensee’s work has minor loss of operational functionality in Licensee’s Software Product related business operations.
    Severity Level 1

    Low

    		 A minor Incident having no impact on

    a)       Software Product usage.

    b)      Licensee’s Software Product related business operations.

    c)       The performance or functionality of Licensee’s system.
  2. Incident Handling Process: Incident handling process and its stages are outlined below.
    1. Incident Identification: Analyze the ticket/email/call if the issue is an incident or service request. Respond to and acknowledge receipt of the issue.
    2. Incident Logging: Once identified as an Incident, the service desk creates the Incident as a ticket. The ticket should include information such as the requester name, contact information, Incident description and the date and time of the Incident receipt for SLA adherence. Ticket creation also includes categorization, prioritization, and the necessary steps that the service desk completes as per Standard Operating Procedure (“SOP”).
    3. Incident Categorization: The service desk team may change the incident category according to the need. Determining incident priority is important for SLA response adherence. The incident priority determines the impact on users and on the business by determining its urgency. Once identified, categorized, prioritized, and logged, the service desk resolves the incident.
    4. Escalation: Functional Escalation refers to the process of assigning an Incident from one team to another based on the skills required to resolve the Incident. Hierarchical Escalation refers to a process where action is taken to avert the situation where resolution of an Incident may be unsatisfactory or late. Management Escalation: refers to a process whereby Management is involved to bring to their attention incident that requires their attention.
    5. Incident Statuses: Incident statuses mirror the steps taken in Incident resolution. They include: New, Under Analysis/In progress, Scheduled/Scheduled with Data Update, Need more information, Waiting for DataQ Response, In User Acceptance Testing (“UAT”), Resolved, and Closed. The new status indicates that the service desk has received the Incident but has not assigned it to an agent.
    6. Incident Closure: Once the issue is marked resolved by the client, Incident is marked as closed.
  3. Automatic Closure of Tickets: Support tickets will close automatically if they have waited for a user’s input for 14 calendar days. Tickets will not automatically close if they are waiting to be addressed by a DataQ Support agent. After addressing the problems that the DataQ Support team can assist in resolving, an agent may close a ticket. If the ticket is closed with an incomplete resolution, the Client can re-open the ticket from the support portal or by sending an email to the support desk.
Scroll to Top