RFO No. HHS0017000 Exhibit M

Department of State Health Services Health Registries

Texas Department of State Health Services

(DSHS)

Exhibit M:

Process Guide V.5.0

Health Registries

Contents 1 Background

2 Changes to the Process Guide

3 Initiation Process - Implementation Project

3.1 Implementation Project - Purpose of System Development Lifecycle (SDLC)

3.2 Implementation Project - High-Level Estimate (HLE) Phase

3.3 Implementation Project - Discovery Phase

3.4 Implementation project - Design & Development Phase

3.5 Implementation Project - Contractor QA Testing Phase

3.6 Implementation Project - System Agency QA/UAT Testing Phase

3.7 Implementation Project - Deployment Phase

4 Implementation Project – Software Deliverable Acceptance Process

4.1 Implementation Project - Software Deliverables

4.2 Implementation Project – Software Deliverable Acceptance Criteria

4.3 Implementation Project - Document Deliverables

4.4 Implementation Project - Document Deliverable Acceptance Criteria

5 Implementation Project - Defect Management Process

5.1 Implementation Project - Opening a Ticket

5.2 Implementation Project - Defect Triage Meetings

5.3 Implementation Project - Defect Assessment & Response

5.4 implementation Project - Defect Resolution Phase

5.5 implementation Project - Defect Response Times

5.6 implementation Project - Defect Severity Definitions

5.7 Implementation Project - Defect Issue Type Definitions

6 Production Support - Defect Management Process

6.1 High Level Operational Alignment for MAVEN Registries & Metal Plans

6.2 Production Support - Opening Tickets

6.3 Production Support - Initial Triage Meetings

6.4 Production Support - Detail Triage & Response

6.5 Production Support - Defect Resolution Steps

6.6 Production Support - Response Times

6.7 Production Support - Defect Severity Definitions

6.8 Production Support - Issue Type Definitions

6.9 Production Support – Issue Size and Resolution Dration

7 Common Shared Processes

7.1 Requesting Account Access

Health Registries

8 Production Release Management Process

8.1 Production Release Management – Establish Release Cutoff Date

8.2 Production Release Management – Planning Process

8.3 Production Release Management – Final Approval Process

8.4 Production Release Management – Validation Process

8.5 Production Release Management – Deployment Process

9 Issue Escalation Process

9.1 Issue Escalation Process – Issue Types

9.2 Issue Escalation Process – Escalation Levels

10 Architecture/Security/Accessibility

11 Communication Plan

11.1 Purpose of the Communication Plan

11.2 Communication Management Approach

11.3 Communication Stakeholders

11.4 Communication Protocol

11.5 Emergency Communication Protocol

12 Invoicing

12.1 General Approach

12.2 Invoicing Template Approach

13 Business Process Guidelines and Workflows

13.1 Purpose of Buisness Process Guidelines and Workflows

13.2 Blood Lead Registry

Table of Figures

Figure 1 – Software Development Life Cycle (SDLC) Figure 2 – Release Management Process Figure 3 – Escalation Levels Figure 4 – Support and Communication Diagram Figure 5 – Blood Lead Business Processes

Table of Tables

Table 1 – Contract Severity/UAT Response Times Table 2 – UAT Severity Descriptions Table 3 – Enhanced Support Response Times Table 4 – Enhanced Support Resolution Times Table 5 – Production Support Defect Severity Description Table 6 – Production Support Sizing Table 8 – Maven Registries Information Matrix Table 9 - Blood Lead Registry Business Process Guide

Health Registries Business Process Guidelines and Standards

1 BACKGROUND

This Health Registries Business Process Guidelines and Standards (“Process Guide”) is based on Contract requirements identified in RFO No. HHS0017000 and reflects updates to the Contract terms and requirements between System Agency and Contractor in providing the Maven software platform. This Process Guide is incorporated by reference in the Contract for all purposes. Therefore, System Agency and Contractor must adhere to the portions of this Process Guide that apply to the Services and Deliverables Contractor is providing under the Contract. This Process Guide’s intent is to direct or instruct Contractor Personnel, the System Agency Project Manager and the Contractor Maven registry subject matter experts in day-to-day processes and procedures based on the Contract terms and requirements.

2 CHANGES TO THE PROCESS GUIDE

This Process Guide is a living document in that System Agency updates the processes and standards in this Process Guide contingent on mutual agreement between the Parties, as set forth in Section 3 (Initiation Process – Implementation Project) of this Process Guide.

System Agency will ensure that the Process Guide is accessible to Contractor and will notify Contractor of any proposed changes within the Process Guide.

The Process Guide will undergo quarterly reviews by System Agency and System Agency will publish mutually agreed upon updates semi-annually unless there are mutually agreed upon changes to apply in the interim. Changes to this Process Guide must be mutually agreed upon by System Agency and Contractor. Any disagreement regarding changes to the Process Guide by either Party will result in engagement of Section 9 (Issue Escalation Process) to the Process Guide.

Health Registries

3 INITIATION PROCESS - IMPLEMENTATION PROJECT

3.1 IMPLEMENTATION PROJECT - PURPOSE OF SYSTEM DEVELOPMENT

LIFECYCLE (SDLC)

The purpose of the SDLC process is to standardize all development across each Maven application instance. The SDLC process enforces standardization for each Maven registry to alleviate miscommunication, align development processes with industry standards, and ensure unanimity.

Figure 1 – Software Development Life Cycle (SDLC)

DSHS Registries Services Software Development Life Cycle (SDLC)

SD

LC

O ve rv ie w D et ai le d

SD

LC

T as ks

