Notice of Contract

STATE OF MICHIGAN PROCUREMENT Department of Technology, Management, and Budget 525 W. ALLEGAN ST., LANSING, MICHIGAN 48913 P.O. BOX 30026 LANSING, MICHIGAN 48909

NOTICE OF CONTRACT

NOTICE OF CONTRACT NO. 171-210000000534 . between THE STATE OF MICHIGAN and

Altarum Institute Multiple – See Below DHHS

3520 Green Ct. Ste 300

Program Ann Arbor MI 48105 1566 Manager Mecca Martin DTMB

David Banks STATE

202-776-5111 517-230-5694 CONTRACTOR Contract Contract [email protected] [email protected] Administra

CV0023268

CONTRACT SUMMARY DESCRIPTION: Michigan Disease Surveillance System (MDSS) Development Modernization INITIAL AVAILABLE EXPIRATION DATE BEFORE INITIAL EFFECTIVE DATE INITIAL EXPIRATION DATE OPTIONS CHANGE(S) NOTED BELOW 3/17/2021 3/18/2024 2 – 1 year options 3/18/2024 PAYMENT TERMS DELIVERY TIMEFRAME Net 45

ALTERNATE PAYMENT OPTIONS EXTENDED PURCHASING

☐ P-card ☐ Payment Request (PRC) ☐ Other ☐ Yes ☒ No MINIMUM DELIVERY REQUIREMENTS n/a MISCELLANEOUS INFORMATION This contract is established from Request for Solution 171-210000000515

ESTIMATED CONTRACT VALUE AT TIME OF EXECUTION $11,498,250.00

CONTRACT NO. 171-210000000534

Program Managers for Multi-Agency and Statewide Contracts

AGENCY NAME PHONE EMAIL MDHHS Jim Collins 517-284-4911 [email protected] DTMB Heather Eakin 517-528-5675 [email protected]

CONTRACT NO. 171-210000000534

FOR THE CONTRACTOR:

Company Name

Authorized Agent Signature

Authorized Agent (Print or Type)

Date

FOR THE STATE:

Signature

Name & Title

Agency

Date

STATE OF MICHIGAN

CONTRACT TERMS CUSTOM SOFTWARE DEVELOPMENT

This CUSTOM SOFTWARE DEVELOPMENT CONTRACT (this “Contract”) is agreed to between the State of Michigan (the “State”) and Altarum Institute (“Contractor”), a Michigan corporation. This Contract is effective on March 17, 2021 (“Effective Date”), and unless earlier terminated, will expire on March 18, 2024 (the “Term”).

This Contract may be renewed for up to two (2) additional one (1) year periods. Renewal must be by written agreement of the parties and will automatically extend the Term of this Contract.

The parties agree as follows:

1. Definitions. For purposes of this Contract, the following terms have the following meanings:

“Acceptance” has the meaning set forth in Section 10.5.

“Acceptance Tests” means such tests as may be conducted in accordance with Section 10 and the Statement of Work to determine whether any Software Deliverable meets the requirements of this Contract and the Specifications and Documentation.

“Affiliate” means any entity which directly or indirectly controls, is controlled by or is under common control of Contractor. The term “control” means the possession of the power to direct or cause the direction of the management and the policies of an entity, whether through the ownership of a majority of the outstanding voting rights or by contract or otherwise.

“Aggregate Software” means the Software, as a whole, to be developed or otherwise provided under the Statement of Work. For avoidance of doubt, if the Statement of Work provides for a single Software Deliverable, such Software Deliverable also constitutes Aggregate Software.

“Allegedly Infringing Materials” has the meaning set forth in Section 19.3(b)(ii).

“API” means all Application Programming Interfaces and associated API Documentation provided by Contractor, and as updated from time to time, to allow the Software to integrate with various State and Third Party Software.

“Approved Open-Source Components” means Open-Source Components that the State has approved, either by inclusion in this Contract at award, or as subsequently approved in accordance with the requirements defined herein to be included in or used in connection with any Software developed or provided under this Contract, and are specifically identified in the Statement of Work.

“Approved Third-Party Materials” means Third-Party Materials that the State has approved to be included in or for use in connection with any Software developed or provided under this Contract, and are specifically identified in the Statement of Work. 4

“Authorized Users” means all Persons authorized by the State to access and use the Software under this Contract, subject to the maximum number of users specified in the applicable Statement of Work.

“Background Technology” means all Software, code, data, know-how, ideas, methodologies, processes, specifications, and other technology and related materials in which Contractor owns such Intellectual Property Rights as are necessary for Contractor to grant the rights and licenses set forth in Section 15.1, and for the State (including its licensees, successors and assigns) to exercise such rights and licenses, without violating any right of any Third Party or any Law or incurring any payment obligation to any Third Party. Background Technology must: (a) be identified as Background Technology in the Statement of Work; and (b) have been developed or otherwise acquired by Contractor prior to the date of the RFP.

“Business Day” means a day other than a Saturday, Sunday or other day on which the State is authorized or required by Law to be closed for business.

“Business Owner” is the individual appointed by the end-user agency procuring the software to (a) act as such agency’s representative in all matters relating to the Contract, and (b) co-sign off on the State’s notice of Acceptance for all Software Deliverables and Aggregate Software. The Business Owner will be identified in the Statement of Work.

“Business Requirements Specification” means the specification setting forth the State’s business requirements regarding the features and functionality of the Software, as set forth in the Statement of Work.

“Change” has the meaning set forth in Section 2.2.

“Change Notice” has the meaning set forth in Section 2.2(b).

“Change Proposal” has the meaning set forth in Section 2.2(a).

“Change Request” has the meaning set forth in Section 2.2.

“Confidential Information” has the meaning set forth in Section 23.1.

“Contract” has the meaning set forth in the preamble.

“Contract Administrator” is the individual appointed by each party to (a) administer the terms of this Contract, and (b) approve and execute any Change Notices under this Contract. Each party’s Contract Administrator will be identified in the Statement of Work.

“Contractor” has the meaning set forth in the preamble.

“Contractor’s Bid Response” means the Contractor’s proposal submitted in response to the RFP.

“Contractor Personnel” means all employees of Contractor or any Permitted Subcontractors involved in the performance of Services or providing Work Product under this Contract.

“Deliverables” means all Software Deliverables and all other documents, Work Product, and other materials that Contractor is required to or otherwise does provide to the State under this Contract and

otherwise in connection with any Services, including all items specifically identified or defined as Deliverables in the Statement of Work.

“Derivative Work” means any modification, addition, upgrade, update, or improvement of the Software and any other work constituting a derivative work under the United States Copyright Act, 17 U.S.C. Section 101, et seq.

“Dispute Resolution Procedure” means the procedure for resolving disputes under this Contract as set forth in Section 27.

“Documentation” means all user manuals, operating manuals, technical manuals and any other instructions, specifications, documents and materials, in any form or media, that describe the functionality, installation, testing, operation, use, maintenance, support and technical and other components, features and requirements of any Software.

“DTMB” means the Michigan Department of Technology, Management and Budget.

“Effective Date” has the meaning set forth in the preamble.

“Fees” has the meaning set forth in Section 12.1

“Financial Audit Period” has the meaning set forth in Section 25.1.

“Force Majeure” has the meaning set forth in Section 28.7.

“Harmful Code” means any: (a) virus, trojan horse, worm, backdoor or other software or hardware devices the effect of which is to permit unauthorized access to, or to disable, erase, or otherwise harm, any computer, systems or software; or (b) time bomb, drop dead device, or other software or hardware device designed to disable a computer program automatically with the passage of time or under the positive control of any Person, or otherwise prevent, restrict or impede the State's or any Authorized User's use of such software.

“Implementation Plan” means the schedule included in the Statement of Work setting forth the sequence of events for the performance of Services under the Statement of Work, including the Milestones and Milestone Dates.

“Intellectual Property Rights” means all or any of the following: (a) patents, patent disclosures, and inventions (whether patentable or not); (b) trademarks, service marks, trade dress, trade names, logos, corporate names, and domain names, together with all of the associated goodwill; (c) copyrights and copyrightable works (including computer programs), mask works and rights in data and databases; (d) trade secrets, know-how and other confidential information; and (e) all other intellectual property rights, in each case whether registered or unregistered and including all applications for, and renewals or extensions of, such rights, and all similar or equivalent rights or forms of protection provided by applicable Law in any jurisdiction throughout the world.

“Intended Users” means the users that are intended to use Software or particular features or functions of the Software, as described in the Specifications for such Software.

“Key Personnel” means any Contractor Personnel identified as key personnel in the Statement of Work.

“Law” means any statute, law, ordinance, regulation, rule, code, order, constitution, treaty, common law, judgment, decree, other requirement or rule of law of any federal, state, local or foreign government or political subdivision thereof, or any arbitrator, court, or tribunal of competent jurisdiction.

“Loss or Losses” means all losses, damages, liabilities, deficiencies, claims, actions, judgments, settlements, interest, awards, penalties, fines, costs or expenses of whatever kind, including reasonable attorneys' fees and the costs of enforcing any right to indemnification hereunder and the cost of pursuing any insurance providers.

“Maintenance and Support Schedule” means the schedule attached as Schedule B, setting forth the Support Services, the Support Fees, and the parties’ additional rights and obligations with respect to such services.

“Milestone” means an event or task described in the Implementation Plan under the Statement of Work that must be completed by the corresponding Milestone Date.

“Milestone Date” means the date by which a particular Milestone must be completed as set forth in the Implementation Plan under the Statement of Work.

“Non-Conformity” or “Non-Conformities” means any failure of any: (a) Software or Documentation to conform to the requirements of this Contract (including the Statement of Work) or (b) Software to conform to the requirements of this Contract or the Specifications or Documentation.

“Object Code” means computer programs assembled or compiled in magnetic or electronic binary form on software media, which are readable and useable by machines, but not generally readable by humans without reverse assembly, reverse compiling, or reverse engineering.

“Open-Source Components” means any software component that is subject to any open-source copyright license contract, including any GNU General Public License or GNU Library or Lesser Public License, or other license contract that substantially conforms to the Open Source Initiative’s definition of “open source” or otherwise may require disclosure or licensing to any third party of any source code with which such software component is used or compiled.

“Open-Source License” has the meaning set forth in Section 3.3.

“Operating Environment” means, collectively, the State test platform and environment on, in, or under which Software is intended to be installed and operate, as set forth in the Statement of Work, including such structural, functional and other features, conditions and components as hardware, operating software and system architecture and configuration.

“Permitted Subcontractor” has the meaning set forth in Section 5.4.

“Person” means an individual, corporation, partnership, joint venture, limited liability company, governmental authority, unincorporated organization, trust, association, or other entity.

“Pricing” means any and all fees, rates and prices payable under this Contract, including pursuant to any Schedule or Exhibit hereto.

“Pricing Schedule” means the schedule attached as Schedule C, setting forth the fees, rates and prices payable under this Contract.

“Project Manager” is the individual appointed by each party to (a) monitor and coordinate the day-today activities of this Contract, and (b) in the case of the State, co-sign off on its notice of Acceptance for all Software Deliverables and Aggregate Software. Each party’s Project Manager will be identified in the Statement of Work.

“Representatives” means a party's employees, officers, directors, partners, shareholders, agents, attorneys, successors and permitted assigns.

“RFP” means the State’s request for proposal designed to solicit responses for Services under this Contract.

“Service Level Agreement” means, if applicable, the service level agreement attached as Schedule E to this Contract, setting forth Contractor’s obligations with respect to the hosting, management and operation of the Software.

“Services” means any of the services Contractor is required to or otherwise does provide under this Contract, the Statement of Work, the Maintenance and Support Schedule (if applicable), or the Service Level Agreement (if applicable).

“Site” means the physical location designated by the State in, or in accordance with, this Contract or the Statement of Work for delivery and installation of any Software.

“Software” means the computer program(s), including programming tools, scripts and routines, the Contractor is required to or otherwise does develop or otherwise provide under this Contract, as described more fully in the Statement of Work, including all updates, upgrades, new versions, new releases, enhancements, improvements, and other modifications made or provided under the Support Services. As context dictates, Software may refer to one or more Software Deliverables or Aggregate Software.

“Software Deliverable” means any Software, together with its Documentation, required to be delivered as set forth in the Statement of Work.

“Source Code” means the human readable source code of the Software to which it relates, in the programming language in which such Software was written, together with all related flow charts and technical documentation, including a description of the procedure for generating object code, all of a level sufficient to enable a programmer reasonably fluent in such programming language to understand, operate, support, maintain and develop modifications, upgrades, updates, enhancements, improvements and new versions of, and to develop computer programs compatible with, such Software.

“Specifications” means, for any Software, the specifications collectively set forth in the Business Requirements Specification and Technical Specification, together with any other specifications set forth in the Statement of Work or any attachment thereto.

“State” means the State of Michigan.

“State Data” has the meaning set forth in Section 22.1.

“State Materials” means all materials and information, including documents, data, know-how, ideas, methodologies, specifications, software, content and technology, in any form or media, directly or indirectly provided or made available to Contractor by or on behalf of the State in connection with this Contract, whether or not the same: (a) are owned by the State, a Third Party or in the public domain; or (b) qualify for or are protected by any Intellectual Property Rights.

“State Resources” has the meaning set forth in Section 7.1.

“Statement of Work” means the statement of work attached as Schedule A to the Contract.

“Stop Work Order” has the meaning set forth in Section 17.

