STATEMENT OF WORK (SOW)
(HHSAS Req # 53700 – 5 – 0000141080)
For
DSHS Health Services Gateway (HSG) Managed Services
Department of State Health Services (DSHS)
Chief Technology Officer (CTO) Unit
Uber Operations must submit Responses and direct inquiries to:
Health and Human Services Commission (HHSC) Procurement and Contracting Services
Attn: Debbie Arbuckle, CTPM 4405 North Lamar Blvd
Austin, TX 78756 Office: (512) 206 – 4733 Email: [email protected]
All communications relating to this SOW must be directed to the HHSC contact person named above. All communications between respondents and other HHS staff members concerning this procurement are strictly prohibited.
To prevent opening by unauthorized individuals, all response copies must be sealed in the package. The following must be clearly typed on a label affixed to the package in a clearly visible location:
SOW Response: Submitted in Response to SOW (HHSAS Req # 53700-4-0000141080) Response Due Date: May 15, 2015 @ 2:00 pm
Attention: Debbie Arbuckle, CTPM
1 INTRODUCTION ________________________________________________________ 3 2 BACKGROUND ________________________________________________________ 3 3 SCOPE _______________________________________________________________ 6 4 DELIVERABLES _______________________________________________________ 11 5 REPORTS AND MEETINGS ______________________________________________ 13 6 SERVICE LEVEL AGREEMENT __________________________________________ 14 7 PERIOD OF PERFORMANCE ____________________________________________ 17 8. INVOICES ____________________________________________________________ 18 9. DSHS/VENDOR FURNISHED EQUIPMENT AND WORK SPACE ________________ 18 10. ADDITIONAL AGENCY TERMS AND CONDITIONS __________________________ 19 11. VENDOR RESPONSE __________________________________________________ 20 12. PRICING _____________________________________________________________ 20 13. RESPONSE SUBMISSION REQUIREMENTS ________________________________ 21 14. AWARD ______________________________________________________________ 22 15. CHANGE REQUEST PROCESS __________________________________________ 22 ACRONYM | INITIALISM GLOSSARY ____________________________________________ 23 EXHIBIT 1 – HHSC EIR ACCESSIBILITY CLAUSE __________________________________ 25
1
INTRODUCTION
The Department of State Health Services Information Technology (DSHS IT) Section, under the guidance of the Chief Technology Officer (CTO), seeks to expand the agency’s capabilities through the development and expansion of a Health Services Gateway (HSG) for secure data services.
The purpose of the HSG is to provide a single landing infrastructure and Service-Oriented Architecture (SOA) backplane for secure services spanning all DSHS public health program areas. HSG is part of a DSHS initiative to increase interoperability among internal and external trading partners across Texas.
DSHS, through the guidance of the CTO Unit, requires Uber Operations LLC (hereinafter “Uber Operations”, Vendor, or Contractor) to customize and deliver a new implementation solution per identified DSHS program area through subsequent statements of work incorporated into and made a part of the mutually agreed upon DSHS Base Contract #141080 between Uber Operations and DSHS, with all the terms and conditions, attachments, appendices, exhibits and schedules of these agreements governing the SOWs and these parties.
The purpose of these engagements are to automate tasks and communicate business practices and toolset changes for the programs areas and their stakeholders who are impacted by delivery of the new architecture.
2 BACKGROUND
The Texas Health and Human Services Commission (HHSC) oversees the operations of the State Health And Human Services Systems, provides administrative oversight of Texas Health and Human Services programs, and provides direct administration of some programs (hereinafter HHS Enterprise).
HHSC's oversight of the Texas Health and Human Services System encompasses five distinct agencies - in which DSHS is one of those five agencies (HHS Agencies).
DSHS lacks a modern software architecture model for designing and implementing communication between mutually interacting software applications in a service-oriented architecture (SOA) environment. The SOA environment facilitates shared data services to support the business processes of the agency and its associated programs.
DSHS wishes to improve operational efficiency and effectiveness by minimizing the amount of paper-based workflow, increase storage capacity, and facilitate retrieval of data used to manage their day-to-day operations within this evolving SOA through the utilization of an HSG.
The HSG utilizes a SOA environment to provide shared data services among DSHS program areas and external stakeholders. A SOA environment is a modular and component-based architecture that contains loosely coupled services that are agnostic of operating system and programming language.
This type of architecture encourages interoperability across the HHS Enterprise. It consists of a tiered platform of multiple applications and data protocols that provide a suite of data exchange services.
Typical functions and core capabilities contain the following characteristics:
Category Functions
Invocation Support for synchronous and asynchronous transport protocols, service mapping (locating and binding). Routing Addressability, static/deterministic routing, content-based routing, rules-based routing, policy-based routing. Mediation Adapters, protocol transformation, service mapping.
Messaging Message-processing, message transformation and message enhancement.
Process Choreography Implementation of complex business processes.
Service Orchestration Coordination of multiple implementation services exposed as a single, aggregate service. Complex Event
Processing Event-interpretation, correlation, pattern-matching. Other Quality of
Service Security (encryption and signing), reliable delivery, transaction management. Management Monitoring, audit, logging, metering, admin console, Business Activity Monitoring (BAM). [BAM is not a management capability - the ESB does not react to a specific
threshold. It is a business service capability surfaced to end users].
Agnosticism General agnosticism to operating systems and programming-languages; it should enable interoperability between Java and .NET applications. Protocol Conversion Comprehensive support for topical communication protocols service standards.
Message Exchange Patterns
Support for various MEPs (Message Exchange Patterns), such as synchronous request/response, asynchronous request/response, send-and-forget, publish/subscribe).
Adapters Adapters for supporting legacy systems integration, possibly based on standards like JCA. Security Standardized security-model to authorize, authenticate & audit use of the HSG.
Transformation Facilitate transformation of data formats & values, including transformation services (often XSLT or XQuery) between the formats of sending & receiving applications. Validation Validation against schemas for sending and receiving messages.
Governance The ability to apply business rules uniformly.
Split And Merge The splitting and combining of multiple messages and the handling of exceptions.
Abstraction The provision of a unified abstraction across multiple layers.
Routing And
Transformation Routing or transforming messages conditionally, based on a non-centralized policy (without the need for a central rules-engine).
Queuing And Staging Queuing, holding messages if applications temporarily become unavailable or work at different speeds. Commodity Services Provisioning of commonly used functionality as shared services depending on context.
Ongoing Implementation and maintenance of these software applications will be accomplished through the combined efforts of DSHS staff (CTO Unit, IT Operations, and IT Applications Development) and Uber Operations. Uber Operations Staff will provide services to aid DSHS in work to be performed, including as approved by the CTO Unit - but not limited to:
1) architectural design;
2) software development, implementation, and testing; 3) production environment deployment;
4) system maintenance and enhancements.
The Health Services Gateway initially provided reporting services to the DSHS State Laboratory, CDC Influenza Reporting, CDC Bio-Terrorism Reporting, National Electronic Disease Surveillance System (NEDSS), Immunizations Registry and Epidemiology as Proof of Concept. Through varying stages, these services will become part of the standardized production pathway.
Over the next several years, DSHS will be launching projects within the program areas with the goal of achieving an enterprise environment that is collaborative, interoperable, repeatable, scalable and standards-based. Processes within the HSG provide the following functions: Current Data Services:
1) Secure Bi-directional data exchange
2) Implementation of standards-based protocols for Health Information Exchange (HIE) 3) Data validation and quality assurance (file format and message content validation) 4) Provider registration
5) Geocoding and census data 6) Web Services
Data Services Offered for Expansion:
1) Enterprise Master Provider Index 2) Enterprise Master Patient Index 3) Vocabulary code mapping 4) Data visualization
5) Client referral services and consent management
6) Translational /Transformational mapping (proprietary to standards-based data) 7) Electronic Test Order and Results (ETOR) System
As additional entities exploit functions of the HSG, it must expand its capacity and maintain scalability to accommodate increased utilization for which the DSHS CTO Unit requires technical services and assistance for support and maintenance of HSG processes. These technical services include:
1) solution recommendations;
2) technical evaluation and consultation; 3) training of DSHS staff;
4) implementation of agreed upon changes to software; 5) updating and configuration of existing software applications;
6) provision of addition of modules that support HSG function and scalability; 7) other maintenance or support services related to HSG process continuity.
DSHS Office of the CTO has engaged
Uber Operations
to enhance the HSG as an enterprise solution. All work accomplished will be approved by DSHS CTO Unit prior to implementation.3
SCOPE
Uber Operations
will provide a solution to allow for the exchange of clinical care data including discharge summaries between the state hospitals and with the external entities such as HHSC’s LMHAs through DSHS Health Services Gateway (HSG). Uber Operations will accomplish this by managing tasks to ensure that planned work efforts are used effectively throughout this engagement.3.1 SCOPE OF WORK 3.1.1 HSG General Support
1) In coordination with CTO Unit staff, resolve configuration, communication, and all other application problems identified and prioritized by CTO Unit support staff during implementation and maintenance of the HSG system processes.
2) Meet regularly with CTO Unit staff to discuss system status, defects, modifications, issues affecting HSG system performance, and upcoming hardware and software maintenance. 3) Monitor performance of the HSG system processes as more users are added to the system. 4) Measure and define recommendations for maximum threshold levels for hardware and
software to maintain a satisfactory level of performance.
5) In coordination with the CTO Unit staff, recommend hardware and software upgrades.
6) Provide knowledge transfer to CTO Unit staff on all tools used for system support using a mutually agreed methodology.
7) Provide a technical team whose members are familiar with all functional areas of the HSG system applications and processes.
8) Provide assistance to CTO Unit staff as requested in resolving program area HSG requests or inquiries, as well as with issues related to accessibility, infrastructure and security that involve DSHS Information Technology Operations or the DSHS Chief Information Security Officer.
9) Support the CTO Unit staff with applicable system changes for the life of the contract. 3.1.2 HSG System Development
For System Development of the HSG, Uber Operations will prepare and maintain software development documentation as defined by the DSHS IT Governance policy, as required. Should changes to the current system standards become necessary during the life of the contract, Uber Operations will revise the system standards in coordination with CTO Unit and Information Technology staff. The following services and deliverables for HSG System Development to be provided by Uber Operations are:
1) Development for the CDC PHIN-MS secure message transport product; 2) Development for the Direct Secure Message Transport Portal;
3) Development for the Rhapsody Integration Broker;
4) Development for the Uber Operations UberMover secure file transfer solution; 5) Development of interfaces with internal and external trading partners;
6) Development of the Immunization DQA software; 7) Development of secure Web Services;
8) Assist and/or advise in the development or improvement of HSG services; 9) Assist with feasibility assessment and studies related to HSG development; 10) Provide security assessment and advice related to the HSG.
3.1.3 HSG System Testing
Within System Testing for the HSG, Uber Operations will work with the CTO Unit staff to design, code, test, and implement system changes as required. Uber Operations will provide assistance to CTO Unit staff as requested during user acceptance and regression testing, including but not exclusive to:
1) Data Mapping and Translation; 2) Completion of System Testing;
3) Acceptance Test Plan and Test Cases; 4) Completion of Acceptance Testing; 5) Performance Test Plan;
6) Completion of Performance Testing; 7) Data Quality Assurance and Security; 8) Knowledge Transfer and Training;
a) Training Plan with training strategies, resources, timeline, and logistic; b) Train the end-users;
c) Train technical resource on installing workstation software; d) Web-based on/or onsite training courses as prescribed; 9) Load balancing;
10) Function Testing Web Services;
11) Internal and external connectivity testing including, but not limited to: SFTP, Direct, PHIN-MS, network transfers.
3.1.4 HSG System Maintenance and Support
HSG is a high availability system except for occasional planned system maintenance and support, inclusive of software upgrades. Uber Operations will perform various tasks to support DSHS systems related to the functionality of the HSG, including Uber Operations managed Amazon Web Services (AWS) servers if applicable:
1) Assist with diagnosis of system problems found by staff or end-users;
2) Work with third-party software vendors to resolve problems related to their products;
3) In coordination with the Infrastructure Service vendors, provide feedback to DSHS in identifying and selecting the best hardware to support the application;
4) Analyze and suggest the use of new technologies to improve HSG systems, including parallel testing with current technologies;
5) Onboarding for DSHS connection to the APHL AIMS Hub;
6) On-boarding of program areas (Epidemiology, Lab, MHSA etc;) trading partners; 7) On-boarding of external partners; including Eligible Providers;
8) Support for DSHS connection to the APHL AIMS Hub;
9) Support for the CDC PHIN-MS secure message transport product; 10) Support for the Direct Secure Message Transport Portal;
11) Support for the Rhapsody Integration Broker
12) Support for the Uber Operations UberMover secure file transfer solution; 13) Support of interfaces with internal and external trading partners;
3.1.5 HSG Go Live Support
Immediately after the deployment of the system, Uber Operations will provide on-site support for the first five (5) days of system operation to resolve any technical problems, assist with change management, assist with training issues, and make configuration changes and answer users’ questions.
The warranty period will be 60 days from the Go-Live date. On-site Go Live Support will include assisting in day-to-day use and operation of the new system and providing instruction as needed.
3.2 ROLES AND RESPONSIBILITIES 3.2.1 Vendor Responsibilities:
1) Uber Operations will be responsible for the following:
a) achieve the anticipated deliverables within projected scope and schedule; b) provide experienced technical resources;
c) lead focus group sessions or other information gathering sessions as needed, with active participation from DSHS program staff;
d) work collaboratively with DSHS Staff to validate the Use Cases provided by DSHS; e) work with DSHS to harmonize testing configuration;
f) escalate issues to DSHS Project Manager as appropriate. 3.2.2 Agency Responsibilities
1) General Responsibilities:
a) ensure that Subject Matter Experts (SMEs) will be available on an as-needed basis; b) provide access to the server(s); suitable remote access will be made available; c) provide the environment for Uber Operations to work;
d) provide adequate staff for testing;
e) provide all software applicable to the scope of work; f) provide the use cases for planning and development. 2) DSHS IT Management and Technical Staff Responsibilities:
a) provide and direct IT Technical SMEs for systems mapping and architecture requirements, as necessary;
b) coordinate with Xerox and Cap Gemini for Texas Data Center Services (DCS) engagement, as necessary;
c) coordinate with CloudNexa for AWS management. 3) DSHS CTO Unit Responsibilities:
a) plan, execute, and control the overall project;
b) assist Uber Operations with the coordination of technical resources;
c) assist Uber Operations with business-related activities and decisions, as necessary; d) in conjunction with appropriate stakeholders, review each submitted deliverables within
e) serve as the DSHS Contract Manager for activities and deliverables related to this Statement of Work;
f) report monthly progress to the functional managers as well as program executive management based on Uber Operations’ status reports.
4) DSHS Contact Manager Responsibilities:
a) review and make comments on Uber Operations’ progress and ensure that the deadlines, work products, reporting, and invoicing are being accomplished as described in the SOW;
b) work with legal and procurement staff as needed, to resolve contractual issues. 5) DSHS Program Management and Staff Responsibilities:
a) identify and schedule program area SMEs to provide necessary project information; b) obtain and provide program information, data, decisions, and approvals, within five (5)
work days of Uber Operations’ request, unless both parties agree to an extended response time;
c) help resolve or advance project issues within the DSHS organization when escalated by the Project Manager (PM) or designate .
3.3 ACCEPTANCE CRITERIA
3.3.1 Uber Operations will have full responsibility for the deliverables (work products, services, and/or milestones) listed in this SOW, and shall detail them and their associated tasks in a formal work breakdown plan. Uber Operations shall describe how the dates will be met in their proposal to DSHS.
3.3.2 All work products shall be submitted to the DSHS for acceptance and approval. DSHS may request that a deliverable outline be submitted for approval prior to work commencing on the deliverable. All correspondence and documentation shall be delivered in both paper and electronic format unless otherwise agreed to by Uber Operations and the DSHS CTO Unit staff.
3.3.3 DSHS CTO Unit staff will complete a review of each submitted deliverable within ten workdays from the date of receipt. Customer feedback that indicates revisions to a deliverable are required will be addressed and re-submitted by Uber Operations within five workdays unless approval (in writing) for a different length of time is obtained from the DSHS PM or designate.
3.4 PROJECT COMPLETION CRITERIA
Once all work products and tasks have been completed and delivered to DSHS CTO Unit, they will be forwarded to the DSHS Executive Leadership for final approval.
Certain deliverables will require a formal presentation to these stakeholders.
The project will be considered complete when all deliverables described in the SOW have been accepted and approved by the DSHS Associate Commissioner or designee.
3.5 PROJECT SCHEDULES TO BE ACHIEVED BY VENDOR
Uber Operations will provide a project schedule to be approved by the DSHS CTO Unit staff. Uber Operations is to complete its designated activities as described in this SOW and report status on a weekly basis to the DSHS CTO Unit as described in Section 5, Reports and Meetings.
If the Uber Operations deliverable cannot be provided within the scheduled timeframe, Uber Operations is required to contact the DSHS CTO Unit in writing with a reason for the delay and a proposed revised schedule.
The request for a revised schedule must include the impact on the related tasks and overall project in addition to impact to the cost and timeline of the project.
A request for a revised schedule must be reviewed and approved by the DSHS CTO Unit before placed in effect.
3.6 RELEVANT QUALITY PROCESSES
Uber Operations is responsible for management of quality processes that ensure the successful completion of the technology assessment and planning deliverables.
Uber Operations will submit deliverables to the DSHS CTO Unit who will evaluate the overall quality and completeness of the deliverable.
Subsequent review by DSHS technical and program staff SMEs will determine if the deliverable meets quality standards related to technical accuracy and business criteria.
Uber Operations will be given the opportunity to revise the deliverable to include properly vetted recommendations.
If disagreement exists regarding scope and quality, a change control board will meet with Uber Operations and relevant stakeholders to review the issues and determine course of action.
4
DELIVERABLES
4.1 IMPLEMENTATION AND SERVICES DELIVERY SCHEDULE
Uber Operations will provide estimated milestone dates in a table containing a proposed Work Breakdown Structure (WBS) or detailed Project schedule. The work plan shall be composed of the identifiable deliverables and shall be spaced over time so that DSHS will be able to manage their resources to a reasonable distribution of effort. There will be testing time worked into the schedule. The desired date at which time DSHS can begin testing functionality and/or results should leave reasonable and appropriate testing time before the end date of the term of this SOW. The following Project Schedule attributes are to be achieved by Uber Operations:
Deliverable
No. Deliverable Name Section SOW Projected Due Date
1. Development for the CDC PHIN-MS secure message transport product 3.1.2 2. Development for the Direct Secure Message Transport Portal 3.1.2 3. Development for the Rhapsody Integration Broker 3.1.2 4. Development for Uber Operations UberMover secure file transfer solution 3.1.2 5. Development of interfaces with internal and external trading partners 3.1.2 6. Development of the Immunization DQA software 3.1.2 7. Support Feasibility Assessments and Studies 3.1.2 8. Develop a security assessment document 3.1.2 9. Data Mapping and Translation 3.1.3 10. Completion of System Testing 3.1.3 11. Data Quality Assurance and Security 3.1.3 12. Knowledge Transfer and Training 3.1.3
13. Load balancing 3.1.3
14. Web Services and SFTP 3.1.3 15. Onboarding for DSHS connection to the APHL AIMS Hub 3.1.4 16. On-boarding of DSHS program area trading partners 3.1.4 17. Support for DSHS connection to the APHL AIMS Hub 3.1.4 18. Support for the CDC PHIN-MS secure message transport product 3.1.4 19. Support for the Direct Secure Message Transport Portal 3.1.4 20. Support for the Rhapsody Integration Broker 3.1.4 21. Support for the Uber Operations UberMover secure file transfer solution 3.1.4 22. Support of interfaces with internal and external trading partners 3.1.4 23. Support of the Immunization DQA software 3.1.4 24. HSG Go Live Support 3.1.5
The listed milestones will describe the status of the project as one or more project activities are complete; they are representative of major sub-categories under each deliverable. It is not necessarily a complete list of all activities required to meet a specified deliverable.
These milestones represent the completion of a major step in the project that requires the commitment of a certain amount of time, resources and effort – it suggests progress has been made toward the completion of one or more deliverables. Deliverables (work products, services, and/or milestones) should be indicated on Uber Operations’ invoice for payment.
4.2 CONTRACT HOURS
Uber Operations must supply a total not to exceed $500,000 of billable effort per fiscal year during the course of the contract. A minimum of three (3) team members are required to be assigned to be available (not necessarily simultaneously) to this support effort up to a maximum of four (4).
4.3 DELIVERABLE ACCEPTANCE
4.3.1 Deliverables (work products, services, and/or milestones) must be provided on the dates specified. Any changes to the delivery date must have prior approval (in writing) by the designated CTO Unit designated staff.
4.3.2 Uber Operations shall complete and submit all deliverables according to the work plans developed during the life of this contract.
4.3.3 The CTO Unit manager must approve the initial Uber Operations work plan and any changes during the course of the contract.
4.3.4 CTO Unit designated staff must approve all documents before billable maintenance, support or work begins.
4.3.5 If the deliverable cannot be provided within the scheduled timeframe, Uber Operations is required to contact the DSHS CTO Unit designated staff in writing with a reason for the delay and the proposed revised schedule.
4.3.6 The request for a revised schedule must include the impact on the related tasks and overall project in addition to impact to the cost and timeline of the project, and must be reviewed and approved by the DSHS IT CTO Staff Designate before placed in effect 4.3.7 The request for a revised schedule must also be reviewed and approved by the DSHS
CM before placed in effect. Contract Terms and Conditions may dictate penalties, costs, and other actions based on the facts related to the request for a revised schedule.
4.3.8 Failure to submit required deliverables according to schedule may result in non-payment or delayed payment until Uber Operations has remedied the situation according to the original terms of the work plan and resulting contract.
4.3.9 Upon receipt of a deliverable, DSHS will have 10 working days, or a mutually agreed timeframe, to review each deliverable and provide Uber Operations with written notice of acceptance or non-acceptance.
4.3.10 In the case of non-acceptance, Uber Operations will have 10 working days, or according to a schedule for re-submission mutually agreed upon by Uber Operations and DSHS, to resubmit the corrected deliverable clearly identifying the exceptions and how they were corrected.
4.3.11 Non-delivery or non-acceptance of deliverables may result in non-payment or delayed payment until Uber Operations has remedied the situation according to the original terms of the work plan and resulting contract.
4.3.12 Payment will be made based on review and acceptance of Uber Operations invoice by CTO Unit staff. Additionally, failure to complete work plan requirements may result in non-payment until Uber Operations has remedied the situation according to the original terms of the SOW and resulting contract.
5
REPORTS AND MEETINGS
5.1 IT SECTION COORDINATION
5.1.1 A kickoff meeting will be held at a location and time selected by DSHS where Uber Operations staff will be introduced to DSHS stakeholders. Uber Operations will facilitate subsequent meetings with assistance from the designated DSHS staff, as required. 5.1.2 Uber Operations is required to provide the DSHS IT Project Manager with weekly written
progress reports of the implementation, due by the close of business on Thursday of each week throughout the life of the project.
1) The progress reports will cover all work performed and completed during the week for which the progress report is provided and will present the work to be performed during the subsequent week.
2) The progress report will identify any problems encountered or still outstanding, with an explanation of both the cause and resolution to the problem – or how the problem will be resolved.
5.1.3 Uber Operations will be responsible for conducting weekly status meetings with the DSHS IT Project Manager. The meetings will be held on a mutually agreed upon day of each week – at a time and place so designated by the DSHS IT Project Manager. These meetings can be held in person or over the phone, at the discretion of the DSHS IT Project Manager, to review and discuss the status and progress of the work plans.
5.1.4 Uber Operations will be responsible for conducting status meetings with the applicable DSHS Management (Managers, Directors, IRM) or designate. The meetings will be as needed – at DSHS discretion, at a time and place so designated, in person or over the phone.
5.1.5 Other meetings may be scheduled as needed to ensure the stability and functionality of the affected HSG applications and systems. Uber Operations will prepare an agenda and generate meeting notes. The meeting notes may be combined with the weekly status report defined in the Delivery Schedule.
5.2 PROGRAM COORDINATION
5.2.1 Information on system modifications must be made available to CTO Unit staff to update the training documentation.
5.2.2 Implementation of system modifications must be coordinated with the CTO Unit staff. 5.2.3 Uber Operations developers must be available to review documentation for accuracy. 5.2.4 CTO Unit staff must be briefed on techniques used for system modification and
6
SERVICE LEVEL AGREEMENT
6.1 VENDOR PERSONNEL REQUIREMENTS
6.1.1 Uber Operations verifies that all data and confidential information will be safeguarded and that Uber Operations Staff will sign and abide by DSHS Confidentiality and Non-Disclosure Agreements.
6.1.2 DSHS IT CTO Unit staff reserve the right to request replacement of vendor-assigned personnel.
6.1.3 DSHS IT CTO Unit staff reserve the right to reject and remove any Uber Operations contractor for any reason with no prior notice:
1) If DSHS requests removal of a contractor at any time during the contractor’s first five workdays, Uber Operations will not charge DSHS for any work or expenses incurred by that contractor.
2) If DSHS requests removal of a contractor after the contractor has completed five workdays, Uber Operations will not charge DSHS for the contractor’s last five workdays or for expenses incurred during these five workdays.
3) In either case, Uber Operations will strive to identify a suitable replacement in a timely manner.
4) All requests for removal shall be made in writing; no written notice of acceptance is required. The absence of a written request for removal shall serve as acceptance 6.1.4 During the life of the contract, Uber Operations will provide an overlap of 4 weeks
whenever an Uber Operations staff member needs to be replaced. The purpose of the overlap is to train the new staff member on system standards and familiarize them with HSG system applications and processes, as well as DSHS Environmental IT Architecture Standards.
6.1.5 DSHS management must approve any new staff. Resumes must be reviewed and approved by DSHS IT CTO, and will be required for any replacement staff. All replacement Uber Operations staff must meet the experience requirements for the position they are filling.
6.1.6 DSHS will provide Uber Operations staff with photo identification badges. Badges will be required for access to the DSHS facility and must be worn at all times.
6.2 DSHS SLA STANDARDS
6.2.1 The achievement of schedule milestones and goals, both final and interim, is Uber Operations’ responsibility and Uber Operations will meet the Implementation and Services Delivery Schedule specified following the criteria specified below.
6.2.2 Uber Operations work plan and timeline must be realistic. Any changes to the timeline must have prior approval (in writing) by the applicable DSHS IT Director or designate. 6.2.3 Uber Operations is responsible for preparation of all required communications
(meetings, reports, emails) and all required documents (plans, estimates, schedules, analyses).
6.2.4 All work products and services will meet acceptance criteria established by DSHS Management including oral presentation to appropriate stakeholders, and a time period for testing or acceptance
6.2.5 All reports must be written in terms and language that can be easily understood by non-technical personnel without subject matter expertise.
6.2.6 All documents must be in formats (hard copy and electronic) as specified by DSHS IT – at a minimum, the formats must be in industry-accepted standards such as Microsoft Tools: MS Word, MS PowerPoint or, MS Project.
6.2.7 Uber Operations must demonstrate its knowledge and expertise of the environment such as platforms, software, applications, network, or tools for which work is to be performed, including as applicable – but not limited to:
1) Achievement of Budget Goals (total and subtotals) 2) Achievement of Schedule Goals (final and interim) 3) Security (as defined by DSHS IT)
4) Quality (as defined by DSHS IT)
5) Availability (data, system, and components)
6) Performance (transmission, response, or completion times) 7) Meantime to Resolution (MTR)
8) Business Continuity
9) Required communications (meetings, reports, calls, emails) 10) Required documents (plans, estimates, schedules, analyses)
11) Degree of accuracy of estimates (schedule, budget, resources, total) 12) Effective risk management and response (adherence to plans)
13) Effective scope management and change control (adherence to plans) 14) Data quality (fitness for use, accuracy, precision, completeness) 15) AdHoc query response (usually written in terms of averages) 16) Reliability (queries generate same valid results)
17) Consistency (calculations & definitions are consistent regardless of source) 18) Acceptable usage (query controls)
19) Correct mapping of old to new (no functions or data lost) 20) Previous software, system, or service retired on time
6.2.8 All current system functions must be maintained and new features added while meeting the production operation requirements as listed within this SOW.
6.2.9 With regard to technical standards, Uber Operations will reference relevant sources (e.g. ISO, ANSI, IEEE) when detailing technical specifications.
6.2.10 Uber Operations is responsible for effective scope management and will work within the DSHS Project Change Control process.
6.2.11 Uber Operations is responsible for effective risk management and adherence to project plans.
6.2.12 Servers that contain DSHS data must meet or exceed the following service levels:
a. Server Availability 99.85%
b. Incident Resolution Time – Severity 1 3 Hours
c. Incident Resolution Time – Severity 2 4 Hours
d. Root Cause Analysis Delivery 10 Business Days
e. Successful Recoveries 24 Hours
f. Monitored 24 hours per day/ 7 days per week for: i. Network Activity
ii. Hardware Performance
iii. Operating System Logs (Access and Errors) iv. Application Software Logs (Access and Errors)
v. Capacity Utilization vi. Capacity Management vii. Intrusion Detection
6.2.13 Servers will be expected to be backed up and replicated to prevent data loss. In the event of data loss, Uber Operations should identify the standard recovery point and identify any costs for recovery points of:
a. 6 hours
b. 12 hours
c. 24 hours
d. 48 hours
6.2.14 Servers that contain DSHS data must meet the Information Security Standards DSHS is accountable to that are derived from applicable state and federal laws, Executive Orders, and Texas Governmental and Administrative Codes, as well as HHS Enterprise and DSHS Agency directives, policies, standards, instructions, regulations, procedures, or organizational mission/business case needs to ensure the confidentiality, integrity, and availability of the information being processed, stored, or transmitted – inclusive of:
a. securing PII and HIPAA data at rest while residing within a data center environment;
b. encrypting PII and HIPAA data at rest while residing within a cloud-based environment.
7
PERIOD OF PERFORMANCE
7.1 Timeline
Uber Operations will begin work within no later than 30 business days of receiving the purchase order and will cease work after all work products and services described in this SOW are delivered and approved by the DSHS Project Management Office (via the assigned Project and Contract Manager(s)), the Executive and Business Sponsors, and the applicable DSHS IT Directors.
The execution of this SOW is scheduled to begin on the date of the award of the contract, with the issue of a valid purchase order, and is targeted to expire on August 31, 2015. Renewals will be accomplished annually, with the number of renewals not to exceed four additional one-year terms, and where the project period does not to exceed 5 years total.
7.2 Modification of Timeline
A modification of the timeline proposed in this SOW for the effort will be generated during the initial phase of the project. Delays on DSHS side and national holidays may affect the calendar duration of the project. Any delays that impact Uber Operations resources ability to be fully utilized will be subject to the change control process
7.3 Work Hours
Normal work hours are Monday through Friday from 8:00 am to 5:00 pm. Expectations are for a standard 40 hours per week, based on a 52-week calendar year less holidays when all state agencies are closed in accordance with the applicable Texas State Auditor’s Office Fiscal Year Holiday Schedule (http://www.hr.sao.state.tx.us/Compensation/holidays.html).
Uber Operations may only work on days as defined as “Optional Holidays” or “Skeleton Crew Required” at the discretion of the applicable CTO Unit staff or designate.
Uber Operations will be required to respond outside of normal working hours and on holidays if necessary to meet production operational requirements.
7.4 Travel Expenses for Work
DSHS will not pay for travel, room and or board. HHS Agencies will not pay any of Uber Operations’ travel expenses unless required for recruiting support and/or other special events preapproved by the requesting agency.
8.
INVOICES
8.1 Uber Operations will be responsible for invoicing DSHS upon completion of specified agreed upon service, deliverable or milestone.
8.2 Invoices will contain the following:
• Description of the deliverable, service, or milestone attained • Delivery or Service Date
• Invoice Date • Invoice Number
• Associated Purchase Order Number • Applicable Costs
8.3 Invoices must be pre-approved by the DSHS IT CTO Unit staff or designate, prior to Uber Operations submitting them to the “Invoices” mailbox for payment.
8.3.1 Uber Operations will email the DSHS IT CTO Unit staff or designate, requesting a pre-approval of the invoiced work, services, or milestone attained.
8.3.2 If acceptable, the DSHS IT CTO Unit staff or designate will notify Uber Operations via email of his or her approval, courtesy copying (Cc) DSHS IT Business Services @ [email protected].
8.4 Once pre-approved by the applicable DSHS IT CTO Unit staff or designate, Uber Operations will submit its invoice to one of the addresses below for payment.
Electronically:
[email protected] Mailing Address:
Department of State Health Services Claims Processing Unit – Mail Code 1940 PO Box 149347
Austin, TX 78714-9347
8.5 Uber Operations will invoice monthly for services provided for the prior month.
9.
DSHS/VENDOR FURNISHED EQUIPMENT AND WORK SPACE
Uber Operations will perform work both on-site and off-site. Due to agency constraints, DSHS will provide a limited amount of workspace and computer equipment for on-site activities as provided for in this SOW and resulting contract.
DSHS will make available conference rooms and work areas in order to conduct stakeholder interviews and design sessions. It is presumed that some of the document creation and preparation can be performed at Uber Operations’ location.
10. ADDITIONAL AGENCY TERMS AND CONDITIONS
10.1 Uber Operations must review and be compliant with current HHSC Uniform Terms & Conditions (Attachment 1 of the DSHS Base Contract #141080), and as provided on the HHSC Business Opportunities public-facing webpage accessible under “General Terms & Conditions”: http://www.hhsc.state.tx.us/about_hhsc/BusOpp/BO_home.shtml. 10.2 Uber Operations is responsible for the quality of all implementation and services
including technical and grammatical accuracy, as well as adherence to the following: 1) Department of Information Resources’ Texas Project Delivery Framework standard
style guides:
http://www.dir.texas.gov/management/projectdelivery/projectframework/pages/framework.aspx
2) Texas Health and Human Services Commission (HHSC) Enterprise Information Security Standards and Guidelines:
http://www.hhsc.state.tx.us/contract/52900140082/docs/hhs-eissgv4-01.pdf
3) HHSC Enterprise Standard Style Guides: http://www.hhsc.state.tx.us/medicaid/provider-information/communications-resources.shtml
10.3 Specifications for business processes and technical solutions must comply with agency technical standards and citations, inclusive but not limited to:
1) United States Department of Health & Human Services guidelines for HIT Privacy and Security: http://www.healthit.gov/policy-researchers-implementers/privacy-security-policy
2) HITSP Interoperability Specifications: http://www.hitsp.org/default.aspx 3) Section 508 Accessibility Requirements: http://www.section508.gov/ 4) Unified Modeling Language 2.0 or greater: http://www.uml.org/ 5) Protecting the Confidentiality of Personally Identifiable Information:
http://csrc.nist.gov/publications/nistpubs/800-122/sp800-122.pdf
6) Texas Administrative Code, Title 1, Part 10, Chapter 202 – Information Security Standards: http://info.sos.state.tx.us/pls/pub/readtac$ext.ViewTAC
7) State Health Information Architecture Interagency Data Sharing Standard: http://www.dir.texas.gov/pubs/Pages/shiarchitecture.aspx
8) HHSC Uniform Electronic and Information Resources (EIR) Accessibility Clause: see Exhibit 1, below.
10.4 DSHS may negotiate the terms and conditions of this SOW to suit business needs so long as the SOW terms and conditions do not conflict with or weaken the HHSC Standard Terms and Conditions and the DSHS General Provisions.
10.5 DSHS and HHSC will presume that Uber Operations agrees to any provision not identified in Uber Operations’ response.
10.6 Contract is subject to cancellation, without penalty, either in whole or in part, if funds are not available prior to commencement of work.
10.7 In accordance with Texas Government Code, Sections 2155.0741 and 2155.075, vendor performance may be used as a factor in the award.
11. VENDOR RESPONSE
11.1 All written responses will be phrased in terms and language that can be easily understood by non-technical personnel (e.g., laypersons without technical subject matter expertise). This does not preclude the inclusion of relevant technical appendices.
11.2 Uber Operations will submit one signed copy of response to this solicitation. This response may be submitted via hand delivery, postal delivery or email to the Sole Point of Contact as indicated in Section 13.3.
11.3 Initial proposals may be submitted in PDF or other portable format. If selected for a Vendor Presentation, the proposal will be submitted in editable Microsoft Word electronic copy with an assigned number of hard copies. The proposed project schedule can be in Microsoft Project or Excel.
11.4 Uber Operations will describe service capabilities relative to this SOW:
a. Outline of capability to deliver the required services, including process, functional and technical expertise;
b. Methodologies to be used to complete this SOW; and
c. Suggested modification of SOW for Work Products and Services. 11.5 Uber Operations will describe any assumptions about SOW and/or project.
11.6 Uber Operations will describe any requirements or requests they will need from DSHS. 11.7 Project management plan will detail a work breakdown structure (WBS) addressing
tasks specified in the SOW and schedule, with milestones and critical path.
12. PRICING
The unit price for each specified agreed upon deliverable (work product, service, or milestone) will be established prior to the beginning of the SOW term and may be renegotiated annually during the contract renewal process.
Once unit prices are established for the HHS fiscal year, those prices may not increase during the fiscal year. Prices may be decreased during the fiscal year if agreed upon by the HHS Agency and Uber Operations. Uber Operations may provide volume discounts for consideration. 12.1 PRICING SHEET
Uber Operations is to provide a fixed, firm price detailing the pricing for each deliverable using the pricing sheet example. Assumptions and exclusions made by Uber Operations must be explicitly detailed in its response, and must include the impact of the assumption on price.
Deliverable No. Deliverable Name Number of Hours Price
1 2 3 4
13. RESPONSE SUBMISSION REQUIREMENTS
13.1
SOW Tentative Schedule of Events:
Event Date
Notification of Solicitation April 24, 2015
Deadline for Vendor Questions May 01, 2015 @ 12:00 Noon Deadline for DSHS Answering Questions May 08, 2015
Response Due Date May 15, 2015 @ 2:00 pm
13.2 SOW Communication Restrictions: From the issue date of this Statement of Work until the SOW is finalized, Uber Operations may not communicate, either orally or in writing, regarding this Statement of Work with any staff except as noted in Section 13.3 (Point of Contact for Response Submission) below.
13.3 Point of Contact for Response Submissions: The PCS Office will not accept telephone and facsimile responses. Responses must not include unrequested materials or pamphlets. The PCS Office reserves the right to reject late submissions. Sole Point of Contact for inquiries concerning this procurement is
Physical Address for Overnight and Commercial Mail:
Health and Human Services Commission
Procurement and Contracting Services, Mail Code 2020 Attn: Debbie Arbuckle, CTPM
4405 North Lamar Blvd Austin, TX 78756
PCS Purchaser Contact Information
POC: Debbie Arbuckle, CTPM
Office: (512) 206 – 4733
Email: [email protected]
13.4 Mandatory Response Contents: Uber Operations’ response must include all specified content in order for Uber Operations to be considered for this contract. Any disparities between the contents of the original printed response and the electronic response will be interpreted in favor of DSHS/HHSC.
13.5 Response Format Requirements: Uber Operations’ response must be typed double-spaced on 8½” x 11” paper, in Tahoma or Verdana font, no less than size 11 for normal text, and no less than size 10 for tables, graphs, and appendices.
13.6 Number of Copies: Uber Operations will provide one original – clearly marked as the original, and three electronic copies on flash drives. All response materials submitted will become property of the State.
13.7 Best Value: Texas Government Code §2155.144 – PROCUREMENTS BY HEALTH AND HUMAN SERVICES AGENCIES obligates HHSC to purchase goods and services for the enterprise based on best value. DSHS defines “best value” as the optimum combination of economy and quality that is the result of fair, efficient, and practical procurement decision-making.
14. AWARD
14.1 HHS Enterprise Procurements over $25,000.00 awards will be posted on the Electronic State Business Daily (ESBD).
14.2 This SOW will serve as the basis for a response by Uber Operations. Final terms of any agreement resulting from such a response will be documented in a contract between the HHS Agency and Uber Operations.
14.3 HHSC will make no contract award if no offer received is acceptable. HHSC reserves the right to make a partial award to a Vendor including some, but not all, of the Work Products and Services.
14.4 HHSC reserves the right to make partial awards to multiple vendors.
14.5 In the event of the availability of unrealized funds to further advance or expand the specifications of this initiative, it is plausible that a second phase (Phase II) could occur at the approval of DSHS. If DSHS requests the addition of Phase II Work Products and Services, DSHS and Uber Operations will execute a change order and amendment as mutually agreed upon in writing by DSHS and Uber Operations.
14.6 All dates are subject to change at HHSC discretion.
15. CHANGE REQUEST PROCESS
15.1 In the event there is a reason to change the project Statement of Work, the Agency Division will initiate the change request.
15.2 The Change Request must provide information regarding the change comparable to the detail originally included in the Statement of Work documentation.
15.3 A Change Request can be initiated by either DSHS or Uber Operations, but DSHS and Uber Operations will endeavor to agree upon appropriate and mutually agreeable changes in cost, schedule or other terms associated with the Change Request.
15.4 While such changes are under review, Uber Operations will continue to perform under the Statement of Work so long as such continued performance does not cause Uber Operations to incur a material cost or other undue hardship in relation to the Change Request.
15.5 A decision to discontinue performance due to a Change Request will be made only by mutual written agreement of both parties.
15.6 No Change Request will be implemented unless set forth in writing and approved and signed by an authorized representative of each party.
15.7 Uber Operations agrees to act in good faith effort with regard to price and schedule terms if required for any proposed change.
15.8 DSHS acknowledges that through discovery there may be additional work required that could impact the timeline’s targeted expiration. DSHS reserves the right to execute an extension should the targeted expiration date be unattainable, at the same terms and conditions – adhering to agency and HHS Enterprise Change Request Process methodologies.
15.9 HHS Agencies must also be able to add services utilizing Change Requests. These services will be added upon mutual agreement between the requesting HHS Agency and Uber Operations. An agreed upon price will be negotiated prior to the additional services being added to the contract
ACRONYM | INITIALISM GLOSSARY
Term Definition
ANSI American National Standards Institute
APHL AIMS Association of Public Health Laboratories (APHL) (AIMS) APHL Informatics Messaging Services AWS Amazon Web Services
BAM Business Activity Monitoring BYOL Bring Your Own License (AWS)
C-CDA Consolidated Clinical Document Architecture CCD Continuity of Care Document
CDA Clinical Document Architecture
CDC Centers for Disease Control and Prevention CDE4BH Clinical Data Exchange for Behavioral Health CTO Chief Technology Office (Officer)
CTPM Certified Texas Procurement Manager DCS Data Center Services
DSHS Department of State Health Services: an agency of the State of Texas, having a principal place of business at 1100 West 49th Street, Austin, Texas, 78756 DSHS IT The Department of State Health Services Information Technology Section
DSHS PM Department of State Health Services Project Manager DQA Data Quality Assurance, Data Quality Audit
EBS Elastic Block Store (AWS) EHR Electronic Health Record ELR Electronic Laboratory Reporting ETOR Electronic Test Orders and Results FTP File Transfer Protocol
HIE Health Information Exchange
HHSC Texas Health and Human Services Commission
HIPAA Health Insurance Portability and Accountability Act of 1996 HITSP Healthcare Information Technology Standards Panel HL7 Health Level 7
HSG Health Services Gateway IB Integration Broker
IBIS Integrated Business Information System IEEE Institute of Electrical and Electronics Engineers ISO International Organization for Standardization JCA Java EE (Enterprise Edition) Connector Architecture LDW Logical Data Warehouse
LMHAs Local Mental Health Authority or Authorities LOINC Logical Observation Identifiers Names and Codes LRN Laboratory Response Network
Term Definition
MEPs Message Exchange Patterns
MHSA Division for Mental Health and Substance Abuse Services NEDSS National Electronic Disease Surveillance System
Netsmart Netsmart Technologies, Inc. PDF Portable Document Format
PHIN-MS Public Health Information Network - Messaging System PII Personally identifiable information
RDS Relational Database Service (AWS) SFTP Secured File Transfer Protocol SMEs Subject Matter Experts
SNOMED Systematized Nomenclature of Medicine SOA Service-Oriented Architecture
SOW Statement of Work Uber
Operations
Uber Operations LLC: a Limited Liability Corporation, duly organized under the laws of the State of Florida having a principal place of business at 400 Capital Circle SE, Suite 18299 Tallahassee, Florida 32301
VPC Virtual Private Cloud (AWS) VPN Virtual Private Network
WADL Web Application Description Language WBS Work Breakdown Structure
WSDL Web Service Definition Language
EXHIBIT 1 – HHSC EIR ACCESSIBILITY CLAUSE
The below language will be used in place of Section 16.02 of the HHSC Uniform Contract Terms and Conditions referred to in the above related paragraph for this solicitation:
Electronic and Information Resources Accessibility (a) Applicability.
This section applies if the contract requires the CONTRACTOR to procure or develop Electronic and Information Resources (EIR) for HHSC, or to change any of HHSC’s EIR. This section also applies if the contract requires the CONTRACTOR to perform a service or supply goods that include EIR that: (i) HHSC employees are required or permitted to access; or (ii) members of the public are required or permitted to access.
This section does not apply to incidental uses of EIR in the performance of a contract, unless the parties agree that the EIR will become property of the state or will be used by the HHS agency’s Client/Recipient after completion of the contract.
Nothing in this section is intended to prescribe the use of particular designs or technologies or to prevent the use of alternative technologies, provided they result in substantially equivalent or greater access to and use of a product / service.
(b) Definitions.
1. “Accessibility Standards” means the Electronic and Information Resources Accessibility Standards and the Web Site Accessibility Standards/Specifications.
2. “Electronic and Information Resources” means information resources, including information resources technologies, and any equipment or interconnected system of equipment that is used in the creation, conversion, duplication, or delivery of data or information. The term includes, but is not limited to, telephones and other telecommunications products, information kiosks, transaction machines, Internet websites, multimedia resources, and office equipment, including copy machines and fax machines.
3. “Electronic and Information Resources Accessibility Standards” means the accessibility standards for electronic and information resources contained in Volume 1 Texas Administrative Code Chapter 213.
4. “Web Site Accessibility Standards/Specifications” means standards contained in Volume 1 Texas Administrative Code Chapter 206.
5. “Products” means information resources technologies that are, or are related to, EIR.
(c) Accessibility Requirements.
Under Texas Government Code Chapter 2054, Subchapter M, and implementing rules of the Texas Department of Information Resources, HHSC must procure Products that comply with the Accessibility Standards when such Products are available in the commercial marketplace or when such Products are developed in response to a procurement solicitation. Accordingly, CONTRACTOR must provide electronic and information resources and associated Product documentation and technical support that comply with the Accessibility Standards.
(d) Evaluation, Testing and Monitoring.
1. HHSC may review, test, evaluate and monitor CONTRACTOR’s Products and associated documentation and technical support for compliance with the Accessibility Standards. Review, testing, evaluation and monitoring may be conducted before and after the award of a contract. Testing and monitoring may include user acceptance testing.
Neither (1) the review, testing (including acceptance testing), evaluation or monitoring of any Product, nor (2) the absence of such review, testing, evaluation or monitoring, will result in a waiver of the State’s right to contest the CONTRACTOR’S assertion of compliance with the Accessibility Standards.
2. CONTRACTOR agrees to cooperate fully and provide HHSC and its representatives timely access to Products, records, and other items and information needed to conduct such review, evaluation, testing and monitoring.
(e) Representations and Warranties.
1. CONTRACTOR represents and warrants that:
(i) as of the effective date of the contract, the Products and associated documentation and technical support comply with the Accessibility Standards as they exist at the time of entering the contract, unless and to the extent the Parties otherwise expressly agree in writing; and
(ii) if the Products will be in the custody of the state or an HHS agency’s client or recipient after the contract expiration or termination, the Products will continue to comply with such Accessibility Standards after the expiration or termination of the contract term, unless the HHS AGENCY and/or Client/Recipient as applicable, uses the Products in a manner that renders it noncompliant.
2. In the event CONTRACTOR should have known, becomes aware, or is notified that the Product and associated documentation and technical support do not comply with the Accessibility Standards, CONTRACTOR represents and warrants that it will, in a timely manner and at no cost to HHSC, perform all necessary steps to satisfy the Accessibility Standards, including but not limited to remediation, replacement, and upgrading of the Product, or providing a suitable substitute.
3. CONTRACTOR acknowledges and agrees that these representations and warranties are essential inducements on which HHSC relies in awarding this contract.
4. CONTRACTOR’s representations and warranties under this subsection will survive the termination or expiration of the contract and will remain in full force and effect throughout the useful life of the Product.
(f) Remedies.
1. Pursuant to Texas Government Code Sec. 2054.465, neither CONTRACTOR nor any other person has cause of action against HHSC for a claim of a failure to comply with Texas Government Code Chapter 2054, Subchapter M, and rules of the Department of Information Resources.
2. In the event of a breach of CONTRACTOR’s representations and warranties, CONTRACTOR will be liable for direct and consequential damages and any other remedies to which HHSC may be entitled. This remedy is cumulative of any and all other remedies to which HHSC may be entitled under this contract and other applicable law.