Approved HLE and Schedule

Vendor Discovery

Phase

Agency

(ADC TEST)

UAT Testing

Phase

Production Deployment

Vendor Design &

Development Phase

Vendor QA Testing

Phase

Go/ No Go Go

1) Vendor facilitates Discovery sessions to review detail requirements/specifications

2) Vendor develops detail project schedule

3) Vendor revises project costs

4) Agency reviews and approves detail requirements/specification

5) Agency reviews and approves detail project schedule

6) Agency reviews and approves final detailed project costs

1) Agency deploys build into HHSC ADC TEST environment

2) Agency program SMEs execute the core sets of UAT test cases

3) Agency program SMEs execute any other agreed UAT test cases

4) Agency accepts or rejects build

5) If rejected, Agency reports defects back to Vendor

5a) Vendor performs triage review with Agency as needed 5b) If defects validated, Vendor proceeds to Step C.4

6) Agency provides UAT acceptance to Vendor and plans move to production

1) Agency deploys build to production

2) Agency Program & Agency IT perform smoke test to validate build

3) Agency Program & Agency IT verifies production deployment.

4) Production Deployment Go Live

1) Vendor designs and develops test cases and test data

2) Agency reviews and approves test cases

3) Vendor designs and develops code in Vendor’s DEV environment

4) Agency provides any model changes to Vendor

5) Vendor completes unit testing in Vendor’s DEV environment

6) Vendor conducts demos of each deliverable to Agency

7) Agency accepts or rejects each deliverable

8) Rejected deliverables sent back to development team

9) Vendor developers create build package for Vendor QA team

1) Vendor QA deploys build in Vendor’s Test environment

2) Vendor QA runs the set of core testing in Vendor’s Test environment

3) Vendor QA runs any optional testing in the Vendor Test environment

4) Vendor resolves test failures and repeats steps 1 through 4 as necessary

5) Vendor creates build package of accepted deliverable for delivery to Agency

6) Vendor QA provides DSHS with test results

1) Agency deploys build into HHSC ADC DEV environment

2) Agency executes the core set of tests

3) Agency executes any other tests as required

4) Vendor executes additional tests and delivers results as agreed upon in Discovery phase

5) Agency accepts or rejects build

6) If rejected, Agency reports defects back to Vendor

6a) Vendor performs triage review with Agency as needed 6b) If defects validated, Vendor proceeds to Step C.4

7) Agency approves moving build to Agency UAT phase

A B C D E G

Agency (ADC DEV) Testing

Phase

Critical Issues Found

Critical Issues Found

1) Agency documents No Go issues in Jira

2) Agency and Vendor resolve No Go issues

3) If issues are resolved, return to Go/No Go decision

F

No Go

Health Registries

3.2 IMPLEMENTATION PROJECT - HIGH-LEVEL ESTIMATE (HLE) PHASE

Any Contract project initiation will start with the High-Level Estimate (HLE) process. This HLE process shall include System Agency bundling various Deliverables into a package, which will include high-level requirements (user stories, requirements worksheets, etc.)

that will be provided to Contractor.

Contractor shall review the requirements and provide a high-level cost estimate and a high-level project schedule. The high-level project schedule shall include the tasks, timeline, dependences, and resources required for each project Deliverable. Contractor shall request any additional clarifications during the development of the HLE.

The high-level project schedule shall also include Discovery, Design & Development, and Implementation (DDI), Testing, and Deployment phases.

Both Parties will agree to a reasonable turnaround timeline at the beginning of the High- Level Estimate Process.

The Deliverables from the HLE phase include the following:

a) Approved high-level requirements/specifications;

b) Approved high-level project costs;

c) Approved high-level project timeline (tasks, duration, dependencies, and resources); and

d) Agreed turnaround timeline for the HLE.

After delivery of the HLE by the Contractor, System Agency will determine whether the project can move forward into the Discovery phase or if the project needs redesign, rescoping or termination.

Hours spent developing an HLE will come from the applicable Maven registries support hours as specified in the Maven registries Metal plan (i.e., Platinum, Gold, Bronze, Silver).

Should support hours be exhausted, and additional hours be required, the Contractor shall seek approval for these additional hours from System Agency.

The Exit Criteria is the final approval of all Deliverables for this phase.

System Agency will provide Deliverable approval within fifteen Business Days after delivery of the HLE or HLE demonstration unless System Agency notifies Contractor of the need for an extended approval deadline.

Health Registries

3.3 IMPLEMENTATION PROJECT - DISCOVERY PHASE

The Discovery phase commences when the final detailed requirements, project costs, and detailed project scheduled are determined. This is also when the development approach (waterfall, agile, etc.), type of core testing (functionality, regression, integration, etc.), type of optional testing (performance, accessibility, security, etc.), and the defect resolution process are determined.

System Agency will determine the need for Contractor to perform required specific testing (onsite/remote) in the System Agency DEV environment with deidentified data.

This is the phase where planning occurs for any integration of System Agency development work (model changes, workflow changes, etc.) included in the build.

The Deliverables from the Discovery phase will include the following:

a) Approved detailed requirements/specifications/user stories;

b) Approved project costs;

c) Approved core and optional testing (Contractor’s environment and System Agency environment);

d) Approved sprint schedule;

e) Approved detailed project schedule (tasks, timeline, dependences, and resources);

and

f) Identification of any specific data requirements required for testing and validation of

Deliverables.

These approved Deliverables set the benchmark for compliance with the appropriate Maintenance Support Plan and Key Performance Measures (KPM).