“Support Fees” means the fees, if any, payable by the State for the Support Services as required under the Maintenance and Support Schedule (as applicable) or the Service Level Agreement (as applicable.

“Support Commencement Date” means, with respect to any Software, the date on which the Warranty Period for such Software expires or such other date as may be set forth in the Maintenance and Support Schedule, the Service Level Agreement, or the Statement of Work.

“Support Services” means the software maintenance and support services Contractor is required to or otherwise does provide to the State under the Maintenance and Support Schedule (if applicable) or the Service Level Agreement (if applicable).

“Technical Specification” means, with respect to any Software, the document setting forth the technical specifications for such Software and included in the Statement of Work.

“Term” has the meaning set forth in the preamble.

“Testing Period” has the meaning set forth in Section 10.1.

“Third Party” means any Person other than the State or Contractor.

“Third-Party Materials” means any materials and information, including documents, data, know-how, ideas, methodologies, specifications, software, content, and technology, in any form or media, in which any Person other than the State or Contractor owns any Intellectual Property Right, but excluding Open-Source Components.

“Transition Period” has the meaning set forth in Section 16.3.

“Transition Responsibilities” has the meaning set forth in Section 16.3.

“Unauthorized Removal” has the meaning set forth in Section 5.3(b).

“Unauthorized Removal Credit” has the meaning set forth in Section 5.3(c).

“User Data” means all data, information and other content of any type and in any format, medium or form, whether audio, visual, digital, screen, GUI or other, that is input, uploaded to, placed into or collected, stored, processed, generated or output by any device, system or network by or on behalf of the State, including any and all works, inventions, data, analyses and other information and materials resulting from any use of the Software by or on behalf of the State under this Contract, except that User Data does not include the Software or data, information or content, including any GUI, audio, visual or digital or other display or output, that is generated automatically upon executing the Software without additional user input.

“Warranty Period” means, for any Software, unless otherwise specified in the Statement of Work, the ninety (90) calendar-day period commencing (a) in the case of Aggregate Software, upon the State’s Acceptance; and (b) in the case of any updates, upgrades, new versions, new releases, enhancements and other modifications to previously-Accepted Aggregate Software, upon the State’s receipt of such modification.

“Work Product” means all Software, API, Documentation, Specifications, and other documents, work product and related materials, that Contractor is required to, or otherwise does, provide to the State under this Contract, together with all ideas, concepts, processes, and methodologies developed in connection with this Contract whether or not embodied in this Contract.

2. Statement of Work. Contractor shall provide Services and Deliverables pursuant to the Statement of Work. The terms and conditions of this Contract will apply at all times to the Statement of Work. The State shall have the right to terminate the Statement of Work as set forth in Section 16. The Parties acknowledge that time is of the essence with respect to the obligations under the Statement of Work and agrees that prompt and timely support and performance of all such obligations in accordance with this Contract and the Statement of Work (including the Implementation Plan and all Milestone Dates) is strictly required.

2.1 Statement of Work Requirements. The Statement of Work will include the following:

(a) names and contact information for Contractor’s Contract Administrator, Project Manager and Key Personnel;

(b) names and contact information for the State’s Contract Administrator, Project Manager and Business Owner;

(c) a detailed description of the Services to be provided under this Contract, including any training obligations of Contractor;

(d) a detailed description of the Software and other Work Product to be developed or otherwise provided under this Contract, including the:

(i) Business Requirements Specification;

(ii) Technical Specification; and

(iii) a description of the Documentation to be provided;

(e) an Implementation Plan, including all Milestones, the corresponding Milestone Dates and the parties’ respective responsibilities under the Implementation Plan;

(f) the due dates for payment of Fees and any invoicing requirements, including any Milestones on which any such Fees are conditioned, and such other information as the parties deem necessary;

(g) disclosure of all Background Technology, Approved Third-Party Materials, Approved Open- Source Components (each identified on a separate exhibit to the Statement of Work), in each case accompanied by such related documents as may be required by this Contract;

(h) description of all liquidated damages associated with this Contract; and

(i) a detailed description of all State Resources required to complete the Implementation Plan.

2.2 Change Control Process. The State may at any time request in writing (each, a “Change Request”) changes to the Statement of Work, including changes to the Services, Work Product, Implementation Plan, or any Specifications (each, a “Change”). Upon the State’s submission of a Change Request, the parties will evaluate and implement all Changes in accordance with this Section 2.2.

(a) As soon as reasonably practicable, and in any case within twenty (20) Business Days following receipt of a Change Request, Contractor will provide the State with a written proposal for implementing the requested Change (“Change Proposal”), setting forth:

(i) a written description of the proposed Changes to any Services, Work Product, or Deliverables;

(ii) an amended Implementation Plan reflecting: (A) the schedule for commencing and completing any additional or modified Services, Work Product, or Deliverables; and (B) the effect of such Changes, if any, on completing any other Services or Work Product under the Statement of Work;

(iii) any additional Third-Party Materials, Open-Source Components, and State Resources Contractor deems necessary to carry out such Changes; and

(iv) any increase or decrease in Fees resulting from the proposed Changes, which increase or decrease will reflect only the increase or decrease in time and expenses Contractor requires to carry out the Change.

(b) Within thirty (30) Business Days following the State’s receipt of a Change Proposal, the State will by written notice to Contractor, approve, reject, or propose modifications to such Change Proposal. If the State proposes modifications, Contractor must modify and re-deliver the Change Proposal reflecting such modifications, or notify the State of any disagreement, in which event the parties will negotiate in good

faith to resolve their disagreement. Upon the State’s approval of the Change Proposal or the parties’ agreement on all proposed modifications, as the case may be, the parties will execute a written agreement to the Change Proposal (“Change Notice”), which Change Notice will be signed by the State’s Contract Administrator and will constitute an amendment to the Statement of Work to which it relates; and

(c) If the parties fail to enter into a Change Notice within fifteen (15) Business Days following the State’s response to a Change Proposal, the State may, in its discretion:

(i) require Contractor to perform the Services under the Statement of Work without the Change;

(ii) require Contractor to continue to negotiate a Change Notice;

(iii) initiate a Dispute Resolution Procedure; or

(iv) notwithstanding any provision to the contrary in the Statement of Work, terminate this Contract under Section 16.2.

(d) No Change will be effective until the parties have executed a Change Notice. Except as the State may request in its Change Request or otherwise in writing, Contractor must continue to perform its obligations in accordance with the Statement of Work pending negotiation and execution of a Change Notice. Contractor will use its best efforts to limit any delays or Fee increases from any Change to those necessary to perform the Change in accordance with the applicable Change Notice. Each party is responsible for its own costs and expenses of preparing, evaluating, negotiating, and otherwise processing any Change Request, Change Proposal, and Change Notice.

(e) The performance of any functions, activities, tasks, obligations, roles and responsibilities comprising the Services as described in this Contract are considered part of the Services and, thus, will not be considered a Change. This includes the delivery of all Deliverables in accordance with their respective Specifications, and the diagnosis and correction of Non-Conformities discovered in Deliverables prior to their Acceptance by the State or, subsequent to their Acceptance by the State, as necessary for Contractor to fulfill its associated warranty requirements and its Support Services under this Contract.

(f) Contractor may, on its own initiative and at its own expense, prepare and submit its own Change Request to the State. However, the State will be under no obligation to approve or otherwise respond to a Change Request initiated by Contractor.

3. Software. Contractor will design, develop, create, test, deliver, install, configure, integrate, customize and otherwise provide and make fully operational Software as described in the Statement of Work on a timely and professional basis in accordance with all terms, conditions, and Specifications set forth in this Contract and the Statement of Work.

3.1 Software Specifications. Contractor will ensure all Software complies with the Specifications. Contractor will provide all Software to the State in both Object Code and Source Code form.

3.2 Third-Party Materials.

(a) Contractor will not include in any Software, and operation of all Software in accordance with its Specifications and Documentation will not require, any Third-Party Materials, other than Approved Third- Party Materials, which must be specifically approved by the State and identified and described in the Statement of Work, and will be licensed to the State in accordance with Section 15.3.

(b) Contractor must secure, at its sole cost and expense, all necessary rights, licenses, consents, approvals, and authorizations necessary for the State to use, perpetually and throughout the universe, all Approved Third-Party Materials as incorporated in or otherwise used in conjunction with Software as specified in the Statement of Work or elsewhere in this Contract.

3.3 Open-Source Components. Contractor will not include in any Software, and operation of all Software in accordance with its Specifications and Documentation will not require the use of, any Open-Source Components, other than Approved Open-Source Components, which must be specifically approved by the State and identified and described in the Statement of Work, and for which the relevant open-source license(s) (each, an “Open-Source License”) are attached as exhibits to the Statement of Work. Contractor will provide the State with the Source Code for Approved Open-Source Components in accordance with the terms of the Open-Source License(s) at no cost to the State.

4. Documentation. Prior to or concurrently with the delivery of any Software, or by such earlier date as may be specified in the Implementation Plan for such Software, Contractor will provide the State with complete and accurate Documentation for such Software. Where the Statement of Work requires or permits delivery of Software in two or more phases, Contractor will also provide the State with integrated Documentation for the Aggregate Software upon its delivery.

4.1 Adequacy of Documentation. All Documentation must include all such information as may be reasonably necessary for the effective installation, testing, use, support, and maintenance of the applicable Software by the Intended User, including the effective configuration, integration, and systems administration of the Software and performance of all other functions set forth in the Specifications.

4.2 Documentation Specifications. Contractor will provide all Documentation in electronic form, in such formats and media as are set forth in the Statement of Work, or as the State may otherwise reasonably request in writing.

4.3 Third-Party Documentation. Other than Documentation for Approved Third-Party Materials and Approved Open-Source Components, no Documentation will consist of or include Third-Party Materials. To the extent Documentation consists of or includes Third-Party Materials, Contractor must secure, at its sole cost and expense, all rights, licenses, consents, approvals and authorizations specified in Section 15.3 with respect to Approved Third-Party Materials.

5. Performance of Services. Contractor will provide all Services and Work Product in a timely, professional and workmanlike manner and in accordance with the terms, conditions, and Specifications set forth in this Contract and the Statement of Work.

5.1 Contractor Personnel.

(a) Contractor is solely responsible for all Contractor Personnel and for the payment of their compensation, including, if applicable, withholding of income taxes, and the payment and withholding of social security and other payroll taxes, unemployment insurance, workers’ compensation insurance payments and disability benefits.

(b) Prior to any Contractor Personnel performing any Services, Contractor will:

(i) ensure that such Contractor Personnel have the legal right to work in the United States;

(ii) require such Contractor Personnel to execute written agreements, in form and substance acceptable to the State, that bind such Contractor Personnel to confidentiality provisions that are at least as protective of the State’s information (including all Confidential Information) as those contained in this Contract and Intellectual Property Rights provisions that grant the State rights in the Work Product consistent with the provisions of Section 14.1 and, upon the State's request, provide the State with a copy of each such executed Contract; and

(iii) upon request, perform background checks on all Contractor Personnel prior to their assignment. The scope is at the discretion of the State and documentation must be provided as requested. Contractor is responsible for all costs associated with the requested background checks. The State, in its sole discretion, may also perform background checks on Contractor Personnel.

(c) Contractor and all Contractor Personnel will comply with all rules, regulations, and policies of the State that are communicated to Contractor in writing, including security procedures concerning systems and data and remote access, building security procedures, including the restriction of access by the State to certain areas of its premises or systems, and general health and safety practices and procedures.

(d) The State reserves the right to require the removal of any Contractor Personnel found, in the judgment of the State, to be unacceptable. The State’s request must be written with reasonable detail outlining the reasons for the removal request. Replacement personnel for the removed person must be fully qualified for the position. If the State exercises this right, and Contractor cannot immediately replace the removed personnel, the State agrees to negotiate an equitable adjustment in schedule or other terms that may be affected by the State’s required removal.

5.2 Contractor’s Project Manager. Throughout the Term of this Contract, Contractor must maintain a Contractor employee acceptable to the State to serve as Contractor’s Project Manager, who will be considered Key Personnel of Contractor. Contractor’s Project Manager will be identified in the Statement of Work.

(a) Contractor’s Project Manager must:

(i) have the requisite authority, and necessary skill, experience, and qualifications, to perform in such capacity;

(ii) be responsible for overall management and supervision of Contractor’s performance under this Contract; and

(iii) be the State’s primary point of contact for communications with respect to this Contract, including with respect to giving and receiving all day-to-day approvals and consents.

(b) Contractor’s Project Manager must attend all regularly scheduled meetings as set forth in the Implementation Plan, and will otherwise be available as set forth in the Statement of Work.

(i) the State requests in writing the removal of Contractor’s Project Manager;

(ii) the State consents in writing to any removal requested by Contractor in writing;

(iii) Contractor’s Project Manager ceases to be employed by Contractor, whether by resignation, involuntary termination or otherwise.

(d) Contractor will promptly replace its Project Manager on the occurrence of any event set forth in Section 5.2(c). Such replacement will be subject to the State's prior written approval.

5.3 Contractor’s Key Personnel.

(a) The State has the right to recommend and approve in writing the initial assignment, as well as any proposed reassignment or replacement, of any Key Personnel. Before assigning an individual to any Key Personnel position, Contractor will notify the State of the proposed assignment, introduce the individual to the State’s Project Manager, and provide the State with a resume and any other information about the individual reasonably requested by the State. The State reserves the right to interview the individual before granting written approval. In the event the State finds a proposed individual unacceptable, the State will provide a written explanation including reasonable detail outlining the reasons for the rejection.

(b) Contractor will not remove any Key Personnel from their assigned roles on this Contract without the prior written consent of the State. The Contractor’s removal of Key Personnel without the prior written consent of the State is an unauthorized removal (“Unauthorized Removal”). An Unauthorized Removal does not include replacing Key Personnel for reasons beyond the reasonable control of Contractor, including illness, disability, leave of absence, personal emergency circumstances, resignation, or for cause termination of the Key Personnel’s employment. Any Unauthorized Removal, which has not been cured within ten (10) business days, as defined in 5.3(a), may be considered by the State to be a material breach of this Contract, in respect of which the State may elect to terminate this Contract for cause under Section 16.1.

(c) It is further acknowledged that an Unauthorized Removal will interfere with the timely and proper completion of this Contract, to the loss and damage of the State, and that it would be impracticable and extremely difficult to fix the actual damage sustained by the State as a result of any Unauthorized

Removal. Therefore, Contractor and the State agree that in the case of any Unauthorized Removal in respect of which the State does not elect to exercise its rights under Section 16.1, Contractor will issue to the State the corresponding credits set forth below (each, an “Unauthorized Removal Credit”):

(i) For the Unauthorized Removal of any Key Personnel designated in the applicable Statement of Work, the credit amount will be $30,000 per individual if Contractor identifies a replacement approved by the State and assigns the replacement to shadow the Key Personnel who is leaving for a period of at least 30 calendar days before the Key Personnel’s removal.

(ii) If Contractor fails to assign a replacement to shadow the removed Key Personnel for at least 30 calendar days, in addition to the $30,000 credit specified above, Contractor will credit the State $1,000 per calendar day for each day of the 30 calendar-day shadow period that the replacement Key Personnel does not shadow the removed Key Personnel, up to $30,000 maximum per individual. The total Unauthorized Removal Credits that may be assessed per Unauthorized Removal and failure to provide 30 calendar days of shadowing will not exceed $60,000 per individual.

(d) Contractor acknowledges and agrees that each of the Unauthorized Removal Credits assessed under Subsection (c) above: (i) is a reasonable estimate of and compensation for the anticipated or actual harm to the State that may arise from the Unauthorized Removal, which would be impossible or very difficult to accurately estimate; and (ii) may, at the State’s option, be credited or set off against any Fees or other charges payable to Contractor under this Contract.

5.4 Subcontractors. Contractor will not, without the prior written approval of the State, which consent will not be unreasonably withheld, engage any Third Party to perform Services (including to create any Work Product). The State’s approval of any such Third Party (each approved Third Party, a “Permitted Subcontractor”) does not relieve Contractor of its representations, warranties or obligations under this Contract. Without limiting the foregoing, Contractor will:

(a) be responsible and liable for the acts and omissions of each such Permitted Subcontractor (including such Permitted Subcontractor's employees who, to the extent providing Services or creating Work Product, shall be deemed Contractor Personnel) to the same extent as if such acts or omissions were by Contractor or its employees;

(b) name the State a third party beneficiary under Contractor’s Contract with each Permitted Subcontractor with respect to the Services and Work Product;

(c) be responsible for all fees and expenses payable to, by or on behalf of each Permitted Subcontractor in connection with this Contract, including, if applicable, withholding of income taxes, and the payment and withholding of social security and other payroll taxes, unemployment insurance, workers' compensation insurance payments and disability benefits; and

(d) prior to the provision of Services or creation of Work Product by any Permitted Subcontractor:

(i) obtain from such Permitted Subcontractor confidentiality, work-for-hire and intellectual property rights assignment agreements, in form and substance acceptable by the State, giving the State rights consistent with those set forth in Section 14.1 and Section 22 and, upon request, provide the State with a fully-executed copy of each such contract; and

(ii) with respect to all Permitted Subcontractor employees providing Services or Work Product, comply with its obligations under Section 5.1(b); and

(e) notify the State of the location of the Permitted Subcontractor and indicate if it is located within the continental United States.

6. Data Privacy and Information Security.

6.1 Undertaking by Contractor. Without limiting Contractor’s obligation of confidentiality as further described, Contractor is responsible for establishing and maintaining a data privacy and information security program, including physical, technical, administrative, and organizational safeguards, that is designed to: (a) ensure the security and confidentiality of the State Data; (b) protect against any anticipated threats or hazards to the security or integrity of the State Data; (c) protect against unauthorized disclosure, access to, or use of the State Data; (d) ensure the proper disposal of State Data; and (e) ensure that all Contractor Representatives comply with all of the foregoing. In no case will the safeguards of Contractor’s data privacy and information security program be less stringent than the safeguards used by the State, and Contractor must at all times comply with all applicable State IT policies, standards, and procedures (“PSP”), of which the publicly available PSPs are located at: https://www.michigan.gov/dtmb/0,5552,7-358-82547_56579_56755---,00.html.

6.2 Acceptable Use Policy. To the extent that Contractor has access to the State’s computer system, Contractor must comply with the State’s Acceptable Use Policy, see https://www.michigan.gov/documents/dtmb/1340.00.01_Acceptable_Use_of_Information_Technology_Standard_ 458958_7.pdf. All Contractor Personnel will be required, in writing, to agree to the State’s Acceptable Use Policy before accessing the State’s system. The State reserves the right to terminate Contractor’s access to the State’s system if a violation occurs.

6.3 Security Accreditation Process. If requested by the State, Contractor must assist the State with its security accreditation process through the development, completion and ongoing updating of a system security plan using the State’s automated governance, risk and compliance (GRC) platform

6.4 Right of Audit by the State. Without limiting any other audit rights of the State, the State has the right to review Contractor’s data privacy and information security program prior to the commencement of Services and from time to time during the term of this Contract. During the providing of Services, on an ongoing basis from time to time and without notice, the State, at its own expense, is entitled to perform, or to have performed, an on- site audit of Contractor’s data privacy and information security program. In lieu of an on-site audit, upon request by the State, Contractor agrees to complete, within forty-five (45) calendar days of receipt, an audit questionnaire provided by the State regarding Contractor’s data privacy and information security program.

6.5 Audit Findings. With respect to State Data, Contractor must implement any required safeguards as identified by the State or by any audit of Contractor’s data privacy and information security program.

6.6 State’s Right to Termination for Deficiencies. The State reserves the right, at its sole election, to immediately terminate this Contract or the Statement of Work without limitation and without liability if the State determines that Contractor fails or has failed to meet its obligations under this Section 6 and has proven unable to cure said deficiencies within a time period that is acceptable to the State

6.7 Security Requirements for Externally Hosted Software. If the Operating Environment for the Software is externally hosted by Contractor or a subcontractor, Contractor shall comply with the security requirements set forth in Schedule D to this Contract.

7. State Obligations.

7.1 State Resources and Access. The State is responsible for:

(a) providing the State Materials and such other resources as may be specified in the Statement of Work (collectively, “State Resources”);

(b) collaborating with the Contractor to facilitate the expedited flow of documentation, information, and approvals required for the Contractor to complete its duties as defined in this Contract; and

(c) if the Software is internally hosted on State systems, providing Contractor Personnel with such access to the Site(s) and Operating Environment as is necessary for Contractor to perform its obligations on a timely basis as set forth in the Statement of Work.

7.2 State Project Manager. Throughout the Term of this Contract, the State will maintain a State employee to serve as the State’s Project Manager under this Contract. The State’s Project Manager will be identified in the Statement of Work.

8. Pre-Delivery Testing.

8.1 Testing By Contractor. Before delivering and installing any Software Deliverable, Contractor must:

(a) test the Software component of such Software Deliverable to confirm that it is fully operable, meets all applicable Specifications and will function in accordance with the Specifications and Documentation when properly installed in the Operating Environment;

(b) scan such Software Deliverable using industry standard scanning software and definitions to confirm it is free of Harmful Code;

(d) prepare, test and, as necessary, revise the Documentation component of the Software Deliverable to confirm it is complete and accurate and conforms to all requirements of this Contract.

8.2 State Participation. The State has the right to be present for all pre-installation testing. Contractor must give the State at least seven (7) calendar days’ prior notice of all such testing.

9. Delivery and Installation.

9.1 Delivery. Contractor will deliver each Deliverable, and install all Software, on or prior to the applicable Milestone Date in accordance with the delivery criteria set forth in the Statement of Work. Contractor will deliver each Software Deliverable, including complete Documentation in compliance with Section 4, and the applicable Source Code. No Software Deliverable will be deemed to have been delivered or installed unless it complies with the preceding sentence.

9.2 Site Preparation. If the Operating Environment for the Software is externally hosted by Contractor or a subcontractor, Contractor is responsible for ensuring the relevant Operating Environment is set up and in working order to allow Contractor to deliver and install the Software on or prior to the applicable Milestone Date. Contractor will provide the State with such notice as is specified in the Statement of Work, prior to delivery of the Software to give the State sufficient time to prepare for Contractor’s delivery and installation of the Software. If the State is responsible for Site preparation, Contractor will provide such assistance as the State requests to complete such preparation on a timely basis.

10. Acceptance Testing; Acceptance.

10.1 Acceptance Testing.

(a) Unless otherwise specified in the Statement of Work, upon installation of each Software Deliverable, Acceptance Tests will be conducted as set forth in this Section 10.1 to ensure the Software Deliverable, including all Software and Documentation, conforms to the requirements of this Contract, including the applicable Specifications and, in the case of the Software, the Documentation.

(b) All Acceptance Tests will take place at the designated Site(s) in the Operating Environment described in the Statement of Work for the Software Deliverable, commence on the Business Day following installation of such Software Deliverable and be conducted diligently for up to ten (10) Business Days, or such other period as may be set forth in the Statement of Work (the “Testing Period”). Acceptance Tests will be conducted by the party responsible as set forth in the Statement of Work or, if the Statement of Work does not specify, the State, provided that:

(i) for Acceptance Tests conducted by the State, if requested by the State, Contractor will make suitable Contractor Personnel available to observe or participate in such Acceptance Tests; and

(ii) for Acceptance Tests conducted by Contractor, the State has the right to observe or participate in all or any part of such Acceptance Tests.

Contractor is solely responsible for all costs and expenses related to Contractor’s performance of, participation in, and observation of Acceptance Testing.

(c) Upon delivery and installation of the Aggregate Software, including any API, under the Statement of Work, additional Acceptance Tests will be performed on the Aggregate Software as a whole to ensure full operability, integration, and compatibility among all elements of the Aggregate Software

(“Integration Testing”). Integration Testing is subject to all procedural and other terms and conditions set forth in Section 10.1, Section 10.3, and Section 10.4.

(d) The State may suspend Acceptance Tests and the corresponding Testing Period by written notice to Contractor if the State discovers a material Non-Conformity in the tested Software Deliverable or part or feature of such Software Deliverable. In such event, Contractor will immediately, and in any case within ten (10) Business Days, correct such Non-Conformity, whereupon the Acceptance Tests and Testing Period will resume for the balance of the Testing Period.

10.2 Notices of Final Completion, Non-Conformities, and Final Acceptance. Within fifteen (15) Business Days following the completion of any Acceptance Tests, including any Integration Testing, the party responsible for conducting the tests will prepare and provide to the other party written notice of the completion of the tests. Such notice must include a report describing in reasonable detail the tests conducted and the results of such tests, including any uncorrected Non-Conformity in the tested Software Deliverables.

(a) If such notice is provided by either party and identifies any Non-Conformities, the parties’ rights, remedies, and obligations will be as set forth in Section 10.3 and Section 10.4.

(b) If such notice is provided by the State, is signed by the State’s Business Owner and Project Manager, and identifies no Non-Conformities, such notice constitutes the State's Acceptance of such Software Deliverable or Aggregate Software.

(c) If such notice is provided by Contractor and identifies no Non-Conformities, the State will have thirty (30) Business Days to use such Software Deliverable in the Operating Environment and determine, in the exercise of its sole discretion, whether it is satisfied that such Software Deliverable or Aggregate Software contains no Non-Conformities, on the completion of which the State will, as appropriate:

(i) notify Contractor in writing of Non-Conformities the State has observed in the Software Deliverable or, in the case of Integration Testing, Aggregate Software, and of the State’s non-acceptance thereof, whereupon the parties’ rights, remedies and obligations will be as set forth in Section 10.3 and Section 10.4; or

(ii) provide Contractor with a written notice of its Acceptance of such Software Deliverable or Aggregate Software, which must be signed by the State’s Business Owner and Project Manager.

10.3 Failure of Acceptance Tests. If Acceptance Tests identify any Non-Conformities, Contractor, at Contractor’s sole cost and expense, will remedy all such Non-Conformities and re-deliver the Software Deliverables, in accordance with the requirements set forth in the Statement of Work. Redelivery will occur as promptly as commercially possible and, in any case, within thirty (30) Business Days following, as applicable, Contractor’s:

(a) completion of such Acceptance Tests, in the case of Acceptance Tests conducted by Contractor; or

(b) receipt of the State’s notice under Section 10.2(a) or Section 10.2(c)(i), identifying any Non-Conformities.

10.4 Repeated Failure of Acceptance Tests. If Acceptance Tests identify any Non-Conformity, which is due solely to Contractor’s performance, in any Software Deliverable after a second or subsequent delivery of such Software Deliverable, or Contractor fails to re-deliver the Software Deliverable on a timely basis, the State may, in its sole discretion, by written notice to Contractor:

(a) continue the process set forth in this Section 10;

(b) accept the Software Deliverable as a nonconforming deliverable, in which case the Fees Such Software Deliverable will be reduced equitably to reflect the value of the Software Deliverable as received relative to the value of the Software Deliverable had it conformed; or

(c) deem the failure to be a non-curable material breach of this Contract and the Statement of Work and terminate this Contract for cause in accordance with Section 16.1.

10.5 Acceptance. Acceptance (“Acceptance”) of each Software Deliverable (subject, where applicable, to the State’s right to Integration Testing) and Aggregate Software will occur on the date that is the earliest of the State’s delivery of a notice accepting such Software Deliverable under Section 10.2(b), or Section 10.2(c)(ii).

11. Training; Maintenance and Support; Hosting.

11.1 Training. With respect to all Software, Contractor will provide the State with initial training as set forth in the Statement of Work at the rates set forth in the Pricing Schedule. The State may request, and if so requested, Contractor must provide on a timely basis, additional training at the rates specified in the Pricing Schedule.

11.2 Support Services for On-Premise Software. If the Operating Environment for the Software is internally hosted by the State, Contractor will provide the State with the Support Services described in the Maintenance and Support Schedule attached as Schedule B to this Contract. Such Support Services will be provided:

(a) Free of charge during the Warranty Period, it being acknowledged and agreed that the Fees includes full consideration for such Services during such period.

(b) Thereafter, for so long as the State elects to receive Support Services for the Software, in consideration of the State's payment of Support as determined in accordance with the rates set forth in the Pricing Schedule.

11.3 Support Services for Externally Hosted Software. If the Operating Environment for the Software is externally hosted by Contractor or a subcontractor, Contractor shall provide the State with the Support Services described in the Service Level Agreement attached as Schedule E to this Contract. Such Support Services shall be provided:

(a) Free of charge during the Warranty Period, it being acknowledged and agreed that the Fees includes full consideration for such Services during such period.

(b) Thereafter, for so long as the State elects to receive Support Services for the Software, in consideration of the State's payment of Support Fees as determined in accordance with the rates set forth in the Pricing Schedule

11.4 Hosting. If the Operating Environment for the Software is externally hosted by Contractor or a subcontractor, Contractor will maintain the Availability Requirement and the Support Service Level Requirement set forth in the Service Level Agreement attached as Schedule E to this Contract.

12. Fees.

12.1 Fees. Subject to all terms and conditions set forth in this Section 12 and Contractor’s performance of Services to the State’s satisfaction and the State’s Acceptance of the applicable Deliverables, the State will pay the fees set forth in the Statement of Work and Pricing Schedule (“Fees”).

12.2 Firm Pricing. The Pricing set forth in the Pricing Schedule is firm and may not be modified during the Term.

13. Invoices and Payment.

13.1 Invoices. Contractor will invoice the State for Fees in accordance with the requirements set forth in the Statement of Work, including any requirements that condition the rendering of invoices and the payment of Fees upon the successful completion of Milestones. Contractor must submit each invoice via such delivery means and to such address as are specified by the State in the Statement of Work. Each separate invoice must:

(a) clearly identify the Contract to which it relates, in such manner as is required by the State;

(b) list each Fee item separately;

(c) include sufficient detail for each line item to enable the State to satisfy its accounting and charge-back requirements;

(d) for Fees determined on a time and materials basis, report details regarding the number of hours performed during the billing period, the skill or labor category for such Contractor Personnel and the applicable hourly billing rates; and

(e) include such other information as may be required by the State as set forth in the Statement of Work; and

(f) itemized invoices must be submitted to [email protected].

13.2 Payment. Invoices are due and payable by the State, in accordance with the State’s standard payment procedures as specified in 1984 Public Act no. 279, MCL 17.51, et seq., within forty-five (45) calendar days after receipt, provided the State determines that the invoice was properly rendered. The State will only disburse payments under this Contract through Electronic Funds Transfer (EFT). Contractor must register with the State at http://www.michigan.gov/SIGMAVSS to receive electronic fund transfer payments. If Contractor does not register, the State is not liable for failure to provide payment.

13.3 Taxes. The State is exempt from State sales tax for direct purchases and may be exempt from federal excise tax, if Services or Deliverables purchased under this Contract are for the State’s exclusive use.

13.4 Payment Disputes. The State may withhold from payment any and all payments and amounts the State disputes in good faith, pending resolution of such dispute, provided that the State:

(a) timely renders all payments and amounts that are not in dispute;

(b) notifies Contractor of the dispute prior to the due date for payment, specifying in such notice:

(i) the amount in dispute; and

(ii) the reason for the dispute set out in sufficient detail to facilitate investigation by Contractor and resolution by the parties;

(d) promptly pays any amount determined to be payable by resolution of the dispute.

13.5 Contractor shall not withhold any Services or fail to perform any obligation hereunder by reason of the State's good faith withholding of any payment or amount in accordance with this Section 13.4 or any dispute arising therefrom.

13.6 Right of Set Off. Without prejudice to any other right or remedy it may have, the State reserves the right to set off at any time any amount owing to it by Contractor against any amount payable by the State to Contractor under this Contract.

13.7 Payment Does Not Imply Acceptance. The making of any payment by the State, or Contractor’s receipt of payment, will in no way affect the responsibility of Contractor to perform the Services in accordance with this Contract, and will not imply the State’s acceptance of any Services or Deliverables or the waiver of any warranties or requirements of this Contract.

13.8 Support Not to be Withheld or Delayed. Contractor will not withhold, delay, or fail to perform any Services or obligations under this Contract by reason of the State’s good faith withholding of any payment or amount in accordance with this Section 13.

14. Intellectual Property Rights.

14.1 State Ownership of Work Product. Except as set forth in Section 14.3, the State is and will be the sole and exclusive owner of all right, title, and interest in and to all Work Product, including all Intellectual Property Rights. In furtherance of the foregoing, subject to Section 14.3:

(a) Contractor will create all Work Product as work made for hire as defined in Section 101 of the Copyright Act of 1976; and

(b) to the extent any Work Product or Intellectual Property Rights do not qualify as, or otherwise fails to be, work made for hire, Contractor hereby:

(i) assigns, transfers, and otherwise conveys to the State, irrevocably and in perpetuity, throughout the universe, all right, title, and interest in and to such Work Product, including all Intellectual Property Rights; and

(ii) irrevocably waives any and all claims Contractor may now or hereafter have in any jurisdiction to so-called “moral rights” or rights of droit moral with respect to the Work Product.

14.2 Further Actions. Contractor will, and will cause the Contractor Personnel to, take all appropriate action and execute and deliver all documents, necessary or reasonably requested by the State to effectuate any of the provisions or purposes of Section 14.1, or otherwise as may be necessary or useful for the State to prosecute, register, perfect, record, or enforce its rights in or to any Work Product or any Intellectual Property Right therein. Contractor hereby appoints the State as Contractor’s attorney-in-fact with full irrevocable power and authority to take any such actions and execute any such documents if Contractor refuses, or within a period deemed reasonable by the State otherwise fails, to do so.

14.3 Background Technology, Approved Third-Party Materials, and Open-Source Components.

(a) Contractor is and will remain the sole and exclusive owner of all right, title, and interest in and to the Background Technology, including all Intellectual Property Rights therein, subject to the license granted in Section 15.1.

(b) Ownership of all Approved Third-Party Materials, and all Intellectual Property Rights therein, is and will remain with its respective owners, subject to any express licenses or sublicenses granted to the State under this Contract.

(c) Ownership of all Open-Source Components, and all Intellectual Property Rights therein, is and will remain with its respective owners, subject to the State’s rights under the applicable Open-Source Licenses.

14.4 State Materials. The State will remain the sole and exclusive owners of all right, title, and interest in and to State Materials, including all Intellectual Property Rights therein. Contractor will have no right or license to, and will not, use any State Materials except solely during the Term of this Contract for which they are provided to the extent necessary to perform the Services and provide the Work Product to the State. All other rights in and to the State Materials are expressly reserved by the State.

15. Licenses.

15.1 Background Technology License. Contractor hereby grants to the State such rights and licenses with respect to the Background Technology that will allow the State to use and otherwise exploit perpetually throughout the universe for all or any purposes whatsoever the Work Product, to the same extent as if the State owned the Background Technology, without incurring any fees or costs to Contractor (other than the Fees set

forth under this Contract) or any other Person in respect of the Background Technology. In furtherance of the foregoing, such rights and licenses will:

(a) be irrevocable, perpetual, fully paid-up and royalty-free;

(b) include the rights to use, reproduce, perform (publicly or otherwise), display (publicly or otherwise), modify, improve, create Derivative Works of, distribute, import, make, have made, sell and offer to sell the Background Technology, including all such modifications, improvements and Derivative Works thereof, solely as part of, or as necessary to use and exploit, the Work Product; and

(c) be freely assignable and sublicensable, in each case solely in connection with the assignment or licensing of the Work Product or any portion, modification, or Derivative Work thereof, and only to the extent necessary to allow the assignee or sublicensee, as the case may be, to use and exploit the Work Product or portion, modification, improvement, or Derivative Work thereof.

15.2 State Materials. The State hereby grants to Contractor the limited, royalty-free, non-exclusive right and license to State Materials solely as necessary to incorporate such State Materials into, or otherwise use such State Materials in connection with creating, the Work Product. The term of such license will commence upon the State’s delivery of the State Materials to Contractor, and will terminate upon the State’s acceptance or rejection of the Work Product to which the State Materials relate. Subject to the foregoing license, the State reserves all rights in the State Materials. All State Materials are considered Confidential Information of the State.

15.3 Approved Third-Party Materials.

(a) Prior to the delivery date for any Deliverables under the Statement of Work, Contractor will secure for the State, at Contractor’s sole cost and expense, such rights, licenses, consents and approvals for any Approved Third-Party Materials, that will allow the State to use and otherwise exploit perpetually throughout the universe for all or any purposes whatsoever the Work Product, to the same extent as if the State owned the Approved Third-Party Materials, without incurring any fees or costs to any Third-Party (other than the Fees set forth under this Contract)in respect of the Approved Third-Party Materials.

(b) All royalties, license fees, or other consideration payable in respect of such licenses are included in the Fees specified in the Statement of Work. Any additional amounts will be the sole responsibility of Contractor.

(c) Contractor acknowledges that the State cannot indemnify any third parties, including but not limited to any third-party software providers that provide Third-Party Materials, and that notwithstanding anything to the contrary contained in any third-party software license agreement or end user license agreement, the State will not indemnify any third-party software provider for any reason whatsoever.

15.4 Open-Source Components. Any use of the Open-Source Components by the State will be governed by, and subject to, the terms and conditions of the applicable Open-Source Licenses.

16. Termination, Expiration, Transition. The State may terminate this Contract, in whole or in part, including the Support Services for all or any Software, or any Statement of Work, in accordance with the following:

16.1 Termination for Cause.

(a) The State may terminate this Contract for cause, in whole or in part, if Contractor, as determined by the State: (i) endangers the value, integrity, or security of any State system, data, facility or personnel; (ii) becomes insolvent, petitions for bankruptcy court proceedings, or has an involuntary bankruptcy proceeding filed against it by any creditor; (iii) engages in any conduct that may expose the State to liability; or (iv) breaches any of its material duties or obligations under this Contract. Any reference to specific breaches being material breaches within this Contract will not be construed to mean that other breaches are not material.

(b) If the State terminates this Contract under this Section 16.1, the State will issue a termination notice specifying whether Contractor must: (a) cease performance immediately, or (b) continue to perform for a specified period. If it is later determined that Contractor was not in breach of this Contract, the termination will be deemed to have been a termination for convenience, effective as of the same date, and the rights and obligations of the parties will be limited to those provided in Section 16.2.

(c) The State will only pay for amounts due to Contractor for Services and Deliverables accepted by the State on or before the date of termination, subject to the State’s right to set off any amounts owed by the Contractor for the State’s reasonable costs in terminating this Contract. Contractor must promptly reimburse to the State any Fees prepaid by the State prorated to the date of such termination, including any prepaid Support Fees. The Contractor may be required to at the State’s sole discretion pay all reasonable costs incurred by the State in terminating this Contract for cause, including administrative costs, attorneys’ fees, court costs, transition costs, and any costs the State incurs to procure the Services from other sources.

16.2 Termination for Convenience. The State may immediately terminate this Contract in whole or in part, without penalty and for any reason, including but not limited to, appropriation or budget shortfalls. The termination notice will specify whether Contractor must: (a) cease performance immediately, or (b) continue to perform in accordance with Section 16.3. If the State terminates this Contract for convenience, the State will pay all reasonable costs, as determined by the State, for State approved Transition Responsibilities to the extent funds are available.

16.3 Transition Responsibilities. Upon termination or expiration of this Contract for any reason, Contractor must, for a period of time specified by the State (not to exceed 180 calendar days, unless otherwise agreed to by the parties)(the “Transition Period”), provide all reasonable transition assistance requested by the State, to allow for the expired or terminated portion of the Contract to continue without interruption or adverse effect, and to facilitate the orderly transfer of the Services to the State or its designees. Such transition assistance may include but is not limited to: (a) continuing to perform the Services at the established Contract rates; (b) taking all reasonable and necessary measures to transition performance of the work, including all applicable Services and Deliverables to the State or the State’s designee; (c) taking all necessary and appropriate steps, or such other action as the State may direct, to preserve, maintain, protect, or return to the State all State Materials and State Data; (d) transferring title in and delivering to the State, at the State’s discretion, all completed or partially completed Deliverables prepared under this Contract as of the Contract termination or expiration date; and (e) preparing an accurate accounting from which the State and Contractor may reconcile all outstanding accounts

(collectively, the “Transition Responsibilities”). This Contract is automatically extended through the end of the Transition Period.

16.4 Effect of Expiration or Termination.

(a) Upon termination or expiration of this Contract for any reason:

(i) Contractor will be obligated to perform all Transition Responsibilities specified in Section 16.3.

(ii) All licenses granted to Contractor in the State Materials and State Data will immediately and automatically also terminate. Contractor must promptly return to the State all State Materials and State Data not required by Contractor for its Transition Responsibilities, if any.

(iii) Contractor will (A) return to the State all documents and tangible materials (and any copies) containing, reflecting, incorporating, or based on the State’s Confidential Information, (B) permanently erase the State’s Confidential Information from its computer systems and (C) certify in writing to the State that it has complied with the requirements of this Section 16.4(a)(iii), in each case to the extent such materials are not required by Contractor for Transition Responsibilities, if any.

(b) No expiration or termination of this Contract will affect the State’s rights in any of the Deliverables that have already been paid for by the State.

16.5 Survival. This Section 16 survives termination or expiration of this Contract.

17. Stop Work Order. The State may, at any time, order the Services of Contractor fully or partially stopped for its own convenience for up to thirty (30) calendar days at no additional cost to the State. The State will provide Contractor a written notice detailing such suspension (a “Stop Work Order”). Contractor must comply with the Stop Work Order upon receipt. Within 30 days, or any longer period agreed to by Contractor, the State will either: (a) issue a notice authorizing Contractor to resume work, or (b) terminate this Contract. The State will not pay for any Services, Contractor’s lost profits, or any additional compensation during a stop work period.

18. Contractor Representations and Warranties.

18.1 Authority. Contractor represents and warrants to the State that:

(a) It is duly organized, validly existing, and in good standing as a corporation or other entity as represented under this Contract under the laws and regulations of its jurisdiction of incorporation, organization, or chartering;

(b) It has the full right, power, and authority to enter into this Contract, to grant the rights and licenses granted under this Contract, and to perform its contractual obligations;

(c) The execution of this Contract by its Representative has been duly authorized by all necessary organizational action;

(d) When executed and delivered by Contractor, this Contract will constitute the legal, valid, and binding obligation of Contractor, enforceable against Contractor in accordance with its terms; and

(e) Contractor is neither currently engaged in nor will engage in the boycott of a person based in or doing business with a strategic partner as described in 22 USC 8601 to 8606.

18.2 Bid Response. Contractor represents and warrants to the State that:

(a) The prices proposed by Contractor were arrived at independently, without consultation, communication, or agreement with any other bidder for the purpose of restricting competition; the prices quoted were not knowingly disclosed by Contractor to any other bidder to the RFP; and no attempt was made by Contractor to induce any other Person to submit or not submit a proposal for the purpose of restricting competition;

(b) All written information furnished to the State by or for Contractor in connection with this Contract, including Contractor’s Bid Response, is true, accurate, and complete, and contains no untrue statement of material fact or omits any material fact necessary to make the information not misleading;

(c) Contractor is not in material default or breach of any other contract or agreement that it may have with the State or any of its departments, commissions, boards, or agencies. Contractor further represents and warrants that it has not been a party to any contract with the State or any of its departments that was terminated by the State within the previous five (5) years for the reason that Contractor failed to perform or otherwise breached an obligation of the contract; and

(d) If any of the certifications, representations, or disclosures made in Contractor’s Bid Response change after contract award, the Contractor is required to report those changes immediately to the Contract Administrator.

18.3 Software and Service. Contractor represents and warrants to the State that:

(a) It will perform all Services in a professional and workmanlike manner in accordance with best industry standards and practices for similar services, using personnel with the requisite skill, experience and qualifications, and will devote adequate resources to meet its obligations under this Contract;

(b) It is in compliance with, and will perform all Services in compliance with, all applicable Law;

(c) The State will receive good and valid title to the Software, free and clear of all encumbrances and liens of any kind;

(d) When delivered and installed by Contractor, the Software will not contain any Harmful Code;

(e) The Software will not contain, or operate in such a way that it is compiled with or linked to, any Open-Source Components other than Approved Open-Source Components;

(f) The Software will not contain, or operate in such a way that it is compiled with or linked to, any Third-Party Materials other than Approved Third-Party Materials;

(g) The Software, including all updates, upgrades, new versions, new releases, enhancements, improvements and other modifications thereof, but excluding components comprising State Materials, Approved Third-Party Materials, and Open-Source Components, is or will be the original creation of Contractor;

(h) As delivered, installed, specified, or approved by Contractor and used by the State or any Third Party authorized by the State, the Software: (i) will not infringe, misappropriate, or otherwise violate any Intellectual Property Right or other right of any third party; and (ii) will comply with all applicable Laws;

(i) No expiration or loss of any patent or application for patent rights in the Software is pending, or, to Contractor’s knowledge after reasonable inquiry, threatened or reasonably foreseeable, and Contractor has no reason to believe that any claims of any such patent or patent application are or will be invalid, unenforceable, fail to issue, or be materially limited or restricted beyond the current claims, except for patent rights expiring at the end of their statutory term; and

(j) All Software will be, and as installed in the Operating Environment (or any successor thereto), will function in all respects, in conformity with this Contract and the Specifications and Documentation.

19. Indemnification.

19.1 General Indemnification. Contractor must defend, indemnify and hold the State, its departments, divisions, agencies, offices, commissions, officers, and employees harmless, without limitation, from and against any and all actions, claims, losses, liabilities, damages, costs, attorney fees, and expenses (including those required to establish the right to indemnification), arising out of or relating to: (a) any breach by Contractor (or any of Contractor’s employees, agents, subcontractors, or by anyone else for whose acts any of them may be liable) of any of the promises, agreements, representations, warranties, or insurance requirements contained in this Contract; (b) any infringement, misappropriation, or other violation of any Intellectual Property Right or other right of any Third Party; and (c) any bodily injury, death, or damage to real or tangible personal property occurring wholly or in part due to action or inaction by Contractor (or any of Contractor’s employees, agents, subcontractors, or by anyone else for whose acts any of them may be liable).

19.2 Indemnification Procedure. The State will notify Contractor in writing if indemnification is sought; however, failure to do so will not relieve Contractor, except to the extent that Contractor is materially prejudiced. Contractor must, to the satisfaction of the State, demonstrate its financial ability to carry out these obligations. The State is entitled to: (i) regular updates on proceeding status; (ii) participate in the defense of the proceeding; (iii) employ its own counsel; and to (iv) retain control of the defense, at its own cost and expense, if the State deems necessary. Contractor will not, without the State’s prior written consent (not to be unreasonably withheld), settle, compromise, or consent to the entry of any judgment in or otherwise seek to terminate any claim, action, or proceeding. Any litigation activity on behalf of the State or any of its subdivisions, under this Section 19, must be coordinated with the Department of Attorney General. An attorney designated to represent the State may not do so until approved by the Michigan Attorney General and appointed as a Special Assistant Attorney General.

19.3 Infringement Remedies.

(a) The remedies set forth in this Section 19.3 are in addition to, and not in lieu of, all other remedies that may be available to the State under this Contract or otherwise, including the State’s right to be indemnified for such actions.

(b) If any Software or any component thereof, other than State Materials, is found to be infringing or if any use of any Software or any component thereof is enjoined, threatened to be enjoined or otherwise the subject of an infringement claim, Contractor must, at Contractor’s sole cost and expense:

(i) procure for the State the right to continue to use such Software or component thereof to the full extent contemplated by this Contract; or

(ii) modify or replace the materials that infringe or are alleged to infringe (“Allegedly Infringing Materials”) to make the Software and all of its components non-infringing while providing fully equivalent features and functionality.

(c) If neither of the foregoing is possible notwithstanding Contractor’s best efforts, then Contractor may direct the State to cease any use of any materials that have been enjoined or finally adjudicated as infringing, provided that Contractor will:

(i) refund to the State all amounts paid by the State in respect of such Allegedly Infringing Materials and any other aspects of the Aggregate Software provided under the Statement of Work for the Allegedly Infringing Materials that the State cannot reasonably use as intended under this Contract; and

(ii) in any case, at its sole cost and expense, secure the right for the State to continue using the Allegedly Infringing Materials for a transition period of up to six (6) months to allow the State to replace the affected features of the Software without disruption.

(d) If Contractor directs the State to cease using any Software under Section 19.3(c), the State may terminate this Contract for cause under Section 16.1.

(e) Contractor will have no liability for any claim of infringement arising solely from:

(i) Contractor’s compliance with any designs, specifications, or instructions of the State; or

(ii) Modification of the Software by the State without the prior knowledge and approval of Contractor;

(iii) unless the claim arose against the Software independently of any of the above specified actions.

20. Liquidated Damages.

20.1 The parties agree that any delay or failure by Contractor to timely perform its obligations in accordance with the Implementation Plan and Milestone Dates agreed to by the parties will interfere with the proper and timely implementation of the Software, to the loss and damage of the State. Further, the State may incur major costs to perform the obligations that would have otherwise been performed by Contractor. The parties understand and agree that any liquidated damages Contractor must pay to the State as a result of such nonperformance are described in the Statement of Work, and that these amounts are reasonable estimates of the State’s damages in accordance with applicable Law.

20.2 The parties acknowledge and agree that Contractor could incur liquidated damages for more than one event if Contractor fails to timely perform its obligations by each Milestone Date.

20.3 The assessment of liquidated damages will not constitute a waiver or release of any other remedy the State may have under this Contract for Contractor’s breach of this Contract, including without limitation, the State’s right to terminate this Contract for cause under Section 16.1, and the State will be entitled in its discretion to recover actual damages caused by Contractor’s failure to perform its obligations under this Contract. However, the State will reduce such actual damages by the amounts of liquidated damages received for the same events causing the actual damages.

20.4 Amounts due the State as liquidated damages may be set off against any Fees payable to Contractor under this Contract, or the State may bill Contractor as a separate item and Contractor will promptly make payments on such bills.

21. Damages Disclaimers and Limitations.

21.1 The State’s Disclaimer of Damages. THE STATE WILL NOT BE LIABLE, REGARDLESS OF THE FORM OF ACTION, WHETHER IN CONTRACT, TORT, NEGLIGENCE, STRICT LIABILITY OR BY STATUTE OR OTHERWISE, FOR ANY CLAIM RELATED TO OR ARISING UNDER THIS CONTRACT FOR CONSEQUENTIAL, INCIDENTAL, INDIRECT, OR SPECIAL DAMAGES, INCLUDING WITHOUT LIMITATION LOST PROFITS AND LOST BUSINESS OPPORTUNITIES.

21.2 The State’s Limitation of Liability. IN NO EVENT WILL THE STATE’S AGGREGATE LIABILITY TO CONTRACTOR UNDER THIS CONTRACT, REGARDLESS OF THE FORM OF ACTION, WHETHER IN CONTRACT, TORT, NEGLIGENCE, STRICT LIABILITY OR BY STATUTE OR OTHERWISE, FOR ANY CLAIM RELATED TO OR ARISING UNDER THIS CONTRACT, EXCEED THE MAXIMUM AMOUNT OF FEES PAYABLE UNDER THIS CONTRACT.

22. State Data.

22.1 Ownership. The State’s data (“State Data”), which will be treated by Contractor as Confidential Information, includes: (a) User Data; and (b) any other data collected, used, processed, stored, or generated by the State in connection with the Services, including but not limited to personally identifiable information (“PII”) collected, used, processed, stored, or generated as the result of the Services, including, without limitation, any information that identifies an individual. State Data is and will remain the sole and exclusive property of the State and all right, title, and interest in the same is reserved by the State. This Section 22.1 survives termination or expiration of this Contract.

22.2 Contractor Use of State Data. Contractor is provided a limited license to State Data for the sole and exclusive purpose of providing the Services, including a license to collect, process, store, generate, and display State Data only to the extent necessary in the provision of the Services. Contractor must: (a) keep and maintain State Data in strict confidence, using such degree of care as is appropriate and consistent with its obligations as further described in this Contract and applicable law to avoid unauthorized access, use, disclosure, or loss; (b) use and disclose State Data solely and exclusively for the purpose of providing the Services, such use and disclosure being in accordance with this Contract, any applicable Statement of Work, and applicable law; and (c) not use, sell, rent, transfer, distribute, or otherwise disclose or make available State Data for Contractor’s own purposes or for the benefit of anyone other than the State without the State’s prior written consent. This Section 22.2 survives termination or expiration of this Contract.

22.3 Loss of Data. In the event of any act, error or omission, negligence, misconduct, or breach by Contractor that compromises or is suspected to compromise the security, confidentiality, or integrity of State Data or the physical, technical, administrative, or organizational safeguards put in place by Contractor that relate to the protection of the security, confidentiality, or integrity of State Data, Contractor must, as applicable: (a) notify the State as soon as practicable but no later than twenty-four (24) hours of becoming aware of such occurrence; (b) cooperate with the State in investigating the occurrence, including making available all relevant records, logs, files, data reporting, and other materials required to comply with applicable law or as otherwise required by the State; (c) in the case of PII, at the State’s sole election, (i) notify the affected individuals who comprise the PII as soon as practicable but no later than is required to comply with applicable law, or, in the absence of any legally required notification period, within five (5) calendar days of the occurrence; or (ii) reimburse the State for any costs in notifying the affected individuals; (d) in the case of PII, provide third-party credit and identity monitoring services to each of the affected individuals who comprise the PII for the period required to comply with applicable law, or, in the absence of any legally required monitoring services, for no less than twenty-four (24) months following the date of notification to such individuals; (e) perform or take any other actions required to comply with applicable law as a result of the occurrence; (f) pay for any costs associated with the occurrence, including but not limited to any costs incurred by the State in investigating and resolving the occurrence, including reasonable attorney’s fees associated with such investigation and resolution (g) without limiting Contractor’s obligations of indemnification as further described in this Contract, indemnify, defend, and hold harmless the State for any and all claims, including reasonable attorneys’ fees, costs, and incidental expenses, which may be suffered by, accrued against, charged to, or recoverable from the State in connection with the occurrence; (h) be responsible for recreating lost State Data in the manner and on the schedule set by the State without charge to the State; and (i) provide to the State a detailed plan within ten (10) calendar days of the occurrence describing the measures Contractor will undertake to prevent a future occurrence. Notification to affected individuals, as described above, must comply with applicable law, be written in plain language, and contain, at a minimum: name and contact information of Contractor’s representative; a description of the nature of the loss; a list of the types of data involved; the known or approximate date of the loss; how such loss may affect the affected individual; what steps Contractor has taken to protect the affected individual; what steps the affected individual can take to protect himself or herself; contact information for major credit card reporting agencies; and, information regarding the credit and identity monitoring services to be provided by Contractor. The State will have the option to review and approve any notification sent to affected individuals prior to its delivery. Notification to any other party, including but not limited to public media outlets, must be reviewed and approved by the State in writing prior to its dissemination. The parties agree that any damages relating to a

breach of this Section 22.3 are to be considered direct damages and not consequential damages. This Section 22.3 survives termination or expiration of this Contract.

23. Confidential Information. Each party acknowledges that it may be exposed to or acquire communication or data of the other party that is confidential in nature and is not intended to be disclosed to third parties. This Section 23 survives termination or expiration of this Contract.

23.1 Meaning of Confidential Information. The term “Confidential Information” means all information and documentation of a party that: (a) has been marked “confidential” or with words of similar meaning, at the time of disclosure by such party; (b) if disclosed orally or not marked “confidential” or with words of similar meaning, was subsequently summarized in writing by the disclosing party and marked “confidential” or with words of similar meaning; or, (c) should reasonably be recognized as confidential information of the disclosing party. The term “Confidential Information” does not include any information or documentation that was or is: (a) in the possession of the State and subject to disclosure under the Michigan Freedom of Information Act (FOIA); (b) already in the possession of the receiving party without an obligation of confidentiality; (c) developed independently by the receiving party, as demonstrated by the receiving party, without violating the disclosing party’s proprietary rights; (d) obtained from a source other than the disclosing party without an obligation of confidentiality; or, (e) publicly available when received, or thereafter became publicly available (other than through any unauthorized disclosure by, through, or on behalf of, the receiving party). Notwithstanding the above, in all cases and for all matters, State Data is deemed to be Confidential Information.

23.2 Obligation of Confidentiality. The parties agree to hold all Confidential Information in strict confidence and not to copy, reproduce, sell, transfer, or otherwise dispose of, give or disclose such Confidential Information to third parties other than employees, agents, or subcontractors of a party who have a need to know in connection with this Contract or to use such Confidential Information for any purposes whatsoever other than the performance of this Contract. The parties agree to advise and require their respective employees, agents, and subcontractors of their obligations to keep all Confidential Information confidential. Disclosure to the Contractor’s subcontractor is permissible where: (a) the subcontractor is a Permitted Subcontractor; (b) the disclosure is necessary or otherwise naturally occurs in connection with work that is within the Permitted Subcontractor's responsibilities; and (c) Contractor obligates the Permitted Subcontractor in a written contract to maintain the State's Confidential Information in confidence. At the State’s request, any of the Contractor’s Representatives may be required to execute a separate agreement to be bound by the provisions of this Section 23.2.

23.3 Cooperation to Prevent Disclosure of Confidential Information. Each party must use its best efforts to assist the other party in identifying and preventing any unauthorized use or disclosure of any Confidential Information. Without limiting the foregoing, each party must advise the other party immediately in the event either party learns or has reason to believe that any person who has had access to Confidential Information has violated or intends to violate the terms of this Contract. Each party will cooperate with the other party in seeking injunctive or other equitable relief against any such person.

23.4 Remedies for Breach of Obligation of Confidentiality. Each party acknowledges that breach of its obligation of confidentiality may give rise to irreparable injury to the other party, which damage may be inadequately compensable in the form of monetary damages. Accordingly, a party may seek and obtain injunctive relief against the breach or threatened breach of the foregoing undertakings, in addition to any other legal remedies which may be available, to include, in the case of the State, at the sole election of the State, the

immediate termination, without liability to the State, of this Contract or any Statement of Work corresponding to the breach or threatened breach.

23.5 Surrender of Confidential Information upon Termination. Upon termination or expiration of this Contract or a Statement of Work, in whole or in part, upon request, each party must, within five (5) Business Days from the date of termination, return to the other party any and all Confidential Information received from the other party, or created or received by a party on behalf of the other party, which are in such party’s possession, custody, or control. If Contractor or the State determine that the return of any Confidential Information is not feasible, such party must destroy the Confidential Information and certify the same in writing within five (5) Business Days from the date of termination to the other party.

24. ADA Compliance. The State is required to comply with the Americans with Disabilities Act of 1990 (ADA), and has adopted a formal policy regarding accessibility requirements for websites and software applications. Contractor’s Software must comply, where relevant, with level AA of the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines (WCAG) 2.0.

25. Records Maintenance, Inspection, Examination, and Audit.

25.1 Right of Audit. The State or its designee may audit Contractor to verify compliance with this Contract. Contractor must retain, and provide to the State or its designee and the auditor general upon request, all financial and accounting records related to this Contract through the Term of this Contract and for three (3) years after the latter of termination, expiration, or final payment under this Contract or any extension (“Financial Audit Period”). If an audit, litigation, or other action involving the records is initiated before the end of the Financial Audit Period, Contractor must retain the records until all issues are resolved.

25.2 Right of Inspection. Within ten (10) calendar days of providing notice, the State and its authorized representatives or designees have the right to enter and inspect Contractor’s premises or any other places where Services are being performed, and examine, copy, and audit all records related to this Contract. Contractor must cooperate and provide reasonable assistance. If financial errors are revealed, the amount in error must be reflected as a credit or debit on subsequent invoices until the amount is paid or refunded. Any remaining balance at the end of this Contract must be paid or refunded within forty-five (45) calendar days.

25.3 Application. This Section 25 applies to Contractor, any Affiliate, and any Permitted Subcontractor that performs Services in connection with this Contract.

26. Insurance Requirements. Contractor must maintain the minimum insurances identified in the Insurance Schedule attached as Schedule C.

27. Dispute Resolution.

27.1 Unless otherwise specified in the Statement of Work, the parties will endeavor to resolve any Contract dispute in accordance with Section 27. The initiating party will reduce its description of the dispute to writing (including all supporting documentation) and deliver it to the responding party’s Project Manager. The responding party’s Project Manager must respond in writing within five (5) Business Days. The initiating party has five (5) Business Days to review the response. If after such review resolution cannot be reached, both parties will have an additional five (5) Business Days to negotiate in good faith to resolve the dispute. If the

dispute cannot be resolved within a total of fifteen (15) Business Days, the parties must submit the dispute to the parties’ Contract Administrators. The parties will continue performing while a dispute is being resolved, unless the dispute precludes performance. A dispute involving payment does not preclude performance.

27.2 Litigation to resolve the dispute will not be instituted until after the dispute has been elevated to the parties’ Contract Administrators, and either Contract Administrator concludes that resolution is unlikely, or fails to respond within fifteen (15) Business Days. The parties are not prohibited from instituting formal proceedings: (a) to avoid the expiration of statute of limitations period; (b) to preserve a superior position with respect to creditors; or (c) where a party makes a determination that a temporary restraining order or other injunctive relief is the only adequate remedy. This Section 27 does not limit the State’s right to terminate this Contract.

28. General Provisions.

28.1 Effect of Contractor Bankruptcy. All rights and licenses granted by Contractor under this Contract are and will be deemed to be rights and licenses to “intellectual property,” and all Work Product is and will be deemed to be “embodiments” of “intellectual property,” for purposes of, and as such terms are used in and interpreted under, Section 365(n) of the United States Bankruptcy Code (the “Code”). If Contractor or its estate becomes subject to any bankruptcy or similar proceeding, the State retains and has the right to fully exercise all rights, licenses, elections, and protections under this Contract, the Code and all other applicable bankruptcy, insolvency, and similar Laws with respect to all Software and other Work Product. Without limiting the generality of the foregoing, Contractor acknowledges and agrees that, if Contractor or its estate shall become subject to any bankruptcy or similar proceeding:

(a) all rights and licenses granted to the State under this Contract will continue subject to the terms and conditions of this Contract, and will not be affected, even by Contractor’s rejection of this Contract; and

(b) the State will be entitled to a complete duplicate of (or complete access to, as appropriate) all such intellectual property and embodiments of intellectual property comprising or relating to any Software or other Work Product, and the same, if not already in the State’s possession, will be promptly delivered to the State, unless Contractor elects to and does in fact continue to perform all of its obligations under this Contract.

28.2 Conflicts and Ethics. Contractor will uphold high ethical standards and is prohibited from: (a) holding or acquiring an interest that would conflict with this Contract; (b) doing anything that creates an appearance of impropriety with respect to the award or performance of the Contract; (c) attempting to influence or appearing to influence any State employee by the direct or indirect offer of anything of value; or (d) paying or agreeing to pay any person, other than employees and consultants working for Contractor, any consideration contingent upon the award of the Contract. Contractor must immediately notify the State of any violation or potential violation of these standards. This Section 28.2 applies to Contractor, any Affiliate, and any Permitted Subcontractor that Performs Services in connection with this Contract.

28.3 Compliance with Laws. Contractor and its Representatives must comply with all Laws in connection with this Contract.

28.4 Nondiscrimination. Under the Elliott-Larsen Civil Rights Act, 1976 PA 453, MCL 37.2101, et seq., and the Persons with Disabilities Civil Rights Act, 1976 PA 220, MCL 37.1101, et seq., Contractor and its Permitted Subcontractors agree not to discriminate against an employee or applicant for employment with respect to hire, tenure, terms, conditions, or privileges of employment, or a matter directly or indirectly related to employment, because of race, color, religion, national origin, age, sex, height, weight, marital status, or mental or physical disability. Breach of this covenant is a material breach of this Contract.

28.5 Unfair Labor Practice. Under MCL 423.324, the State may void any Contract with a Contractor or Permitted Subcontractor who appears on the Unfair Labor Practice register compiled under MCL 423.322.

28.6 Governing Law. This Contract is governed, construed, and enforced in accordance with Michigan law, excluding choice-of-law principles, and all claims relating to or arising out of this Contract are governed by Michigan law, excluding choice-of-law principles. Any dispute arising from this Contract must be resolved in the Michigan Court of Claims. Complaints against the State must be initiated in Ingham County, Michigan. Contractor waives any objections, such as lack of personal jurisdiction or forum non conveniens. Contractor must appoint agents in Michigan to receive service of process.

28.7 Non-Exclusivity. Nothing contained in this Contract is intended nor is to be construed as creating any requirements contract with Contractor. This Contract does not restrict the State or its agencies from acquiring similar, equal, or like Services from other sources.

28.8 Force Majeure. (a) Force Majeure Events. Subject to Subsection 28.8 (b) below, neither party will be liable or responsible to the other party, or be deemed to have defaulted under or breached this Contract, for any failure or delay in fulfilling or performing any term hereof, when and to the extent such failure or delay is caused by: acts of God, flood, fire or explosion, war, terrorism, invasion, riot or other civil unrest, embargoes or blockades in effect on or after the date of this Contract, national or regional emergency, or any passage of law or governmental order, rule, regulation or direction, or any action taken by a governmental or public authority, including imposing an embargo, export or import restriction, quota or other restriction or prohibition (each of the foregoing, a “Force Majeure”), in each case provided that: (a) such event is outside the reasonable control of the affected party; (b) the affected party gives prompt written notice to the other party, stating the period of time the occurrence is expected to continue; (c) the affected party uses diligent efforts to end the failure or delay and minimize the effects of such Force Majeure Event.

(b) State Performance; Termination. In the event of a Force Majeure Event affecting Contractor’s performance under this Contract, the State may suspend its performance hereunder until such time as Contractor resumes performance. The State may terminate this Contract by written notice to Contractor if a Force Majeure Event affecting Contractor’s performance hereunder continues substantially uninterrupted for a period of five (5) Business Days or more. Unless the State terminates this Contract pursuant to the preceding sentence, any date specifically designated for Contractor’s performance under this Contract will automatically be extended for a period up to the duration of the Force Majeure Event.

28.9 Relationship of the Parties. The relationship between the parties is that of independent contractors. Nothing contained in this Contract is to be construed as creating any agency, partnership, joint venture or other form of joint enterprise, employment or fiduciary relationship between the parties, and neither party shall have authority to contract for or bind the other party in any manner whatsoever.

28.10 Media Releases. News releases (including promotional literature and commercial advertisements) pertaining to this Contract or project to which it relates must not be made without the prior written approval of the State, and then only in accordance with the explicit written instructions of the State.

28.11 Notices. All notices, requests, consents, claims, demands, waivers and other communications under this Contract must be in writing and addressed to the parties as follows (or as otherwise specified by a party in a notice given in accordance with this Section 28.11):

If to Contractor: Altarum Institute

3520 Green Court, Suite 300, Ann Arbor, MI 48105

Email: [email protected]

Attention: General Counsel

If to State: Mecca Martin

525 W. Allegan Street, Lansing, MI 48909

Email: [email protected]

Attention: Contract Administrator

Notices sent in accordance with this Section 28.11 will be deemed effectively given: (a) when received, if delivered by hand (with written confirmation of receipt); (b) when received, if sent by a nationally recognized overnight courier (receipt requested); (c) on the date sent by email (with confirmation of transmission), if sent during normal business hours of the recipient, and on the next Business Day, if sent after normal business hours of the recipient; or (d) on the fifth (5th) calendar day after the date mailed, by certified or registered mail, return receipt requested, postage prepaid.

28.12 Headings. The headings in this Contract are for reference only and will not affect the interpretation of this Contract.

28.13 Schedules All Schedules that are referenced herein and attached hereto are hereby incorporated by reference. The following Schedules are attached hereto and incorporated herein:

Schedule A Statement of Work

Schedule B Pricing Schedule

Schedule C Insurance Schedule

Schedule D Service Level Agreement

Schedule E Data Security Requirements

Schedule F Transition In and Out

Schedule G Federal Provisions Addendum

Appendix A Optional Task

28.14 Assignment. Contractor may not assign or otherwise transfer any of its rights, or delegate or otherwise transfer any of its obligations or performance, under this Contract, in each case whether voluntarily,

involuntarily, by operation of law or otherwise, without the State’s prior written consent. The State has the right to terminate this Contract in its entirety or any Services or Statements of Work hereunder, pursuant to Section 16.1, if Contractor delegates or otherwise transfers any of its obligations or performance hereunder, whether voluntarily, involuntarily, by operation of law or otherwise, and no such delegation or other transfer will relieve Contractor of any of such obligations or performance. For purposes of the preceding sentence, and without limiting its generality, any merger, consolidation or reorganization involving Contractor (regardless of whether Contractor is a surviving or disappearing entity) will be deemed to be a transfer of rights, obligations, or performance under this Contract for which the State’s prior written consent is required. Any purported assignment, delegation, or transfer in violation of this Section 28.14 is void.

28.15 No Third-Party Beneficiaries. This Contract is for the sole benefit of the parties and their respective successors and permitted assigns. Nothing in this Contract, express or implied, is intended to or will confer on any other person or entity any legal or equitable right, benefit or remedy of any nature whatsoever under or by reason of this Contract.

28.16 Amendment and Modification; Waiver. No amendment to or modification of this Contract is effective unless it is in writing, identified as an amendment to this Contract and signed by both parties Contract Administrator. Further, certain amendments to this Contract may require State Administrative Board Approval. No waiver by any party of any of the provisions of this Contract will be effective unless explicitly set forth in writing and signed by the party so waiving. Except as otherwise set forth in this Contract, no failure to exercise, or delay in exercising, any right, remedy, power, or privilege arising from this Contract will operate or be construed as a waiver. Nor will any single or partial exercise of any right, remedy, power or privilege under this Contract preclude the exercise of any other right, remedy, power or privilege.

28.17 Severability. If any term or provision of this Contract is invalid, illegal, or unenforceable in any jurisdiction, such invalidity, illegality or unenforceability will not affect any other term or provision of this Contract or invalidate or render unenforceable such term or provision in any other jurisdiction. Upon such determination that any term or other provision is invalid, illegal, or unenforceable, the parties must negotiate in good faith to modify this Contract so as to effect the original intent of the parties as closely as possible in a mutually acceptable manner in order that the transactions be consummated as originally contemplated to the greatest extent possible.

28.18 Equitable Relief. Each party to this Contract acknowledges and agrees that (a) a breach or threatened breach by such party of any of its obligations under this Contract may give rise to irreparable harm to the other party for which monetary damages would not be an adequate remedy and (b) in the event of a breach or a threatened breach by such party of any such obligations, the other party hereto is, in addition to any and all other rights and remedies that may be available to such party at law, at equity or otherwise in respect of such breach, entitled to equitable relief, including a temporary restraining order, an injunction, specific performance and any other relief that may be available from a court of competent jurisdiction, without any requirement to post a bond or other security, and without any requirement to prove actual damages or that monetary damages will not afford an adequate remedy. Each party to this Contract agrees that such party will not oppose or otherwise challenge the appropriateness of equitable relief or the entry by a court of competent jurisdiction of an order granting equitable relief, in either case, consistent with the terms of this Section 28.19.

28.19 Counterparts. This Contract may be executed in counterparts, each of which will be deemed an original, but all of which together will be deemed to be one and the same Contract. A signed copy of this Contract delivered by email or other means of electronic transmission (to which a signed PDF copy is attached) will be deemed to have the same legal effect as delivery of an original signed copy of this Contract.

28.20 Further Assurances. Each party will, upon the reasonable request of the other party, execute such documents and perform such acts as may be necessary to give full effect to the terms of this Contract.

28.21 Entire Agreement. This Contract, together with all Schedules, Exhibits, and the Statement of Work constitutes the sole and entire agreement of the parties to this Contract with respect to the subject matter contained herein, and supersedes all prior and contemporaneous understandings and agreements, representations and warranties, both written and oral, with respect to such subject matter. In the event of any inconsistency between the statements made in the body of this Contract, the Schedules, Exhibits, and the Statement of Work, the following order of precedence governs: (a) first, this Contract, excluding its Exhibits and Schedules, and the Statement of Work; and (b) second, the Statement of Work as of the Effective Date; and (c) third, the Exhibits and Schedules to this Contract as of the Effective Date. NO TERMS ON CONTRACTORS INVOICES, WEBSITE, BROWSE-WRAP, SHRINK-WRAP, CLICK-WRAP, CLICK-THROUGH OR OTHER NON- NEGOTIATED TERMS AND CONDITIONS PROVIDED WITH ANY OF THE SERVICES, OR DOCUMENTATION HEREUNDER WILL CONSTITUTE A PART OR AMENDMENT OF THIS CONTRACT OR IS BINDING ON THE STATE OR ANY AUTHORIZED USER FOR ANY PURPOSE. ALL SUCH OTHER TERMS AND CONDITIONS HAVE NO FORCE AND EFFECT AND ARE DEEMED REJECTED BY THE STATE AND THE AUTHORIZED USER, EVEN IF ACCESS TO OR USE OF SUCH SERVICE OR DOCUMENTATION REQUIRES AFFIRMATIVE ACCEPTANCE OF SUCH TERMS AND CONDITIONS.

SCHEDULE A - STATEMENT OF WORK

. 1. DEFINITIONS

The following terms have the meanings set forth below. All initial capitalized terms that are not defined in this Schedule shall have the respective meanings given to them in Section 1 of the Contract Terms and Conditions.

Term Definition

CDC Centers for Disease Control and Prevention

ICHAT Internet Criminal History Access Tool

MDSS Michigan Diseases Surveillance System

NCIC National Crime Information Center

NEDSS National Electronic Disease Surveillance System

PHIN Public Health Information Network

SOM State of Michigan government

UAT User Acceptance Testing

UI User Interface

UX User Experience

MVP Minimal Viable Product

PV Planned Value

PI Product Increment

PAT Product Accessibility Template

2. BACKGROUND

The goal of the Michigan Disease Surveillance System (MDSS) has been the on-going development of a Public Health Information Network (PHIN) compliant disease information system that implements a logical data model based on the National Electronic Disease Surveillance System (NEDSS), to support the MDHHS public health surveillance system. MDSS improves the medical and epidemiological management of the case investigations and enhances public health capacity.

MDSS is to maintain a logical data model based on the National Electronic Disease Surveillance System (NEDSS). Additionally, MDSS must meet the requirements for reporting communicable diseases as specified in Michigan’s Public Health Code (MCL 333.5111) and Centers for Disease Control and Prevention (CDC) Public Health Emergency Preparedness and EPI/Lab Capacity funding.

PURPOSE

The State is seeking a software solution that is fully customized.

3. SCOPE OF WORK

The project will meet the busines goals outlined by standardizing and simplifying policy and business processes, and by leveraging a technical solution that is flexible and easy to maintain.

The State’s general approach to this project is to have the Contractor work with key State of Michigan staff to perform a knowledge transfer throughout the project. This will enable the State to maintain and enhance the system at the end of the contract. This approach encompasses both business (i.e., MDHHS) and technical (i.e., DTMB) staff. MDHHS and DTMB will fully commit resources to the successful implementation of this project. Repeated failure to meet requirements, which substantially impact the critical path of the project, due solely to Contractor’s failure to perform, may be considered by the State to be a material breach of the Contract.

3.1 In Scope 1. A scalable Michigan Disease Surveillance System that is: a. On-premise hosted solution. b. Meets Enterprise Architecture (EA) assessments standards. c. Must accommodate online and offline solutions. d. Person Centric 2. Design, Development and Implementation (DDI) of the system and project management including: a. Development or Modification of the solution incorporate functionality required to support MDSS program requirements. b. Testing c. Program staff training. d. Business process change management. e. Risk mitigation. f. Support and maintenance. g. System and process documentation. 3. Requirements for the solution: a. Data Conversion needs b. Data Quality needs/expectations c. Language on any requirements due to current or new law, etc… d. User stories (detailed in appendix) e. System Integrations with a preliminary list of known integrations f. Testing services g. Transition to SOM @ SOW end h. Training services as defined in SOW i. Deliverables as defined in SOW 4. Any code changes to the mobile software, if any, must be managed through the State App Store. 5. Create the interfacing components in the system to accomplish business requirements as specified in Schedule A, Table 1 – Business Specifications Worksheet. 6. The Contract will have seven (7) releases (This may change after the completion of Sprint 0 scoping and release planning stage): a. Project initiation (Kick off) b. Release 1: Architecture and Design c. Release 2: Core Services d. Release 3: Data Management and System Interfaces e. Release 4: Disease Specific Program Needs f. Release 5: Reporting and Analytics Module

g. Release 6: Overdose, Chronic Disease, Outbreak Management and Tracing Module h. Release 7: Documentation, Training and Outreach i. Testing: User Acceptance Testing j. Production Go-Live 7. At the State’s option, a one (1) year transition period post-implementation including the following. Note, in the event the State does not wish to activate the one (1) year transition period, the contract will revert to one (1) additional year of maintenance and support and will extend the overall length of the contract. a. A structured take-over of operations and maintenance by the State b. Provide guidance to State as it performs business operations c. Provide requested enhancements to system, if any d. Perform application software maintenance, troubleshooting assistance, and e. Requested enhancements while training DTMB staff to take over these roles. f. Address low severity defects that did not affect the new system going into production. 8. Transfer knowledge and work with assigned DTMB personnel for the term of the agreement for maintenance services. a. Provide one dedicated resource from the development team for 6 months following the end of the warranty period (TBD) to perform requested enhancements or troubleshoot system defects under the direction of MDHHS/DTMB (as required) and assure smooth daily operations. b. The resources will be billed at a rate consistent with other phases of the contract and the State will not incur additional charges for this service. c. Knowledge transfer to DTMB personnel throughout the design, development, testing and implementation.

3.2 Product Increment Roadmap - This section is under development the Contractor and State will come to mutual agreement on the project planning and implementation of the system pending the assessment completion.

4. THE STATE DELIVERY APPROACH (SCRUM FRAMEWORK)

Below is a description of a Scrum /Agile methodology the State of Michigan utilizes as a guideline for the completion of this project.

The State and Contractor agree to outline roles and responsibilities of Contract, MDHHS and DTMB as part of project kickoff. This includes the expected process, roles and responsibilities during:

• Sprint Planning • Sprint Execution • Sprint Review/Retrospective • Testing

The State and Contractor agree that any and all work associated with the realization of the PV can only commence on each PI after the Contractor receives a written PI Work Order from the MDHHS Executive Sponsor. The State and Contractor agree that the State is the sole party to initiate a PI Work Order.

The State of Michigan utilizes the Scrum framework accompanied by select practices from Extreme Programming (XP) on projects using adaptive techniques for development. The agile approach is supported by the State’s SUITE methodology with tailoring for Scrum and XP.

Agile Application Development Activities (AADA)

The following sections describe the specific activities that are to be executed as part of the AADA by the Contractor in collaboration with the SOM. Included in this description is a list of activities which indicate whether the State or the Contractor own, contribute or collaborate on each activity for the processes described below.

The State and Contractor understand and accept the assigned responsibilities for the AADA as defined in the following responsibility matrices. The responsibilities address the following agile development definition areas:

• PV, PI Roadmap definition (State SOW Readiness complete) • PI definition and planning • Sprint execution — potentially multiple per PI • Sprint execution — technical debt reduction - as needed • Warranty Period — team or teams continue the sprinting cycle to remediate erroneous code • PI End to End User Acceptance Test (UAT) • PI delivery (includes Contractor Performance Evaluation) resulting in either: o a). Issuance of the next PI Work Orders o b). Termination of the underperforming Contractor and awarding the remaining work to the next qualified Contractor • Transition Sprint (invoked when replacing a Contractor) • Release to Production

