Question
What are Service Tiers? What are the requirements which must be met at each Service Tier level?
| Note: For assistance in determining the service tier for an existing application or service, please see Service Tiers - Find the Service Tier for Applications and Services. |
Answer
Service Tiers allows IT Service Providers to set expectations with customers to enable mission-appropriate, efficient, and cost-effective technology solutions. Service tiers provide a basis for setting customer expectations regarding availability, recoverability and level of support, as well as establish the customer contributions required to achieve the desired outcomes.
All Trusted IT Service Providers are expected to align their services into the Service Tiers expectations set in standard ST-05-004 HITS Service Tiers. Service Tiers can be viewed from a business or technology perspective as defined below:
Business Service Tier: A level of service defined by business requirements which are driven by loss of service and its business impact. This tier of service illustrates the financial and operational impact of a service degradation or failure which is influenced by the duration of the event and loss of data. The business service tier also defines the customer’s involvement in the service support structure, level of funding, and participation in recovery.
Architectural Service Tier: A technology and service provider focused view of a service that takes into account all technical, support, and recovery aspects. This view identifies all components, products, and associated service dependencies that collectively support the operation of a business service. The service tier classifications of these dependencies will impact the overall architecture tier rating.
Service Tier Levels
Each service tier has associated expectations related to the support, availability, response, and performance of the service. Those expectations are defined in the tables below. For specific details about how HITS architects hosting services to align to this standard, see the attached HITS Hosting Architectural Service Tier Design Standards document.
|
Notice for systems containing ePHI Effective July 1, 2021, any new system storing or transmitting ePHI must be rated as a Silver Architectural Service Tier or higher. HIPAA regulations require the ability to recover data, and the Bronze service tier currently does not require data recovery. |
| HITS Service Tiers | Platinum | Gold | Silver | Bronze | |
|
Service Availability
|
Hours of Operation | 7x24x365 | 7x24x365 |
6am - 7pm, |
7am - 5:30pm Monday - Friday |
| Hours of Support | 7x24x365 | 7x24x365 | 7am - 7pm Mon-Sat | 8am - 5pm Mon-Fri | |
| Standard Scheduled Downtime Windows | 2-5 am First or Third Sunday of Month | 2-5am any Sunday | 8pm to 6am Fri/Sat/Sun not to exceed 8 hrs/wk | Not to exceed 48 hours per week | |
|
Uptime Availability Target
|
Application and Middleware Uptime Availability Target | TBD | TBD | TBD | TBD |
| Infrastructure Services Uptime Availability Target | 99.999% | 99.70% | 99% | 98% | |
|
Disaster Recovery
|
Recovery Time Objective | 4 hours | 24 - 48 Hours | 7 - 30 days | > 1 months or non-recoverable |
| Recovery Point Objective | No data loss exc. Data in flight | 0 - 24 hours | 1 - 7 days | Greater than 1 month or risk of entire loss | |
|
Major Incident
|
Recovery Time Target | 2 hours | 8 hours | 72 hours | >72 hours or non-recoverable |
| Response Time Target | 15 minutes | 45 minutes | 4 hours within hours of support | 4 hours within hours of support | |
| Management Escalation Protocol | Immediate DOC involvement | Escalate to DOC within 4 hours | Escalate to technical manager within 4 hrs and escalate to DOC as needed | No escalation | |
| Customer Communication Plan Requirements | Downtime communications pre-drafted to reflect failure scenarios AOC and DOC are active in Communication Process |
Downtime communications pre-drafted to reflect failure scenarios DOC and IT Staff assist to validate Communication |
Downtime communications drafted during event | Downtime communications drafted during event | |
| Customer Communication Escalation Protocol | Immediate FYI notification to AOCs, Pharmacy and Incident Commanders when applicable with a follow-up within 30 minutes from declaration | AOC Involvement based on DOC Discretion | AOC Involvement based on DOC Discretion | AOC Involvement based on DOC Discretion | |
|
Incident Management
|
Resolution Time Target |
Metric Under Development |
Metric Under Development |
Metric Under Development |
Metric Under Development |
| Response Time Target |
Metric Under Development |
Metric Under Development |
Metric Under Development |
Metric Under Development |
|
| Update Interval |
Metric Under Development |
Metric Under Development |
Metric Under Development |
Metric Under Development |
|
| Request Fulfillment | Resolution Time Target |
Metric Under Development |
Metric Under Development |
Metric Under Development |
Metric Under Development |
|
Change & Release Management
|
Frequency of Releases - Major | No more than 2x per year | No more than 6x per year | No more than 6x per year | No Limit |
| Frequency of Releases - Minor/patch | No more than monthly | No more than weekly | No more than weekly | No Limit | |
| Change Management Processes | Follow HITS Change Management Process and Procedures with customer governance | Follow HITS Change Management Process and Procedures | Follow HITS Change Management Process and Procedures | Recommended | |
Definitions
|
Term |
Definition |
|
Hours of Operation |
The hours that a service is expected to be available for business operations |
|
Hours of Support |
The hours when support staff are available to provide the agreed upon level of support as illustrated in the HITS service tier support matrix |
|
Standard Scheduled Downtime Windows |
A window of time used for the purpose of upgrading, patching or maintaining a service. |
|
Application and Middleware Uptime Availability Target |
A numeric calculation used to estimate a target duration of time for application and middleware service layer availability. Excludes scheduled downtime. (Include formula) |
|
Infrastructure Services Uptime Availability Target |
A numeric calculation used to estimate a target duration of time for the core infrastructure service layer availability. Excludes scheduled downtime. (Include formula) |
|
Recovery Time Objective |
The targeted duration of time within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity. |
|
Recovery Point Objective |
The age of files that must be recovered from backup storage for normal operations to resume if a service goes down as a result of a failure. |
|
Application and Middleware Recovery Time Target |
The targeted duration of time within which an application and associated middleware business process must be restored after a disruption in order to avoid unacceptable consequences associated with a break in business continuity. |
|
Infrastructure Services Recovery Time Target |
The targeted duration of time within which the core infrastructure service layer must be restored after a disruption in order to avoid unacceptable consequences associated with a break in business continuity. |
|
Response Time Target |
The targeted duration of time support staff would be expected to engage in a Major Incident recovery efforts after being notified. |
|
Management Escalation Protocol |
The protocol used to escalate and notify key IT leadership resources during a Major Incident. |
|
Customer Communication plan requirements |
The documentation of a static or dynamic method of communicating the status of a major incident. The plan outlines the frequency and type of communication required based on the severity and type of impact to service continuity. |
|
Customer Communication escalation protocol |
The protocol used to escalate and notify key Health System leadership resources during a Major Incident. |
|
Resolution Time Target |
The targeted, median amount of time it takes to resolve an incident starting from the moment the incident is reported. |
|
Response Time Target |
The targeted, median amount of time it takes HITS to initially contact a customer after an incident is reported. |
|
Update Interval |
The targeted frequency in which HITS update customers while incident resolution work is in progress. |
|
Resolution Time Target |
The targeted, average amount of time it takes to fulfill a request starting from the moment the request is submitted. |
|
Frequency of Releases - Major |
The frequency at which major version upgrades are applied to the service. |
|
Frequency of Releases - Minor |
The frequency at which minor version upgrades are applied to the service. |
|
Change Management processes |
The processes and procedures used by HITS staff in planning, scheduling, communicating, and approving changes to the service. |