The Exit Criteria is when System Agency provides final approval on all Deliverables for this phase. System Agency will provide Deliverable approval within fifteen Business Days after delivery or demonstration unless System Agency notifies Contractor of the need for an extended approval deadline.

3.4 IMPLEMENTATION PROJECT - DESIGN & DEVELOPMENT PHASE

The Contractor Design & Development phase is when the Contractor developers design and develop the coding changes for each Deliverable.

This is the phase when design and development of test cases and test data occur.

System Agency will review, and if acceptable to System Agency, approve the test cases.

Contractor developers shall also perform unit testing to validate that the code is correct.

This is the phase where the integration of any System Agency development work (model changes, workflow changes etc.) occurs.

Contractor developers shall also provide recurring demonstrations of each appropriate Deliverable to ensure the Deliverable aligns with System Agency expectations and requirements.

The Deliverables from the Design & Development phase include the following:

a) Delivery package test cases/user story acceptance criteria reviewed and approved;

Health Registries

b) Delivery package integration with System Agency developed Deliverables;

c) Delivery package code development complete;

d) Delivery package unit testing complete; and

e) Delivery package demos completed and approved.

The Exit Criteria is when delivery package Deliverables are demonstrated and approved by System Agency.

System Agency will review the Deliverable(s), and if acceptable to System Agency, will approve the Deliverable(s) within fifteen Business Days after delivery or demonstration unless Contractor is notified of the need for an extended approval deadline.

3.5 IMPLEMENTATION PROJECT - CONTRACTOR QA TESTING PHASE

The Contractor QA Testing phase is when the Contractor’s QA team deploys the production ready build into the Contractor’s test environment and begins its QA testing activities. This will include executing the standard testing and any optional testing activities identified during the Implementation Project - Discovery Phase.

There will be a defined set of standard testing that will be executed for every project. The types of standard testing utilized for each project will be determined in the Implementation Project - Discovery Phase of each project. The standard testing will include the following:

a) Regression Testing; and

b) Functional Testing.

There will also be some optional testing requested for specific Implementation projects, depending on the types of Deliverables. The types of optional testing utilized for each project will be determined in the Implementation Project - Discovery Phase of each Implementation project. The optional testing will include the following:

a) Performance Testing;

b) Security Testing (SAST/DAST Security scans provided to System Agency); and

c) Accessibility Testing.

The testing will leverage the test cases developed by the Contractor and approved in the Implementation Project - Design & Development Phase.

When the Contractor QA testing is completed, Contractor will provide System Agency with the testing results for each Deliverable. System Agency will approve or reject each individual Deliverable, as part of the Implementation Project - Contractor QA Testing Phase. All rejected Deliverables will be returned to Contractor’s development team for correction.

Contractor will deliver a build fully tested by the Contractor QA team. The build shall include the approved Deliverables in the build package, along with release notes, test cases and test results, configuration files, etc. General test cases for a release will be uploaded in WebDAV when the release documentation is delivered.

Contractor shall perform SAST/DAST security scans as the application code is changed and share scan reports with System Agency on a quarterly basis. First month of the quarter THISIS will be run, and second month of the quarter all other Maven registries will be run. Additionally, security scans will also be run for major code releases on an ad-hoc basis.

Health Registries

The Exit Criteria will be the delivery of a fully tested build package. The testing results for the build package will be reviewed, and if acceptable to System Agency, approved by System Agency.

If the Deliverable is acceptable to System Agency, System Agency will provide Deliverable approval within fifteen Business Days after delivery or demonstration unless Contractor is notified of the need for an extended approval deadline.

3.6 IMPLEMENTATION PROJECT - SYSTEM AGENCY QA/UAT TESTING PHASE

This is the phase when the build package deploys into the System Agency testing environment.

System Agency may request Contractor to perform specific (onsite/remote) testing in the System Agency DEV environment with deidentified data (data from which personal identifiers have been removed or obscured so that the remaining data cannot be used to identify a specific individual).

The System Agency QA team will execute the standard testing and any optional testing activities identified during the Implementation Project - Discovery Phase, to ensure everything is deployed successfully. The testing will leverage the test cases developed by the Contractor and developed by the System Agency QA team approved in the Implementation Project - Design & Development Phase.

This is the phase where the System Agency QA team will approve or reject each individual Deliverable in the development environment. All rejected Deliverables will be returned to the Contractor’s development team for correction.

When the System Agency QA team successfully completes their testing activities, the System Agency program SMEs will be invited to start their UAT test scenarios and various smoke tests.

This is the phase where the System Agency program SMEs will approve or reject each individual Deliverable in the TEST environment. All rejected Deliverables will be returned to Contractor’s development team for correction.

Contractor will provide System Agency with an Acceptance Letter at the end of the Implementation Project – System Agency UAT Testing Phase that includes each Deliverable included in the build package for review and approval. System Agency will provide its acceptance for those Deliverables that meet the requirements agreed to in the Implementation Project - Discovery Phase.

The Exit Criteria is when defects in the following categories are resolved:

a) All Severity 1 defects;

b) All Severity 2 defects; and

c) Designated high priority Severity 3 or Severity 4 defects by agreement by both

Parties.

3.7 IMPLEMENTATION PROJECT - DEPLOYMENT PHASE

This is the phase when the build package deploys into the System Agency production environment, and the System Agency program SMEs execute final smoke tests to validate the deployment.

Health Registries

The System Agency Technical Lead deploys the build into the production environment and notifies the System Agency program SMEs that the application is available for smoke testing.

The System Agency program SMEs conduct random smoke tests to validate the deployment was successful and notifies the System Agency Technical Lead if any issue is encountered.