The State and the Contractor understand and accept that all assigned responsibilities for the AADA, as described under the respective agile development areas are repetitive and executed in accordance with the statement of work outlined in this document.

The State has provided a PV, PI Roadmap, Story Map, Personas, and Initial Product Backlog that will be used to form the basis for this statement of work. The Contractor will provide estimates, duration, and effort for each PI and for the overall product during Sprint 0.

The Contractor carries the responsibility to involve any other party needed to deliver the defined PV, at its own expense.

Once an award is made, additional activities are performed in Sprint 0 by the State and the Contractor selected. Collectively, State SOW Readiness and post-award Sprint 0 is considered the “Getting Ready to Go” portion of the project. In keeping with the agile lean principles, post-award Sprint 0 duration should be as short as possible. Post-award duration should be appropriate to the length of the overall project, but in no event should it exceed 30 calendar days.

It will be the responsibility of the State Product Owner to define, prioritize, and accept the functionality needed to achieve the PV.

During this period the project’s Project Manager(s) establishes and verifies that adequate test environments (typically development, integration, QAT and UAT) are available, and identifies team members: Business Analyst (BA), Developers, QA Testers, DBA’s etc. The State identifies the State Product Owner, Agency Subject Matter Experts (that will provide feedback as the project progresses), and the State Project Manager(s).

The State Project Manager will identify and secure a fully equipped team work space large enough for colocation of the project team. The Contractor Project Manager will be located onsite at the Lansing Office. Alternative work locations for the Contractor Project Manager can be negotiated and approved by the State Project Manager

The Contractor Project Manager also provides the following agreed upon development components:

• Continuous Integration and supporting software based on the state’s recommended tooling (Exhibit B), at Contractors cost. • Build processes that support: o Static code quality checking and reporting o Unit test code coverage metrics o Automated unit and regression testing capability o Regression test results

The State will provide an established project in the State’s Enterprise Team Foundation Server (TFS), or similar environment prior to commencing the project. The State will supply licenses for TFS to all state employees needing access. The Contractor is responsible to fund the costs for TFS licenses for its employees assigned to the project as needed

See metrics section below for the minimum metrics to be reported.

When all parties have agreed that the activities outlined above are complete, the project will move into the execution phase and begin sprinting.

4.1 Sprint Cycle 4.1.1 Sprint Planning Sprint planning activities reflect the work associated with formalization of what user stories will be realized per sprint.

1. Product Owner and the scrum team agree on what will be built in the sprint 2. Team capacity determined 3. Tasks with effort hours are added for each user story selected

The focus of each sprint can be on realizing a new PI, technical debt or remediating post release defects.

4.1.2 Sprint Execution The State utilizes the basic Scrum process during execution. Sprints should be less than 4 weeks in length (2 weeks is the preferred length). Each sprint starts with a sprint planning meeting on the first day of the sprint. Multiple Sprints may be grouped together to form a PI. Multiple PIs may be grouped together to form the State’s Minimum Viable Product with sufficient business value that it could be released to production.

The heart of an agile development approach is the rapid iterative nature of the execution cycles – sprints. Sprint execution activities reflect the work associated with the programming, scripting, activating, configuring, customizing, debugging, test automation and daily progress information of user stories and other application artifacts, as agreed to in sprint planning.

Executed properly, the development approach is not a mini-waterfall development effort but a radically different way of working. To execute properly, all parties must embrace the approach and meet its commitments. Every single execution sprint should deliver completed (coded, unit tested, integration tested, and acceptance tested) piece of functionality. There is NO lag in testing to future sprints.

Sprint execution will also include unit, system and a UAT of each user story’s deliverables to verify that all deliverables meet acceptance criteria set out in each user story.

An automated build (required), including execution of all unit tests (automated) with each build and at a minimum daily execution of the automated regression test suite provides the team and Product Owner the assurance that new code does not result in errors to previously coded and accepted user stories.

Technical debt reduction focuses on the improvement of product/solution reliability, performance, operability, security, compatibility, maintainability and/or transferability (in line with ISO25010 standards). Technical debt (not to be confused with defects) reduction is considered a normal pattern in agile frameworks. Every effort should be made to reduce technical debt as it is incurred by adding technical stories to the backlog and working with the State’s Product Owner to address the technical stories in future sprints. If technical debt is allowed to accumulate to an effort large enough to fill an entire sprint, the Contractor Project Manager, the MDHHS Project Manager, the DTMB Project Manager should collaborate on a solution to reduce the technical debt.

Additionally, during each sprint, user stories are further detailed in the Product Backlog by elaboration (refined, split, sized, complete acceptance criteria) to provide sufficient user stories that meet the Definition of Ready for upcoming sprints.

4.1.2.1 The Scrum/Stand-up meeting Scrum Development Team meets daily (< 15 minutes) to inform the team of:

• What has been accomplished since the last Scrum (stand-up) • What will be accomplished before the next daily scrum. • What is impeding progress.

4.1.2.2 Sprint Review / Demo (once per sprint) On the last day of the sprint the Development Team meets with the Product Owner and any interested stakeholders to: • Review (demo as appropriate) all work completed (to Definition of Done) • Product Owner signals acceptance of the user story • Obtain feedback on possible product improvements from the Product Owner and other stakeholders.

4.1.2.3 Sprint Retrospective (once per sprint) At the end of a sprint and before the next sprint planning meeting the Scrum Development Team meets to review their processes, delivery, and challenges during the previous sprint to determine: • What was done well and should continue to be practiced. • What didn’t go well and should be improved. • What actions will be taken in the next sprint to improve outcomes. During the sprint period the Development Team and Product Owner will informally discuss and review work in process to gain an understanding and verify that what is being built meets the Product Owner’s needs.

4.1.3 User Acceptance Testing During a Sprint Multiple times during a sprint (possibly multiple times per day) the functionality (code etc.) added to satisfy a user story will be released into an environment where the State Product Owner or designee will perform acceptance testing of the user story based on the documented acceptance criteria of each user story and on the user story test scenarios detailed by the State BA, Contractor BA or State Product Owner (or a combination of any of those roles). All sprint UAT activities by the State will be conducted within the State UAT Environment.

Testing and reporting of any defects found in functionality being delivered in the sprint or developed in previous sprints will be completed within one (1) business day of release to the State Product Owner test environment. All defects identified during Sprint UAT (bug or regression issue) must be remediated before the end of the sprint. If remediation (and retest) is not possible before the end of the sprint the user story will not be presented at the sprint review (demo) or marked accepted (does not contribute to that sprint’s velocity). It will be moved to the next sprint for defect remediation. Only when the user story can be accepted by the State Product Owner can credit for completion (velocity) be accrued.

4.1.4 Warranty Execution – Remediation of Erroneous Code The process for the warranty period remains the same as for execution sprints. The Contractor doesn’t receive payment for the work that has erroneous code.

4.1.5 Product Increment delivery (every 2-3 months) or Release to Production When the Product Owner deems that there is sufficient product available, the date for the next PI UAT sprint will be finalized. The MDHHS Project Manager and Contractor will determine if the PI will be released to production or to an environment where a larger group of end users can exercise the Product and provide feedback. All Critical Defects must be remediated prior to authorization of payment for that PI by the Executive Sponsors. Medium and Low severity defects found during End 2 End testing will be added to the Product Backlog, marked as a defect, and prioritized by the Product Owner for remediation in upcoming sprints or during the warranty period.

4.1.6 Transition Sprint If the evaluation of a Contractor’s performance (completed at the end of a PI delivery) is determined to be inadequate in terms of:

• Amount of business value delivered (code and non-code deliverables) • Quality of delivered features (both code quality metrics and defects) and the Contractor has in place a Corrective Action Plan that wasn’t fully executed, the State will terminate the current Contractor’s contract and award the remaining work under this SOW to the next qualified Contractor.

The State will use the Transition Sprint period to onboard the new Contractor and their Scrum Team. The on-boarding includes, acquainting the new team with the work completed to date, standards, procedures, architectural direction etc., granting access to team members, issuing a PI Work Order and other start-up activities.

The State anticipates that the transition period can be completed in two business weeks but will work with the new Contractor to establish an appropriate length for this start-up period. Contractors must review the contractual Terms and Conditions to understand their responsibilities in the event that a transition period is needed.

4.2 Handling Change to the Scope of the Product on an Agile Project An agile approach to product development and delivery is by its nature fluid, evolving and undergoing constant elaboration and refinement. The methodology embraces change based on value and feedback from users and subject matter experts.

To provide a mechanism for managing the evolution of the details of what is being built and to accommodate input on usability from subject matter experts story elaborations and additions are handled in one of several methods.

Items of equal relative size can be “exchanged” (one deleted and the other added) without formal change documentation. A note should be made in the backlog item as to what was substituted. The state should be set to “removed” by the State Product Owner so that the history is available for audit purposes.

Items found through standard elaboration of an epic, which was part of the original scope or when scope is deemed to be larger than originally anticipated, the first course of action should be an exchange.

Optional items can be added to the Product Backlog that were not included in the original Story Map. For those items the importance should be set to “Nice to Have” by the State Product Owner (history is available for audit).

Should the development team have capacity (time and budget), AFTER delivering the required In Scope business functionality, the State and Contractor can mutually agree on additional sprints and determine which of the items should be included.

Formal change management processes (defined and agreed to in the Project Management Plan) will be utilized when items that affect the overall budget, number of releases needed to deliver the required scope or final delivery date of the project are:

For example, an add or enhancement that is clearly outside the scope of the project and must be included in the product delivery. The additional work results in the need for more time or budget or both.

5. IT ENVIRONMENT RESPONSIBILITIES

Contractor must comply with all State policies, standards, and procedures applicable to the proposed solution which will be hosted in the State environment. Contractor personnel will follow the State policies and procedures to access State systems. The Contractor has experience working with State systems and understand responsibilities when working with State testing, staging, and production environments. Contractor employees who have access to the State will comply with the State’s Acceptable Use Policy. Contractor also realizes the importance of security and privacy training. All Contractor employees are required to successfully complete three security and privacy training courses annually. Contractor will ensure the security and confidentiality of State data accessed as part of providing services to the State.

Although we will not be hosting the solution, we expect to be required to interact with personal health information (PHI) and are fully prepared and trained to handle this.

Contractor must support the State in completing the Security Accreditation Process and work together in planning and implementing remediation when necessary, including addressing any vulnerabilities identified through scanning. Industry standard scanning tools will also be used to analyze the software in the development environment prior to deploying to State servers.

For a State Hosted Software Solution:

Definitions:

Application – Software programs which provide functionality for end user and Contractor services.

Development - Process of creating, integrating, testing and maintaining software components.

Component Matrix Disclose subcontractor name(s), if applicable. Application N/A Development N/A

Contractor will not be using subcontractors.

6. ADA COMPLIANCE

The State is required to comply with the Americans with Disabilities Act of 1990 (ADA) and has adopted standards and procedures regarding accessibility requirements for websites and software applications. All websites, applications, software, and associated content and documentation provided by the Contractor as part of the Solution must comply with Level AA of the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines (WCAG) 2.0.

Contractor must provide a description of conformance with WCAG 2.0 Level AA specifications by providing a completed PAT for the Solution. If the Solution is comprised of multiple products, a PAT must be provided for each product. In addition to PATs, Contractors may include a verification of conformance certified by an industry-recognized third-party. If the Contractor is including any third-party products in the Solution, Contractor must obtain and provide the third-party PATs as well.

Each PAT must state exactly how the product meets the specifications. All “Not Applicable” (N/A) responses must be fully explained. Contractor must address each standard individually and with specificity; and clarify whether conformance is achieved throughout the entire product (for example – user functionality, administrator functionality, and reporting), or only in limited areas. A description of the evaluation methods used to support WCAG 2.0 Level AA conformance claims, including, if applicable, any third-party testing, must be provided. For each product that does not fully conform to WCAG 2.0 Level AA, Contractor must provide detailed information regarding the plan to achieve conformance, including timelines.

Contractor software solutions, products, and other deliverables implemented or released under this contract will conform to WCAG 2.0 Level AA specifications.

7. USER TYPE AND CAPACITY

Number of Concurrent Type of User Access Type Number of Users Users

State Employee Role Based 500 250

Approved Third Role Based 3000 500 Party

Contractor Solution must be able to support the expected number of concurrent Users.

MDSS 2.0 must be capable of scaling independently in multiple ways to accommodate changing performance requirements. The system is comprised of three main layers: a surveillance services layer that performs storage and retrieval from the database using a REST facade to support storing of case, patient, and other surveillance data; user experience/user interface and content management system (UX/UI) layer that provides the user interface customization of workflow; and an indexing search repository to support fast searching, reporting, and analytics. The surveillance services layer may be scaled to match database capacity and support processing load. The UX/UI layer may likewise be scaled to match user load by adding instances across multiple virtual machines. The search and reporting index layer can be scaled to accommodate new reporting services and user demands in the same way. Background services (non-user session processing like data imports or exports) can be scaled separately as needed. Specific CPU and memory intensive services within a layer component, such as deduplication, can be allocated resources separately from other system service components to insure consistent response. Also, multiple service instances across multiple virtual machines for each set of services are mediated by load balancing to enable scale out to any degree needed for future user and data source expansion for pandemics or other public health challenges. Similarly, if demand from incoming message processing and user load remains consistently low after such events, active resources like VMs may possibly be reduced.

The MDSS 2.0 system must be tuned to provide 95th percentile latency of 2 seconds for home page load. For standard reports, the proposed system will be tuned to begin delivering results within 5 seconds for 95% of all user queries; the time to complete delivery of results is dependent on data output volume, connection speed, and receiver capability. Ad-hoc reports, as the name implies, cannot be scoped or tuned to achieve a particular level of performance. Ad-hoc reports that are structurally similar to standard equivalents should be expected to perform similarly to standard counterparts.

The MDSS 2.0 system must be composed of a baseline engine of several virtual machines, plus other VMs as required for decoupled systems like on-premises surveys or public-facing reporting services. CPU and memory resources for each VM host will be tuned and benchmarked to achieve the given latency targets. VM hosts may be added to provide additional load capacity, and as network, security, and management policies require. A Docker containerization environment on each VM is highly desired to manage operations and simplify management across VMs. Ten gigabit ethernet connectivity or equivalent between engine hosts is required. Sufficient inbound network bandwidth to support the projected user base is required, through a load balancing router to the engine virtual machine cluster. A round robin connection distribution technique is adequate for user session balancing, but other connection management strategies may be employed if preferred or required by policy.

Test and Staging environments of the system, along with the Production environment, will be required.

8. ACCESS CONTROL AND AUTHENICATION

The Contractor’s solution must integrate with the State’s IT Identity and Access Management (IAM) environment as described in the State of Michigan Digital Strategy (https://www.michigan.gov/dtmb/0,5552,7-358-82547_56345_56351_69611-336646--,00.html), which consist of:

8.1 MILogin/Michigan Identity, Credential, and Access Management (MICAM). An enterprise single sign-on and identity management solution based on IBM’s Identity and Access Management products including, IBM Security Identity Manager (ISIM), IBM Security Access Manager for Web (ISAM), IBM Tivoli Federated Identity Manager (TFIM), IBM Security Access Manager for Mobile (ISAMM), and IBM DataPower, which enables the State to establish, manage, and authenticate user identities for the State’s Information Technology (IT) systems.

8.2 MILogin Identity Federation. Allows federated single sign-on (SSO) for business partners, as well as citizen-based applications.

8.3 MILogin Multi Factor Authentication (MFA, based on system data classification requirements). Required for those applications where data classification is Confidential and Restricted as defined

by the 1340.00 Michigan Information Technology Information Security Policy (i.e. the proposed solution must comply with PHI, PCI, CJIS, IRS, and other standards).

8.4 MILogin Identity Proofing Services (based on system data classification requirements). A system that verifies individual’s identities before the State allows access to its IT system. This service is based on “life history” or transaction information aggregated from public and proprietary data sources. A leading credit bureau provides this service.

To integrate with the SOM MILogin solution, the Contractor’s solution must support SAML, or OAuth or OpenID interfaces for the SSO purposes.

The Contractor solution must support SAML integration with the SOM MILogin to make use of the SSO for performing the user authentication and controlling access to the application. This will provide the authentication (basic or multi-factor as determined by State) and will provide application access for internal State of Michigan employees, contractual (third party) and public users across all supported environments. Within the application itself, there will be validation that confirms whether the user is active in the system and should be allowed to proceed. The proposed solution will also interface with the current MILogin solution to support the registration of new users requesting access to the disease surveillance system.

The Contractor solution must also provide the ability for administrators to configure roles and privileges for users based on job function, location, and disease group responsibilities. The settings will determine which modules a user is able to access and which application functionality is available to them. This will also control and limit access to the data that a user is allowed to view and edit.

Actions performed by users will be logged for the purpose of tracking the history of the disease surveillance data so administrator level users can be aware of who made changes to cases and when they were made. Other actions will be audited for the purpose of understanding system usage and for tracking when users are logging into the system.

9. DATA RETENTION AND REMOVAL

The State will need to retain all data for the entire length of the Contract unless otherwise direct by the State. The State will need the ability to delete data, even data that may be stored off-line or in backups. The State will need to retrieve data, even data that may be stored off-line or in backups.

10. END USER OPERATING ENVIRONMENT

The SOM IT environment includes X86 VMware, IBM Power VM, MS Azure/Hyper-V and Oracle VM, with supporting platforms, enterprise storage, monitoring, and management.

Contractor must accommodate the latest browser versions (including mobile browsers) as well as some pre- existing browsers. To ensure that users with older browsers are still able to access online services, applications must, at a minimum, display and function correctly in standards-compliant browsers and the state standard browser without the use of special plugins or extensions. The rules used to base the minimum browser requirements include:

• Over 2% of site traffic, measured using Sessions or Visitors (or) • The current browser identified and approved as the State of Michigan standard

This information can be found at https://www.michigan.gov/browserstats. Please use the most recent calendar quarter to determine browser statistics. For those browsers with over 2% of site traffic, except Internet Explorer which requires support for at minimum version 11, the current browser version as well as the previous two major versions must be supported.

Contractor must support the current and future State standard environment at no additional cost to the State.

MDSS 2.0 must be capable of running in multiple VM environments. The final decision will be made at design time after consulting with State resource controllers on the best choice for running Linux and Docker in their environments. Oracle VMs will be needed for the Operational Data Store.

MDSS 2.0 must support the current and future State standard environments.

For all MDSS 2.0 application servers, the Contractor will require remote VPN access to each server in the Production, Staging, and Test/Dev environments hosted at the State. This is the same access requirement Contractor has for the existing legacy MDSS. On each application server, the Contractor will need full read/write access to the applications accounts. This is necessary to provide basic maintenance, retrieve logs, update delivery services, and provide backup support as needed.

For all new database servers in the production, staging, and test/dev environments, the Contractor will need VPN access to connect to all database ports needed to run remote clients. This is necessary to retrieve and verify information stored for special requests, test database scripts in lower environments, monitor database sessions, and process special requests.

To accomplish routine maintenance tasks and perform normal system operation, the Contractor will also need various firewall considerations to other State supplied services such as (but not limited to) email servers, geocoding services, Rhapsody, FTS (file transfer service), etc.

The application will run in the specified State environment as described above. Changes/updates to the environment would need to be communicated with appropriate advance notice so that the application can be tested in lower environments with proposed changes. If proposed environment changes require updates to the application, the Contractor would coordinate with the client to determine the impacts of the change and resolution process. Upon mutual agreement of the timeline to support the environment changes, the Contractor will perform the required application updates as needed.

Contractor will support the original environment throughout the term of the contract.

All changes or additions made to application functionality will be made in collaboration with the State’s Project Manager. Prior to deploying any new version of any part of the system, Contractor will engage in collaborative meetings to discuss a complete list of potential modifications. When a new version is deployed to a lower environment, all modifications applied in that version will be listed. The new application deployment will be tested and approved by the client in a lower environment before the production release is scheduled. Release instructions for required software and architecture updates will be documented to specify the database and application updates required to perform for successful deployment. The team will ensure appropriate data restore points created as part of the backup process. The Contractor will be available to support the deployment process and ensure the release is successful.

The Contractor project manager must work closely with the State’s Project Manager and other program area leads to manage all upgrades, maintenance, and all change control tracking. Upgrades will be a collaborative process in which Contractor will gather requirements from major stakeholders and come to a consensus about proposed application updates and how to implement them. Regular maintenance will be scheduled with the project manager and DTMB to ensure that any interruption to the user base is minimal. All application sources will be stored within our source code repository, ensuring that all coding changes are controlled and tracked by release number.

There are no plug-ins necessary for the proposed MDSS 2.0 solution.

11. SOFTWARE

Software requirements are identified in Schedule A – Table 1 Business Specification Worksheet.

Look and Feel Standards All software items provided by the Contractor must adhere to the State of Michigan Application/Site standards which can be found at https://www.michigan.gov/standards.

Mobile Responsiveness If the software will be used on a mobile device as defined in Schedule A – Table 1, Business Specification Worksheet, the Software must utilize responsive design practices to ensure the application is accessible via a mobile device.

The Contractor grants to the State and its Authorized Users a non-exclusive, royalty-free, perpetual, irrevocable right and license to use the Software and Documentation in accordance with the terms and conditions of this Contract.

Contractor must use the following third-party components to support the solution: • Tableau for interactive visual components • Mirth for internal messaging within the application • Oracle version 19c for the Operational Data Store

Additional open source components may be included or used with the proposed Solution depending upon design requirements.

MDSS 2.0 must be compatible with the current and most recent mobile operating systems from Android and Apple. These include Apple- and Android-based phones and tablets. The system does not run native on these platforms but will work in browsers running on these platforms where screen size is not an issue.

MDSS 2.0 must feature a user interface with a responsive front end. While not a native Android or iPhone app, it will be usable on a mobile device. Some operations are better suited for larger screens. Contractor expects that the following features will be suitable for mobile devices: alerting and notifications, field questionnaires, work queue status, and basic data entry functions. Contractor expects to work with MDHHS as mobile requirements are finalized to ensure that priority features are available on mobile devices.

Solution Overview

Architecture Contractor proposes a modern microservices architecture for the MDSS 2.0 to better meet the needs of users, provide efficient scalability, and be both configurable and interoperable. Our solution achieves MDHHS’ goals with the least amount of risk, the least amount of disruption in current communicable disease processes and provides the most up-to-date architecture to future-proof the MDSS. It does this while greatly minimizing long-term maintenance costs compared to COTS or semi-COTS solutions.

A microservices architecture, when coupled with containers, allows for each service to scale or update without disrupting other services in the application so that applications or modules can be continuously delivered to end users. Containers are a lightweight, efficient, and standard way for applications to run independently. Everything needed (except for the shared operating system on the server) to run the application is packaged within the container object: code, run time, system tools, libraries, and dependencies.

This microservices framework with containers creates a massively scalable and distributed system, which avoids the bottlenecks of a central database and improves business capabilities, such as enabling continuous delivery/deployment of applications and the ability to scale up performance as needed (for example, during a pandemic). Applications are easier to build, optimize, and maintain when they are split into a set of smaller parts, and managing the code also becomes significantly more efficient.

MDSS 2.0 Architecture Diagram

The MDSS 2.0 architecture diagram above shows how we plan to structure the new system to accomplish the project goals. The services for the major components each have their own containers to make managing resources easier. This includes the main portal that will manage most of the content, the various applications, the operational and reporting databases, the messaging services, and the analytics warehouse. MDSS 2.0 must also leverage ‘load balancers’ to better manage and direct network traffic to handle spikes in component usage.

Solution Features

MDSS 2.0 must increase automation, improve data quality, and provide a much-enhanced user experience to meet the needs of all users. The new system will better support longitudinal surveillance and case management tracking. It will be configurable to meet the wide-ranging needs of end users and include standard and customizable dashboards, reports, and analytics that leverage dynamic and interactive visualizations of MDSS data.

MDSS 2.0 will be highly integrated and will streamline communication with other data systems. Its UI will proactively identify and eliminate manual errors and enrich information when data elements are missing. Some key features of the solution include:

Increased automation. Automation will be improved through the use of business rules built around the application microservices. For example, these rules will enable the automation of patient and case deduplication and ELR handling.

Enhanced data quality. Validating, cleaning, and processing documents and messages from hundreds of senders is made simpler and more reliable by separate upstream services. These services also enable hot fixes and rapid code changes to keep up with changes in the onboarding process to speed fixes to the user community.

Improved data linkages for improved case management. Microservices with exposed application programming interfaces (APIs) allow for easy linking with internal and external applications and databases and provide longitudinal case management for a more complete picture of a patient or case.

Enhanced Reporting and analytics. A modern data system coupled with an analytic engine allow for fast, intuitive graphics, analytics, and interactive visualizations. The analytics module will also be able to operate in its own computing container so high demand there will not affect performance in other parts of the system.

Communication enhancements. Data exchanges and streamlined communication will be handled by the Message Transformation Services (see Architecture Diagram) and include HL7, FHIR, other REST APIs,

XML, and JMS. This will allow for outreach to providers and patients through these streamlined integration points.

System alerts. MDSS 2.0 must allow for both system - and user-level alerts. System functions in the Production environment will be monitored and system administrators will be alerted to any detected aberrations. These include message flow disruptions, concurrent user spikes, and other configurable items of interest. User level alerts will be end user configurable and statistically-based, using our monitoring and incident aberration detection algorithms.

Local customizations and configurable user experience. The data visualization server module enables user exploration and report creation, and users will be able to create and deploy personal dashboards/reports within their personalized work environment. Custom workflows can be created and deployed without system downtime and without disrupting the workflows of other users. System-wide logging with a customizable dashboard. Events as disparate as the messaging engine input and output rates, system page views, transaction rates for cases processing, and work queue servicing, will be captured in the MDSS 2.0 monitoring system and presented for easy viewing via the system dashboard.

Improved integration and system performance. Well-defined microservices with exposed APIs allow for easier integration with internal and external applications and databases. They also improve system performance by allowing service bundles/applications to be assigned more resources with a simple reconfiguration rather than application rewrites. As processing hot spots develop, resources can be specifically allocated to keep the system running efficiently.

The solution must meet or exceed all requirements contained in this Contract. Based on Contractor’s many years working with the current system, its users, and with MDHHS, we have proposed innovative optional tasks beyond the base system for consideration. These are not included in the base proposed solution but could be added and completed within the base timeline.

1. Contact Tracing and Patient Outreach • Eliminate significant maintenance costs, reduce costs of future enhancements, and more tightly couple the Traceforce application with the rest of the MDSS.

2. An Integrated Chronic Disease Warehouse • There has been a lot of interest in the different chronic disease program areas in getting their data into the legacy MDSS. While Contractor worked with MDHHS to come up with a way to accomplish this by reusing the MICelerity module, this optional task would gather requirements and implement a true chronic disease warehouse to store and integrate into the MDSS program.

3. A Reimagined Outbreak Management System • We understand that there some significant updates and improvements that MDHHS wishes to make to the current OMS. While outside the scope of this Contract, Contractor provides some ideas on how to implement these changes to achieve MDHHS’ goals for the OMS. Please see

4. Enhancements to the Syringe Service Program Utilization Platform • We understand that there some significant updates and improvements that MDHHS wishes to make to the current SUP. While outside the scope of this Contract, Contractor provides some ideas on how to implement these changes to achieve MDHHS’ goals for the SUP.

5. A Google Research Data Warehouse and Analytics Laboratory • The Contractor understand that the State plans to host the modernized MDSS at a State hosting data center, Contractor would like to offer a way for the State to test new advanced analytic techniques in a low-risk easy-to-use environment. For this optional task Contractor would team with Google to send de-identified data to the research data warehouse on the Google Cloud Platform.

6. Ad-hoc Support • Contractor recognizes that this list is not exhaustive and would engage the State on additional optional tasks at the State’s discretion.

12. INTEGRATION

Contractor must integrate their solution to the following technologies:

Integration List - General Integration Title MILogin Current Technology Identity management service used for identifying, authenticating, and authorizing individuals or groups of individuals to access applications, systems, or IT environments. Volume of Data Approximately 5000 + public users. Approximately 400 + internal users. Approximately 60+ contractual staff. Approximately 500+ community resources. Format of the input & export files

MDSS 2.0 must be accessed from the MILogin single sign-on (SSO) solution for authentication (basic or future multi-factor) and primary application access for internal State of Michigan employees, contractual (third party), and public users across all supported Development/Test, Staging, and Production environments. MDSS 2.0 will support the registration of new application users and maintain metadata on additional user attributes and subsystem access and privileges. As users flow through the various MDSS components, the user account metadata will also flow to the MDSS components through the current SAML integration with MILogin. MDSS 2.0 will transition this integration to OAuth or OpenID interfaces as needed in the future. Currently, the F5 proxies provide user account details in the forwarded request headers. MDSS 2.0 will expand the current integration capabilities to include explicitly logging out of any intermediate user sessions (e.g., F5 proxy sessions; for increased security, etc.) and to possibly maintain the MILogin session state so that user transfers back to MILogin from the MDSS do not require users to re-login – the behavior before the F5 integration.

Integration Title Enterprise Service Bus (ESB) Current Technology IBM WebSphere MDHHS utilizes an ESB for implementing communication between internal interacting software applications. The ESB will provide a standard, structured, and general-purpose concept for implementing loosely coupled software components that are expected to be independently deployed. Volume of Data Webservices calls within MDHHS Format of the input & export files

MDSS 2.0 must include a separate service to connect with State Enterprise Service Bus and exchange the case data as needed. Integration with State ESB will provide the advantage of exchanging patient health records between State registries. Data exchange between multiple applications will follow data interoperability rules. Receiving additional health records will benefit the case investigation process in MDSS 2.0. The proposed service will support secure connection with ESB using the REST API service. The data exchanged will undergo additional data transformations to support the valid formats accepted by the clients on both the ends. For example: The current MPI patient data exchange can be performed by connecting directly to the state ESB using the REST API service. MDSS 2.0 can include a dedicated service to connect with ESB to exchange MDSS case data and MiCelerity data with the State health data warehouse. Implementing this as a separate service will reduce code duplication to send data from different sources in MDSS such as MiCelerity, MDSS, chronic disease registry data, etc. Further data exchange details will be dependent on the business requirements gathered with stakeholders and the State.

Integration Title Rhapsody Service Bus (ESB) Current Technology The MDHHS Data Hub is technically comprised of the Orion Health Rhapsody Integration Engine. It serves as the core messaging service and utilizes various messaging technologies, including the Health Level 7 Standards (HL7). It serves as the message broker and router, receiving messages from external sources and passing them on to internal SOM systems, from SOM systems to other SOM systems, and from SOM systems to external destinations. It acts as part of the security gateway that allows only known types of messages from approved senders to access MDHHS systems This integration will be especially important for integrating with the MDSS Rhapsody/Data Quality Tool (DQT).

Volume of Data 90% of the inbound/outbound traffic for the existing system passes through this interface. Format of the input & export files HL7

The HL7 data received from the Rhapsody external lab facilities and other data vendors such as Electronic Death Registry System (EDRS) will be transferred to MDSS 2.0 via the DQT from the Rhapsody Service bus hosted by MDHHS data hub. The current connection between data hub and DQT is supported using the Rhapsody communication point and agnostic to data format and type of the messages received.

The Java Message Service (JMS) is loosely coupled, reliable for message transfer between applications, and capable of distributed communication between applications asynchronously. The point-to-point model of the JMS service will be used to transfer messages for the proposed solution. The messages received from data hub are delivered to the destination, which is a queue, which in turn will be delivered to one of the consumers registered for the queue. While any number of producers can send messages to the queue, each message is guaranteed to be delivered and consumed by one consumer. If no consumers are registered to consume the messages, the queue holds them until a consumer registers to consume them. The proposed JMS works efficiently, independent of the message type and data format. Adding new data transfers or supporting high data volume to the application can be achieved by adding additional queues, ensuring that the data received on the application end is handled appropriately.

Message transfers between the current DQT and the MDSS 2.0 must be performed using different queues registered to transfer data in both directions. The number of message producers or the queues on the DQT end can easily be extended to the same consumer on the MDSS application end to ensure the system handles the increased message traffic during critical times. A separate service will be implemented to handle the data handoff between the queues and the MDSS application to ensure the system performance is not impacted with batches received from some of the national lab feeders. Message audit and monitoring will be performed on the application end to ensure the user can monitor the messages received from DQT and execute reports based on various parameters such as facility CLIA, time frame, and frequency.

Integration Title Master Person Index

Current Technology The Master Person Index (MPI) and Provider Index (PI) are enterprise solutions used to identify citizens or providers (e.g. individuals, group practices, facilities) across systems. The MPI/PI allows disparate systems to easily share data about an individual or provider by linking them together within the MPI/PI. This will be used to match externally to other MDHHS systems. There is currently an internal MPI for MDSS and migrating to the State MPI directly would be cause for some data loss. Prospective vendors are encouraged to address how a migration from an internal master person index to the State master person index would be accomplished.

Volume of Data All internal web service calls Format of the input & export files

The proposed solution must integrate with State MPI/PI to exchange patient records. The internal patient records will be exchanged with State MPI as patient records are created, merged, updated, and deleted. Patient demographic details along with unique internal patient ID and the record status will be sent to the State MPI based on the MDSS operations performed. Secured data transfer between MDSS 2.0 and the State MPI will be performed using the REST API services with SSL authentication. Data transfer status will be interpreted based on the status code received from the State MPI response. Unexpected record failures due to State MPI system unavailability will be re-sent after a specified timeframe. Automated emails will be triggered to the State team if a record fails due to data discrepancies, MPI system unavailability, or any other reason. Exchanged data audit logs will be recorded in a database and can be reported to the State team to verify system performance and data exchange reports.

MDSS 2.0 can be extended to utilize the State MPI data during automatic patient deduplication process when needed. When the internal MPI doesn’t return accurate results or returns multiple close patient record matches, it would benefit the MDSS user to verify the incoming patient data against state MPI records. The proposed solution will query the State MPI exchange [QBP - Query by Parameter] based on patient record details to identify possible matches across systems, including EDRS, Michigan Care Improvement Registry (MCIR), and others. The matched results will be returned for user verification to ensure the patient deduplication decisions are accurate. This implementation will help remove duplicate patient records in MDSS.

Integration Title MDSS Rhapsody/Data Quality Tool (DQT) Current Technology Rhapsody Volume of Data 90% of the in/out traffic from MDSS

Format of the input & export files The DQT is the gateway infrastructure to MDSS. Data from EDRS, CDC and Outside Lab/eCR/ADT senders is loaded through DQT or sent out to the DQT. It is important the solution integrate with the existing DQT and this will leverage existing integrations already in place.

As stated above, message transfers between the current DQT and the proposed solution will be performed using different queues registered to transfer data in both directions. The number of message producers or the queues on the DQT end will be easily extendable to the same consumer on the MDSS application end to ensure the system handles the increased message traffic during critical times. A separate service will be implemented to handle the data handoff between the queues and the MDSS application to ensure the

system performance is not impacted with batches received from some of the national lab feeders. Message audit and monitoring will be performed on the application end to ensure the user can monitor the messages received from DQT and execute reports based on various parameters such as facility CLIA, time frame, frequency.

Message transfers will be performed to MDSS applications based on the lab facility onboarding process. Test messages will be routed to the test environment while the production messages will be directed to the MDSS production environment based on processing ID. The CDC case exports from MDSS will be sent to DQT using the Java Messaging Service (JMS) queues, which will be transformed to HL7 messages before being securely transferred via PHINMS. Human Immunodeficiency Virus (HIV) case data will be transferred to DQT, which will be routed to the eHARs application. Similarly, ADT messages received from MIHIN will be routed to the MiCelerity application using the JMS message queues to create events in the system. EDRS messages received from the Rhapsody Service Bus will be transferred via DQT. The eCr data received from the APHL exchange will be transformed to MDSS case data format at DQT before being transferred to MDSS for subsequent case creation and updates. Message status reports for specific programs will be executed based on the message flow between DQT and MDSS 2.0.

Integration Title MCIR Current Technology Query by parameter (QBP) connection directly from MDSS to MCIR. Volume of Data TBD Format of the input & export files QBP

The solution must integrate with the MCIR application using the QBP connection to receive vaccine-related data for a specific patient record in MDSS 2.0. Vaccine data from MCIR will be retrieved based on the patient demographics and reportable condition sent from the MDSS application for the selected patient. Secured data transfer between MDSS 2.0 and MCIR will be performed using the REST services enabling SSL authentication between the applications. Data transfer requests will be initiated by MDSS users and the received data will be auto populated in the MDSS case record based on reportable condition. The vaccine data information will also be received from MCIR in PDF format as part of the data exchange. This received document will be attached to the case in MDSS. Audit action will be logged in MDSS to track the data transfer, the request initiation details, etc. An appropriate message will be displayed to the user based on the different response status received from the MCIR application, in case of failure.

This integration will be extended to receive vaccine data for all the vaccine preventable diseases such as Mumps, Varicella, Pertussis, etc.

Integration Title EDRS Current Technology Data formatting done in Data Quality Tool (DQT). There is no current direct interface. Volume of Data TBD Format of the input & export files No direct connection

The solution will integrate with the EDRS Exchange registry using the web service implementation available on the datahub end. The proposed solution will ensure that both the matched and unmatched death records will be received by the MDSS application. An authenticated data transfer connection will be established between the EDRS and MDSS 2.0 to ensure the PHI data is transmitted securely. The proposed solution will receive death records from EDRS based on cause of death (COD) or if the patient already exists in MDSS.

The unmatched death records will be received by MDSS 2.0 if the cause of death in the death message matches one of the reportable conditions in MDSS. The matched death records will verify the patient details against the MDSS patient records sent to the State MPI exchange. If the patient record matches, the data will be sent to the MDSS application. For unmatched death records, patient deduplication will be performed to ensure the death records are attached to the patient and the patient status and disposition is updated based on the cause of death. For unmatched death records received, an MDSS unique patient ID will be part of the death message and the death message will be attached to the patient record directly and ensure the patient status is updated. The death record data received from EDRS will initially be validated to ensure

data quality. Validated death records will be processed further to perform data customization and mapping, to ensure the data can be ingested in the MDSS application. Audit actions will be recorded to ensure the patient status change is recorded and the death record data is received for the selected patient. Invalid death records will trigger an email to the State team to initiate further investigation about the reason behind failures.

Additional features, such as ad-hoc reporting options, will be provided to ensure MDSS investigators can verify the patient and the associated case records that are created or updated with EDRS data.

Integration Title TraceForce/PEG - Current Technology API Connections Volume of Data TBD Format of the input & export files Webservice

MDSS 2.0 must provide functionality to exchange MDSS data with external systems as needed. It will be able to establish a secured connection with Traceforce/PEG environments to transfer the data with State- approved authentication methods.

MDSS 2.0 must have the option to initiate data transfers in real time or schedule them at specific times and frequency to meet any business requirements. The scheduled data transfers can be customized by the system administrator based on parameters like timeframe, geographic locations, and case types. The solution will also allow additional customization for the administrators to onboard jurisdictions at different times.

To ensure that duplicate records are not transferred to the Traceforce environment, case/contact data will be verified against the contact data sent already. Data validation will ensure fake phone records or generic contact names are restricted to avoid transferring invalid data to the Traceforce environment. Other customized data checks desired by users can be added to ensure that contacts sent to the Traceforce environment are valid. Data transfers will be audited to ensure the processing performance can be verified for these transfers. Transfer failures will trigger an automated email to the State administrator that will include the reason for the transfer failure, allowing the remediation process to be expedited.

Data received in MDSS 2.0 from the Traceforce environment will also be validated, to identify any data quality issues. Validation will handle duplicate records, special characters, and other unexpected data. Once the data validation is successful, the received data will be ingested to the system fields based on the defined mapping. Additional functionality, such as creating new cases based on the received data, will be triggered based on the decision logic laid out in the business requirements.

Hierarchical contact reports can be created to provide an in-depth view of the original point of source, and transmission paths can be identified based on the data sent/received from the Traceforce environment.

The solution will be able to export case data for specific reportable conditions to the PEG survey tool for further investigation. The case records exported will be flagged with status updates, so the MDSS users are posted with case investigation status. The investigation data received from the PEG tool will be mapped to case form fields in MDSS 2.0 for the selected reportable conditions. Further updates to the case, such as triggering automatic case investigation completion and initiating further review before sending the data to CDC, will be triggered.

Additional features include providing ad-hoc reporting on the data received from the PEG survey tool, identifying the status of a selected case that is sent to PEG, sorting based on parameters like jurisdiction, timeframe, status, and more.

Integration Title CDC

Current Technology Flat Volume of Data TBD Format of the input & export files Currently exporting data out of MDSS and back to DQT to send to CDC

The MDSS 2.0 solution must support sending the collected disease event information to the CDC in defined formats at specific intervals based on the reportable condition. The case data format and specifications will be dependent on the program type and onboarding status of the reportable conditions for State of Michigan. Exports to CDC will be implemented as a separate service in the solution. The suggested new service will include important features, such as scheduling customized exports, identifying the status of the requested export, canceling a requested export, generating a status report based on different parameters. The service for handling CDC exports will include the functionality to onboard new reportable conditions to send the case data to CDC automatically with minimal clicks.

The CDC exports will be driven from the reporting indexes as mentioned in the system architecture. This enables the case records to be exported any time of the day without impacting the system performance when yearly reconciliation data is sent to CDC. Implementing the CDC exports as separate service also enables a dedicated scheduler process that is independent of the other scheduled jobs such as case exports and data processing, and this will improve the system throughput. The cases exported from MDSS 2.0 will be sent to DQT using assigned program queues implemented with JMS. The exported case data will be sent to DQT to format according to the message mapping specifications provided by CDC. The case data will be converted to HL7 format messages based on CDC message specifications for each program. The HL7 messages will be securely transmitted to CDC using the PHINMS server for secured communication. The solution will support both NETSS (National Electronic Telecommunications System for Surveillance) and NEDSS (National Electronic Disease Surveillance System) exports based on onboarding processes for different reportable conditions. Switching from one export format to the other will be implemented as a system administrator function in the application.

As part of handling pandemic scenarios, the solution will be able to add new reportable conditions with a quick addition in the system interface by the system administrator and trigger the data transfer to CDC without any additional delay.

Integration Title Outside Lab/eCR/ADT senders Current Technology DQT Flat Files Volume of Data TBD Format of the input & export files Flat

MDSS 2.0 will continue to be able to ingest data received from various data vendors in approved formats such as HL7, comma delimited, and XML. Data vendors such as lab facilities, hospitals, and EHR vendors will onboard within the test environment before sending the production feed to MDSS 2.0. The System Administrator role will be able to onboard new lab senders to the production environment.

MDSS 2.0 must also include a separate service to receive the electronic lab/eCR/ADT data. The data transfer can be implemented using a message broker system and the message data will be directed to the appropriate application based on the message type and sender information. The data received from lab senders can be in different formats depending on vendor products that generated the message data. Message data ingestion will account for different message types. The ORU and eCR messages will be directed to the MDSS application and the ADT messages will be directed to the MiCelerity application based on the diagnosis code. The incoming data will be transformed to a compatible format before ingestion. Initial processing will identify duplicate records, log messages for audit, and send acknowledgement to the senders. The MDSS 2.0 will include a data viewer to display the entire ADT and eCR message received to users for analysis purposes. Failure message processing will be logged for auditing purposes. ELR monitoring report will be provided as part of the service to track the messages received from each sender and allow the user to drill down on the data to verify the summary counts based on various parameters such as program type, frequency, etc. The solution will also generate user alerts to identify and send email to the administrator when a facility fails to send data within the expected timeframe for a message.

13. MIGRATION

Contractor must migrate the data identified in the table below:

Current Technology Oracle 19c

Relational

Number of data fields to give Contractor awareness of There are multiple schemas of different sizes. the size of the schema. The database also stores non-structured data in the form of files. Volume of Data Estimated 3million individual records (rows) Estimated several dozen data elements each (columns)

Database current size.

Relying on firsthand knowledge of the current MDSS database, Contractor must transfer all necessary data from the old MDSS system to the new system. This task will be accomplished using various techniques, including but not limited to writing Java standalone loaders, PLSQL export routines, and SQL, and will be automated as much as possible to reduce the chance of errors on the final data migration for the go-live.

Contractor must design and implement the appropriate processes to extract and insert the data into new databases accounting for different types and formats of data. Data that needs to be transformed to a new format, will be transformed with a standalone Java program. Other data extraction might use PLSQL, or any process that is appropriate.

By addressing data migration early in the development process, Contractor will ensure that all processes needed to populate the new system are ready, tested, and working far before go-live of the new system. This will make final deployment as smooth as possible.

In order to plan for current and future data requirements, Contractor must derive current growth rates from pandemic and non-pandemic time frames. Contractor will work with DTMB engineers to create a data growth plan based on speed and data access business requirements. While the system will be hosted at a State hosting center, Altarum will help DTMB gather the necessary data to create and test a data growth plan to insure that the MDSS 2.0 will be able to handle the anticipated growth and the spikes we would see during the next pandemic.

The data storage for this system will consist of two independent databases. One database will be used for data entry, updating, and processing of case-based reportable disease cases and all the supporting data. The other database will store all the information for reporting and export. Both databases will be constructed so that they can scale as needed, whether at the start or end of a public health emergency.

Scaling up of these databases will consist of adding more resources. The resources needed for database scale are system memory, SAN space, and CPU cores. By increasing some or all these resources, the system will be able to store more information and increase database throughput.

Scaling down would likely happen when a public health emergency ends. The same resources that are available for database scaling up will be used to scale down. With less throughput necessary, it will be possible to reduce the memory footprint, give back CPU cores, and give back SAN. However, it is unlikely that the State would want to store less information in the database, so giving back SAN would only occur if the State wanted to store less historical information in the system.

Costs associated with migration are integrated into our solution pricing presented in Schedule B – Pricing.

Contractor's unique knowledge of the current systems database design and content will allow data migration design and implementation to begin as soon as the database designs have been completed. To accomplish this task, Contractors will use various techniques including Java standalone loaders, PLSQL export routines, and SQL. The goal will be to automate this process so that when we are ready to populate the Production environment, it will be as error-free as possible.

Contractor will begin the process by migrating data to the new Test environment. Once perfected, we will move on to the Stage and eventually the Prod environments. By designing and implementing the solutions along with the development effort, the State will be assured that when MDSS 2.0 goes live, the process to populate the new system with all appropriate data from the existing system is known and verified.

The database may be increased at the time of transition, if required by the State.

14. TRAINING SERVICES

The Contractor must provide administration, end-user, train the trainer, training for implementation, go-live support and transition to customer self‐sufficiency.

Modernized training services will accompany the new system. We will take our years of subject matter expertise creating materials and conducting trainings for MDSS users, along with Contractor’s expertise in creating and conducting accredited continuing education courses for healthcare providers and public health, to create trainings that will minimize the disruption of ongoing work activities. Given the COVID-19 pandemic and to prepare for future events, we will create a virtual learning center with instructor-led online sessions, as well as recorded sessions for self-paced learning. Training courses will be tailored to the type of user and the level of knowledge. We will create train-the-trainer, end-user, and administrator trainings.

Contractor must develop a comprehensive training plan. The plan will outline the course curriculum by type of user. The plan will include course objectives and expected outcomes, course materials, delivery methods, the length of the courses, class sizes, and schedule. The plan will also identify training staff, developers, and subject matter experts and their hours available during Go-live. We will detail our Go-live Command Center structure, communication plan, and transition plan.

15. TRANSITION RESPONSIBILITIES See Schedule F for Transition In and Out plan.

16. DOCUMENTATION Contractor must provide all user manuals, operating manuals, technical manuals and any other instructions, specifications, documents or materials, in any form or media, that describe the functionality, installation, testing, operation, use, maintenance, support, technical or other components, features or requirements of the Software.

Contractor must develop and submit for State approval complete, accurate, and timely Solution documentation to support all users, and will update any discrepancies, or errors through the life of the contract.

The Contractor’s user documentation must provide detailed information about all software features and functionality, enabling the State to resolve common questions and issues prior to initiating formal support requests.

Contractor will create, update, and maintain the required documentation. Contractor will leverage years of experience working with end-users, administrators and DTMB to ensure the Contractor has created clear, concise, and approved documentation for the new system. The documentation we have created and maintained in the past, and will continue to develop for the new system, include:

1. MDSS Specific Documentation:

a. User and Technical Manuals b. Data Element Dictionary c. Operations Manual

2. System documentation required by the State, include the following documents. Some of these will be led by the State with input from Contractor:

a. Functional design documentation b. System design documentation c. System Security Plan (SSP) using the State’s governance, risk, and compliance tool d. Maintenance Plan

e. Enterprise Architecture Solution Assessment (EASA) f. Technical components information necessary for completion and maintenance of relevant data sharing agreements and interconnection sharing agreements g. Disaster Recovery Plan h. Installation procedure i. Module configuration documents for configuration maintenance purposes j. Requirements documentation k. Testing scripts and scenarios l. Test plan and traceability matrix m. Specification documentation n. Production migration documentation

17. ADDITIONAL PRODUCTS AND SERVICES

Contractor must add the following enhancements to the MiCelerity module as part of the base system and at no additional costs to the State. We understand that these are important to MDHHS and we can use the microservices of the base system to add them when we port the MiCelerity module to the MDSS 2.0.

• Integrate with State MPI exchange and send the patient records from MiCelerity to enhance deduplication in MiCelerity.

• Solution must have the ability to export the drug related event data from MiCelerity and format the data to automatically send the details to the CDC using secure message transfers.

• Solution must be able to create dhoc reports to drill down the ADT messages received from different facilities to check the message data quality and validity of the incoming messages.

• Solution must integrate with State data warehouse to send the overdose event data from MiCelerity.

• Solution must add the ability to add new diagnosis codes and retire older codes and transition the existing events between different drug groups.

The system must also need to access to the following support services.

SAP geocoder service – The incoming addresses to MDSS will be cleansed and geocoded by the SAP geocoder. The new MDSS will need to be able to utilize this system as well. This service will be accessed in all three state hosted environments dev, stage and prod. This service will require firewall updates to enable the access to the new MDSS.

Bing geocoding service – The MDSS needs to have a school district associated with every address. In the current MDSS system, a call is made to the BING service to retrieve this information and we plan to use it in the new MDSS 2.0. This service will be accessed in all three state hosted environments dev, stage, and prod. This service will require firewall updates to enable the access to the new MDSS.

LDAP service – To retrieve email addresses, etc. for the system users, MDSS connects to the state’s LDAP service. Various modules send emails to the users and it is essential we have the most up to date email address available. This service will be accessed in all three state hosted environments dev, stage, and prod. This service will require firewall updates to enable the access to the new MDSS.

Email Service – MDSS sends emails to users, providers, and lab facilities based on various system functions. This service will be accessed in all three state hosted environments dev, stage, and prod. This service requires firewall changes.

18. SUGGESTED ROLES AND RESPONSIBILITIES FOR AGILE DEVELOPMENT

Below is a description of the roles and responsibilities of the parties and may be utilized as a guidelines for the completion of this project.

18.1 Team Experience and Training with Agile Techniques For key Scrum Development Team members (Contractor PM, Contractor Scrum Master, Business Analyst, Lead Tester and Lead Developer) the Contractor must supply appropriate documentation on their experience using agile practices on successful projects delivered within the last 3 years. Training and prior experience with agile development processes, procedures and practices is required. The State prefers a combination of certifications and documented successful application of Scrum and Extreme Programming (development and testing practices). The State’s preference is for certifications from Scrum.Org of one or more of the following: • Professional Scrum Master I (Contractor PM/Scrum Master) • Professional Scrum Product Owner (Contractor Business Analyst, Contractor Test Manager) • Professional Scrum Developer (Contractor Lead Developer)

• Project Management Institute – Agile Certified Practitioner (PMI_ACP) (Contractor PM, Business Analyst, Lead Tester)

Other certifications can be substituted at the State’s discretion.

The Contractor understands and accepts the assigned responsibilities for the activities as defined in the following responsibility matrices. The responsibilities address the following agile development areas:

Responsibilities are defined in accordance with the Ownership model: • Owner (O) – Operational Owner role ensures the execution of a respective activity and realizes the respective deliverable for the activity. A Contractor can be the Owner of Some activities. • Accountable (A): o The business role has overall accountability for defining and accepting deliverables and owns the budget. Accountability also extends to the product or project Governance Board. o During execution, accountability rests with the sprint teams, the Product Owner, who is a representative from the Organization's business, and the Contractor. • Contributor (CtB) – Roles that proactively support the Owner role in executing an activity and realizing the deliverables (i.e. developers, testers, business analysts, Operations, Architects). • Collaborator (Coll) – Roles that proactively support the Owner role in executing an activity and realizing the deliverables (i.e. developers, testers, business analysts, Operations, Architects).

18.2 Post-Award – Sprint 0 and First PI Planning During the post award Sprint 0 the State and selected Contractor will work closely to establish the scrum development team and the physical and development environments necessary for a successful engagement. For the purposes of this engagement key personnel on the Scrum Development Team include (but not limited to) the State Product Owner, MDHHS Project Manager, DTMB Project Manager, MDHHS Core Team, Contractor Project Manager / Scrum Master, Contractor Technical Lead, Contractor Business Analyst, and Contractor Test Manager

If colocation of the entire team is not possible then the Contractor must identify the technologies being utilized (at Contractors expense) to afford as near a colocation experience as possible. The Contractor Project Manager must be located on site with MDHHS staff or as negotiated with MDHHS Project Manager.

In addition to project start-up activities, refinement (elaboration of the key Epics and Features) of the first PI is conducted during Sprint 0. The refinement includes detailing of the user stories targeted for the first several sprints.

User stories will be specific enough to be completed (meet the “Definition of Done”) in less than a single sprint, and will comply with any architecture, functional and nonfunctional principles set out

by the State and agreed to by the Contractor. Sprints reflect the combined effort of the team to realize an agreed set of objectives, where objectives reflect features and artifacts of user stories.

The PI Authorization Work Order form may encompass one or more sprints. The PI Work Order form will specify the target environment(s) for the PI delivery and additional items in the “Definition of Done” for the PI in order for the Work Order to be considered complete and payment authorized

The State and Contractor agree that the State — at its sole discretion — can decide to initiate a PI work order. A PI work order shall cover all activities to deliver a PI, except for warranty work executed during the PI work order period. Warranty work is delivered at zero cost by Contactor to the State.

Table 2 - Post-Award Sprint 0 & First PI Planning State Contractor Operations [Dev] [Ops] Present PV. A/O Coll Create and maintain Architectural Vision that supports the PV. A/CtB O Coll Present Architectural Vision. A/CtB O Coll Select Architectural Vision. A/O Coll Coll Develop initial architecture diagrams (EASA) for the PV’s first PI. A/Coll O Coll Develop initial product security assessment (GRC Governance, Risk A/Coll/O CtB Coll and Compliance) for the PV’s first PI. Review DTMB-3533 with eMichigan. A/Coll O Establish the development, test and user acceptance environments for the PV realization, based on AV and development architecture A/Coll O Coll (training environment maybe also be added).

Identify scrum development team members and verify their A/CtB O Coll allocations. Define PI. - Set PI objectives (as much as possible specific, measurable, agreed, realistic, time-bound (SMART)) terms. A/O CtB Coll - Update Product Backlog Traceability (PBT) tracing Epics to Features and Features to user stories.

Write user stories — in support of the PI CtB Coll - Use agreed templates and tools. A/O - Define "Acceptance Criteria" per story. Assign business value to user stories. A/O CtB Estimate required number of sprints to deliver the PI. AO/CtB CtB Create tentative sprint plan (allocate stories to sprints). A/O Coll Ongoing grooming, elaboration and refinement of the product A/O CtB backlog. Define test strategy for the PI including at least one End 2 End test A/O/Coll O/CtB/Coll sprint.

18.3 Sprint Execution Once development of a PI begins the Sprint Execution cycle (planning, build, review, retrospective) is repeated (per the release plan) until the PI is complete and accepted.

Table 3 - Sprint Planning — Once Per Sprint, Potentially State Contractor Operations Multiple Sprints per PI [Dev] [Ops] Determine main focus of sprint: - New features, technical debt reduction, warranty work. A/O Coll - Integration and PI delivery. Formalize delivery plan per sprint (Team effort). All team members participate. - Product Owner states the order of the user stories desired in the sprint. A/Coll O/CtB - Teams discuss objectives, risks and dependencies. - Teams agree on final user stories for the sprint. - Team self-assigns user stories, defines tasks and adds effort hours to tasks. Finalize test cases per sprint. A/CtB O/CtB - Automate successful tests Set up/maintain Sprint Board – physical and/or electronic. A/CtB/Coll O Identify sufficient work for the sprint (user stories) that meet the A/O/Coll Coll/CtB Definition of Ready. Commit to the user stories to be delivered in the sprint. Coll O Update PBT by tracing all user stories to features and features to A/Coll O/CtB EPICS on the PBT.

Table 4 - Sprint Execution (build) State Contractor Operations [Dev] [Ops] Manage objectives across affected stakeholders A/O CtB - DTMB Project Manager (PI/PV focus) Manage objectives of the PI - Project Manager /Scrum Master (PI focus) A/Coll O/Coll - Technical architect (AV focus) Provide guidance and details on User Stories - Agency Product Owner A/O/Coll CtB/Coll - DTMB Business Analyst Deliver User Stories - Scrum Master - UX Designers (optional) A/Coll O/Coll - Developers - Testers Validate and verify (test) realized User Stories: Developers and Testers Coll/CtB A/O/CtB/Coll - Unit, Integration, functional testing to ensure user stories meet "definition of done" Validate and verify (test) realized User Stories: Agency Product Owner A/O/Coll CtB/Coll Acceptance testing of the user story Update backlog for upcoming sprints – Agency Product Owner / Contractor Business Analyst - Refine, order User Stories A/Coll O/Coll - Assess Impact on next sprints - Include defects and requirement changes identified in Sprint Review (Demo) Contractor Business Analyst A/CtB O/CtB/Coll - Update PBT

Table 5 - Sprint Review and Retrospective State Contractor Operations [Dev] [Ops] Scrum Team reviews all user stories delivered in the sprint (meets Definition of Done) with Agency Product Owner and other affected A O Stakeholders Scrum Team reflects (Retrospective) on the completed sprint by identifying what practices and procedures went well (continue using), what practices and procedures didn’t go well (stop doing), Coll A/O/Coll what improvements should be made in the next sprint, who is assigned to take action on the improvements

18.4 Product Increment End 2 End User Acceptance Test Sprint UAT occurs on each user story as it is built and automated regression testing proves that new items are successfully integrated. When several sprints are needed to achieve a PI, End 2 End UAT is needed to verify and validate typical business flows.

All defects deemed Critical must be remediated prior to Acceptance of the PI by the State Product Owner and Executive Sponsor (or designee). Acceptance of the PI is required to trigger payment to the Contractor for the PI. At the State’s discretion they may authorize only partial payment for the PI or in the case of the final PI for the project holdback a portion of the payment until all Warranty work is completed.

During the End 2 End sprint, the design documents for the current PI are finalized, reviewed (structured walkthrough) with the State, and delivered as part of the PI.

Table 6 - Product Increment End 2 End UAT Sprint State Contractor Operations [Dev] [Ops] Validate and verify (test) Developed Functionality (PI) A/O/Coll CtB/Coll – State Product Owner Contractor must submit compiled source code that has completed UAT and has been approved by the Agency to DTMB Agency Coll A/O Services for security validation. (AppScan) Contractor completes design documentation and other non-code Coll A/O deliverables. State reviews and accepts non-code and design documentation. A/O CtB/Coll If State hosted, the State PM submits the Operations Request For A/O Coll Change (RFC) if needed. Application Deployed to target environment or to Production O A/CtB State Executive Sponsor and State Product Owner accepts (written communication) the PI once all Critical and High defects are A/O remediated All medium and low severity defects are recorded in the Product A/O CtB Backlog. State Executive Sponsor authorizes payment (full or partial) for the A/O CtB PI

18.5 Subsequent Release Planning Each new release on the State’s Release Roadmap starts with a planning session that: • Reflects on the results of the prior release including Contractor Performance (on time delivery, quality, performance metrics (velocity, code quality, test results etc.) • Finalizes the contents and number of sprints to achieve the next PI (next release).

Table 7 - Product Increment Definition & Planning State Contractor Operations [Dev] [Ops]

Assess Contractor Performance on previous release to SOM A/O Upon the first occurrence of unacceptable PI delivery the Contractor must be able to prepare and submit a Corrective Action Plan (CAP) A/O to bring performance (productivity and quality) to State standards and expectations. State Executive Sponsor awards the next PI Work Order to current A/O Contractor (e-mail sent to Contractor) by State Executive Sponsor. If the primary Contractor has submitted a CAP from the prior release but terms of the CAP have not been met (performance still does not meet State standards and expectations) the executive sponsor A/O - Notifies the current Contractor of SOW Termination (in writing) - Awards the next PI Work Order to the next qualified Contractor (Executive Sponsor engages Contractor and begins transition) Define PI. - Set PI objectives (as much as possible specific, measurable, agreed, realistic, time-bound (SMART)) terms. A/O CtB Coll - Update PBT tracing Epics to Features and Features to user stories. Write user stories — in support SOM PI - Use agreed templates and tools. A/O CtB Coll - Define "Acceptance Criteria" per story. Assign business value to user stories. A/O CtB Estimate required number of sprints to deliver the PI. AO/CtB CtB Create tentative sprint plan (allocate stories to sprints). A/O Coll Ongoing grooming, elaboration and refinement of the product A/O CtB backlog. Define test strategy for the PI including at least one End 2 End test A/O/Coll O/CtB/Coll sprint. Update PBT by tracing all user stories to features and features to A/Coll O/Coll Epics on the PBT. Ongoing grooming, refinement, elaboration of user stories A/Coll O/CtB

19. CONTRACTOR PERSONNEL

Contractor Contract Administrator. Contractor resource who is responsible to(a) administer the terms of this Contract, and (b) approve and execute any Change Notices under this Contract.

Contractor: Altarum Institute

Name: David Banks Address: 2000 M Street Washington, DC 20036 Phone: 202-776-5111 Email: [email protected]

Classification Skill Set Years of Experience Architect/Integration Lead (key) Surveillance system design and 15+ yrs. maintenance, Java development, Database development, HL7v2, EDI, the Clinical Document Architecture, FHIR specifications, wide range of messaging transports; Java Server Pages (JSP), JavaScript, HTML, XML, Hibernate, Oracle database management and configuration, GIT, ANT, Jasper, HL7, Python, REST, SOAP, FHIR, Gradle, webservice integration Development Team Lead Surveillance system 10+ years design/maintenance, Java/J2EE applications and coding standards, cloud-based servers, wide range of messaging transports, HL7 and FHIR standards; Java, Java Server Pages (JSP), JavaScript, HTML, XML, Hibernate, Oracle database management and configuration, GIT, ANT, Jasper, Python, REST, SOAP, FHIR, Gradle, webservice integration User Experience Manager Project management, surveillance 10+ years system design/maintenance; Software development using Java, JSP, Oracle SQL, HL7, XML; experience with MDSS and SOM, web service integration; UI Team Lead (key) Leading front end design and 5+ years development; Javascript, HTML5/XHTML, Bootstrap, CSS, SCSS, JSON, jQuery, Ajax and XML; modern Javascript frameworks like VUE, React or Angular2 Reporting/Analytics Team Lead Java, JavaScript, C/C++, 10+ years C#/VB.NET, Delphi/Object Pascal, Python, PHP, x86 Assembly Language, PL/I, PowerBuilder, Oracle SQL & PL/SQL, MySql,

SQLite, PostgreSQL, DB2, Informix, Access, Spatially enabled DBMS/ArcSDE, SAS EBI, OLAP Cubes and integration with web mapping APIs, GIS dataset creation, web mapping, and spatial analysis, ESRI ArcGIS Desktop, Server, and Web Mapping APIs, EDI, XML, json/geojson, DOS/Shell Scripting, EDI, XML, json/geojson, DOS/Shell Scripting, various OS QA Team Lead Software Engineering Quality 10+ years Assurance Testing; Software QA, Agile processes, Selenium, Redwood, LoadRunner

DevOps Team Lead (key) Software Deployment, IT 10+ years Management, Cloud Services, Project Management; Microsoft SQL Server, Microsoft Clustering, Active Directory, Microsoft Exchange, Microsoft IIS, Remote Desktop Services, Citrix, Office 365, Network Firewalls (Cisco, Palo Alto, F5, Sonic Wall, Juniper), Network Switches (Cisco, Dell, Extreme), Wireless Networking (Cisco, Aerohive, AirPort), Azure VM, Gateways, Network Security, Subnets, Storage Accounts, SQL, Apache, Tomcat, Open DNS, Microsoft Team Foundation Server, Microsoft SharePoint, Json Template Deployments, Chef Database Team Lead (or Sr Database development, Java, 10+ years Database Admin) Kodo, Hibernate Analyst Performance testing; Agile, 3+ years NeoLoad Performance Testing Tool, Performance Testing Level, JIRA, Tableau, Microsoft Power BI,HL7 messaging, Enterprise Architect, LoadRunner, Java, HTML Integration Engineer Rhapsody development, 7+ years implementation, development, and maintenance; NSSP/Biosense Java, PHP, Perl, FHIR eLTSS, Javascript, JMS QA Engineer Quality Assurance testing in an 5+ years Agile framework, Selenium, Redwood, Sr Software Engineer Software development and 10+ years maintenance; Java, Java Server Pages (JSP), JavaScript, HTML, XML, Hibernate, Oracle, NoSQL databases, MongoDB, GIT, ANT, Jasper, HL7, Python, REST, SOAP, FHIR, Gradle, webservice integration Software Engineer Software development and 5+ years maintenance; Java, Java Server Pages (JSP), JavaScript, HTML, XML, Hibernate, Oracle database management and configuration, GIT, ANT, Jasper, HL7, Python, REST, SOAP, FHIR, Gradle, webservice integration Scrum Manager Scrum Master, Agile processes, 5+ years project management, product management, JIRA UI Engineer Web design and development, 5+ years Drupal, Java, Javascript, jQuery, Symfony, Oracle, HTML/CSS, XML,XSLT, Bootstrap

20. CONTRACTOR KEY PERSONNEL

Contractor Project Manager/Scrum Master. Contractor resource who is responsible to serve as the primary contact with regard to services who will have the authority to act on behalf of the Contractor in

matters pertaining to the implementation services, matters pertaining to the receipt and processing of Support Requests and the Support Services.

Contractor Name: Lakshmi Atluri Address: 3520 Green Court, Suite 300 Ann Arbor, MI 48105 Phone: 734-302-4704 Email: [email protected]

21. CONTRACTOR PERSONNEL REQUIREMENTS Background Checks. Contractor must present certifications evidencing satisfactory Michigan State Police Background checks, ICHAT, and drug tests for all staff identified for assignment to this project.

In addition, Contractor personnel will be required to complete and submit an RI-8 Fingerprint Card for the National Crime Information Center (NCIC) Finger Prints, if required by project.

Contractor will pay for all costs associated with ensuring their staff meets all requirements.

Offshore Resources. Contractor is not proposing to use any offshore resources.

22. STATE RESOURCES/RESPONSIBILITIES The State will provide the following resources as part of the implementation and ongoing support of the Solution.

State Contract Administrator. The State Contract Administrator is the individual appointed by the State to (a) administer the terms of this Contract, and (b) approve and execute any Change Notices under this Contract.

State Contract Administrator Name Mecca Martin Phone 517-230-5694 Email [email protected]

Program Managers. The DTMB and Agency Program Managers (or designee) will jointly approve all Deliverables and day to day activities.

DTMB Program Manager Name Heather Eakin Phone 517-528-5675 Email [email protected]

Agency Program Manager Name Jim Collins Phone 517-284-4911 Email [email protected]

23. MEETINGS

At start of the engagement, the Contractor Project Manager must facilitate a project kick off meeting with the support from the State’s Project Manager and the identified State resources to review the approach to accomplishing the project, schedule tasks and identify related timing, and identify any risks or issues related to the planned approach. From project kick-off until final acceptance and go-live, Contractor Project Manager must facilitate weekly meetings (or more if determined necessary by the parties) to provide updates

on implementation progress. Following go-live, Contractor must facilitate monthly meetings (or more or less if determined necessary by the parties) to ensure ongoing support success.

The Contractor must attend the following meetings, at a location and time as identified by the state, at no additional cost to the State: • Weekly

Upon initiation of the award, Contractor’s project manager will coordinate with the State’s Project Manager to schedule the project kick-off meeting. The kick-off meeting will take place within 30 days of the project execution. Contractor’s project manager will be prepared to review the project plan, work breakdown structure, schedule, and milestones. Contractor will present to the State team any foreseeable issues and risks with mitigation strategies. Contractor will update the project plan as recommended and approved by the DTMB and MDHHS Program Managers.

During the kick-off meeting the Contractor will establish an agreed-upon schedule for project status meetings. With our long- standing experience coordinating with the State team, we are recommending weekly status meetings throughout the duration of the project. We also recommend continuing with our Scrum methodology, and recommend key State staff attend our daily stand-ups during releases/go-live and will facilitate ad-hoc meetings as needed.

24. PROJECT CONTROL & REPORTS

Once the Project Kick-Off meeting has occurred, the Contractor Project Manager will monitor project implementation progress and report on a weekly basis to the State’s Project Manager the following: • Progress to complete milestones, comparing forecasted completion dates to planned and actual completion dates • Accomplishments during the reporting period, what was worked on and what was completed during the current reporting period • Indicate the number of hours expended during the past week, and the cumulative total to date for the project. Also, state whether the remaining hours are sufficient to complete the project • Tasks planned for the next reporting period • Identify any existing issues which are impacting the project and the steps being taken to address those issues • Identify any new risks and describe progress in mitigating high impact/high probability risks previously identified • Indicate the amount of funds expended during the current reporting period, and the cumulative total to date for the project.

On a weekly basis throughout the lifecycle of the project, Contractor will provide data to the State’s Project Manager to feed the weekly status report. The approved project plan, with the identified metrics, will serve as the baseline for tracking the project status. Contractor’s project manager will monitor for change in resource productivity and availability, expected activity durations, and unanticipated risks. Contractor will notify the State’s Project Manager if there is a potential adjustment needed in the project schedule and project budget. Contractor’s project manager will provide the status of the following:

• Change in forecasted key milestone completion dates • The current activity and accomplishments • The number of hours expended during the past week • Identify if the estimated hours are enough to complete the project • Tasked planned for the next reporting period • Issues and risks with mitigation strategies • Additional status reporting metrics to be negotiated. o Error Reports with description of error and time for resolution from Schedule C - Service Level Agreement. o Performance to response and time reports from Schedule C – Service Level Agreement o Progress report which must contain: . Accomplishments: Indicate what was worked on and what was completed during the current reporting period. . Upcoming Tasks: Indicate tasks due within the next reporting period.

. Risks: Indicate any risks, problems, or issues, which could delay the project or endanger its success. . Updates: New releases or bug fixes to be delivered by Contractor in the next reporting period. . Summary of end user training provided and most common support issues o Annual Security Report . Contractor will provide security and control information for the State's annual security review with remediation of any issues reported in the monthly status reports.

25. PROJECT MANAGEMENT

The Contractor Project Manager will be responsible for maintaining a project schedule (or approved alternative) identifying tasks, durations, forecasted dates and resources – both Contractor and State - required to meet the timeframes as agreed to by both parties.

Changes to scope, schedule or cost must be addressed through a formal change request process with the State and the Contractor to ensure understanding, agreement and approval of authorized parties to the change and clearly identify the impact to the overall project.

SUITE Documentation In managing its obligation to meet the above milestones and deliverables, the Contractor is required to utilize the applicable State Unified Information Technology Environment (SUITE) methodologies, or an equivalent methodology by the Contractor.

SUITE’s primary goal is the delivery of on-time, on-budget, quality systems that meet customer expectations. SUITE is based on industry best practices, including those identified in the Project Management Institute’s PMBoK and the Capability Maturity Model Integration for Development. It was designed and implemented to standardize methodologies, processes, procedures, training, and tools for project management and systems development lifecycle management. It offers guidance for efficient, effective improvement across multiple process disciplines in the organization, improvements to best practices incorporated from earlier models, and a common, integrated vision of improvement for all project and system related elements.

While applying the SUITE framework through its methodologies is required, SUITE was not designed to add layers of complexity to project execution. There should be no additional costs from the Contractor, since it is expected that they are already following industry best practices which are at least similar to those that form SUITE’s foundation.

SUITE’s companion templates are used to document project progress or deliverables. In some cases, Contractors may have in place their own set of templates for similar use. Because SUITE can be tailored to fit specific projects, project teams and State project managers may decide to use the Contractor’s provided templates, as long as they demonstrate fulfillment of the SUITE methodologies.

The Contractor is required to review http://www.michigan.gov/suite and demonstrate how each PMM/SEM requirement will be met. Contractors wishing to use their own documents must submit an example of the document that will be substituted. If the Contractor deems a document to be non-applicable, please provide reasons for the determination. The State reserves the right to give final approval of substituted documents and items marked as non-applicable.

This section is under development the Contractor and State will come to mutual agreement on the project planning and implementation of the system pending the assessment completion.

Sprint 0: Planning The Project Management Plan (PPM-0102) outlines the following information: • Project Summary • High Level Schedule • Human Resource Management Plan • Project Budget • Communication Management Plan

• Change Management Plan • Quality Management Plan • Risk Management Plan • Issue Management Plan • Detailed Project Schedule (Release/Sprint), Milestones and Resources

Additional planning documentation will include a Business Continuity Plan and a Disaster Recovery Plan which will be completed and maintained in partnership between the Contractor and MDHHS. MDHHS and DTMB will approve updates and final deliverable.

Backlog & Backlog Refinement In Agile framework, the traditional Requirements Document (SEM-402) and Requirements Traceability Matrix (SEM-401) are replaced by the Product Backlog (Story Map / Epics /Features / User Stories). Due to the volume of small user stories an automated tool is used to house the Product Backlog and provide traceability from the high-level Story Map through user story, checked in code, build, and test cases / results.

Backlog refinement (grooming) will be an ongoing activity during the course of each Sprint. Refinement activities will include: • Facilitated workshops with the Product Owner and Subject Matter Experts to document and refine Features, Epics, and User Stories that meet the project’s Definition of Ready • Ordering (or re-ordering) Stories based on current value to the customer • Removing Stories that are no longer valid • Including Technical Debt stories as needed • Managing the backlog to keep it in agreement with Project Story Map, PIs, and releases • Identify backlog stories marked for delivery in next Sprint prior to that Sprint’s planning session • Product Backlog Traceability (in the Product Backlog Tool)

Design In Scrum/agile approach emphasis is on the “as built” documentation rather than a big upfront design. During Post Award – Sprint 0, the following application assets (functional and system design) are started and are continually elaborated as the project progresses to reflect the “as built” design. In Sprint 0, just enough of each is documented to communicate the overall direction to the development team, security architects (Keylight LockPath), enterprise architecture (EASA) and other teams as needed.

At each PI or release to production, these assets are considered part of the formal deliverables and must reflect the “as built” delivered functionality of the PI. A formal Structured Walkthrough with the State’s IT and Business partners must be conducted PRIOR to the acceptance and payment for the PI, during the PI End 2 End UAT Sprint. o Functional Design . Application . Database . Interface(s) . Integration(s) . Data dictionary o System Design . Application . Database . Interface(s) . Integration(s) . Architectural Assessment (EASA collaboration and documentation) . Security Assessment (Governance, Risk, and Compliance process)

Development This section describes the items to be delivered that satisfy the scope of the project outlined in this SOW. o Configuration Management Plan (including branching and merging procedures) o Delivered Application – Source code, scripts / procedures (including build, deploy, etc.), Conversion assets, Configurations, Test Scenarios and Test cases and all executables including any automated tests o Application Databases – Design, Source code, and scripts/executables

o Solution Interfaces o Solution Integrations o Product Backlog in the State’s instance of Team Foundation Server o Product Backlog Traceability Matrix (story map - features - Epics - User stories- code check in / build- test case – test case outcome) o Agile Metrics as defined in the Status Reporting - Project and Product Quality Section

Implementation The following items are created / updated / delivered at each release to production. o Installation instructions / procedures o Implementation schedule including installation acceptance testing o Staff Training o Back out / recovery plans and procedures o Backup procedures o Technology Continuity Plan o Updated Disaster Recovery Plan o Request for Change (RFC for move to production) o End 2 End User Acceptance and final Regression testing o Go Live Support Plan

Agile Test Strategy Provides a single document to describe the types of testing the project will execute (and where in the life cycle each is executed) to ensure delivery of a maintainable and quality product that satisfies the State of Michigan’s business and technical needs. It also includes information on test assets (number and location of each test environment, tools, cases, data, results, and defect reporting). The document outlines the number of testers (by type of testing) and the approximate timeframe they are needed (for planning purposes). Types of testing that should be performed are: o Unit o Functional o Integration o User Story Acceptance o Performance o System and Standards o Regression (automated) o End 2 End UAT including regression testing by the State

Testing Environments o Local o Development o QAT o UAT o Training

Knowledge Transfer / Transition o Transfer / transition workgroup sessions with appropriate materials o Security Information including accounts and pass codes

Training / Documentation o End User Guides o Training website/mobile application o Administration Guides o Technical Installation & Support Guides

25.1 Deliverable Acceptance Criteria 25.1.1 Document Deliverables Documents include, but are not limited to plans, design documents, project schedules, user guides, and procedure manuals. o Documents are dated, version controlled, and stored in the State Repository in electronic format, compatible with State of Michigan software. o Draft documents are not accepted as final deliverables. o The documents will be reviewed and accepted in accordance with the requirements of the Contract. o MDHHS and DTMB will review business documents within a mutually agreed upon

timeframe. o Approvals will be written and signed by MDHHS Project Manager and DTMB Project Manager. o Unacceptable issues will be documented and submitted to the Contractor. o After issues are resolved or waived, the Contractor must resubmit documents for approval within 30 days of receipt.

25.1.2 Software Deliverables Software includes, but is not limited to, software product, development tools, support tools, integration software, and installation software. o Beta software is not accepted as final deliverable. o The software will be reviewed and accepted in accordance with the requirements of the contract. o MDHHS will review software within a mutually agreed upon timeframe for acceptance of functionality, usability, installation, performance, security, standards compliance, backup/recovery, and operation. o Approvals will be written and signed by MDHHS Project Manager and DTMB Project Manager. o Unacceptable issues will be documented and submitted to the Contractor. o After issues are resolved or waived, the Contractor must resubmit software for approval within 30 days of receipt. o Software is installed and configured, with assistance from DTMB as applicable, in an appropriate environment (e.g. development, QA testing, UAT testing, production, and training). o Contingency plans, de-installation procedures, and software are provided by the Contractor and approved by MDHHS Project Manager and DTMB Project Manager. o Final acceptance of the software will depend on the successful completion of UAT. o MDHHS will review test software, data, and results within a mutually agreed upon timeframe. o Approvals will be written and signed by MDHHS Project Manager and DTMB Project Manager. o Unacceptable issues will be documented and submitted to the Contractor. o After issues are resolved or waived, the Contractor must resubmit test software, data and results for approval within 30 days of receipt.

25.1.3 Final Approval o All documents and software are delivered and accepted by MDHHS Project Manager and DTMB Project Manager in accordance with the requirements of the contract. o For thirty (30) days after installation and configuration in the UAT environment, the software and any related infrastructure must meet or exceed acceptance testing requirements in accordance with the requirements of the contract. o Due to the nature of required data reporting at various times throughout the year, there will be a sixty (60) day period after the creation of quarterly, semi-annual, and yearly reports, in which the performance and reliability requirements must be met in order to prove the creation, operation, and accuracy of those first reports. o All bills related to this contract have been submitted and approved by the MDHHS Project Manager and DTMB Project Manager for payment. o A product roadmap is available to MDHHS Project Manager and DTMB Project Manager including information such as technical requirements, functional enhancements, and product availability periods.

25.2 Status Reporting – Project and Product Quality The Contractor Project Manager will store all user stories associated to and release related artifacts in the State’s Enterprise Team Foundation Server (TFS instance). The information needed to support the following reporting needs must be maintained by the Contractor and the Contractor’s staff.

• PI status a total story points by state: new, in progress, done, accepted, total.Project status (entire Product Backlog) total story points by state: new, done, accepted, total and sprint velocity.

The Contractor Project Manager will provide a status report to the MDHHS Project Manager, DTMB Project Manager, and Product Owner. The Contractor Scrum Master/Project Manager will provide the status in a

mutually agreed collaboration tool. The report will include: key project delivery milestone status, and estimated completion date for each key milestone.

The weekly status report submitted following a sprint planning session will include the following additional metric:

• Planned user stories for the sprint

The status report submitted following a sprint review (demo) will include the following additional metrics:

• User stories Accepted by the State Product Owner • User stories Done but not yet accepted by the State Product Owner • User stories in Progress and moving to the next sprint • User stories Planned but not started and being moved to the next sprint • User stories Planned but not started and moving back to the Backlog • Escaped defects (not found in the current sprint) remediated

Additional charts to be provided after each sprint review (demo):

• Planned vs Accepted user stories trended over time (last 6 – 10 sprints) • Projected number of sprints needed to complete all work in the Product Backlog (finish date): o Minimum user stories accepted in a sprint to date once the velocity has stabilized (usually 3-4 sprints after sprint execution starts) o Maximum user stories accepted in a sprint to date once the velocity has stabilized – (usually 3-4 sprints after sprint execution starts) o Average user stories accepted in a sprint (minimum of six sprints’ average)

Additional code quality metrics to be supplied with each status report:

• Number of successful builds • Number of unsuccessful builds • Number of automated regression test cycles executed • For each execution of the automated regression cycle: o Number of tests failed o Number of scenarios covered by automated regression testing • Percent Unit Test code coverage from the last build before submitting the status report

The status report will include other information relevant for the delivery of the project as may be agreed upon between the parties’ Product Owner and Scrum Master.

An online collaboration tool will be also used to track risks, action items, and issue escalations between the Contractor Project Manager/Scrum Master, the State Project Manager, and the State Product Owner.

Milestones/Deliverables for Implementation

The State’s milestone schedule and associated deliverables are set forth below.

Release Product Features Requirements Increment

Kickoff Completion of the Kickoff Meeting Sprint 0 Sprint 0 - Project scope and release plan R1 Architecture and Person Centric The system will be person centric and Design Design designed around the participant.

The system will associate information to a single participant.

The system will reduce duplication of participants during the creation of new participant records.

The system will have the ability to populate forms for entering and editing participant centric data.

Database Security & The solution will preserve all data Archiving indefinitely. All data will be backed up. This includes full data backups and incremental backups.

All data will follow DTMB policies and procedures as it relates to obfuscation and security of sensitive information.

The system will contain all existing MDSS data. System Security The system will use MiLogin for authentication The system will capture detail logs of access and record modification.

The system will be managed by a role- based access control interface

The system will allow for the creation and modification of all system roles and permissions.

System Availability The System will be accessible by all modern browsers. The system will be available to users 24x7 with the exception of scheduled and approved system maintenance.

The system will meet or exceed industry standard response times and load limits for web applications.

The system will be designed to meet ADA standards. The system will provide detail logging and error handling User Interfaces and The system will use menu's and keyboard Experience shortcuts for navigation.

The system will provide robust search functionality including Users, Diseases and Time Periods.

The solution will provide communications tools like bulletins, announcements and alerts.

The system will allow the management of drop down values and selection options as a way to adapt quickly to changing surveillance needs.

R2 Core Services Operational The system will allow for manual entry of Development Datastore participant information.

The system will allow for the modification of participant information during import.

Content The system will allow users to modify case Management System data that is assigned.

The solution will have a separate data reporting environment.

The system will include a dashboard for a user’s default page upon login.

The system will provide the ability to modify dashboards for each persona.

R3 Data The system will allow for automated entry of Management participant information from other systems and System Interfaces Automated Data The system will interface with the CDC Distribution and Consumption The system will interface with MPI

The system will utilize the Enterprise Service Bus The system will interface with the Rhapsody Service Bus The system will interface with the Rhapsody Data Quality Tool

The system will interface with TraceForce/PEG The system will accept LAB/eCR/ADT messages

Data Deduplication The system will automatically deduplicate at and Merge the patient level Management The system will automatically deduplicate case level data. The system will provide a mechanism to review records that have been merged from a deduplication process.

The system will provide a mechanism to un merge records that have been done by mistake.

The system will provide a manual method for merging case and user information.

R4 Reporting and Data Reporting The system will alert users to aberrations in Analytics reporting Module The system will have built-in, customizable, reporting and analytics

The system will provide exports of participant and encounter data

The system will provide location based reports of patient and encounter data.

Data Analytics The system will use data and trends to identify potential outbreaks.

The system will provide interactive data visualizations to support analysis

The system will allow the user to query MCIR for vaccination status

The system will identify reporting errors and messaging anomalies

The system will allow Administrators to be able to set user permissions based on defined roles.

R5 Disease Longitudinal The system will accommodate disease Specific Surveillance and specific rules for data surveillance and case Program Needs Case Management management

The system will allow a user to review all patient's history

The solution will incorporate all existing case management functionality in the current MDSS architecture

The system will allow for the creation of new condition through the UI.

Hospital Based The system will allow for the management Information / Medical of sending facilities Coded Data

The system will allow for the addition of new ICD10 codes The system will analyze hospital based information and medical coded data sources

R6 SUP, SUP architecture The SUP module architecture will be MICelerity, alignment modernized to conform with the MDSS Outbreak architecture. Management

At a minimum, the system will provide access to all legacy SUP functionality.

MICelerity The MICelerity module architecture will be architecture modernized to conform with the MDSS alignment architecture.

At a minimum, the system will provide access to all legacy MICelerity functionality.

OMS architecture The OMS module architecture will be alignment modernized to conform with the MDSS architecture.

At a minimum, the system will provide access to all legacy OMS functionality.

R7 Documentation, User Training The system will use a help function to Training and Manuals and provide contextual help throughout the Outreach Contextual Help. system.

The system will provide the ability to modify the contextual help text that is presented to the users.

Technical The vendor will provide system Configuration and documentation detailing setup process and User Guides configuration details and processes.

User Training The vendor will create and facilitate user Sessions training sessions for each system role.

All system training session will be recorded and published for future onboarding efforts.

R-All Final Testing & System Integration System integration testing will be performed Project Go Live Testing by the vendor as part of the sprint and release deployments.

System integration testing will take place prior to user acceptance testing during the lifecycle of the project.

User Acceptance The business unit will perform User Testing Acceptance Testing for each release.

There will be a designated regression test and End to end test prior to Go-Live

Project Go-Live User Acceptance Testing Approval and Go- Live

Termination of Contractor Statement of Work

If the Contractor supplied a Corrective Action Plan at the start of the prior release (unsuccessful release delivery), and the outcome of this release’s evaluation indicates the Contractor is still under performing, the Contractor’s SOW is terminated, and the State will negotiate all future releases with the next qualified Contractor.

26. WARRANTY

The warranty period is used for remediating defects and technical debt that was deferred by mutual agreement between State and Contractor prior to and during implementation and to remediate any additional defects found during the warranty period. Contractor must make corrections as per the defect severity agreed upon with the State. This work will be performed by the Contractor at no cost to the State.

Any release to production prior to the final Go Live will have warranty (defect corrections) work identified during the next release period. Warranty work performed during execution sprints is considered outside the scope of the normal build sprint and cannot affect Scrum Development Team Velocity.

The State will provide the single point of contact for reporting and recording defects. The Contractor is required to have Scrum Development Team members immediately available (during normal business hours) for escalated questions, research and defect identification and Severity 1 defect resolution. All other defects will be recorded in the Product Backlog.

Warranty Period

• Warranty Period – at least 22 months from “Go Live”

Service Level Expectations for Warranty Remediation after Go Live

• Critical - must be resolved (fixed, tested, released) within 24 business hours of the defect being reported by the State to the Contractor PM.

• Medium – will be added to the backlog by the State and the State will determine the order that items should be addressed as part of normal sprint planning during the Warranty period. • Low – will be added to the backlog by the State and the State will determine the order that items should be addressed as part of normal sprint planning during the Warranty period. The State expects the Contractor at a minimum to remediate all Critical and Medium defects during the Warranty period. Remediation of Low severity defects will occur as time permits.

27. ADDITIONAL INFORMATION

The State reserves the right to purchase any additional services or products from the Contractor during the duration of the Contract.

28. Exhibit A – Agile Definitions When used in the Statement of Work, the following capitalized words and phrases have these meanings: Acceptance Criteria – Conditions determined by the State Product Owner that a software product must satisfy to be accepted by a user, customer or other stakeholder. Agile – Set of Values and Principles characteristic of a family of methodologies embodying transparency, inspection, and adaption, that embrace engineering best practices and lean thinking. Backlog Refinement – On-going process executed during each sprint cycle that clarifies and orders future user stories. Business Day – Means a day other than a Saturday, Sunday or other day on which the State is authorized or required by Law to be closed for business. Contractor Project Manager – Individual assigned to manage the Project on a day-to-day basis and provides regular updates to the State. Defect – A failure of accepted User Story to meet its Acceptance Criteria or any applicable DTMB Standard once integrated with existing or additional project code. Definition of Ready – Criteria determined by the development team and agreed to by the Product Owner that verifies a user story is ready for inclusion in a future sprint. Definition of Done – Criteria determined by the Product Owner and agreed to by the development team which must be met before a PI (a single user story or group of user stories) is considered “Done” for reporting progress. Deliverables – All materials, information, documents, and reports, whether finished, unfinished or draft, developed or prepared by Contractor or any of its agents for delivery to the State in the course of performing the Services, including all source code and source code modules, build scripts, data loading scripts, configurations and configuration scripts, templates, and databases/tables. It is the Contractor’s responsibility to comply with terms and conditions regarding any third party or approved open source software and seek explicit approval from the State, when making them part of deliverables. DTMB – Michigan Department of Technology, Management and Budget. Epic – A description from the end user perspective of one or more functions, the software for which may not be capable of being developed in a single Sprint and may be broken down into a number of User Stories. UAT – End 2 End UAT Pre-release to Production - Successful completion of end-to-end testing, testing that is conducted on all of the components of the system, including but not limited to all interfaces to other systems, reports, batches and on output files. - If applicable, successful completion of performance testing and the system meets the performance requirements with regards to response times during simulated peak and average user volumes and endurance of the system.

- If applicable, successful completion of data conversion or migration and data cleansing, and successful testing of such conversion and migration. Go Live Acceptance – Acceptance by the State of the Product as satisfying the Go Live Criteria. Go Live Criteria – Includes each of the following: Successful completion of Final UAT; no Business critical or Major severity defects; All regression test scenarios passed; All scheduled training performed, and training guides completed according to training plans and schedules as required by the Contract and mutually agreed during Sprint 0; If applicable, all data converted successfully from legacy systems; All security profiles and roles loaded into the system and tested successfully; All performance testing completed successfully according to its acceptance criteria; Detailed deployment plan presented to the State. The Deployment Plan must be provided early enough for the State to review and approve the document; A detailed Operations and Maintenance Manual developed, presented to the State and State is given enough time to review and approve; All deliverables scheduled to be delivered prior to the deployment have been delivered and reviewed and approved by the State; All knowledge transfer tasks completed successfully as defined in the Knowledge Transfer Plans developed by the Contractor and approved by the Agency’s designated Training and Implementation Coordinator along with State Project Manager. Impeding Progress – Any problem, question or other issue that needs to be resolved to avoid blocking, impeding or slowing the development process. Minimum Viable Product – In product development, the minimum viable product (MVP) is a product which has just enough features to be of value to the State. It typically is the minimum set of features needed for the product to be useful in production (i.e. business users can accomplish one or more of their duties). Product – Overall deliverable(s) covered by this statement of work. Product Backlog – A list of all deliverables that need to be completed and accepted as specified by the statement of work. Product Increment – A grouping of User Story Deliverables contained in one or more Sprints. Product Owner – Scrum team member who is a member of the State Agency requesting the product and works with end users and other stakeholders to define, prioritize and accept User Stories detailed in the Product Backlog, to reflect the PV. Project – The activities required to create, deliver and deploy the Product as defined in this statement of work. Project Completion Date – The date on which the final Product, including all agreed upon deliverables, activities and warranty work, is accepted by the State. Project Term – The period commencing on the Commencement Date and terminating on the Project Completion Date. Release UAT (Non-Production deploy) – A period of testing where, actual software users test the software to make sure it can perform the required tasks in real-world scenarios, according to the agreed upon acceptance criteria. Scrum – A set of agile best practices characterized by a development team’s ability to deliver results quickly and to respond and adapt to emerging requirements. Scrum Master – The facilitator, coach and mentor of the Scrum team. The Scrum Master is

a member of the Scrum Team. 1. Scrum Development Team – Group of individuals (state (IT and Agency), Contractor or other Contractor) responsible for the development of the Product in accordance with this Agreement. 2. Severity 1 – Critical The System is not available/usable for all users. No workaround or temporary solution is available.

Severity 2 – High It is a highly severe defect and collapses the system. However, certain parts of the system remain functional.

Severity 3 – Medium End Users are not able to complete some core functions required for the normal business operations.

Severity 4 – Low Defect does not significantly impair end-user normal business operations or compliance of the system and does not impact core functionality. Sprint – A scrum sprint (typically 1-4 weeks) is a regular, repeatable work cycle during which user stories are developed, integrated, tested, and demonstrated to the Product Owner and other affected stakeholders. Sprint 0 – A “getting ready to go” phase of a project used to establish project infrastructure (budget, financials, procurement of technical infrastructure, and development team) to perform high-level collaborative product discovery with the product owner. Sprint Review (Demo) – A meeting upon sprint completion where the Scrum Team demonstrates completed (meets Definition of Done) user stories. The Product Owner provides feedback (may lead to additional user stories) and accepts completed work. Participants in the sprint review include the Scrum Product Owner, the Scrum Team and the Scrum Master. Other stakeholders (End users and other project representatives) may also attend. Sprint Backlog – The list of User Stories listed on the Product Backlog prioritized by the Product Owner and agreed to by the development team to be addressed in a particular Sprint. State/SOM – The State of Michigan. State Project Executive Sponsor – Agency’s Director level Manager who has ultimate authority and responsibility for the project. This is the person who secures funding, makes decisions regarding project resources and be the champion of the project. Story Point – A unitless measure of relative size of the effort, complexity and uncertainty used to compare one story to another for the purpose of capacity planning. Story Point Compensation – The Full Purchase Price minus the Acceptance Reserve, Warranty Reserve and Sprint 0 Compensation, with the sum divided by the gross number of Story Points as determined during Sprint 0. Testing Environments Local Developer workstation. Development (Test) The Scrum Development Team performs development, integration, unit, and functional testing in this environment. This is the environment where the Scrum Development Team will informally review their in-process work with the Product Owner. This environment also supports the first level of scheduled automated regression testing.

Quality Assurance Testing (QAT) The QAT environment is utilized for conducting end-to-end testing, including testing with external interfaces, if any. The QAT environment is utilized by Scrum Team Testers and the State Product Owner to verify acceptance criteria has been met in the developed application. User Acceptance Test (UAT) The UAT Environment will be utilized by the business community to perform final application testing (End 2 End UAT) prior to production deployment. This environment may also be used for performance testing. Training (Optional) A stable environment used for training end users to use the system. 3. User Acceptance Test (UAT) – The objective and measurable tests used by the State to confirm that each Deliverable outlined in the SOW is fit for purpose and meets the end user’s needs. 4. User Story – Lightweight description in everyday business language of how the user of the system interacts with it to achieve the user’s goals 5. Velocity – A measure of the amount of work a Team can deliver during a single Sprint and is the key metric in Scrum. Velocity is calculated by totaling the Story Points for all fully and accepted User Stories. 6. Warranty Period – 12 month period following the ”Go Live”.

29. Exhibit B – Tooling (State approved tooling) 29.1.1 Java Stack

Concept/Need Tool URL

1 Automate the process Jenkins https://jenkins.io/

• How do we pull all of this together?

2 Build the Code Gradle https://gradle.org/

• How do we compile the code? 3 Deploy Code Gradle - Scp https://gradle.org/

• How do we get WinScp the code on the web https://winscp.net/ server? 4 Static Code Analysis Gradle https://checkstyle.sourceforge.io/ plugins • Are we http://findbugs.sourceforge.net/ following coding standards?

5 Code Metrics Gradle https://pmd.github.io/latest/pmd_java_metrics_index.html plugins • Is it maintainable, Simple? 6 Code Coverage JUnit https://junit.org/ (Requires Unit Tests)

• How much of our business

logic code is tested? 8 Security Analysis Reshift https://www.reshiftsecurity.com/

• Is My Code JSHint https://jshint.com/about/ Secure?

9 ADA Analysis Pa11y http://pa11y.org/

• Is it JAWS http://www.freedomscientific.com/Products/Blindness/JAWS Accessible?

this should be fine

10 Automated Regression Selenium http://docs.seleniumhq.org/ Testing

• Is it still working today? 11 Requirements/Resource Jira https://www.atlassian.com/ Management

• What are we building? 12 Test Case Jira https://www.atlassian.com/ Management/Reporting

• How do I test? Did it pass?

SCHEDULE A – TABLE 1 - Business Specification Worksheet

A B C D

Business Business Contractor must meet how they will deliver the business

specification. Contractor must meet the details of any

Specification Specification configuration/customization and the impacted risk that may be Number caused if configured or customized to meet the business

Future Future specification.

Current Requires Requires Requires Capability Not Available Not Configuration Enhancement Customization

MANDATORY MINIMUM 1.0 Contractor must have at least 8 years of X Altarum has been working with MDHHS on all aspects of the MDSS for experience building, maintaining, almost 20 years. We began helping on programmatic aspects in 2003 and integrating and enhancing we formally won a bid to take over all development, enhancement, and communicable disease surveillance maintenance functions in 2006. Our staff have the required technology, systems, preferably for a decentralized and intimate knowledge of the Michigan environment and public health state health departments. interoperability including the Fast Healthcare Interoperability Resources (FHIR) standards expertise that will all be critical to this modernization effort. The MDSS has grown over the years to encompass not just communicable disease surveillance but also drug overdose surveillance, outbreak management, a syringe service program, along with an ever-increasing need to integrate with internal and external public health partners. These partners include the immunization program, vital records, chronic disease programs, local and national laboratories, the CDC, the Michigan Health Information Network (MIHIN), health care providers, local public health, and many others. Altarum has been MDHHS’ partner throughout this growth, enhancing and developing the MDSS to accommodate these new modalities. And the current pandemic has taught everyone many lessons and, as a result, we are prepared to modernize the MDSS so Michigan is better prepared for the next pandemic. 2.0 Contractor must demonstrate the ability X Altarum is fully prepared to rapidly scale up our project team to meet the to rapidly scale staffing to requirements and timeline of the MDSS 2.0 project. Success on this accommodate an aggressive project is a major strategic goal for Altarum and therefore it will implementation timeline, with strong receive priority in the assignment of any staff resources. organizational capacity and experience In anticipation of this work, we began recruitment activities and a among project leads realignment of internal technical resources in the Fall of 2020. Altarum is in the unique position of currently supporting the legacy MDSS while also proposing to support this modernization effort. Should we be awarded this

contract, Altarum will absolutely continue to support the legacy system at the same high level that MDHHS has come to expect, while fielding the MDSS 2.0 team. In addition to the current technical team of 60, we are planning to extend offers of employment to 4-7 new team members upon award. However, the majority of the team is already in place and available to begin work immediately. This includes analysts, software developers, database engineers, integration engineers, user interface engineers and quality assurance experts. With respect to hiring support for the project’s ongoing needs, Altarum has an exclusive employer brand and mission that appeals to skilled technical candidates, ensuring we can quickly attract the talent needed to support large contracts. Our skilled recruiting team regularly identifies, targets, and onboards specialized technical talent from around the country. We also work with third party staffing firms to supplement our hiring team when the need arises. 3.0 Contractor must have demonstrated X Altarum’s experienced team has managed handling data transmission for experience with digesting and public health systems for more than 20 years. The Altarum team has vast transmitting data to and from electronic experience with building public health systems that are adaptable to the systems, quickly adapting to changing needs of the public health officials to be able to manage, process, track, user needs, and automating workflows and analyze lab and case data received from various sources. to increase productivity, maintain data quality, and eliminate errors. Altarum developed the Data Quality Tool (DQT) which handles 90% of all incoming and outgoing electronic messaging traffic for the MDSS. The DQT inspects, validates, transforms and routes messages of various types including multiple HL7 version, encapsulated CDAs, XML, spreadsheets, electronic case reports and flat files. The DQT is based on the Rhapsody integration engine and our Integration Engineers are experts in its use and with other engines. Altarum also used the DQT to automate workflows by applying matching criteria algorithms for potential patient/case matches and utilizing program specific rules to automatically process messages into cases or to place them in a holding queue if manual intervention is required. Altarum also created the Validator system. The Validator provides pre- production onboarding support and production monitoring for nearly a dozen different HL7 use-cases including syndromic surveillance, electronic lab reporting, cancer reporting and newborn screening. The Validator ensures that incoming data providers are sending messages that meet data standards and must go through a testing process before their data is accepted into production systems. It reduces system errors by confirming data quality standards are being met and catching changes to external system sending data to the MDSS.

4.0 Contractor must demonstrate a plan to X The evaluation process will determine whether the disease surveillance evaluate the successful implementation system has been modernized. We will assess the system’s performance of the MDSS Modernization Initiative. and functionality against the business objectives and goals described in in this Contract. Based on the business goals described in the Contract, we have identified evaluation milestones, listed below, and measures as described in the Evaluation Section of the proposal. Milestones: 1. Increased automation 2. Improved data quality 3. Improved data linkage 4. Improved case management 5. Enhanced reporting capabilities 6. Improved team and reporter communications 7. Local customization 8. Improved system integration with requested systems We will collect data points to measure the milestones throughout the lifecycle of the project. Examples of the data points collected are: the status of the deadlines, the percentage of completion, budgeted expense status, identified issues, and risks and mitigation strategies. The data will be compiled and aggregated into reports for tracking project performance and metrics. Regularly scheduled team meetings will occur to continuously evaluate progress and develop mitigation strategies if needed. At the end of the project, we will produce a final assessment of the accomplishments, challenges, and opportunities including a description of the problems encountered, lessons learned, and potential improvements. REQUIRED 1.0 The Contractor solution must be a X X At Go-Live, the solution will be a person centric disease surveillance Person Centric system system. As such, a single patient record in the system will represent a single person in the real world. As new disease events occur over time for this same person, the data collected will be associated with the same patient record. This allows viewing the history of events, lab tests, addresses, and any other relevant information for a given patient over time. The system will have patient deduplication capability so that as new data is ingested it can automatically determine whether a new person/patient needs to be added to the system or the new data should be linked to an existing patient. The patient centric approach will also be conducive to linking to patients in other systems and registries like the state master person index and the Michigan immunization registry.

2.0 The Contractor solution must be able to X X At Go-Live, the solution will be a system that has as its core functionality accept electronic and manual input of the collection of data for all reportable conditions as defined by the State of standardized data Michigan. Lab report data is an essential source of disease information so the system will provide a scalable and optimized capability to process a large number of electronic lab reports. The modern MDSS will also support processing and ingesting other types of standardized data submitted electronically to include sources such as electronic case reports, EDRS death record messages, and out-of-state case reports. The disease surveillance system will also provide a well-designed user interface to support manual data entry. This web interface will allow users to view, enter, and edit case data, and relevant patient information according the user’s privileges. 3.0 The Contractor solution must receive X X At Go-Live, the MDSS 2.0’s interface engine layer will easily connect and data from and transmit data to other interoperate with numerous common protocols, like REST, SOAP, SFTP, systems (i.e. CDC, REST Services and HTTPS, HL7 MLLP, database, and file/directory exchange. Rhapsody) Communications interface scripting enables build out, integration, and update of specific interfaces into the running system without affecting ongoing processing. Multiple data formats, including HL7v2, CDA/CCD, custom XML, JSON, CSV and text file will be accepted for integration at system go-live. 4.0 The Contractor solution must X X At Go-Live the solution will make use of automated patient matching deduplicate at the person level through algorithms to link new patient related data coming into the system with the an automatic process when possible correct existing patient and avoid creating duplicate patient records. This will consist of automatic processing where internal master patient index tools compare the incoming patient information fields to existing patient records in a search to find both exact and close matches. If it cannot find a close patient it will automatically be treated as a new patient and added to the system, but if a possible match is found and the confidence level is sufficiently high to interpret as being the same patient, then it will be processed as incoming data for the existing matching patient. Only when the system lacks the information to make the final determination as to whether it is a match to a single specific existing patient will the system place it with the group of tasks that require human intervention to finalize the decision. In addition to preventing duplicates, the system will offer a method for making corrections in situations where patient records are later identified as being duplicates or, alternately, were initially treated as a single patient but later found to be two different patients. The deduplication process may be further tuned based on observation and information from the State master person index. 5.0 The Contractor solution must X X At Go-Live the solution will apply a set of predefined rules to determine deduplicate at the case level, an whether case data entering the system for an existing patient is to create a automatic process when possible new case for that patient or whether that data is to be treated as additional information for that patient’s existing case. These rules are based on SOM

public health experts and specify the expected behavior based on the particular disease, lab tests, lab results, specimen collection dates, and any other relevant criteria. The disease surveillance system will implement this expertise by using the encoded version of these rules to process incoming data and determine when to create a new case versus adding the data to an existing case. For example, an electronic lab report with a positive result for chronic hepatitis C should not create a new case if there is already an existing confirmed case for the patient. Or for condition ‘x’, a new lab test should create a new case only if it has been more than three weeks since the patient last had condition ‘x’. Human intervention will be required for case deduplication when there is not sufficient information for the system to make that decision. 6.0 The Contractor solution must provide X X At Go-Live the solution will have the capability to send alerts and other alerts and user messaging messages to registered users so they are made aware of important activities occurring in the disease surveillance system. This consists of system administrator messages that are created to inform all users or could be customized to send messages to a subsets of users. Alert messages will be sent based on scenarios that are defined to require an alert message. This could be to inform epidemiologists who are responsible for a reportable condition that they need to log onto the system for further details on an unusually high occurrence of cases entering the system. Messages can also alert selected users based on an unusual flow of data into the system, such as when lab report counts are unusually low from a particular laboratory. 7.0 The Contractor solution must perform X X At Go-Live the solution will support automated and manually initiated data analytics to meet business reporting requirements of (including but not limited to): NEDSS reporting to analysis and reporting requirements the CDC, daily COVID statistics, Contact Tracing Exports (CTE), synchronization with the Master Person Index (MPI) efforts, and Patient Education Genius (PEG) integration for patient status updates, and the Weekly Status and other system reports. We will work with the State to further enhance these as needed and add future reporting capabilities into the system. We will also support investigations in the system Operational Data or processed inter-system messages to answer ad-hoc questions, new feature investigations, or implementing a new report in the system. These combined data will be accessible from an analytics engine to allow additional system reporting and to support State teams performing external reporting and statistical analytics using tools like: Tableau and R etc., The solution will also feature ad-hoc reporting based on both on the case data and messages received by the system for advanced system users to support their data analysis.

8.0 The Contractor solution must store data X X At Go-Live the solution will allow data flows into the system from external in a manner to allow users to download vendor sources and added to the MDSS Operational Data to supplement and export information to meet business the patient and/or investigation case details. Electronic messages will be needs stored in full and indexed for additional future data handling requirements and to ease export tasks. In addition to the current import data formats (HL7, eCR, ELR, CCDA), the system will support importing and exporting data in the following formats: XML, JSON/GeoJSON. The use of decimal degrees for latitude and longitude coordinates supports the use of the geographical data in other external systems without additional conversion. External export data methods include direct data connection transfers, JMS queues, SFTP, and REST services. User requested reports will be available as HTML/PDF for viewing on the screen or downloading for take-away external report use, and CSV/XML for the underlying report requested data. 9.0 The Contractor solution must generate X X At Go-Live the MDSS 2.0 will support all the existing static and custom reports to meet • business reporting needs General (Diseases by Demographics, Year to Date, History, by Geography, Epi Curve, Aggregate Case, Audit, TB, Disease Trends, and GIS maps), • Administrative (Field Record, Interview Record, COVID Audit), and • System (VADS, Lab Status, Weekly) based reports, monitor views, and alerts. Also, search operations include basic and advanced case investigations, aggregates, detailed case specifics, and field records. All searches will allow the user to name and save the settings for future reuse. Search operations on case data can cover: program (STD vs. Hep), reportable conditions, demographics, referral data, time and geographic parameters, and program specific data captured on specific disease forms. Search enhancements include the ability to find values across repeated fields or data rows instead of field specific locations, and the ability to drill down on the available data fields in the Operational Data. With the indexing of incoming messages, reports (and alerts) can be created on these to search by facility, date received, patient demographics, test codes, results, different program types, providers, ordering physicians, specimen types, and other contents of the message details. The added data processing engine allows for the creation of new statistical and spatial relationship analyses that can be added as available reports from within the system UI.

10.0 The Contractor solution must be able to X X At Go-Live, the MDSS 2.0 will provide an interface layer that connects query and integrate with other systems incoming and outgoing messaging queues with SOAP, REST, JMS, HL7 MLLP, FTP/SFTP, HTTP, FHIR, database, directory polling and other common communications transports. Communication resources can be easily deployed and updated with script configurations and micro-service restarts. Incoming and outgoing messaging data can be transformed and routed to system input queues through configuration. CDA/CCD, HL7v2, custom XML, JSON, CSV and other file formats will be supported in integration at go-live. 11.0 The Contractor solution must provide X X At Go-Live the solution will have multiple levels of detailed logging to detailed logging (Error, system, access, provide all the necessary tools to maintain the system. All logs will be users, etc.) configurable, and the client will have the final say on what will be logged. The application will provide logs at the following levels: • User Level logging: User level logging will be broken out by operation. Each major interaction will be written to a database table that will record the user, the operation performed, and the time it is performed. There will be an interface provided to query and report on this data. • Application Error logging: Application errors will be reported to various logs contained on the application server. These logs will typically contain code exceptions, container exceptions, and file system exception messages organized by application. • Application Access logs: Application access logs will be kept at various levels. All web serving containers will have access logging turned on. This records requests sent to the webserver as well as the originating IP. Separate access logs will be kept for all user logins and logouts by date and time. • Electronic Message input logs: All incoming electronic messages will be tracked. These logs will be stored within the database. They will include all pertinent information to track any message sent to the system, processed by the system, or rejected by the system. There will be reporting interfaces available to search and track all incoming information. 12.0 The Contractor solution must be X X At Go-Live the solution will feature an interface that will manage role- managed by a role-based access based access to the application. This will allow system administrators to control interface configure precisely the access they want an end user to have. The interface will be configurable by several key layers. Each user’s access will be made up of these 3 items: i. Role: A role controls what data the user can see. It is broken out in terms of jurisdictions and facilities. The jurisdictions are the same

jurisdiction’s currently available in the MDSS, things like county, region and statewide access. Facilities are usually groupings of hospitals. The user can be assigned multiple jurisdictions or facilities. This value controls what data can be seen by the user. ii. Disease Program Group: Disease Program Group assignment allows you limit the disease groups an end user will be able to see/interact with. These groups are totally configurable through the interface and can easily be added to as the need arises. iii. Privileges: Privileges control what you can do with the data that you can see. Privileges are things like: can I view reports, can I update the cases I can see, can I export the cases that I see. These privileges are grouped together into job functions. These job functions are lists of privileges that can be used over and over to give consistence rights and functionality to the end users. Job functions can be created as needed from the privileges available in the system though this interface. 13.0 The Contractor solution must adapt X X The ability to adapt quickly flows from good design and depth of quickly for changing surveillance needs experience on our team. The modernized MDSS takes all the lessons learned, successful implementations, and actual pandemic experience and combines that into a system ready to face surveillance needs. The MDSS 2.0 provide adaptability in 3 areas: • Ability to integrate new data and tools – The new microservices architecture provides the required APIs to easily connect to new data sources and tools. • Ability to handle spikes in data and usage – Another benefit of the microservices architecture is the ability better target more resources to exactly where they are needed to handle performance bottlenecks. • Ability for users to flexibly view/analyze data – The new ad-hoc reporting and data access will allow for easier ad-hoc reporting of more data to easily adapt to changes surveillance needs. Our microservice-oriented design will allow us to quickly ramp up in the areas that need it the most. As usage of the underlying microservices increases, we can increase both the number of instances of that service and the resources allocated to it. These new features will allow us to ramp up system throughput at an accelerated rate. The modular new architecture will allow us to more easily add new tools and move data in and out of the system to adapt quickly. We can create

new exports and imports to connect with new systems that are built just to address the current emergency. 14.0 The Contractor solution must include X X At Go-Live the solution will be deployed covering every reportable solutions for every condition covered condition covered under the current MDSS. The initial deployment will be under the current MDSS architecture configured with 145 reportable conditions existing in the current system. The solution will include features to add new reportable conditions without deployment. The user will be able to add new fields to the existing conditions on the fly without system deployments. The system shall group the different data fields captured for reportable conditions such as Treatment, Social History, Epidemiology, Vaccine Information, etc., It will include customized search features to ensure the user can perform data search on the disease-specific data entered for each reportable condition. The search results will be filtered based on the user’s role. The searched reportable condition case data can be exported from the system in desired format. The solution will be able to capture case information for both nationally notifiable conditions and conditions that are not nationally notifiable. The solution will support exporting investigation data to CDC for the nationally notifiable conditions in the desired format based on the message guide implementations provided. The solution will support exporting the HIV data to eHARS system in the desired format. The solution will support displaying the lab report data received from different facilities for the specific reportable condition. 15.0 The Contractor solution must preserve X X At Go-Live the solution will allow data retention utilizing both online and all data indefinitely. All data must be offline storage. The most recent changed data will be logged in the backed up. database for easy access. The timeframe for retention in the database will be determined based on the client’s input and that of the State DBAs. Once outside the agreed upon timeframe the data will be archived/exported from the current database to long-term storage in the State of Michigan data centers at regular intervals. These data archives will be named with beginning and ending date information for retrieval identification purposes. If there is a need to retrieve data and the data is not available in the current database, the client would request the archives for the timeframe in question from the data center. That data would then be loaded in the database for easy access of the information. Any deletion of this data will be performed at the client’s request. Databases will be backed up according to DTMB policy. These backups will be used in times of emergency, like machine failure, or anytime it is

necessary to restore the entire database immediately. Altarum will support DTMB staff to insure data is preserved according to State guidelines. 16.0 The Contractor solution must provide X X At Go-Live the solution will allow for dynamic individual case profile for longitudinal surveillance and case management at different levels by integrating with internal and external management, especially for chronic applications. It supports a whole-person approach as individuals conditions experience disease over time, in connecting with systems of care and other public health systems such as EDRS, EHARS, MCIR, etc. The MDSS 2.0 surveillance functionality will also be enhanced by providing functionality to search for the patient records in internal applications such as MiCelerity, Outbreak Management and chronic disease registry. The MDSS application will support the longitudinal view of current and prior cases for the selected patient in MDSS. The patient’s prior cases will be displayed based on the investigator roles and their privileges to the specific programs. The new MDSS will provide a patient dashboard to retrieve the whole patient record summary such as the patient’s labs results, vaccine information, treatment history, social history, etc., within the system and across multiple registries based on their privileges. 17.0 The Contractor solution must not have X X At Go-Live, the system will be specified and tuned for the heaviest latency/stability issues even under projected load. This includes adjusting the number of virtual machines heavy load (VMs), compute cores, threads, and memory configuration across multiple services for UX/UI, search, and persistence microservices. The clustering, microservice layers, and containerization design of the system enable rapid and precise targeting of resources to application hotspots. Altarum will perform load testing to verify the solution meets all requirements. Altarum will support DTMB in tuning the Production environment to insure that it meets the needs of the production user community. 18.0 The Contractor solution must X X At Go-Live, the system will be designed as a clustered system with continually be available except for redundancy, where applicable, across the cluster. The microservice design routine system maintenance enables updating and restarting individual services, such as incoming messages with minimal user impact. Production releases to targeted user subsets may also be made to assess feature changes in the UX/UI without affecting the overall user population as in a full feature rollout. Routine system maintenance windows will be communicated to the user community well in advance to minimize work interruptions. OPTIONAL 1.0 The Contractor solution may have X X At Go-Live the solution will include automated data quality checks for all automated data quality checks to the data entered manually by the MDSS users to create/update reduce human error (e.g. case case/patient/lab data in the system. classification, laboratory reporting) To insure that standard code sets are used, MDSS 2.0 will include CDC VADS mapping functionality to automatically map the test codes and

results to the MDSS conditions. The solution will include a user interface to map local codes that are specific to a lab facility to automate the condition assignment process. Additional condition-specific data validation rules will be added to validate that the case status correctly corresponds to lab test/results. These will be customized for different programs based on the incoming lab data and other rules such as patient demographics, treatment history, etc. Customized program-specific automation logic will be provided for programs such as STD, Hep and COVID, VPD, HAI, Foodborne, etc., These customizations can be easily extended to other reportable conditions. 2.0 The Contractor solution may be able to X X At Go-Live the solution will have the ability to house information on case house information on contacts to cases contact for any infectious condition. The current legacy MDSS is able to with an infectious condition handle contact information for some conditions but the MDSS 2.0 will have a generalized capability to handle contacts for any condition. When a contact turns positive for an outbreak based on the assigned rules, customized features will be available to create a confirmed case in MDSS. Contact monitoring processes for different outbreaks will be supported using the configurable outbreak management module. Additional functionality will generate contact reports for the selected cases in MDSS based on different parameters such as case/investigation status, timeframe, geographic locations, etc. The reports will include monitoring summary, exposure information, contact hierarchy process, etc., as required for outbreak investigation processes. 3.0 The Contractor solution may be able to X As an optional solution, the new MDSS can include additional functionality perform automated outreach to cases to handle contact outreach programs and send investigation survey (e.g., PEG) or contacts (e.g. questionnaires to patients. This would be implemented as a separate TraceForce) via text/email service that can be configured with the MDSS reportable conditions as needed during an occurrence of an outbreak or due to high volume of the cases that benefit from an automated investigation process. The solution will include the functionality to build customized questionnaires based on the specific outreach requirements. The module can be configured to send secured SMS messages/email based on the contact/patient details available with a link to the built questionnaire to the selected patients in MDSS. The completed forms shall be received securely back from the patients/contacts by the implemented service. Different workflows can be implemented based on the responses received. Additional data requests can be sent to the patients/contacts as needed or the data received can be ingested back to proceed to the next step. The main reason behind the outreach program is to speed up the investigation process in the system and reduce the manual workload.

Separate user dashboards will be provided for administrators to view the status of the requests/messages sent and the responses received. The solution can be extended to integrate with a messaging service to make automated calls/texts to the contacts/cases to proceed with investigation processes. Different ad-hoc reports can be initiated based on different parameters such as the received response status, timeframe, geographic limitations, contact/patient status, etc. 4.0 The Contractor solution may have the X X At Go-Live the solution will include a user interface to let the MDSS ability to send customizable educational administrators send customized messages, educational information, and information and form letters to cases, form letters to different user groups, such as case patients, contacts, contacts, providers providers, local health jurisdiction user groups, etc. The system administrators shall be able to identify the preferred MDSS user groups based on their roles and privileges in the system. Case patients and contacts can be drilled down based on various parameters provided to pick the correct list. The MDSS 2.0 will include the functionality to send messages to different MDSS users during system upgrades, etc. The user interface will provide configurable options to identify the different users group based on their user groups and privileges in the system to send an email message within the dashboard. MDSS administrators shall be able to trigger sending the customized information to the selected people. A separate management tab will be available for administrators to manage the existing information sent. Additional functionality can be implemented based on the business requirements gathered during implementation. 5.0 The Contractor solution may allow LHD X X At Go-Live the solution will provide LHD Administrators the ability to Administrators the ability to turn on/off customize their participation in automated functions that involve reaching various automated functions and out to case patients and case contacts. Opting out of any functionality customize messages to cases/contacts would apply to the functionality available to assist local health departments, for example, in performing their contact tracing or data collection activities. For functionality that involves messages to case patients or contacts, the system would use customized text and participation options, applying it to a case based on the case’s jurisdiction and according to the settings specific for each jurisdiction. 6.0 The Contractor solution may allow X X At Go-Live the solution will support the automatic mapping of incoming incoming data to automatically map to data to its corresponding field in the case report forms, providing a relevant fields in case report forms supplemental method for obtaining useful data from outside sources when it is available. The values coming in may apply to fields that are common across diseases or be specific to a disease. The system will expect that fields and values follow predefined rules and formats so that it can take that data and populate the proper fields correctly. Some fields may be defined as text, others as numeric values,

and others as codes which represent values in a value set. In the scenarios where the incoming data requires conversion to the desired standards, pre-processing rules will be applied to format the data automatically. Any data that falls outside of the range of accepted and expected values will fail validation and will not be mapped, but would be logged as errors so that data can be corrected in future submissions. 7.0 The Contractor solution may allow for X X At Go-Live the solution will allow Local Health Department administrators custom fields to be created to meet to create custom fields that are only visible to users in their jurisdiction and individual business needs (i.e. at the can be used to help meet specific business needs at the local level. The LHD level) LHD administrator user would choose to add a new local field, give the field a name and a description, and then select the type of field it should be. For example, a field could just be free text or it could be a checkbox type. These custom fields would appear in an area specifically designated for displaying custom fields so that it does not disrupt the format of the standard fields that are part of the application. 8.0 The Contractor solution may be able to X X At Go-Live the MDSS 2.0 will include additional functionality to customize filter out extraneous information (e.g. processing incoming lab data for new and existing reportable conditions. erroneously reported negative The solution will include a robust user interface to add new test laboratory results) codes/results to follow existing program specific rules, so the incoming lab messages with these codes/results are appropriately classified. The system functionality will feature lab classifications customized for different programs. This include identifying the negative labs for Hepatitis and COVID, etc., and holding them for a defined period until the patient receives a positive lab report. The functionality will also include parsing the panel lab messages and excluding tests/results that are not reportable in MDSS. Some of the most common panels include metal, lead, and HIV labs that are not part of MDSS lab reporting. Additional customization will include validating the incoming values in specific message segments to ensure the value can be mapped for specific fields. Some examples would include pregnancy status, AOE (Ask at Order Entry) results, clinical information, etc. 9.0 The Contractor solution may be able to X X At Go-Live the solution will include a dashboard to display details about automatically detect, visualize, and alert incoming messages to MDSS. The dashboard will include the summary of administrators of significant changes in all the message types, such as ELR’s, eCR’s, EDRS, ADT messages, etc. submitter volume (e.g. dashboards by The messaging dashboard will provide the message counts classified by geography, health system, laboratory, various parameters such as incoming lab facility, provider, message type provider) for a given timeframe and geographic location, such as county, jurisdiction, etc. The messaging dashboard will provide the message counts based on lab test code and result classification for each reportable condition in MDSS. The dashboard will also provide customized charts and graphs to compare the quality of the incoming data for each lab facility.

The dashboard will alert the system administrators about message delay identified for a specific lab facility based on the precalculated limits. The system administrators will be alerted when the message volume is higher than the precalculated cut-off for a specific lab facility to verify if the messages received are appropriate. The alert messages will be sent to signed-up users through emails and the summary will be appropriately color coded in the dashboard. MDSS users can sign up on the dashboard to receive appropriate alerts for different options provided. The dashboard will provide the functionality to search for incoming messages based on different parameters, such as message control ID, specimen ID, patient name, provider, etc. The user will be able to drill down to identify the patient ID in the application for the selected incoming message. 10.0 The Contractor solution may have the X As an optional solution, the new MDSS can include additional user ability to communicate requests for interfaces to customize and send messages to selected providers based information or transmit clinical on the provider information available in the application. A specific workflow recommendations to providers can also be built to send automated messages to selected providers requesting them to enter additional information for the selected case. These workflows will be customized for specific programs or reportable conditions, and providers can be identified based on the referral information entered for the selected case. Messages can also be triggered manually/automatically to the providers based on the case investigation performed for selected reportable conditions. These clinical recommendation messages can be prebuilt based on various parameters such as reportable condition, different data fields populated, etc., for the selected case. The messages can be triggered when the required case information is entered, or lab data comes with specific results for the selected case. Additional customizations can be provided based on user requirements.

11.0 The Contractor solution may have an X X At Go-Live the solution will include the ability to customize contact data ability to link and visualize disease collection (event, location, and person data) and, for a specific outbreak, transmission between cases and handle data storage/management and provide data visualization of contacts transmission. The above-mentioned steps will help identify the contact transmission patterns for any outbreak. The collected outbreak data enables the user to establish and display visual links among patients, contacts, and locations when graphed. 12.0 The Contractor solution may have X As an optional solution, the system integrate with a pharmacy data source ability to digest pharmacy (prescribing) to get prescription data specific for a case/event. The patient prescription data (e.g. prescription of rabies vaccine data can be received as part of eCR/CCDA messages or other valid HL7 should be reportable) formats. We will expand our electronic messaging to accept messages that contain “reportable” prescriptions. This new message information would

100

also need a new onboarding process to ensure data quality. This is necessary to ensure that each data provider is only sending reportable prescription data. The incoming prescription data will be mapped to currently mapped infectious diseases in the MDSS. If the incoming message contains pharmacy-related data, this will be associated with the case based on the associated lab tests/results of the incoming message. The pharmacy-related data will be mapped to case details based on the specific reportable condition. If the incoming data includes vaccine related information, then the condition mapping can be achieved based on the vaccine code and a case would be created using the information available. In addition to accepting this new data, the user will also be able to search existing cases for it. The prescription pharmacy information will be accessible through our case search and report/export module. Additional system functionality can be implemented based on business requirements gathering. 13.0 The Contractor may allow users to X X At Go-Live the solution will include a report/export scheduling module that schedule routine exports or 'subscribe' will be accessible in two ways: to scheduled exports/reports • When running a report and requesting an export • Directly from the user menu While executing an export/report the user will be offered the option to schedule. If they choose to schedule their current task, they will be transferred to the scheduling module. The times offered for scheduling will be based on their size, role, and type using predetermined heuristics. The user will also be given the option to save the request to execute at a future time. Once the report is ready to download, the user will be notified by email. The scheduling module can be accessed directly from the user menu. The user will be presented with their previously saved export/report, the exports ready for download, as well as system wide reports/exports that they can subscribe to or just directly download. The user will be able to rerun any of their saved searches/exports and schedule them for delivery. If they wish, they could subscribe to popular system-wide (official, popular, etc.) available reports/exports. This subscription will notify them by email when their subscribed reports/exports are available. By generating a single export/report for these subscriptions system resources are saved and consistency is insured. Allotting and managing the designation for subscription will be reserved for higher roles (system admin). 14.0 The Contractor may have automated X X At Go-Live the solution will include automated data quality checks for all data quality checks to reduce human the data entered manually by the MDSS users to create/update case/patient/lab data in the system.

101

error (e.g. case classification, laboratory To insure that standard code sets are used, MDSS 2.0 will include CDC reporting) VADS mapping functionality to automatically map the test codes and results to the MDSS conditions. The solution will include a user interface to map local codes that are specific to a lab facility to automate the condition assignment process. Additional condition-specific data validation rules will be added to validate that the case status correctly corresponds to lab test/results. These will be customized for different programs based on the incoming lab data and other rules such as patient demographics, treatment history, etc. Customized program-specific automation logic will be provided for programs such as STD, Hep and COVID, VPD, HAI, Foodborne, etc., These customizations can be easily extended to other reportable conditions 15.0 The Contractor may be able to house X X At Go-Live the solution will have the ability to house information on case information on contacts to cases with an contact for any infectious condition. The current legacy MDSS is able to infectious condition handle contact information for some conditions but the MDSS 2.0 will have a generalized capability to handle contacts for any condition. When a contact turns positive for an outbreak based on the assigned rules, customized features will be available to create a confirmed case in MDSS. Contact monitoring processes for different outbreaks will be supported using the configurable outbreak management module. Additional functionality will generate contact reports for the selected cases in MDSS based on different parameters such as case/investigation status, timeframe, geographic locations, etc. The reports will include monitoring summary, exposure information, contact hierarchy process, etc., as required for outbreak investigation processes.

102

SCHEDULE B – PRICING

Price includes all costs for the licensing, support, implementation, and training for the Solution. Pricing is contingent on the Assessment.

1. Implementation Fees. All costs associated with Implementation Services are included below (e.g. configuration, customization, migration, integration, testing, etc.) (the “Implementation Fees”). All costs are firm fixed.

Altarum has a total of $11,498,250.00 for Implementation Services and Fees. Detailed pricing and a payment schedule for implementation of Altarum’s product is shown below. Altarum’s total costs are based on a period of performance of March 16, 2021 through December 31, 2022.

Altarum go-live with our Solution on January 1, 2023 and will provide support services through January 1, 2025 at no additional cost to the State of Michigan.

Altarum Detailed Pricing

Milestones/Deliverables for Implementation The State’s milestone schedule and associated deliverables are set forth below.

Pricing is firm fixed the State and Contractor will mutually agree and sign off on completed deliverables prior to payment based on the SEM-0185 Release Review and Approval form.

Product Release Features Initial Requirements % Invoice Amount Increment Kickoff Completion of the Kickoff Meeting 5% $574,912.50 Sprint 0 Sprint 0 - Project scope and release plan 10% $1,149,825.00 The system will be person centric and 10% $1,149,825.00 designed around the participant. The system will associate information to a single participant. Person Centric The system will reduce duplication of Design participants during the creation of new participant records. The system will have the ability to populate forms for entering and editing participant centric data. The solution will preserve all data indefinitely. Architecture and All data will be backed up. This includes R1 Design full data backups and incremental Database backups. Security & All data will follow DTMB policies and Archiving procedures as it relates to obfuscation and security of sensitive information. The system will contain all existing MDSS data. The system will use MiLogin for authentication System The system will capture detail logs of Security access and record modification. The system will be managed by a role- based access control interface

103

The system will allow for the creation and modification of all system roles and permissions. The System will be accessible by all modern browsers. The system will be available to users 24x7 with the exception of scheduled and approved system maintenance. System The system will meet or exceed industry Availability standard response times and load limits for web applications. The system will be designed to meet ADA standards. The system will provide detail logging and error handling The system will use menu's and keyboard shortcuts for navigation. The system will provide robust search functionality including Users, Diseases and Time Periods. User Interfaces The solution will provide communications and tools like bulletins, announcements and Experience alerts. The system will allow the management of drop down values and selection options as a way to adapt quickly to changing surveillance needs. The system will allow for manual entry of 10% $1,149,825.00 Operational participant information. Datastore The system will allow for the modification of participant information during import. The system will allow users to modify Core Services case data that is assigned. R2 Development The solution will have a separate data Content reporting environment. Management The system will include a dashboard for a System user’s default page upon login. The system will provide the ability to modify dashboards for each persona. The system will allow for automated entry 15% $1,724,737.50 of participant information from other systems The system will interface with the CDC The system will interface with MPI The system will utilize the Enterprise Service Bus Automated The system will interface with the Data Data Rhapsody Service Bus Management Distribution R3 The system will interface with the and System and Rhapsody Data Quality Tool Interfaces Consumption The system will interface with TraceForce/PEG The system will accept LAB/eCR/ADT messages Data The system will automatically deduplicate Deduplication at the patient level and Merge The system will automatically deduplicate Management case level data.

104

The system will provide a mechanism to review records that have been merged from a deduplication process. The system will provide a mechanism to un merge records that have been done by mistake. The system will provide a manual method for merging case and user information. The system will alert users to aberrations 10% $1,149,825.00 in reporting The system will have built-in, customizable, reporting and analytics Data Reporting The system will provide exports of participant and encounter data The system will provide location based reports of patient and encounter data. Reporting and The system will use data and trends to R5 Analytics identify potential outbreaks. Module The system will provide interactive data visualizations to support analysis The system will allow the user to query Data Analytics MCIR for vaccination status The system will identify reporting errors and messaging anomalies The system will allow Administrators to be able to set user permissions based on defined roles. The system will accommodate disease 10% $1,149,825.00 specific rules for data surveillance and case management Longitudinal The system will allow a user to review all Surveillance patient's history and Case The solution will incorporate all existing Management case management functionality in the current MDSS architecture.. Disease Specific R4 The system will allow for the creation of Program Needs new condition through the UI. The system will allow for the management of sending facilities Hospital Based The system will allow for the addition of Information / new ICD10 codes Medical Coded Data The system will analyze hospital based information and medical coded data sources The SUP module architecture will be 5% $574,912.50 SUP modernized to conform with the MDSS architecture architecture. alignment At a minimum, the system will provide access to all legacy SUP functionality. The MICelerity module architecture will SUP, MICelerity, be modernized to conform with the R6 Outbreak MICelerity MDSS architecture. Management architecture At a minimum, the system will provide alignment access to all legacy MICelerity functionality. OMS The OMS module architecture will be architecture modernized to conform with the MDSS alignment architecture.

105

At a minimum, the system will provide access to all legacy OMS functionality. The system will use a help function to 10% $1,149,825.00 User Training provide contextual help throughout the Manuals and system. Contextual The system will provide the ability to Help. modify the contextual help text that is presented to the users. Documentation, Technical The vendor will provide R7 Training and Configuration system documentation detailing setup Outreach and User process and configuration details and Guides processes. The vendor will create and facilitate user training sessions for each system role. User Training All system training session will be Sessions recorded and published for future onboarding efforts. System integration testing will be 15% $1,724,737.50 performed by the vendor as part of the System sprint and release deployments. Integration System integration testing will take place Testing Final Testing & prior to user acceptance testing during R-All Project Go Live the lifecycle of the project. The business unit will perform User User Acceptance Testing for each release. Acceptance There will be a designated regression Testing test and End to end test prior to Go-Live Project Go- User Acceptance Testing Approval and

Live Go-Live Total $11,498,250.00

106

2. Postproduction Warranty. The Contractor must provide a postproduction warranty through January 1, 2025 at no cost to the state of Michigan. The postproduction warranty will meet all requirements of the contract, including all Support Services identified in Schedule D.

3. Rate Card for Ancillary Professional Services.

Resource On-Site Hourly On-Site Hourly On-Shore and On-Shore and Off- Rate Rate Off-Site Hourly Off-Site Hourly Shore Rate Rate Hourly 3/3/21 - 12/31/21 1/1/22 - 12/31/22 Rate 3/3/21 - 12/31/21 1/1/22-12/31/22

Analyst $94.10 $96.21 $94.10 $96.21 N/A

Integration Engineer $139.50 $142.76 $139.50 $142.76 N/A

QA Engineer $90.69 $92.72 $90.69 $92.72 N/A

Sr Database Admin $152.91 $156.50 $152.91 $156.50 N/A

Sr Project Manager $161.76 $165.57 $161.76 $165.57 N/A

Sr Software $151.66 $155.23 $151.66 $155.23 N/A Engineer

Software Engineer $110.78 $113.31 $110.78 $113.31 N/A

MGMT Support $149.35 $152.86 $149.35 $152.86 N/A

4. Maintenance and Operations M&O price for post warranty from 2025-2030 is shown below, assumes the maintenance of the Solution. The calculation is representative of the industry standard cost of 20% to maintenance a customized product. Any service years beyond the dates included herein shall increase at 3%, per annum.

YR 2022 YR 2023 YR 2024 YR 2025 YR 2026

M&O Post Protection $0.00 $0.00 $0.00 $225,000.00 $231,750.00 Warranty

YR 2027 YR 2028 YR 2029 YR 2030

M&O Post Protection Warranty $238,702.50 $245,863.58 $253,239.48 $260,836.67

5. Transition Out Pricing

The costs associated with the Transition Out period defined herein (assuming 180 calendar day transition period) are as follows:

MDSS Modernization Transition Out - 180 Calendar Days Project Level of Loaded Staff Role/Category Effort Hourly Extended Cost Hours Rate

107

Analyst Analyst 35% 364 $104.18 $ 37,920 Integration Engineer Integration 0 $155.02 $ - Engineer QA Engineer QA Engineer 0 $100.36 $ - Sr Database Admin Sr Database 10% 104 $170.04 $ 17,684 Admin Sr Project Manager Sr Project 20% 208 $179.94 $ 37,428 Manager Sr Software Engineer Sr Software 10% 104 $168.64 $ 17,539 Engineer Software Engineer Software 10% 104 $122.86 $ 12,777 Engineer Keller, Richard A MGMT Support 0 $231.87 $ - Rappleye, Laura C MGMT Support 0 $166.06 $ -

884 TOTAL DIRECT LABOR $ 123,348 OTHER DIRECT COSTS

Estimated Travel $ - M&O Support Estimated ODCs (Post- 6 $18,750, $ 112,500 Warranty Period) months per

TOTAL OTHER DIRECT COSTS $ 112,500.00 TOTAL ESTIMATED NOT TO EXCEED $ 235,848.35 COSTS

108

6. Optional Task Pricing – Appendix A Pricing below is only an estimate and subject to change at the State’s sole discretion.

Description Total Optional Task 1 – Contact Tracing and Patient Outreach $ 2,633,224 Optional Task 2 – Chronic Disease Warehouse $ 4,669,784 Optional Task 3 – Outbreak Management System $ 2,744,448 Optional Task 4 – SUP Enhancements $ 1,243,725 Optional Task 5 – Google Research Data Warehouse $ 677,955 Total $ 11,969,136 Bulk Pricing (If All Optional Tasks are Purchased): $10,532,839.77

7. Additional Pricing Terms

The Contractor is encouraged to offer quick payment terms. The number of days must not include processing time for payment to be received by the Contractor's financial institution.

Quick payment terms: N/A % discount off invoice if paid within N/A days after receipt of invoice.

If Contractor reduces its prices, or offers a lower price to any other entity, private or public, for any of the software or services during the term of this Contract, the State shall have the immediate benefit of such lower prices for new purchases. Contractor shall send notice to the State’s Contract Administrator with the reduced prices within fifteen (15) Business Days of the reduction taking effect.

Travel and Expenses The State does not pay for overtime or travel expenses.

109

SCHEDULE C - INSURANCE SCHEDULE

Required Coverage.

Insurance Requirements. Insurance Requirements. Contractor, at its sole expense, must maintain the insurance coverage identified below. All required insurance must: (i) protect the State from claims that arise out of, are alleged to arise out of, or otherwise result from Contractor's or subcontractor's performance; (ii) be primary and non-contributing to any comparable liability insurance (including self-insurance) carried by the State; and (iii) be provided by a company with an A.M. Best rating of "A-" or better, and a financial size of VII or better.

Required Limits Additional Requirements

Commercial General Liability Insurance

Minimum Limits: Policy must be endorsed to add “the State of Michigan, its departments, divisions, $1,000,000 Each Occurrence agencies, offices, commissions, officers, employees, and agents” as additional $1,000,000 Personal & Advertising Injury insureds using endorsement CG 20 10 11 85, $2,000,000 Products/Completed Operations or both CG 20 10 12 19 and CG 20 37 12 19.

$2,000,000 General Aggregate

Umbrella or Excess Liability Insurance Minimum Limits: Policy must follow form.

$5,000,000 General Aggregate

Automobile Liability Insurance

Minimum Limits: Policy must: (1) be endorsed to add “the State of Michigan, its departments, divisions, $1,000,000 Per Accident agencies, offices, commissions, officers, employees, and agents” as additional insureds; and (2) include Hired and Non- Owned Automobile coverage.

Workers' Compensation Insurance

Minimum Limits: Waiver of subrogation, except where waiver is prohibited by law. Coverage according to applicable laws governing work activities

Employers Liability Insurance

Minimum Limits:

$500,000 Each Accident

$500,000 Each Employee by Disease

$500,000 Aggregate Disease

110

Privacy and Security Liability (Cyber Liability) Insurance Minimum Limits: Policy must cover information security and privacy liability, privacy notification costs, $1,000,000 Each Occurrence regulatory defense and penalties, and website media content liability. $1,000,000 Annual Aggregate

1.1 If any required policies provide claims-made coverage, the Contractor must: (i) provide coverage with a retroactive date before the Effective Date of the Contract or the beginning of Contract Activities; (ii) maintain coverage and provide evidence of coverage for at least three (3) years after completion of the Contract Activities; and (iii) if coverage is cancelled or not renewed, and not replaced with another claims-made policy form with a retroactive date prior to the Effective Date of this Contract, Contractor must purchase extended reporting coverage for a minimum of three (3) years after completion of work.

1.2 Contractor must: (i) provide insurance certificates to the Contract Administrator, containing the agreement or delivery order number, at Contract formation and within twenty (20) calendar days of the expiration date of the applicable policies; (ii) require that subcontractors maintain the required insurances contained in this Section; (iii) notify the Contract Administrator within five (5) business days if any policy is cancelled; and (iv) waive all rights against the State for damages covered by insurance. Failure to maintain the required insurance does not limit this waiver.

1.3 This Section is not intended to and is not to be construed in any manner as waiving, restricting or limiting the liability of either party for any obligations under this Contract (including any provisions hereof requiring Contractor to indemnify, defend and hold harmless the State)

111

SCHEDULE D - SERVICE LEVEL AGREEMENT

The parties agree as follows:

1. Definitions. For purposes of this Schedule, the following terms have the meanings set forth below. All initial capitalized terms in this Schedule that are not defined in this Schedule shall have the respective meanings given to them in the Contract Terms and Conditions.

“Contact List” means a current list of Contractor contacts and telephone numbers set forth in the attached Schedule D – Attachment 1 to this Schedule to enable the State to escalate its Support Requests, including: (a) the first person to contact; and (b) the persons in successively more qualified or experienced positions to provide the support sought.

“Critical Service Error” has the meaning set forth in the Service Level Table.

“Error” means, generally, any failure or error referred to in the Service Level Table.

“First Line Support” means the identification, diagnosis and correction of Errors by the State.

“High Service Error” has the meaning set forth in the Service Level Table.

“Low Service Error” has the meaning set forth in the Service Level Table.

“Medium Service Error” has the meaning set forth in the Service Level Table.

“Resolve” and the correlative terms, “Resolved”, “Resolving” and “Resolution” each have the meaning set forth in Section 2.4

“Service Credit” has the meaning set forth in Section 3.1

“Second Line Support” means the identification, diagnosis and correction of Errors by the provision of (a) telephone and email assistance by a qualified individual on the Contact List and remote application support, or (b) on- site technical support at the State's premises by a qualified individual on the Contact List.

“Service Levels” means the defined Error and corresponding required service level responses, response times, Resolutions and Resolution times referred to in the Service Level Table.

“Service Level Table” means the table set out in Section 2.4

“State Cause” means any of the following causes of an Error: (a) a State server hardware problem; (b) a desktop/laptop hardware problem; or (c) a State network communication problem.

“State Systems” means the State's information technology infrastructure, including the State's computers, software, databases, electronic systems (including database management systems) and networks.

“Support Hours” means Monday – Friday 8:00 AM-5:00 PM ET

“Support Period” means the period of time beginning 90 days after the date the Software has entered full production mode and ending on the date the Contract expires or is terminated.

“Support Request” has the meaning set forth in Section 2.2 2. Support Services. The State will provide First Line Support prior to making a Service Request for Second Line Support. Contractor shall perform all Second Line Support and other Support Services during the Support Hours throughout the Support Period in accordance with the terms and conditions of this Schedule and the Contract, including the Service Levels and other Contractor obligations set forth in this Section 2 112

2.1 Support Service Responsibilities. Contractor shall:

(a) provide unlimited telephone support during all Support Hours;

(b) respond to and Resolve all Support Requests in accordance with the Service Levels;

(d) provide on-premise Second Line Support to the State if remote Second Line Support will not Resolve the Error; and

(e) provide to the State all such other services as may be necessary or useful to correct an Error or otherwise fulfill the Service Level requirements, including defect repair, programming corrections and remedial programming.

2.2 Support Requests. Once the State has determined that an Error is not the result of a State Cause, the State may request Support Services by way of a Support Request. The State shall classify its requests for Error corrections in accordance with the support request classification and definitions of the Service Level Table set forth in Section 2.4. (each a "Support Request"). The State shall notify Contractor of each Support Request by e-mail or telephone. The State shall include in each Support Request a description of the reported Error and the time the State first observed the Error.

2.3 State Obligations. The State shall provide the Contractor with each of the following to the extent reasonably necessary to assist Contractor to reproduce operating conditions similar to those present when the State detected the relevant Error and to respond to and Resolve the relevant Support Request:

(i) if not prohibited by the State’s security policies, remote access to the State Systems, and if prohibited, direct access at the State's premises;

(ii) output and other data, documents and information, each of which is deemed the State's Confidential Information as defined in the Contract; and

(iii) such other reasonable cooperation and assistance as Contractor may request.

2.4 Service Level Table. Response and Resolution times will be measured from the time Contractor receives a Support Request until the respective times Contractor has (a) responded to that Support Request, in the case of response time and (b) Resolved that Support Request, in the case of Resolution time. "Resolve", "Resolved", "Resolution" and correlative capitalized terms mean, with respect to any particular Support Request, that Contractor has corrected the Error that prompted that Support Request and that the State has confirmed such correction and its acceptance of it in writing. Contractor shall respond to and Resolve all Support Requests within the following times based on the State's designation of the severity of the associated Error, subject to the parties' written agreement to revise such designation after Contractor's investigation of the reported Error and consultation with the State:

Support Definition Service Level Metric Service Level Metric Request (Required Response (Required Resolution Classific Time) Time) ation

113

Critical (a) Issue affecting entire Contractor shall Contractor shall Resolve Service Software system or acknowledge receipt of a the Support Request as Error single critical production Support Request within soon as practicable and function; thirty (30) minutes. no later than four (4) hours after Contractor's (b) Software down or receipt of the Support operating in materially Request. degraded state; If the Contractor (c) Data integrity at risk; Resolves the Support Request by way of a (d) Material financial work-around accepted in impact; writing by the State, the support classification (e) Widespread access assessment will be interruptions: or reduced to a High Service Error. (f) Classified by the state as a Critical Service Error

High (a) A Critical Service Contractor shall Contractor shall Resolve Service Error for which the State acknowledge receipt of a the Support Request as Error has received, within the Support Request or, soon as practicable and Resolution time for where applicable, the no later than two (2) Critical Service Errors, a State's written Business Days after work-around that the acceptance of a Critical Contractor's receipt of State has accepted in Service Error work- the Support Request or, writing; or around, within twenty- where applicable, the four (24) hours. State's written (b) Primary component acceptance of a Critical failure that materially Service Error work- impairs Software’s around. performance;

(d) performance issues of severe nature impacting critical processes

114

Medium An isolated or minor Contractor shall Contractor shall Resolve Service Error in the Software acknowledge receipt of the Support Request as Error that meets any of the the Support Request soon as practicable and following requirements: within two (2) Business no later than ten (10) Days. Business Days after (a) does not significantly Contractor's receipt of affect Software the Support Request. functionality;

(b) can or does impair or disable only certain non- essential Software functions; or

Low Request for assistance, Contractor shall N/A Service information, or services acknowledge receipt of Error that are routine in the Support Request nature. within five (5) Business Days.

2.5 Escalation. If Contractor does not respond to a Support Request within the relevant Service Level response time, the State may escalate the Support Request to the Contractor Project Manager and State Program Managers, or their designees, and then to the parties’ respective Contract Administrators.

2.6 Time Extensions. The State may, on a case-by-case basis, agree in writing to a reasonable extension of the Service Level response or Resolution times.

2.7 Contractor Updates. Contractor shall give the State monthly electronic or other written reports and updates of:

(a) the nature and status of its efforts to correct any Error, including a description of the Error and the time of Contractor's response and Resolution;

(b) its Service Level performance, including Service Level response and Resolution times; and

2.8 Go-Live Support Calls Contractor must answer call within 2 hours, failure to meet this service level will result in a Critical Error credit as outlined in Section 3.

3. Service Credits.

3.1 Service Credit Amounts. If the Contractor fails to respond to a Support Request within the applicable Service Level response time or to Resolve a Support Request within the applicable Service Level Resolution time, the State will be entitled to the corresponding service credits specified in the table below ("Service Credits"), provided that the relevant Error did not result from a State Cause.

115

Support Request Service Level Credits Service Level Credits Classification (For Failure to Respond to any (For Failure to Resolve any Support Support Request Within the Request Within the Corresponding Corresponding Response Time) Required Resolution Time)

Critical Service An amount equal to 5% of the then An amount equal to 5% of the then Error current monthly Support Fee for each current monthly Support Fee for each hour by which Contractor's response hour by which Contractor's Resolution of exceeds the required Response time. the Support Request exceeds the required Resolution time.

High Service An amount equal to 3% of the then An amount equal to 3% of the then Error current monthly Support Fee for each current monthly Support Fee for each Business Day, and a pro-rated share of Business Day, and a pro-rated share of such percentage for each part of a such percentage for each part of a Business Day, by which Contractor's Business Day, by which Contractor's response exceeds the required Resolution of the Support Request Response time. exceeds the required Resolution time.

3.2 Compensatory Purpose. The parties intend that the Service Credits constitute compensation to the State, and not a penalty. The parties acknowledge and agree that the State's harm caused by Contractor's delayed delivery of the Support Services would be impossible or very difficult to accurately estimate as of the Effective Date, and that the Service Credits are a reasonable estimate of the anticipated or actual harm that might arise from Contractor's breach of its Service Level obligations.

3.3 Issuance of Service Credits. Contractor shall, for each monthly invoice period, issue to the State, together with Contractor's invoice for such period, a written acknowledgment setting forth all Service Credits to which the State has become entitled during that invoice period. Contractor shall pay the amount of the Service Credit as a debt to the State within fifteen (15) Business Days of issue of the Service Credit acknowledgment, provided that, at the State's option, the State may, at any time prior to Contractor's payment of such debt, deduct the Service Credit from the amount payable by the State to Contractor pursuant to such invoice.

3.4 Additional Remedies for Service Level Failures. Contractor's repeated failure to meet the Service Levels for Resolution of any Critical Service Errors or High Service Errors, or any combination of such Errors, within the applicable Resolution time set out in the Service Level Table will constitute a material breach under the Contract. Without limiting the State's right to receive Service Credits under this Section the State may terminate this Schedule for cause in accordance with terms of the Contract.

4. Communications. In addition to the mechanisms for giving notice specified in the Contract, unless expressly specified otherwise in this Schedule or the Contract, the parties may use e-mail for communications on any matter referred to herein.

116

SCHEDULE E – DATA SECURITY REQUIREMENTS

“Contractor Security Officer” has the meaning set forth in Section 2 of this Schedule.

“FedRAMP” means the Federal Risk and Authorization Management Program, which is a federally approved risk management program that provides a standardized approach for assessing and monitoring the security of cloud products and services.

“FISMA” means The Federal Information Security Modernization Act of 2014 (Pub.L. No. 113-283 (Dec. 18, 2014.).

“Hosting Provider” means any Permitted Subcontractor that is providing any or all of the Hosted Services under this Contract.

“NIST” means the National Institute of Standards and Technology.

“PCI” means the Payment Card Industry.

“PSP” or “PSPs” means the State’s IT Policies, Standards and Procedures.

“SSAE” means Statement on Standards for Attestation Engagements.

“Security Accreditation Process” has the meaning set forth in Section 6 of this Schedule

2. Security Officer. Contractor will appoint a Contractor employee to respond to the State’s inquiries regarding the security of the Hosted Services who has sufficient knowledge of the security of the Hosted Services and the authority to act on behalf of Contractor in matters pertaining thereto (“Contractor Security Officer”).

3. Contractor Responsibilities. Contractor is responsible for establishing and maintaining a data privacy and information security program, including physical, technical, administrative, and organizational safeguards, that is designed to:

(a) ensure the security and confidentiality of the State Data;

(b) protect against any anticipated threats or hazards to the security or integrity of the State Data;

(d) ensure the proper disposal of any State Data in Contractor’s or its subcontractor’s possession; and

(e) ensure that all Contractor Representatives comply with the foregoing.

The State has established Information Technology (IT) PSPs to protect IT resources under the authority outlined in the overarching State 1305.00 Enterprise IT Policy. In no case will the safeguards of Contractor’s data privacy and information security program be less stringent than the safeguards used by the State, and Contractor must at all times comply with all applicable public and non-public State IT policies and standards, of which the publicly available ones are at https://www.michigan.gov/dtmb/0,5552,7-358-82547_56579_56755---,00.html.

This responsibility also extends to all service providers and subcontractors with access to State Data or an ability to impact the contracted solution. Contractor responsibilities are determined from the PSPs based on the services being provided to the State, the type of IT solution, and the applicable laws and regulations.

4. Acceptable Use Policy. To the extent that Contractor has access to the State’s IT environment, Contractor must comply with the State’s Acceptable Use Policy, see 117

https://www.michigan.gov/documents/dtmb/1340.00.01_Acceptable_Use_of_Information_Technology_Standard_458 958_7.pdf. All Contractor Personnel will be required, in writing, to agree to the State’s Acceptable Use Policy before accessing State systems. The State reserves the right to terminate Contractor’s and/or subcontractor(s) or any Contractor Personnel’s access to State systems if the State determines a violation has occurred.

5. Protection of State’s Information. Throughout the Term and at all times in connection with its actual or required performance of the Services, Contractor will:

5.1 If Hosted Services are provided by a Hosting Provider, ensure each Hosting Provider maintains FedRAMP authorization for all Hosted Services environments throughout the Term, and in the event a Hosting Provider is unable to maintain FedRAMP authorization, the State, at its sole discretion, may either a) require the Contractor to move the Software and State Data to an alternative Hosting Provider selected and approved by the State at Contractor’s sole cost and expense without any increase in Fees, or b) immediately terminate this Contract for cause pursuant to Section 15.1 of the Contract;

5.2 for Hosted Services provided by the Contractor, maintain either a FedRAMP authorization or an annual SSAE 18 SOC 2 Type II audit based on State required NIST Special Publication 800-53 MOD Controls using identified controls and minimum values as established in applicable State PSPs.

5.3 ensure that the Software and State Data is securely hosted, supported, administered, accessed, and backed up in a data center(s) that resides in the continental United States, and minimally meets Uptime Institute Tier 3 standards (www.uptimeinstitute.com), or its equivalent;

5.4 maintain and enforce an information security program including safety and physical and technical security policies and procedures with respect to its Processing of the State Data that complies with the requirements of the State’s data security policies as set forth in this Contract, and must, at a minimum, remain compliant with FISMA and NIST Special Publication 800-53 MOD Controls using identified controls and minimum values as established in applicable State PSPs;

5.5 provide technical and organizational safeguards against accidental, unlawful or unauthorized access to or use, destruction, loss, alteration, disclosure, encryption, transfer, commingling or processing of such information that ensure a level of security appropriate to the risks presented by the processing of State Data and the nature of such State Data, consistent with best industry practice and applicable standards (including, but not limited to, compliance with FISMA, NIST, CMS, IRS, FBI, SSA, HIPAA, FERPA and PCI requirements as applicable);

5.6 take all reasonable measures to:

(a) secure and defend all locations, equipment, systems and other materials and facilities employed in connection with the Services against “malicious actors” and others who may seek, without authorization, to destroy, disrupt, damage, encrypt, modify, copy, access or otherwise use Hosted Services or the information found therein; and

(b) prevent (i) the State and its Authorized Users from having access to the data of other customers or such other customer’s users of the Services; (ii) State Data from being commingled with or contaminated by the data of other customers or their users of the Services; and (iii) unauthorized access to any of the State Data;

5.7 ensure that State Data is encrypted in transit and at rest using FIPS validated AES encryption modules and a key size of 128 bits or higher;

5.8 ensure the Hosted Services support Identity Federation/Single Sign-on (SSO) capabilities using Security Assertion Markup Language (SAML), Open Authentication (OAuth) or comparable State approved mechanisms;

118

5.9 ensure the Hosted Services implements NIST compliant multi-factor authentication for privileged/administrative and other identified access.

6. Security Accreditation Process. Throughout the Term, Contractor will assist the State, at no additional cost, with its Security Accreditation Process, which includes the development, completion and on-going maintenance of a system security plan (SSP) using the State’s automated governance, risk and compliance (GRC) platform, which requires Contractor to submit evidence, upon request from the State, in order to validate Contractor’s security controls within two weeks of the State’s request. On an annual basis, or as otherwise required by the State such as for significant changes, re-assessment of the system’s controls will be required to receive and maintain authority to operate (ATO). All identified risks from the SSP will be remediated through a Plan of Action and Milestones (POAM) process with remediation time frames based on the risk level of the identified risk. For all findings associated with the Contractor’s solution, at no additional cost, Contractor will be required to create or assist with the creation of State approved POAMs and perform related remediation activities. The State will make any decisions on acceptable risk, Contractor may request risk acceptance, supported by compensating controls, however only the State may formally accept risk. Failure to comply with this section will be deemed a material breach of the Contract.

7. Unauthorized Access. Contractor may not access, and shall not permit any access to, State systems, in whole or in part, whether through the Hosted Services or otherwise, without the State’s express prior written authorization. Such authorization may be revoked by the State in writing at any time in its sole discretion. Any access to State systems must be solely in accordance with the Contract and this Schedule, and in no case exceed the scope of the State’s authorization pursuant to this Section. All State-authorized connectivity or attempted connectivity to State systems shall be only through the State’s security gateways and firewalls and in compliance with the State’s security policies set forth in the Contract as the same may be supplemented or amended by the State and provided to Contractor from time to time.

8. Security Audits.

8.1 During the Term, Contractor will maintain complete and accurate records of its data protection practices, IT security controls, and the security logs relating to State Data, including but not limited to any backup, disaster recovery or other policies, practices or procedures relating to the State Data and any other information relevant to its compliance with this Contract.

8.2 Without limiting any other audit rights of the State, the State has the right to review Contractor’s data privacy and information security program prior to the commencement of Services and from time to time during the term of this Contract. The State, at its own expense, is entitled to perform, or to have performed, an on-site audit of Contractor’s data privacy and information security program. If the State chooses to perform an on-site audit, Contractor will, make all such records, appropriate personnel and relevant materials available during normal business hours for inspection and audit by the State or an independent data security expert that is reasonably acceptable to Contractor, provided that the State: (i) gives Contractor at least five (5) Business Days prior notice of any such audit; (ii) undertakes such audit no more than once per calendar year, except for good cause shown; and (iii) conducts or causes to be conducted such audit in a manner designed to minimize disruption of Contractor’s normal business operations and that complies with the terms and conditions of all data confidentiality, ownership, privacy, security and restricted use provisions of the Contract. The State may, but is not obligated to, perform such security audits, which shall, at the State’s option and request, include penetration and security tests, of any and all Hosted Services and their housing facilities and operating environments.

8.3 During the Term, Contractor will, when requested by the State, provide a copy of Contractor’s or Hosting Provider’s FedRAMP System Security Plan(s) or SOC 2 Type 2 report(s) to the State within two weeks of the State’s request. The System Security Plan and SSAE audit reports will be recognized as Contractor’s Confidential Information.

8.4 With respect to State Data, Contractor must implement any required safeguards as identified by the State or by any audit of Contractor’s data privacy and information security program.

119

8.5 The State reserves the right, at its sole election, to immediately terminate this Contract or a Statement of Work without limitation and without liability if the State determines that Contractor fails or has failed to meet its obligations under this Section 8.

9. Application Scanning. During the Term, Contractor must, at its sole cost and expense, scan all Contractor provided applications, and must analyze, remediate and validate all vulnerabilities identified by the scans as required by the State Secure Web Application and other applicable PSPs.

Contractor’s application scanning and remediation must include each of the following types of scans and activities:

9.1 Dynamic Application Security Testing (DAST) – Scanning interactive application for vulnerabilities, analysis, remediation, and validation (may include Interactive Application Security Testing (IAST).

(a) Contractor must either a) grant the State the right to dynamically scan a deployed version of the Software; or b) in lieu of the State performing the scan, Contractor must dynamically scan a deployed version of the Software using a State approved application scanning tool, and provide the State a vulnerabilities assessment after Contractor has completed such scan. These scans and assessments i) must be completed and provided to the State quarterly (dates to be provided by the State) and for each major release; and ii) scans must be completed in a non-production environment with verifiable matching source code and supporting infrastructure configurations or the actual production environment.