The Exit Criteria is a successful build deployment into production, and the smoke tests reveal no issues.

Health Registries

4 IMPLEMENTATION PROJECT – SOFTWARE DELIVERABLE ACCEPTANCE

PROCESS

There are two different types of Deliverables identified in this Process Guide: Software Deliverables and Document Deliverables. Each type of Deliverable will have its own acceptance criteria.

4.1 IMPLEMENTATION PROJECT - SOFTWARE DELIVERABLES

Software Deliverables are software development Services and software products approved by and delivered to System Agency.

Software Deliverable examples:

a) New reports, print templates, interfaces, workflows, business rules, models, custom code, configurations, etc.; and

b) Changes to reports, print templates, interfaces, workflows, business rules, models, custom code, configurations, etc.

4.2 IMPLEMENTATION PROJECT – SOFTWARE DELIVERABLE ACCEPTANCE

CRITERIA

This section outlines the steps that System Agency and Contractor will work together to specify what is acceptable to both Parties.

The System Agency Contract manager or the Contract manager’s designee has the authority to review, revise and provide feedback to Contractor on the submitted software Deliverable by the agreed review period.

If the initial review determines one or more Deliverables are deficient, System Agency will report the deficiencies to the Contractor in one complete set by the end of the agreed review period.

Contractor and System Agency will conduct review of the detailed requirements to identify if the issue is an in-scope requirement or a new requirement.

There is a specific period-of-time granted to Contractor, mutually agreed in writing by System Agency and Contractor, to correct any documented deficiencies.

Comments made on any Deliverables submitted a second time (after the initial correction of deficiencies) shall pertain only to the new/updated content. If after the second review, System Agency determines the Deliverable to be unacceptable, Contractor shall meet with System Agency to discuss each comment to reach a joint resolution.

A software Deliverable is acceptable when it includes all requirements documented and approved in the detailed requirements and specifications during the Implementation Project - Discovery Phase.

Any agreed variation from the acceptance criteria for a project Deliverable will be documented in the Process Guide in the appendices that cites the project.

Health Registries

4.3 IMPLEMENTATION PROJECT - DOCUMENT DELIVERABLES

Document Deliverables are any document Deliverable included in Section 12 (Invoicing) of this document and considered by System Agency as a non-service or “Document Deliverable”.

4.4 IMPLEMENTATION PROJECT - DOCUMENT DELIVERABLE ACCEPTANCE

CRITERIA

This section outlines the steps that System Agency and Contractor will engage to determine what is acceptable to both Parties.

The System Agency Contract manager or its designee has the authority to review, revise and provide feedback to Contractor on the submitted Document Deliverables by the agreed upon review period.

If after the initial review, System Agency determines one or more document Deliverables are deficient, System Agency will report the deficiencies back to Contractor in one complete set by the end of the agreed review period.

There is a specific period-of-time granted to Contractor, mutually agreed in writing, to correct any documented deficiencies.

Comments made regarding any document Deliverables submitted a second time (after the initial correction of deficiencies) shall pertain only to the new or otherwise updated content.

If after the second review, System Agency determines the document Deliverable to be unacceptable, Contractor shall meet with System Agency to discuss each comment to reach a joint resolution.

A Document Deliverable is acceptable when it includes all requirements outlined in Section 12 (Invoicing) of this Process Guide.

5 IMPLEMENTATION PROJECT - DEFECT MANAGEMENT PROCESS

During the System Agency IT application development team Acceptance Testing (UAT) phase, System Agency program SMEs and System Agency QA testers will execute a series of standard and mutually agreed in writing potential optional testing activities to validate the Deliverables within the build packages.

5.1 IMPLEMENTATION PROJECT - OPENING A TICKET

During this testing activity, if the System Agency program SME or System Agency QA tester recognizes an issue, they will open a defect ticket in the Implementation project system (currently JIRA) to document the issue. When opening a ticket, the tester will include the following required information:

a) Severity: Select one the five severities listed in the (Implementation Project - Defect Severity Definitions) Section 5.6 of this document.

b) Type of Issue: Select one of the six Issue types listed in the (Implementation Project - Issue Type Definitions) Section 5.7 of this document.

c) Description: A description of the issue.

d) Steps to Reproduce: Step by step list of actions taken that cause the issue to occur. This should include information such as the user role and pertinent details in leading to reproduce the issue. Include the steps to reproduce the issue, even if they do not cause the issue to consistently occur.

e) Actual Result: A description of the actual results encountered with the functionality used when the issue appeared.

f) Expected Result: A description of how the functionality is expected to work.

g) System Agency Initial Investigation: A checklist describing investigation steps taken by the System Agency Technical Lead prior to reporting to Contractor, and an indication if the issue is reproducible.

h) Program SME: The System Agency program SME, who is the point of contact for the reported issue.

i) Additional Relevant Information: Inclusion of additional details needed to triage an issue. For example, logs scrubbed of PHI, PII, test HL7 files, etc.

j) Issue Order: Ordering of sub-priority within the ticket Priority/Severity.

5.2 IMPLEMENTATION PROJECT - DEFECT TRIAGE MEETINGS

During the System Agency IT application development team Acceptance Testing (UAT) phase there will be daily triage meetings facilitated by the System Agency QA Test Lead.

The triage meetings is when the assessment of the issue occurs to determine if it is a defect or a change request. A review of the ticket also occurs to make sure it includes the minimum required details as outlined in the (Implementation Project – Opening a Ticket) Section 5.1 of this Process Guide. During the triage meetings the following topics will be addressed for each defect based on agreed upon priority for the discussion:

Health Registries

a) Severity;

b) Type of Issue;

c) Description;

d) Steps to Reproduce;

e) Actual Result;

f) Expected Result;

g) System Agency Initial Investigation;

h) System Agency program SME;

i) Additional Relevant Information; and

j) Issue Order.

The issue will be assigned to Contractor to start the assessment and response phase.

The defect resolution and response clocks will start and stop in accordance with Exhibit N, Key Performance Measures (KPMs) and Liquidated Damages.

5.3 IMPLEMENTATION PROJECT - DEFECT ASSESSMENT & RESPONSE

Contractor will perform an initial assessment on the issue to determine if it is one of the following:

a) Core/Overlay defect;

b) Known issue defect; and

c) New change request.

The initial response to the JIRA ticket from Contractor helps validate the severity and provides a minimum informative response that should include:

a) Indicate if any additional information required and ask for specific details;

b) Indicate if the issue can is reproduceable; and

c) Indicate initial findings (what is causing the issue).

System Agency and Contractor will work together to achieve agreement on the below acceptance criteria, to terminate the response period and to begin the resolution period:

a) Severity;

b) Type of issue (defect, change request, etc.);

c) No additional information needed to work toward a resolution;

d) The issue is reproducible;

e) Proposed resolution;

f) Expected result of resolution; and

g) Resolution timeline (agree to resolution ETA).

N, Key Performance Measures (KPMs) and Liquidated Damages.

5.4 IMPLEMENTATION PROJECT - DEFECT RESOLUTION PHASE

Health Registries

A defect is resolved when the defect fix is delivered (can be a build, configuration instructions, etc.) to System Agency.

System Agency will go through a validation process to ensure the defect fix will resolve the original issue. The validation process will entail comparing the delivered resolution to the requirement and documented expected result.

If any additional issues identified, a new ticket will be opened.

If the test result matches the expected result of the resolution, the defect fix is accepted, and the defect is closed. If the test results do not match the expected result, then the ticket will be set to a “Failed” status and be reassigned back to the Contractor.

The defect resolution and response clocks will start and stop in accordance with Exhibit N, Key Performance Measures (KPMs) and Liquidated Damages.

5.5 IMPLEMENTATION PROJECT - DEFECT RESPONSE TIMES

Implementation defects are pre-production defects. UAT defects are all defects identified in the system during the UAT process. Both Parties will agree to the Defect severity during the triage meetings.

Contractor must correct all the UAT defects based on the severities and timelines as indicated in Exhibit N, Key Performance Measures (KPMs) and Liquidated Damages (listed in the table below).

Table 1 – Contract Severity/UAT Response Times

JIRA

Severity Contract Severity UAT Response Times

Blocker/S1 Severity 1 - Critical (S1) Contractor must respond to Severity 1 UAT defects within one (1) Business Day after the defect is opened.

Critical/S2 Severity 2 - Major (S2) Contractor must respond to Severity 2 UAT defects within three (3) Business Days after the defect is opened.

Major/S3 Severity 3 - Medium (S3)

Contractor must respond to Severity 3 UAT defects within eight (8) Business Days after the defect is opened.

Minor/S4 Severity 4 - Minor (S4)

Contractor must respond to Severity 4 UAT defects within 30-Business Days after the production defect is opened or at a later date as agreed to by System Agency.

Refer to Exhibit N, Key Performance Measures (KPMs) and Liquidated Damages.

Health Registries

5.6 IMPLEMENTATION PROJECT - DEFECT SEVERITY DEFINITIONS

Below are the five (5) defect severity definitions that will be used when opening a UAT defect, as outlined in the (Implementation Project – Opening a Ticket) Section 5.1 of this Process Guide.

Table 2 – UAT Severity Descriptions

JIRA

Severity

Contract Severity UAT Severity Description

Blocker/S1 Severity 1 - Critical (S1)

The defect blocks the tester from executing UAT testing.

Critical/S2 Severity 2 - Major (S2)

The defect is a significant failure of the test case expected results or subject matter expert’s understanding of the requirements.

Major/S3 Severity 3 - Medium (S3)

The defect is a failure of the test case expected results or subject matter expert’s understanding of the requirement.

Minor/S4 Severity 4 - Minor (S4)

The defect has little or no consequence to the test case expected results or subject matter expert’s understanding of the requirements.

Refer to Exhibit N, Key Performance Measures (KPMs) and Liquidated Damages.

5.7 IMPLEMENTATION PROJECT - DEFECT ISSUE TYPE DEFINITIONS

Below are the five (5) Issue Type definitions that shall be used when opening a ticket, as outlined in the (Implementation Project – Opening a Ticket) Section 5.1 of this Process Guide.

a) Bug – Identifies a problem which impairs or prevents the functions of the product.

b) Change Request – Identifies new functionality or a change in requirements to an existing functionality.

c) Project Deliverable – Identifies a named Deliverable in the Implementation project.

d) Question – Identifies questions related to new or existing functionality, or capability of the product.

e) Task – Identifies a specific task that needs to be performed as part of Implementation project.

Health Registries

6 PRODUCTION SUPPORT - DEFECT MANAGEMENT PROCESS

6.1 HIGH LEVEL OPERATIONAL ALIGNMENT FOR MAVEN REGISTRIES & METAL

PLANS

Registry Metal Plans

Bronze Modified

Bronze Silver Gold Platinum

Blood Lead

(BLR) X

THISIS X

Contractor Personnel

Fixed Price included in

Annual Maintenance Metal Price

Fixed Price included in Annual Maintenance Metal Price

Fixed Price included in