9.2 Static Application Security Testing (SAST) - Scanning Source Code for vulnerabilities, analysis, remediation, and validation.

(a) For Contractor provided applications, Contractor, at its sole expense, must provide resources to complete static application source code scanning, including the analysis, remediation and validation of vulnerabilities identified by application Source Code scans. These scans must be completed for all Source Code initially, for all updated Source Code, and for all Source Code for each major release and Contractor must provide the State a vulnerability assessment after Contractor has completed the required scans.

9.3 Software Composition Analysis (SCA) – Third Party and/or Open Source Scanning for vulnerabilities, analysis, remediation, and validation.

(a) For Software that includes third party and open source software, all included third party and open source software must be documented and the source supplier must be monitored by the Contractor for notification of identified vulnerabilities and remediation. SCA scans may be included as part of SAST and DAST scanning or employ the use of an SCA tool to meet the scanning requirements. These scans must be completed for all third party and open source software initially, for all updated third party and open source software, and for all third party and open source software in each major release and Contractor must provide the State a vulnerability assessment after Contractor has completed the required scans if not provided as part of SAST and/or DAST reporting.

9.4 In addition, application scanning and remediation may include the following types of scans and activities if required by regulatory or industry requirements, data classification or otherwise identified by the State.

(a) If provided as part of the solution, all native mobile application software must meet these scanning requirements including any interaction with an application programing interface (API).