Annual Maintenance Metal Price

Severity 1 If a Severity 1 issue occurs in a Maven registry, with the approval of the System Agency manager, or designee, Contractor may pull fractional resources, away from working on lower severity items in the same registry, to address the severity 1 issue.

Customer Service Representative

(CSR)

Single point of contact handling all Metal Plans intake (tickets and calls).

Also responsible for providing ticket status reporting on request by System Agency.

6.2 PRODUCTION SUPPORT - OPENING TICKETS

When a System Agency IT application development team user recognizes an issue, they will create a ticket using the System Agency help desk (currently Remedy) to document the issue. According to each Maven registry (CHI/LIDS) the ticket will route to the appropriate applications Technical Group.

a) The System Agency Technical Lead will perform the initial internal triage of the issue to determine the following:

b) The System Agency Technical Leads ability to resolve this issue;

c) For environmental (DCS) issues the System Agency Technical Lead will open a ticket with DCS;

d) For technical (Maven/Application) issues the System Agency Technical Lead will open a JIRA ticket; and

e) For non-technical or non-environmental issues (e.g., user error), the System

Agency Technical Lead will resolve via the System Agency help desk.

When opening a ticket, the System Agency Technical Lead will include the following:

a) Severity: Select of the five severities listed in the (Production Support - Defect

Severity Definitions) Section 5.6 of this document.

b) Type of Issue: Select one of the six Issue types listed in the (Production Support

- Issue Type Definitions) Section 5.7 of this document.

Health Registries

c) Description: A description of the issue.

d) Steps to Reproduce: Step by step list of actions taken that cause the issue to occur. This should include information such as the user role and pertinent details in leading to reproduce the cause. Include the steps to reproduce the issue, even if they do not cause the issue to consistently occur.

e) Actual Result: A description of the actual results encountered with the functionality used when the issue appeared.

f) Expected Result: A description of how the functionality is expected to work.

g) The System Agency Initial Investigation: A checklist describing investigation steps taken by System Agency Technical Lead prior to reporting to the Contractor, and an indication, if the issue is reproducible.

h) Program SME: The DSHS program SME, who is the point of contact for the reported issue.

i) Additional Relevant Information: Inclusion of additional details needed to triage an issue. For example, logs scrubbed of PHI, test HL7 files, etc.

j) Issue Order: Sub-priority order within the ticket Priority/Severity.

k) Public Health Impact: Description of Public Health impact on the citizens of Texas.

Health Registries

6.3 PRODUCTION SUPPORT - INITIAL TRIAGE MEETINGS

For JIRA tickets, the Contractor’s CSR receives the JIRA ticket and begins the triage. If the Contractor’s CSR reviews the ticket and determines additional information is needed, the JIRA will be updated with the request for additional details and assigned back to the System Agency Technical Lead for response.

The System Agency Technical Lead will provide additional information and reassign the JIRA ticket back to the Contractor’s CSR.

The Contractor’s CSR will perform triage of the issue with Contractor support team to determine if the issue is one of the following:

a) Reproducible;

b) Core/Overlay defect;

c) Known issue;

d) Working as designed;

e) Configuration change required;

f) Change request (CR); and

g) Analyze the data (legacy, conversion, etc.).

The initial JIRA response from the Contractor’s CSR will include the following:

a) Reproducibility;

b) Description of findings;

c) Potential causes (if known);

d) If it is a known issue;

e) Investigations steps and results;

f) Functionality or Data Impacts (if known); and

g) Next steps.

The defect resolution and response clocks will start and stop in accordance with Exhibit N, Key Performance Measures (KPMs) and Liquidated Damages.

6.4 PRODUCTION SUPPORT - DETAIL TRIAGE & RESPONSE

The Contractor’s CSR will begin the detailed triage phase:

If Contractor is unable to reproduce the issue, the investigation continues, and may include the following additional steps as agreed to by System Agency and Contractor:

a) Additional information requests;

b) Conference call;

c) Onsite triage; and

d) System Agency confirms the end user is still encountering the issue if:

i. All options have been exhausted and the issue is not reproducible.

Contractor will then submit a request for System Agency to withdraw the ticket. If System Agency and the Contractor can’t reach agreement, the issue will be escalated following the (Issue Escalation Process) Section 9 of this document.

Health Registries

ii. If the Contractor’s CSR determines that the issue is a “Bug” (core or overlay) the Contractor will start the Production Support – Defect Resolution Phase.

iii. If the Contractor’s CSR determines that the issue is a “Known Issue” Contractor will start the Production Support – Defect Resolution Phase.

iv. If the Contractor’s CSR determines that the issue is a “Duplicate” the issue will be linked to the known issue and the ticket will be resolved with a resolution of “Duplicate” by the Contractor’s CSR.

v. If the Contractor’s CSR determines that the issue is a Change Request the Contractor will start the Production Support – Change Request Process. If System Agency and the Contractor can’t reach agreement, the issue will be escalated following the (Issue Escalation Process) Section 9 of this document.

vi. If the Contractor’s CSR determines that the issue is “Working as Intended” the Contractor will update the JIRA ticket with a detailed explanation, update the ticket status to “Resolved” and reassign to JIRA ticket to the System Agency Technical Lead for validation. If System Agency and Contractor can’t reach agreement, the issues will be escalated following the (Issue Escalation Process) Section 9 of this document.

Before starting the Production Support – Defect Resolution Phase the following will be answered and agreed upon:

a) Severity;

b) Type of issue (defect, change request, etc.);

c) No additional information needed to work toward a resolution;

d) The issue is reproducible;

e) Proposed resolution;