(b) Penetration Testing – Simulated attack on the application and infrastructure to identify security weaknesses.

10. Infrastructure Scanning.

120

10.1 For Hosted Services, Contractor must ensure the infrastructure and applications are scanned using an approved scanning tool (Qualys, Tenable, or other PCI Approved Vulnerability Scanning Tool) at least monthly and provide the scan’s assessments to the State in a format that is specified by the State and used to track the remediation. Contractor will ensure the remediation of issues identified in the scan according to the remediation time requirements documented in the State’s PSPs.

11. Nonexclusive Remedy for Security Breach.

11.1 Any failure of the Services to meet the requirements of this Schedule with respect to the security of any State Data or other Confidential Information of the State, including any related backup, disaster recovery or other policies, practices or procedures, is a material breach of the Contract for which the State, at its option, may terminate the Contract immediately upon written notice to Contractor without any notice or cure period, and Contractor must promptly reimburse to the State any Fees prepaid by the State prorated to the date of such termination.

121

SCHEDULE F – Transition In and Out

Transition – In Plan

The Transition IN plan covers the tasks and timeline of the move from the Legacy MDSS to the MDSS 2.0. This plan includes the following components:

- End user training plan

- Data migration plan

- Testing plan

- Go-live plan

The end user training plan will contain a timeline, list of the training material deliverables and a description of the roles and responsibilities. The goal is to have the majority of the MDSS userbase to be trained in the new system prior to go-live and have MDHHS fully trained using a “train the trainer” model.

The Data Migration plan includes a data migration timeline along with the necessary scripts and tools to perform the migration. The data migration process will be fully tested and verified in the TEST environment prior to moving to the production system. Altarum will work with MDHHS and DTMB to set the timing of the data migration and go-live with the goal of minimizing any MDSS downtime.

The Testing Plan specific to the Transition In process include a testing of the new system in the Production Environment prior to “turning off” the Legacy system and “turning on” the new MDSS 2.0. The process begins with Test data in the Test environment and moves to the Production environment with increasingly larger amount of real data with a complete test suite executed including load testing. The final testing occurs with the environment and data simulating the real Production environment as closely as possible without affecting the running Legacy system.

Go-Live will likely be scheduled over a weekend after having tested all aspects of the process prior. Go/No-Go gates will be established at each milestone of the Go-Live process so the team will have the opportunity to make the decision to proceed with the Go-Live or revert in the case of unexpected issues cropping up. The userbase will be alerted well in advance the Altarum team will be standing by to handle any issues or questions.

Transition - Out Plan

Altarum will provide complete transition out services for up to 180 days in the event of contract termination, expiration or non-renewal to allow for a smooth transition of all services to DTMB or its designated 3rd party provider.

Continuity. In the event transition is required, Altarum will continue to provide contracted ancillary services at the labor rates quoted in the proposal until the termination or expiration of the contract. We will provide resources with project experience to ensure no disruption in service during the transition period. M&O support will be provided as required in the contract and, should termination occur post-Warranty, shall be billed on a monthly pro-rata basis.

Transition of performance of work. If the contract is terminated for any reason and transition is required prior to completion of final deliverables, Altarum will ensure a smooth transition of the performance of work to the State or its designated successor. Altarum will do this by appointing a senior Project Manager to be the single point of contact during the Transition Out period. This Transition Project Manager will work with personnel designated by MDHHS and DTMB to create a detailed Transition Out project plan tailored to the point in time when transition is needed. The plan will include the following elements:

• The identification of positions or functions that require transition. • Transition tasks, deliverables, responsible party and timeline. • Description of the dependencies on the successor and specific staffing required to perform the Transition Out plan. • An inventory of documentation and work products required to facilitate the transition.

122

• A risk list co-developed by Altarum and State resources detailing risk factors related to the transition. • A schedule and plan for the return to the State any confidential information, data, documents, records, files, tapes or disks. • System training for State personnel or designee. Training shall be at the request of the State and can cover such items as the technical environment, software build process, system modules and interfaces.

Please note that since Altarum does not provide Tier 1 support for this system, no helpdesk operations or helpdesk materials will need to be transitioned. During the transition period, Altarum will work with MDHHS and DTMB to review all reasonable requests for additional information not covered by the above list.

Return of State Materials and Preservation of State Data. Altarum will work the State to develop an inventory of all materials in Altarum’s possession that need to be returned to the State. This includes all data, source code, equipment, documents, files and other materials provided by the State for the performance of the contract. In addition, Altarum will ensure that all State data provided during the contract period is maintained and preserved during the Transition Out period until such time that that data is transferred to State-designated custodial owners and responsible parties.

Transfer of Deliverables. Altarum will provide and review with MDHHS successor all deliverables completed or in progress at the time of transition. This includes documentation, source code, libraries, technical specifications. If ancillary services are being provided at this time, during transition planning, Altarum will develop a list of completed and in-progress deliverables for the State to review to determine which require transition, to whom, and the timelines for the deliverable transfer.

Final Accounting. Altarum will work with the State to determine a final accounting of the project. This will include an accounting of the labor hours by category up to point of Transition Out, the Transition Out activities and hours, and other materials, invoices or factors deemed relevant to final project accounting. Altarum will iterate this process with the State as needed to ensure a final accounting is complete and accurate.

This Transition-Out Plan assumes that any contract termination or expiration would occur after the Solution has been fully developed and implemented. As there are many points in the project timeline that could be impacted by an unforeseen termination during development, should a termination during the initial Term (i.e. prior to full development and implementation), additional services may be required to “wind down” any activities in process, as to ensure no impacts to operation of the current system.

Should the State require such termination during the development of the Solution, Altarum will work with the State to define and develop a project plan, and associated costs (based on the Ancillary Services pricing schedule), to create a supplemental Transition Out strategy, in addition to the Plan provided herein.

123

SCHEDULE G - Federal Provisions Addendum

This addendum applies to purchases that will be paid for in whole or in part with funds obtained from the federal government. The provisions below are required and the language is not negotiable. If any provision below conflicts with the State’s terms and conditions, including any attachments, schedules, or exhibits to the State’s Contract, the provisions below take priority to the extent a provision is required by federal law; otherwise, the order of precedence set forth in the Contract applies. Hyperlinks are provided for convenience only; broken hyperlinks will not relieve Contractor from compliance with the law.

1. Equal Employment Opportunity

If this Contract is a “federally assisted construction contract” as defined in 41 CFR Part 60-1.3, and except as otherwise may be provided under 41 CFR Part 60, then during performance of this Contract, the Contractor agrees as follows:

(1) The Contractor will not discriminate against any employee or applicant for employment because of race, color, religion, sex, sexual orientation, gender identity, or national origin. The Contractor will take affirmative action to ensure that applicants are employed, and that employees are treated during employment without regard to their race, color, religion, sex, sexual orientation, gender identity, or national origin. Such action shall include, but not be limited to the following:

Employment, upgrading, demotion, or transfer; recruitment or recruitment advertising; layoff or termination; rates of pay or other forms of compensation; and selection for training, including apprenticeship. The Contractor agrees to post in conspicuous places, available to employees and applicants for employment, notices to be provided setting forth the provisions of this nondiscrimination clause.

(2) The Contractor will, in all solicitations or advertisements for employees placed by or on behalf of the Contractor, state that all qualified applicants will receive consideration for employment without regard to race, color, religion, sex, sexual orientation, gender identity, or national origin.

(3) The Contractor will not discharge or in any other manner discriminate against any employee or applicant for employment because such employee or applicant has inquired about, discussed, or disclosed the compensation of the employee or applicant or another employee or applicant. This provision shall not apply to instances in which an employee who has access to the compensation information of other employees or applicants as a part of such employee's essential job functions discloses the compensation of such other employees or applicants to individuals who do not otherwise have access to such information, unless such disclosure is in response to a formal complaint or charge, in furtherance of an investigation, proceeding, hearing, or action, including an investigation conducted by the employer, or is consistent with the Contractor's legal duty to furnish information.

(4) The Contractor will send to each labor union or representative of workers with which he has a collective bargaining agreement or other contract or understanding, a notice to be provided advising the said labor union or workers' representatives of the Contractor's commitments under this section, and shall post copies of the notice in conspicuous places available to employees and applicants for employment.

(5) The Contractor will comply with all provisions of Executive Order 11246 of September 24, 1965, and of the rules, regulations, and relevant orders of the Secretary of Labor.

(6) The Contractor will furnish all information and reports required by Executive Order 11246 of September 24, 1965, and by rules, regulations, and orders of the Secretary of Labor, or pursuant thereto, and will permit access to his books, records, and accounts by the administering agency and the Secretary of Labor for purposes of investigation to ascertain compliance with such rules, regulations, and orders.

(7) In the event of the Contractor's noncompliance with the nondiscrimination clauses of this contract or with any of the said rules, regulations, or orders, this Contract may be canceled, terminated, or suspended in whole or in

124

part and the Contractor may be declared ineligible for further Government contracts or federally assisted construction contracts in accordance with procedures authorized in Executive Order 11246 of September 24, 1965, and such other sanctions may be imposed and remedies invoked as provided in Executive Order 11246 of September 24, 1965, or by rule, regulation, or order of the Secretary of Labor, or as otherwise provided by law.

(8) The Contractor will include the portion of the sentence immediately preceding paragraph (1) and the provisions of paragraphs (1) through (8) in every subcontract or purchase order unless exempted by rules, regulations, or orders of the Secretary of Labor issued pursuant to section 204 of Executive Order 11246 of September 24, 1965, so that such provisions will be binding upon each subcontractor or vendor. The Contractor will take such action with respect to any subcontract or purchase order as the administering agency may direct as a means of enforcing such provisions, including sanctions for noncompliance:

Provided, however, that in the event a Contractor becomes involved in, or is threatened with, litigation with a subcontractor or vendor as a result of such direction by the administering agency, the Contractor may request the United States to enter into such litigation to protect the interests of the United States.

The applicant further agrees that it will be bound by the above equal opportunity clause with respect to its own employment practices when it participates in federally assisted construction work: Provided, that if the applicant so participating is a State or local government, the above equal opportunity clause is not applicable to any agency, instrumentality or subdivision of such government which does not participate in work on or under the contract.

The applicant agrees that it will assist and cooperate actively with the administering agency and the Secretary of Labor in obtaining the compliance of contractors and subcontractors with the equal opportunity clause and the rules, regulations, and relevant orders of the Secretary of Labor, that it will furnish the administering agency and the Secretary of Labor such information as they may require for the supervision of such compliance, and that it will otherwise assist the administering agency in the discharge of the agency's primary responsibility for securing compliance.

The applicant further agrees that it will refrain from entering into any contract or contract modification subject to Executive Order 11246 of September 24, 1965, with a contractor debarred from, or who has not demonstrated eligibility for, Government contracts and federally assisted construction contracts pursuant to the Executive Order and will carry out such sanctions and penalties for violation of the equal opportunity clause as may be imposed upon contractors and subcontractors by the administering agency or the Secretary of Labor pursuant to Part II, Subpart D of the Executive Order. In addition, the applicant agrees that if it fails or refuses to comply with these undertakings, the administering agency may take any or all of the following actions: Cancel, terminate, or suspend in whole or in part this grant (contract, loan, insurance, guarantee); refrain from extending any further assistance to the applicant under the program with respect to which the failure or refund occurred until satisfactory assurance of future compliance has been received from such applicant; and refer the case to the Department of Justice for appropriate legal proceedings.

2. Davis-Bacon Act (Prevailing Wage)

If this Contract is a prime construction contracts in excess of $2,000, the Contractor (and its Subcontractors) must comply with the Davis-Bacon Act (40 USC 3141-3148) as supplemented by Department of Labor regulations (29 CFR Part 5, “Labor Standards Provisions Applicable to Contracts Covering Federally Financed and Assisted Construction”), and during performance of this Contract the Contractor agrees as follows:

(1) All transactions regarding this contract shall be done in compliance with the Davis-Bacon Act (40 U.S.C. 3141- 3144, and 3146-3148) and the requirements of 29 C.F.R. pt. 5 as may be applicable. The contractor shall comply with 40 U.S.C. 3141-3144, and 3146-3148 and the requirements of 29 C.F.R. pt. 5 as applicable.

(2) Contractors are required to pay wages to laborers and mechanics at a rate not less than the prevailing wages specified in a wage determination made by the Secretary of Labor.

125

(3) Additionally, contractors are required to pay wages not less than once a week.

3. Copeland “Anti-Kickback” Act

If this Contract is a contract for construction or repair work in excess of $2,000 where the Davis-Bacon Act applies, the Contractor must comply with the Copeland “Anti-Kickback” Act (40 USC 3145), as supplemented by Department of Labor regulations (29 CFR Part 3, “Contractors and Subcontractors on Public Building or Public Work Financed in Whole or in Part by Loans or Grants from the United States”), which prohibits the Contractor and subrecipients from inducing, by any means, any person employed in the construction, completion, or repair of public work, to give up any part of the compensation to which he or she is otherwise entitled, and during performance of this Contract the Contractor agrees as follows: (1) Contractor. The Contractor shall comply with 18 U.S.C. § 874, 40 U.S.C. § 3145, and the requirements of 29 C.F.R. pt. 3 as may be applicable, which are incorporated by reference into this contract.

(2) Subcontracts. The Contractor or Subcontractor shall insert in any subcontracts the clause above and such other clauses as FEMA or the applicable federal awarding agency may by appropriate instructions require, and also a clause requiring the Subcontractors to include these clauses in any lower tier subcontracts. The prime contractor shall be responsible for the compliance by any subcontractor or lower tier subcontractor with all of these contract clauses. (3) Breach. A breach of the contract clauses above may be grounds for termination of the contract, and for debarment as a Contractor and Subcontractor as provided in 29 C.F.R. § 5.12.

4. Contract Work Hours and Safety Standards Act

If the Contract is in excess of $100,000 and involves the employment of mechanics or laborers, the Contractor must comply with 40 USC 3702 and 3704, as supplemented by Department of Labor regulations (29 CFR Part 5), as applicable, and during performance of this Contract the Contractor agrees as follows:

(1) Overtime requirements. No Contractor or Subcontractor contracting for any part of the contract work which may require or involve the employment of laborers or mechanics shall require or permit any such laborer or mechanic in any workweek in which he or she is employed on such work to work in excess of forty hours in such workweek unless such laborer or mechanic receives compensation at a rate not less than one and one-half times the basic rate of pay for all hours worked in excess of forty hours in such workweek.

(2) Violation; liability for unpaid wages; liquidated damages. In the event of any violation of the clause set forth in paragraph (1) of this section the Contractor and any Subcontractor responsible therefor shall be liable for the unpaid wages. In addition, such Contractor and Subcontractor shall be liable to the United States (in the case of work done under contract for the District of Columbia or a territory, to such District or to such territory), for liquidated damages. Such liquidated damages shall be computed with respect to each individual laborer or mechanic, including watchmen and guards, employed in violation of the clause set forth in paragraph (1) of this section, in the sum of $27 for each calendar day on which such individual was required or permitted to work in excess of the standard workweek of forty hours without payment of the overtime wages required by the clause set forth in paragraph (1) of this section.

(3) Withholding for unpaid wages and liquidated damages. The State shall upon its own action or upon written request of an authorized representative of the Department of Labor withhold or cause to be withheld, from any moneys payable on account of work performed by the Contractor or Subcontractor under any such contract or any other Federal contract with the same prime contractor, or any other federally-assisted contract subject to the Contract Work Hours and Safety Standards Act, which is held by the same prime contractor, such sums as may be determined to be necessary to satisfy any liabilities of such contractor or subcontractor for unpaid wages and liquidated damages as provided in the clause set forth in paragraph (2) of this section.

126

(4) Subcontracts. The Contractor or Subcontractor shall insert in any subcontracts the clauses set forth in paragraph (1) through (4) of this section and also a clause requiring the Subcontractors to include these clauses in any lower tier subcontracts. The prime contractor shall be responsible for compliance by any subcontractor or lower tier subcontractor with the clauses set forth in paragraphs (1) through (4) of this section.

5. Rights to Inventions Made Under a Contract or Agreement

If the Contract is funded by a federal “funding agreement” as defined under 37 CFR §401.2 (a) and the recipient or subrecipient wishes to enter into a contract with a small business firm or nonprofit organization regarding the substitution of parties, assignment or performance of experimental, developmental, or research work under that “funding agreement,” the recipient or subrecipient must comply with 37 CFR Part 401, “Rights to Inventions Made by Nonprofit Organizations and Small Business Firms Under Government Grants, Contracts and Cooperative Agreements,” and any implementing regulations issued by the awarding agency.

6. Clean Air Act and the Federal Water Pollution Control Act

If this Contract is in excess of $150,000, the Contractor must comply with all applicable standards, orders, and regulations issued under the Clean Air Act (42 USC 7401-7671q) and the Federal Water Pollution Control Act (33 USC 1251-1387), and during performance of this Contract the Contractor agrees as follows:

Clean Air Act

1. The Contractor agrees to comply with all applicable standards, orders or regulations issued pursuant to the Clean Air Act, as amended, 42 U.S.C. § 7401 et seq. 2. The Contractor agrees to report each violation to the State and understands and agrees that the State will, in turn, report each violation as required to assure notification to the Federal Emergency Management Agency or the applicable federal awarding agency, and the appropriate Environmental Protection Agency Regional Office. 3. The Contractor agrees to include these requirements in each subcontract exceeding $150,000 financed in whole or in part with Federal assistance provided by FEMA or the applicable federal awarding agency.

Federal Water Pollution Control Act

1. The Contractor agrees to comply with all applicable standards, orders, or regulations issued pursuant to the Federal Water Pollution Control Act, as amended, 33 U.S.C. 1251 et seq. 2. The Contractor agrees to report each violation to the State and understands and agrees that the State will, in turn, report each violation as required to assure notification to the Federal Emergency Management Agency or the applicable federal awarding agency, and the appropriate Environmental Protection Agency Regional Office. 3. The Contractor agrees to include these requirements in each subcontract exceeding $150,000 financed in whole or in part with Federal assistance provided by FEMA or the applicable federal awarding agency.

7. Debarment and Suspension

A “contract award” (see 2 CFR 180.220) must not be made to parties listed on the government-wide exclusions in the System for Award Management (SAM), in accordance with the OMB guidelines at 2 CFR 180 that implement Executive Orders 12549 (51 FR 6370; February 21, 1986) and 12689 (54 FR 34131; August 18, 1989), “Debarment and Suspension.” SAM Exclusions contains the names of parties debarred, suspended, or otherwise excluded by agencies, as well as parties declared ineligible under statutory or regulatory authority other than Executive Order 12549.

127

(1) This Contract is a covered transaction for purposes of 2 C.F.R. pt. 180 and 2 C.F.R. pt. 3000. As such, the Contractor is required to verify that none of the Contractor’s principals (defined at 2 C.F.R. § 180.995) or its affiliates (defined at 2 C.F.R. § 180.905) are excluded (defined at 2 C.F.R. § 180.940) or disqualified (defined at 2 C.F.R. § 180.935). (2) The Contractor must comply with 2 C.F.R. pt. 180, subpart C and 2 C.F.R. pt. 3000, subpart C, and must include a requirement to comply with these regulations in any lower tier covered transaction it enters into. (3) This certification is a material representation of fact relied upon by the State. If it is later determined that the contractor did not comply with 2 C.F.R. pt. 180, subpart C and 2 C.F.R. pt. 3000, subpart C, in addition to remedies available to the State, the Federal Government may pursue available remedies, including but not limited to suspension and/or debarment. (4) The Contractor or proposer agrees to comply with the requirements of 2 C.F.R. pt. 180, subpart C and 2 C.F.R. pt. 3000, subpart C while this offer is valid and throughout the period of any contract that may arise from this offer. The Contractor or proposer further agrees to include a provision requiring such compliance in its lower tier covered transactions.

8. Byrd Anti-Lobbying Amendment

Contractors who apply or bid for an award of $100,000 or more shall file the required certification in Exhibit 1 – Byrd Anti-Lobbying Certification below. Each tier certifies to the tier above that it will not and has not used Federal appropriated funds to pay any person or organization for influencing or attempting to influence an officer or employee of any agency, a Member of Congress, officer or employee of Congress, or an employee of a Member of Congress in connection with obtaining any Federal contract, grant, or any other award covered by 31 U.S.C. § 1352. Each tier shall also disclose any lobbying with non-Federal funds that takes place in connection with obtaining any Federal award. Such disclosures are forwarded from tier to tier up to the recipient who in turn will forward the certification(s) to the awarding agency.

9. Procurement of Recovered Materials

Under 2 CFR 200.322, Contractors must comply with section 6002 of the Solid Waste Disposal Act, as amended by the Resource Conservation and Recovery Act.

(1) In the performance of this contract, the Contractor shall make maximum use of products containing recovered materials that are EPA-designated items unless the product cannot be acquired—

a. Competitively within a timeframe providing for compliance with the contract performance schedule; b. Meeting contract performance requirements; or c. At a reasonable price.

(2) Information about this requirement, along with the list of EPA- designated items, is available at EPA’s Comprehensive Procurement Guidelines web site, https://www.epa.gov/smm/comprehensive- procurement-guideline-cpg-program.

(3) The Contractor also agrees to comply with all other applicable requirements of Section 6002 of the Solid Waste Disposal Act.

10. Additional FEMA Contract Provisions.

The following provisions apply to purchases that will be paid for in whole or in part with funds obtained from the Federal Emergency Management Agency (FEMA):

128

(1) Access to Records. The following access to records requirements apply to this contract: a. The Contractor agrees to provide the State, the FEMA Administrator, the Comptroller General of the United States, or any of their authorized representatives access to any books, documents, papers, and records of the Contractor which are directly pertinent to this contract for the purposes of making audits, examinations, excerpts, and transcriptions. b. The Contractor agrees to permit any of the foregoing parties to reproduce by any means whatsoever or to copy excerpts and transcriptions as reasonably needed. c. The Contractor agrees to provide the FEMA Administrator or his authorized representatives access to construction or other work sites pertaining to the work being completed under the contract. d. In compliance with the Disaster Recovery Act of 2018, the State and the Contractor acknowledge and agree that no language in this contract is intended to prohibit audits or internal reviews by the FEMA Administrator or the Comptroller General of the United States.

(2) Changes. See the provisions regarding modifications or change notice in the Contract Terms.

(3) DHS Seal, Logo, And Flags. The Contractor shall not use the DHS seal(s), logos, crests, or reproductions of flags or likenesses of DHS agency officials without specific FEMA pre-approval.

(4) Compliance with Federal Law, Regulations, and Executive Orders. This is an acknowledgement that FEMA financial assistance will be used to fund all or a portion of the contract. The Contractor will comply with all applicable Federal law, regulations, executive orders, FEMA policies, procedures, and directives.

(5) No Obligation by Federal Government. The Federal Government is not a party to this contract and is not subject to any obligations or liabilities to the State, Contractor, or any other party pertaining to any matter resulting from the Contract.”

(6) Program Fraud and False or Fraudulent Statements or Related Acts. The Contractor acknowledges that 31 U.S.C. Chap. 38 (Administrative Remedies for False Claims and Statements) applies to the Contractor’s actions pertaining to this contract.

129

Schedule G, Attachment 1 - Byrd Anti-Lobbying Certification

Contractor must complete this certification if the purchase will be paid for in whole or in part with funds obtained from the federal government and the purchase is greater than $100,000.

APPENDIX A, 44 C.F.R. PART 18 – CERTIFICATION REGARDING LOBBYING

Certification for Contracts, Grants, Loans, and Cooperative Agreements

The undersigned certifies, to the best of his or her knowledge and belief, that:

1. No Federal appropriated funds have been paid or will be paid, by or on behalf of the undersigned, to any person for influencing or attempting to influence an officer or employee of an agency, a Member of Congress, an officer or employee of Congress, or an employee of a Member of Congress in connection with the awarding of any Federal contract, the making of any Federal grant, the making of any Federal loan, the entering into of any cooperative agreement, and the extension, continuation, renewal, amendment, or modification of any Federal contract, grant, loan, or cooperative agreement.

2. If any funds other than Federal appropriated funds have been paid or will be paid to any person for influencing or attempting to influence an officer or employee of any agency, a Member of Congress, an officer or employee of Congress, or an employee of a Member of Congress in connection with this Federal contract, grant, loan, or cooperative agreement, the undersigned shall complete and submit Standard Form-LLL, “Disclosure Form to Report Lobbying,” in accordance with its instructions.

3. The undersigned shall require that the language of this certification be included in the award documents for all subawards at all tiers (including subcontracts, subgrants, and contracts under grants, loans, and cooperative agreements) and that all subrecipients shall certify and disclose accordingly.

This certification is a material representation of fact upon which reliance was placed when this transaction was made or entered into. Submission of this certification is a prerequisite for making or entering into this transaction imposed by section 1352, title 31, U.S. Code. Any person who fails to file the required certification shall be subject to a civil penalty of not less than $10,000 and not more than $100,000 for each such failure.

The Contractor, certifies or affirms the truthfulness and accuracy of each statement of its certification and disclosure, if any. In addition, the Contractor understands and agrees that the provisions of 31 U.S.C. Chap. 38, Administrative Remedies for False Claims and Statements, apply to this certification and disclosure, if any.

______Signature of Contractor’s Authorized Official

______Name and Title of Contractor’s Authorized Official

______Date

130

APPENDIX A: OPTIONAL TASKS

I. Optional Task 1: Contact Tracing and Patient Outreach Altarum proposes to bring Contact Tracing and Patient Outreach in-house to integrate that functionality more tightly into MDSS, automate processes and cut long-term maintenance costs. The legacy MDSS system supports contact tracing and patient outreach capabilities through an integration with the external TraceForce and PEG COVID-19 patient outreach systems. Altarum proposes replacing this with a capability native to MDSS 2.0 that will enable users to:

1. Generate and deploy contact tracing forms 2. Generate and deploy patient surveys for any condition 3. Generate materials for patient educational outreach and surveys 4. Generate materials for outreach and recommendations to clinicians

The integrated system will be customizable to support time-saving features such as automatically creating scripts or guidance for contact tracers reaching out to patients through text and email for surveys. It can also be used to distribute educational materials to targeted patients or clinicians. These services can be applied to any condition, providing a broadly applicable solution for the MDSS user community.

For local health support, the system will offer a user dashboard in the MDSS for local health department contact tracers and provide SMS text messaging capabilities. MDSS disease specific forms will be extended to include scripted preset or customized SMS text messages that may be sent to suspected patient contacts on a configurable schedule. Message replies would be automatically captured and used to populate MDSS 2.0. Contract tracing personnel may review replies and resend questions as needed to complete tracing.

Survey enhancement will extend the MDSS disease-specific forms to include patient-directed questions. The questions will be extracted and published in a public-facing survey system to collect information directly from patient populations. Automated SMS text messages or emails with an access token can be sent to the patient directing them to the survey site. Data will then be collected from the survey and returned to MDSS. These tools also enable the patient and clinician educational outreach described above. Bringing these capabilities into the MDSS:

• Streamlines the creation and deployment of outreach activities • Provides a consistent service for all conditions • Removes extra coordination with external systems and vendors • Eliminates unacceptable long-term maintenance costs This MDSS 2.0 integrated system would eliminate duplicative effort and remove delays inherent to the current multi- vendor/multi-tool environment. For example, if the CDC updates reportable condition guides and new data fields are created, those changes can be made in one place to update MDSS and all survey instruments and contact tracing scripts. No meetings between different vendors to confirm data formats, to schedule tool updates, or to negotiate costs.

This system also allows for a unified view of the entire contact tracing process including up-to-the-minute status on progress. The MDSS 2.0 microservices architecture makes it easy to pull data from different modules and present them in an easy-to-use dashboard. This unified view could include status of patient outreach actions, test results, case creation status, case status, and other items of interest. Currently, such a comprehensive view requires waiting for batch file imports to be completed from multiple tools, deduplication tasks to be completed, and all data aggregated into a single view.

131

II. Optional Task 2: An Integrated Chronic Disease Warehouse Altarum proposes to build a Chronic Disease Warehouse (CDW) that is housed in the MDSS program and captures State-wide registry data for conditions such as asthma, heart disease, hypertension, and diabetes and tightly integrated with the modernized MDSS. More than 60 percent of Michigan's adult population suffers from a chronic disabling condition, and over 95 percent of Michigan adults report behaviors that can lead to many chronic diseases, such as smoking, unhealthy diet, lack of physical activity, and alcohol use.1 A centralized CDW covering many conditions and risk behaviors will improve Michigan’s ability to analyze, evaluate, and deliver services for existing cases and to better prevent new cases through improved resource allocation, policy, and planning.

The CDW would provide immediate benefits to Michigan’s public health capabilities and provide a more complete picture of population health across Michigan. It will also eliminate the siloed databases and spreadsheets where much of the chronic disease data are currently housed. A single centralized CDW tightly integrated with MDSS 2.0 will provide insights on patient-level comorbidities, which are important to understanding likely clinical outcomes and managing communicable disease outbreaks. The new MDSS 2.0 services would enable the CDW to:

• Connect and analyze hospital-based information systems and data with advanced analytical models. Most predictive analytics focus on one specific event. Future opportunities should consider multi-task learning that encompasses multiple comorbidities common among people with chronic disease.

• Include “health sensing” data such as physiological signals (heart rate, blood pressure, blood glucose, etc.), genomic biomarkers, EHR, radiology and imaging data, etc. This will be particularly useful in tracking chronic conditions as the population ages (conditions and adverse events include frailty, diabetes, Parkinson’s disease, dementia, stroke, falls, etc.).

• Provide region-specific population-based views and reports to serve individual communities to reduce disparities and improve equity in chronic disease care and outcomes.

• Support Michigan’s providers with clinical decision support. A centralized CDW will establish data standards that improve data aggregation, consolidation, and extraction to support management of specific populations with flexible reporting for groups of patients and individual patients. This will help providers identify and reach patients at an earlier point in time, preventing more costly care such as emergency department visits.

• Utilize intuitive user interfaces and templates. The MDSS 2.0 visualization module empowers CDW users to discover insights quickly, on their own, to make data-driven decisions.

• Leverage new architecture. The CDW would be created using the MDSS 2.0 services, which would allow for the same flexibility and scalability inherent to the modernized MDSS. We believe integrating a CDW into MDSS 2.0 will also pay immense dividends by helping the State reduce the impact of infectious diseases on vulnerable populations. Building an integrated CDW offers several other notable benefits:

1. Epidemiologists can better understand health disparities and social determinants of health, informing prevention and service delivery plans that will advance health equity. 2. Epidemiologists can track multi-morbidity across all chronic disease types that increase patients’ risk of mortality and other negative health outcomes. 3. Investigators can be alerted of new cases and cluster patterns. 4. Health care providers and payers can improve population health by identifying gaps in care and areas for quality improvement. 5. Health care providers can access patient risk stratification computed by machine learning algorithms based on a more complete set of chronic and communicable disease data. 6. Integrating the CDW closely with the Outbreak Management System (OMS) will enable patient risk

1 MDHHS - Overview of the Chronic Disease Epidemiology Section (michigan.gov)

132

APPENDIX A: OPTIONAL TASKS

stratification during outbreaks of novel viruses like COVID-19. For example, an outbreak tracked in OMS can be associated with a list of diabetes cases in the region, allowing local health jurisdictions to target interventions for the most vulnerable populations. Stratification algorithms can also account for existing surveillance data on chronic conditions and behavioral risk factors (e.g., smoking, drug/alcohol use, etc.) to inform population-based strategies. 7. Provide MDSS users and other stakeholders a better picture of co-morbidities for complex chronic cases such as cancer, mental health disorders, substance use disorders, and infectious diseases to improve population health management Statewide.

III. Optional Task 3: Outbreak Management Reimagined Recent experience has shed light on the need for a much-improved Outbreak Management System (OMS). Altarum proposes enhancing the OMS to better handle the next public health emergency by adding advanced features to better support public health response.

Expand the capability to receive data from different data sources. Improve OMS capabilities to receive data feeds from CDC, local health departments, schools, hospitals, and others in different formats to foster earlier detection of outbreaks and investigation of exposure trends. Integrating these data feeds with case investigation processes will allow contact information collected to be immediately part of OMS. Unique contact records will be maintained by using the advanced deduplication services planned for MDSS 2.0.

Integrate with hospital feeds. OMS would mine ADT messages from hospitals for specific disease diagnosis codes of interest for early outbreak detection and real-time capacity monitoring. By integrating OMS with Michigan’s Syndromic Surveillance System, it can also receive spike alerts that indicate potential early outbreak activity. Customized, disease-specific workflows can then alert different user groups of emerging capacity issues, emerging disease or syndrome concerns, and the need for further analysis.

Broadening the user base. Extending access to OMS to health care providers, including behavioral/mental health, community health workers, etc., would promote earlier disease detection and response. The enhanced module will also improve analysis of disease trends and impacts on sensitive population groups. It will also feature insightful dashboards and robust reporting to help users understand the state of contact imports, contact data collection, and contact-to-case conversions. This functionality will assist administrators when assigning responsibilities and assist users in managing their workload.

Integrate with Contact Isolation Monitoring program. This TraceForce module is used to determine the need for isolation housing. Bringing it into OMS would allow authorized users to assess needs, register residents, track daily monitoring information as part of wellness checks, update resident status based on periodic evaluations (i.e. completed isolation, needs emergency care, needs telehealth, etc.) and to track overall well-being during the monitoring period to determine if escalation is needed.

Thoughtful user interaction. The new system would improve user experience in ways that promote convenient and efficient management of outbreaks regardless of the size or complexity of the outbreak. This includes extended configuration options that can be controlled and applied at a jurisdiction level, an outbreak level, or according to other user preferences.

Advanced analytics and ad-hoc reporting capabilities. We would seek to incorporate new data sources and advanced analytics to facilitate rapid investigation and support targeted, timely response to emerging outbreaks. Examples of more advanced capabilities include tracking the regional distribution of genetic viral subtypes, or functions to support early transmission assessment to help ensure the safety of health care workers responding in the early phases of an outbreak of a novel disease. Also, more robust reporting capabilities to handle line listing, geographic trends, and demographic reports. Ad-hoc reporting would enable advanced users to better identify outbreak-specific spread trends based on monitoring data and identify hot spot areas linked to drill drown reports identifying emerging patterns and impacts of different parameters over different outbreaks.

IV. Optional Task 4: Syringe Service Program Utilization Platform (SUP) Enhancements Altarum proposes to enhance the MDHHS Syringe Service Program Utilization Platform (SUP) module to take full advantage of the new MDSS 2.0 microservices architecture. This optional task offers the following suggested enhancements we believe will be beneficial to the SUP user community.

133

APPENDIX A: OPTIONAL TASKS

Mobile device support. The SUP module could be refactored to better support devices like tablets for the main, non-administrator related functionality of the module covering activities like encounter related data entry.

Dashboard overview and graphs of module usage. Adding a dashboard view for system and organization administrators to view summaries, statistics, graphs, and trends of the module data captured at various levels. This can include standardized breakouts or analyses that users currently perform externally on the exported data – making these available for other module users or user roles. Data topics include: monitoring supply usage over time showing trends and helping with next event resource planning; locating “hot spot” areas that may need additional support or encounter events; analyzing client demographics to assist outreach planning; and incorporating census data to locate potential areas for future encounters.

“New trend” monitoring. The existing encounter and client intake forms capture data on known topics and desired client monitoring. A “new trend” monitoring capability would capture data on a new substance or variation that end users are starting to observe during client encounters. It would also help alert SUP administrative users of potential new adjustments to the module or program planning.

User role-based “to do” lists. Adding a “To Do” list section to the users “My Action” tab would help remind users of activities that need to be performed to keep the module up to date. As an example, the addition of a new SUP module could show users a “To Do” item on the first page that would serve as a quick reminder that there are still users who need to have their initial module role and organization affiliation defined.

Alerts. An alerting system in the SUP module would notify users of monitored events. This would leverage the MDSS 2.0 messaging service and include things like sending an email to system administrators when a new user request arrives or sending a text message to a user’s cell phone when a specified data condition has been observed.

User enhancement comment area. Adding the capability for users to comment on portions of the system that could be adjusted to better integrate with their daily workflow or streamline discussions with clients during encounters. These comments could remain centrally tracked instead of through external email discussions. SUP program managers and administrators could then review and categorize these comments and determine whether to schedule any of these user-informed updates in future module releases.

Other “read only” user support. To support the needs of users who do not perform data entry, additional views or functionality would be added to help support the State and jurisdictional roles beyond the current “read only” views of the system form data and lists.

V. Optional Task 5: Google Research Data Warehouse and Analytics Laboratory Altarum has partnered with Google on this optional task to allow MDHHS to create a Research Data Warehouse (RDW) and leverage Google Cloud’s product portfolio with its robust analytics capabilities. It could also provide a place to test other aspects of the Google platform that may be helpful to MDHHS, including lower cost database options and native cloud tools and services to optimize application performance.

This task would create a pipeline of de-identified MDSS 2.0 data that would be securely sent to the Google platform. Altarum would work with Google to set up the environment. MDSS 2.0 users could then use this RDW to explore the data in novel ways not currently available.

To aid in testing and development efforts, Google has agreed to provide the help of their engineering team. Google engineers would work hand-in-hand with Altarum to design and architect the deployment. The combined team could provide valuable insight when it comes to building integrations, or pipelines to existing data sources, or Google’s curated public data sets.

One of the biggest benefits of creating a RDW on the Google platform is access to BigQuery. BigQuery is a fully managed, serverless data warehouse that enables scalable, cost-effective, rapid analysis over petabytes of data. It is a serverless Software as a Service (SaaS) that supports querying using ANSI SQL. It also has built-in:

• Machine learning capabilities. Machine learning (ML) enables data scientists and data analysts to build and operationalize ML models directly inside BigQuery.

134

APPENDIX A: OPTIONAL TASKS

• GIS. GIS uniquely combines the serverless architecture of BigQuery with native support for geospatial analysis.

• Public datasets. Users can access these datasets, hosted by BigQuery, and integrate them into their applications. This includes Census data, data from the American Hospital Association, CDC birth data, CMS dual enrollment data, and many others. Google pays for the storage of these datasets and provides public access to the data via a project.

• Business Intelligence (BI) Engine. BI Engine provides in-memory analysis allowing users to analyze large and complex datasets interactively with sub-second query response time and high concurrency.

• Connected Sheets. Connected Sheets allows users to analyze billions of rows of live BigQuery data in Google Sheets without requiring SQL knowledge. Users can apply familiar tools—like pivot tables, charts, and formulas—to easily derive insights from big data.

VI. We are including this optional task to offer MDHHS a low-cost, low-risk way to explore using Google’s Cloud Platform and related BI tools, analytics capabilities, and datasets. Optional Task 6: Ad-Hoc Services Optional Task 6 is meant to make it easy to request Altarum’s help under the MDSS 2.0 contract in other areas not covered in any of the other Optional Tasks. As we saw during the past year, rapid development and deployment of new integrations and upgrades were critical to the State’s COVID response and Altarum was able to easily partner with the MDHHS team and deliver needed enhancements with agility.

An example of a task not covered by the other optional tasks is the potential integration of pharmacy data into the MDSS 2.0. A doctor's diagnosis followed by a prescription can be a good clinical indicator for case investigation and used in surveillance systems, and it may also help to eliminate false positives. Pharmacy data can be received as part of the existing data types such as eCRs, and CCDA and other HL7 messages formats (RDE, OMP types). The MDSS 2.0 messaging services could be used to capture pharmacy data from multiple sources (MAPS – the prescription drug monitoring program, provider EHRs, pharmacy benefit managers, and the clinical pharmacies themselves) and integrate it into MDSS.

MDHHS would work with the Altarum team to further refine required features of such a task including how the data would be viewed, analyzed and exported, which MDSS 2.0 modules could potentially use the data, and the algorithms needed to inform case definition, promote earlier detection, and improve investigation of surveillance events. The received prescription data could be displayed as part of the patient record in the MDSS application and pharmacy data could also be screened for vaccine related information and interpreted based on a subsequent mapping with any reportable conditions in the MDSS.

135