f) Expected result of resolution;

g) Resolution target timeline (agree to resolution ETA);

h) Resolution Level of Effort (“LOE”)/sizing;

i) Link the Contractor JIRA development ticket and update JIRA ticket with resolution timeline; and

j) Draft test cases.

The defect resolution and response clocks will start and stop in accordance with Exhibit N, Key Performance Measures (KPMs) and Liquidated Damages.

6.5 PRODUCTION SUPPORT - DEFECT RESOLUTION STEPS

Contractor will assign the issue to a Contract developer, who will implement the proposed solution.

If a proposed solution needs to be modified, to the extent that it will have an impact on the user experience or the expected results, the Contractor will document the reasons why, the proposed modification, and if the modification prevents the Contractor from continuing

Health Registries work in the corresponding JIRA ticket. If discussion is needed, the Contractor will stop work on the relevant components.

If System Agency approves the proposed solution, it will document the agreement in the JIRA ticket and the Contractor will move forward with implementing the modified proposed solution.

If further discussion is needed, a meeting can be scheduled as appropriate. The meeting results and final agreed proposed solution will be documented in the JIRA ticket and System Agency will add a comment to JIRA to reflect agreement. Contractor will move forward with implementing the modified proposed solution.

Contractor will create a build package (build, configurations, etc.) and perform QA testing on the build package. Contractor will attach bug specific test cases, targeted regression test, and test results to the corresponding JIRA ticket.

A defect is considered resolved when the defect fix is delivered (can be a build, configuration instructions, etc.) to System Agency.

System Agency will go through a validation process to ensure the defect fix resolved the original issue. The validation process will be to compare the delivered resolution to the requirement and documented expected result.

If the test result matches expected result, the defect fix shall be deemed accepted, and the defect will be closed by the System Agency Technical Lead. If the test results do not match the expected result, then the ticket will be set to a “Failed QA” status and reassigned back to the Contractor.

6.6 PRODUCTION SUPPORT - RESPONSE TIMES

Production defects are defects discovered in the production environment by System Agency or initially discovered in a test environment and validated that the issue exists in the production environment.

Contractor must respond to and resolve all Production Support defects based on the Maintenance Support Plan as identified in Exhibit N, Key Performance Measures (KPMs) and Liquidated Damages. These timeframes are summarized in the tables below.

Health Registries

Table 3 – Enhanced Support Response Times

Metal Plan JIRA Severity

Contract Severity

Enhanced Support Response Times

Modified Bronze and

Bronze

- Blood Lead

- THISIS

Blocker/S1 Critical/S2 Major/S3 Minor/S4 Trivial/S5

Severity 1 - Critical (S1) Severity 2 - Major (S2) Severity 3 -

Medium (S3) Severity 4 - Minor (S4) Severity 5 - Trivial (S5)

Contractor must respond to Severity 1 defects within seven

(7) Business Days.

Contractor must respond to Severity 2 defects within ten

(10) Business Days.

Contractor must respond to Severity 3 defects within fifteen

(15) Business Days.

Contractor must respond to Severity 4 defects within thirty

(30) Business Days.

The Contractor must respond to Severity 5 defects within thirty (30) Business Days.

Gold

Major/S3 Minor/S4 Trivial/S5

Severity 1 - Critical (S1) Severity 2 - Major (S2) Severity 3 -

Medium (S3) Severity 4 - Minor (S4) Severity 5 - Trivial (S5)

The Contractor must respond to Severity 1 defects within three (3) Business Days.

The Contractor must respond to Severity 2 defects within six

(6) Business Days.

The Contractor must respond to Severity 3 defects within twelve (12) Business Days.

The Contractor must respond to Severity 4 defects within twenty (20) Business Days.

The Contractor must respond to Severity 5 defects within twenty (20) Business Days.

Platinum

Major/S3 Minor/S4 Trivial/S5

Severity 1 - Critical (S1) Severity 2 - Major (S2) Severity 3 -

Medium (S3) Severity 4 - Minor (S4) Severity 5 - Trivial (S5)

The Contractor must respond to Severity 1 defects within three (3) Business Days.

The Contractor must respond to Severity 2 defects within six

(6) Business Days.

The Contractor must respond to Severity 3 defects within twelve (12) Business Days.

Health Registries

Metal Plan JIRA Severity

Contract Severity

Enhanced Support Response Times

The Contractor must respond to Severity 4 defects within twenty (20) Business Days.

The Contractor must respond to Severity 5 defects within twenty (20) Business Days.

Table 4 – Enhanced Support Resolution Times

Metal Plan JIRA Severity

Contract Severity

Enhanced Support Resolution Times

Modified Bronze and

Bronze

- Blood Lead

- THISIS

Major/S3 Minor/S4 Trivial/S5

Severity 1 - Critical (S1) Severity 2 - Major (S2) Severity 3 -

Medium (S3) Severity 4 - Minor (S4) Severity 5 - Trivial (S5)

Issue resolution time is based on the proposed resolution timeline as agreed to from the defect response report.

Gold

Major/S3 Minor/S4 Trivial/S5

Severity 1 - Critical (S1) Severity 2 - Major (S2) Severity 3 -

Medium (S3) Severity 4 - Minor (S4) Severity 5 - Trivial (S5)

Issue resolution time is based on the proposed resolution timeline as agreed to from the defect response report.

Platinum

Major/S3 Minor/S4 Trivial/S5

Severity 1 - Critical (S1) Severity 2 - Major (S2) Severity 3 -

Medium (S3) Severity 4 - Minor (S4) Severity 5 - Trivial (S5)

Issue resolution is based on the proposed resolution timeline as agreed to from the defect response report.

6.7 PRODUCTION SUPPORT - DEFECT SEVERITY DEFINITIONS

Below are the five (5) defect severity definitions that should be used when opening a Production Support defect, as outlined in the (Production Support - Opening Tickets) Section 6.2 of this Process Guide.

Table 5 – Production Support Defect Severity Description

JIRA

Severity

Contract Severity

Production Support Defect Severity Description

Blocker/S1 Severity 1 - Critical (S1)

The defect prohibits the user’s key business operations or causes DSHS to be out of compliance with federal or state laws and regulations.

Critical/S2 Severity 2 – Major (S2)

A Severity 1 with a workaround or corrective action.

The defect does not significantly impair the user’s normal business operations or causes DSHS to be out of compliance with federal or state laws and regulations.

Major/S3 Severity 3 - Medium (S3)

The defect does not significantly impair the user’s normal business operations or compliance of DSHS and does not affect core functionality with a workaround.

Minor/S4 Severity 4 – Minor (S4)

The defect has little or no consequence on the user’s normal business operations or the core functionality and does not cause DSHS to be out of compliance with federal or state laws and regulations.

Trivial/S5 Severity 5 – Trivial (S4)

The defect has little or no consequence on the user’s normal business operations or the core functionality and does not cause DSHS to be out of compliance with federal or state laws and regulations.

Health Registries

6.8 PRODUCTION SUPPORT - ISSUE TYPE DEFINITIONS

Below are the five (5) Issue Type definitions that will be used when opening a Production Support ticket, as outlined in the (Production Support – Opening Tickets) Section 6.2 of this Process Guide:

a) Bug – Identifies a problem which impairs or prevents the functions of the product.

b) Change Request – Identifies new functionality or a change in requirements to an existing functionality that is approved to be executed using Support Hours.

c) Deliverable – Identifies a named Deliverable in the Support Project.

d) Question – Identifies questions related to new or existing functionality, or capability of the product.

e) Task – Identifies a specific task that needs to be performed as part of Production Support.

6.9 PRODUCTION SUPPORT – ISSUE SIZE AND RESOLUTION DRATION

The following resolution size and durations are applicable:

Table 6 – Production Support Sizing

Size Duration Small 1 – 3 days

Medium 4 – 7 days Large 2 – 3 weeks

Extra Large 1 month or greater

The estimates include the following tasks:

a) Defect assessment tasks;

b) Defect development tasks;

c) Defect development testing tasks; and

d) Defect QA testing tasks.

Health Registries

7 COMMON SHARED PROCESSES

7.1 REQUESTING ACCOUNT ACCESS

Requesting New User Account Access or Modifying Existing User Account Access:

The System Agency Technical Lead creates a “Task” type JIRA ticket within the corresponding support project. The ticket must include the following information:

a) User’s name;

b) Email address; and

c) Type of use access being requested (e.g., JIRA, WebDAV, Confluence, SVN).

For new JIRA accounts, indicate the specific JIRA projects (e.g., TXEDSS, TXEDSSI, or TXEDSSS) for which access is requested. Only create one ticket when requesting access for multiple JIRA projects.

If the request is for access to a TX Support project, include if read-only or write permission (System Agency IT application development team only) is needed.

The following are the request and approval steps:

1. The System Agency Technical Lead assigns the ticket to the project’s Contractor’s

CSR;

2. The Contractor CSR will review the ticket to confirm all required information is included and notify the Contractor’s Client Services Manager of the request;

3. If the request includes access to a TX Support project, the Contractor’s Client Services

Manager will contact the System Agency Contract Manager or designee for approval;

4. The Contractor Client Services Manager will submit the request to the Contractor’s IT team to create the account;

5. The Contractor’s IT team will create the account and email the credentials to the user;

and

6. The Contractor Client Services Manager or Client Success Representative will add a comment to the Support ticket, update the status to “Resolved” and assign it to the reporter to validate the user is able to access the account(s) and close the ticket.

To expedite the process, send an email to the System Agency Contract Manager (cc the Client Services Manager and Client Success Representative) requesting approval to grant user access to the TX Support project.

Deactivating Account Access

The System Agency Technical Lead will create a “Task” type JIRA ticket within the corresponding support project. The ticket must include the following information:

a) User’s name;

b) Email address; and

c) Applications to deactivated for (e.g., JIRA, WebDAV, Confluence, SVN).

The following are the deactivate request and approval steps:

1. The System Agency Technical Lead will assign the ticket to the project’s Client

Success Representative;

Health Registries

2. The Client Success Representative will review the ticket to confirm all required information is included and will submit the request to Contractor’s IT team to deactivate the account(s);

3. Contractor’s IT team will deactivate the account and notify the Client Success Representative; and

4. The Client Success Representative will add a comment to the Support ticket, update the status to “Resolved” and assign it to the reporter to notify the request is complete so the reporter can close the ticket.

Health Registries

8 PRODUCTION RELEASE MANAGEMENT PROCESS

The Release Management Process includes the planning, prioritization, approval, validation, and deployment of changes into the production system. System Agency and the Contractor will agree to an established schedule for production releases.

Each release will follow the Release Management processes listed below:

a) Release final cutoff date (no additional defect fixes or Deliverables after this date);

b) Release planning during Jira calls;

c) Release final approval process;

d) Release validation process; and

e) Release production deployment process.

8.1 PRODUCTION RELEASE MANAGEMENT – ESTABLISH RELEASE CUTOFF

DATE

Contractor will fix defects prioritized by System Agency.