Statement_of_Objective.pdf

Project Title: Performance Category Calculation Architecture with Merit-Based Incentives

Payment System

1. Statement of Objectives

1.1 Program History

The objective of this contract is to utilize the Agile development process to establish the architecture for the Merit-based Incentive Payment System (MIPS). The purpose of the MIPS will be to accept quality payment program reporting data from Medicare eligible physicians, calculate a composite performance score (CPS), compare the CPS to a predetermined threshold to determine if the eligible clinician receives a payment incentive or negative adjustment, and account for the results of a physician appeal process (targeted reviews). The MIPS/APM proposed rule is on display at the Federal Register: https://s3.amazonaws.com/public-inspection.federalregister.gov/2016- 10032.pdf.

1.2 Users

The primary users will include the following:

1. External People/The Public

2. Internal People/Government Employees

1.3 User Research

The vendor will be responsible for the user research.

1.4 Understand What People Need

The vendor services will include exploring and pinpointing the needs of the people who will use the service, and the ways the service will fit into their lives. The vendor shall continually test the products with real people to ensure delivery is focused on what is important and simplifying the user experience in the Government’s products.

As a part of this effort, the vendor will:

Early in the project, spend time with current and prospective users of the service Use a range of qualitative and quantitative research methods to determine people’s goals, needs, and behaviors.

Test prototypes of solutions with real people, in the field if possible Document the findings about user goals, needs, behaviors, and preferences Share findings with the team and agency leadership Create a prioritized list of tasks the user is trying to accomplish, also known as 'user stories' As the digital service is being built, regularly test it with potential users to ensure it meets people’s needs

1.5 Address the whole experience, from start to finish

The contractor shall ensure the Government understands the different ways people will interact with the services, including the actions they take online, through a mobile application, on a https://s3.amazonaws.com/public-inspection.federalregister.gov/2016-10032.pdf https://s3.amazonaws.com/public-inspection.federalregister.gov/2016-10032.pdf https://s3.amazonaws.com/public-inspection.federalregister.gov/2016-10032.pdf phone, or in person. Every encounter, whether it's online or offline, should move the user closer towards their goal.

In delivery of this effort the contractor shall:

- Understand the different points at which people will interact with the service, both online and in person

- Identify pain points in the current way users interact with the service, and prioritize these according to user needs

- Design the digital parts of the service so that they are integrated with the offline touch points people use to interact with the service

- Develop metrics that will measure how well the service is meeting user needs at each step of the service

The team within ISG managing this contract commit to support the vendor in the user research process, and will provide the vendor with access to the Government employees who will be the users of the product. (See section entitled 'Government Roles').

2 Universal Requirements

2.1 Build the service using agile and iterative practices

Deliverables shall be delivered in an incremental, fast-paced style of software development to reduce the risk of failure. The vendor shall deliver working software into users hands as early as possible to give the design and development team opportunities to adjust based on user feedback about the service. A critical capability is being able to automatically test and deploy the service so that new features can be added often and be put into production easily.

Requirements Checklist

Ship a functioning minimum viable product (MVP) that solves a core user need as soon as possible, no longer than three months from the beginning of the project, using a beta or test period if needed Run usability tests frequently to see how well the service works and identify improvements that should be made Ensure the individuals building the service communicate and collaborate closely using techniques such as sprint planning meetings, co-working spaces, daily standups, and team chat tools Keep delivery teams small and focused; limit organizational layers that separate these teams from the business owners Release features and improvements multiple times each month Create a prioritized list of features and bugs, also known as the product backlog Use a source code version control system Give the entire project team access to the issue tracker and version control system Use code reviews to ensure quality

2.3 Make it simple and intuitive

The contractor shall build services that are simple and intuitive enough that users succeed the first time, unaided. In delivery of this effort the contractor shall:

- Use a simple and flexible design style guide for the service. Use the U.S. Web Design

Standards (https://playbook.cio.gov/designstandards) as the default starting point

- Document any modifications/enhancements to the default starting point

- Use the design style guide consistently for related digital services

- Give users clear information about where they are in each step of the process

- Follow accessibility best practices to ensure all people can use the service

- Provide users with a way to exit and return later to complete the process

- Use language that is familiar to the user and easy to understand

- Apply these language and design standards consistently throughout the service, including online and offline touch points

2.4 Use data to drive decisions

At every stage of a project, the contractor shall measure how well our service is working for our users. This includes measuring how well a system performs and how people are interacting with it in real-time. These metrics shall be reported to the Program Managers to find issues and identify which bug fixes and improvements should be prioritized. Along with monitoring tools, a feedback mechanism should be in place for people to report issues directly.

In delivery of this effort the contractor shall:

- Monitor system-level resource utilization in real time (Suggest tools)

- Monitor system performance in real-time (e.g. response time, latency, throughput, and error rates)

- Ensure monitoring can measure median, 95th percentile, and 98th percentile performance

- Create automated alerts based on this monitoring

- Track concurrent users in real-time, and monitor user behaviors in the aggregate to determine how well the service meets user needs

- Provide metrics which may be published internally

- Provide metrics which may be published externally

- Use an experimentation tool that supports multivariate testing in production

- Provide Government employees access to these monitoring systems

3 DevOps Development and Operations (DevOps) is the practice of operations and development engineers participating together in the entire service lifecycle, from design, through the development process, to production support. It emphasizes communication, collaboration, and integration between software developers and IT operations personnel. DevOps is a response to the interdependence of software development and IT operations and it aims to help an organization rapidly produce software products and services. The DevOps approach includes improved deployment frequency, which can lead to faster time to market, lower failure rate of new releases, shortened lead time between fixes, and faster mean time to recovery in the event of a new release crashing or otherwise disabling the current system. Simple processes become increasingly programmable and dynamic, using a DevOps approach, which aims to maximize the predictability, efficiency, security, and maintainability of operational processes. Very often, automation supports this objective. The Contractor shall support the DevOps model for CMS projects and operations as directed.

For reference, the latest CMS projects related to quality endeavors are using Amazon Web Services (AWS) for commercial cloud infrastructure.

The Contractor shall support multiple CMS environments and other contractor environments, including sandbox environments, as directed by CMS. CMS environments may include, but are not limited to, the following:

Development Test Implementation (staging/pre-prod environment) Production

The Contractor shall ensure that final software is provided in CMS environments as appropriate. Local virtualized development environments shall be standardized across development teams. Specifically,

1. The Contractor will be supplied commercial cloud infrastructure procured through an alternative vendor, and will be provided with credentials for the cloud infrastructure management environment and a base machine image. The contractor shall be responsible for the rest of the DevOps responsibilities for developing and maintaining necessary environments.

2. The Contractor shall be responsible for the overall service or software fully delivered to the customer/operational environment. This includes, but is not limited to, open source product support.

3. The Contractor shall use a DevOps approach to maximize the predictability, efficiency, security, and maintainability of operational processes.

4. To the greatest extent practicable, the Contractor shall use automation to support DevOps.

5. The Contractor shall use a DevOps approach to result in improved deployment frequency, which can lead to faster time to market, lower failure rate of new releases, shortened lead time between fixes, and faster mean time to recovery in the event of a new release crashing or otherwise disabling the current system.

6. Research/explore Open source software.

7. Focus on active application level monitoring/continuous monitoring

8. Ensure application performance including pro-active performance tuning of application and the underlying infrastructure to optimize application delivery.

9. Focus on Automated Testing.

10. Use Continuous Integration (CI) and Continuous Delivery (CD) best practices and methodologies including, but not limited to the following:

a. Ensure that the majority of core functionalities can be automatically tested prior to deployments (BDD, TDD).

b. Build configuration and provisioning scripts for application deployments that are reusable for future deployments.

c. Ensure that CMS stakeholders are automatically notified when deployments occur to specific environments

4 Specific Tasks and Deliverables

4.1 Deliverables

A deliverable will be considered complete and acceptable when it meets the contractor's 'Definition of Done' which are based on the contractors Agile Software Development methodology and defined in the Performance Work Statement (PWS).

Each deliverable shall incorporate CMS IT requirements, including technical and/or detailed design documents within iterations, and the United States Digital Service Playbook (https://playbook.cio.gov) standards and be compliant with Section 508.

4.2 OBJECTIVES:

Functional goals:

The CMS/CCSQ/ISG seeks the skills to build software for some or all of the following needs.

For the Quality Payment Program, performance is measured in four categories: Clinical Practice Improvement Activities (CPIA), Advancing Care Information (ACI), Quality (formerly known as PQRS), and Resource Use (RU). The categories have varying inputs but standardized outputs.

For instance, Quality uses aggregated numerator/denominator measures in an XML file as an input, whereas Resource Use uses claims data as an input, but both components output a “category score” that is used to calculate a comprehensive MIPS score.

In this Contract, CMS seeks to build a proof-of-concept API and platform that serves to integrate measure calculation and results across these four categories. The application will serve as the technical architecture for an end-to-end, integrated submission and scoring system. A number of standardized processes must be performed across all four categories and are documented below.

The Contractor would be expected to design and develop the platform according to best practices for performance, reliability, and independence. For instance, the vendor may research the design of the problem and decide that a micro service-style architecture with a standalone measures engines for each category is appropriate. For instance, CPIA and ACI may be calculated by one standalone service, Quality may be calculated by another standalone service, and Resource Use by another standalone service. If so, initial development work on the platform could use “dummy services” for the individual categories – accepting input data in the expected format and producing sample output data in the expected format – in order to build the necessary services around all four categories. The goal is to learn-by-doing by building the platform that wraps around the entire backend analytics of the Quality Payment Program.

An important goal is to establish the API contracts and service boundaries between components, so that individual components of the backend architecture can be isolated and improved while knowing they fit into a well-orchestrated overall architecture.

For reference, here are the inputs for each category:

• CPIA requires simple attestations (yes/no).

• ACI requires simple attestations (yes/no) as well as attestations of simple numerator/denominator measures.

• Quality requires more complex submission of a subset of hundreds of quality measures, which can become complex but ultimately involve addition and multiplication for scoring.

o Quality measures also require inputs from claims-based administrative data to address mandatory population measures.

• Resource Use requires claims-based cost data as an input.

Specific objectives for this work are below and are subject to change at any time based on CMS priorities during sprint planning. Additional functionality may be added as sprint capacity allows.

CMS priorities may modify or replace the functional goals/tasks noted above.

• Contractor should generate representative sample input and output data for each category o CMS will provide, where appropriate, small volumes of sample submissions such as last year’s PQRS submissions o Data should be generated at volumes that represent more than our maximum expected volume from real users

• This contract does not include building a front-end, graphical user interface for submitting data.

• Design a RESTful API that can be consumed by a front-end webapp (built by CMS) and by external, authenticated users (such as registries and EHRs) to submit QPP data.

o Consideration to the large file sizes being transferred is also important, as web services may struggle with bulk upload and may need to be replaced by implementations such as SSH File Transfer Protocol (SFTP).

o Compatibility with current XML-based submission methods should be maintained, and the application should also allow for submission in smaller chunks consistent with modern API design.

o Document the specifics of the API so that external developers can consume and create tools based on the API, using scalable documentation frameworks such as Swagger.

• Application should coordinate submissions for the three categories that require user submissions (CPIA, ACI, and Quality) and route the data to the appropriate scoring engine o All three categories can be submitted via the same XML specification by the user, either submitted in separate files or submitted in the same file. Note that it is not required that a user submit all categories via the same XML specification.

Multiple specifications can be used to submit data, including the QRDA-

3 XML spec, the QCDR XML spec, and the Registry XML spec.

• Application should reference provider characteristics data to be supplied by CMS.

These characteristics will be used to determine the scoring methodology, and scoring exemptions or exceptions. Examples of characteristics: whether the provider is in an APM, whether the provider is patient facing, the provider’s specialty.

• Standup at least dummy services (whether part of a unified application or built as standalone services) for each measure category o The decision to build unified or standalone services should integrate research into best practices given the data and calculation requirements.

o The dummy services accept data input at expected volumes and produce data output at expected volumes, in order to ensure testing is adequate.

• Create a simple command line application to submit data to the API. This need not be fully featured, but should be sufficient to test and demo the application

• As possible, develop a working scoring engine for at least one measure within each category o For instance, implement one quality measure, one ACI measure, one CPIA measure, and one Resource Use measure.

o Using sample data and real calculations.

o These will prove the concept of the types of data inputs and outputs needed for each service, which help prove the concept of the overall architecture.

• The application should aggregate category scores into a single, unified MIPS score o In the first year, score is a simple linear combination:

50%: Quality

25%: ACI

15%: CPIA

10%: Resource Use o This may change in the future.

o This combined score must also be able to change based on user characteristics.

For instance, Nurse Practitioners are allowed to submit ACI measures but are not required to submit them. If a Nurse Practitioner (NP) does submit ACI measures, the NP is scored on that category. If an NP does not submit ACI measures, that category is removed from their total MIPS score and the contributions of the other categories are forced to add up to 100% (e.g., 67% Quality, 20% CPIA, 13% Resource Use).

• System performs under high volumes of concurrent users submitting numerous submissions with large individual file sizes that represent thousands of clinicians o The submission and scoring platform should be designed to support high-volume submissions (using real and/or manufactured sample data) from the beginning of its development.

o Some users, such as third-party surrogates, will attempt to submit data in a single large XML file that represents hundreds or thousands of clinicians that they represent.

o After a user submits their data, as much feedback as possible on their submission and scoring should be immediately given to the user.

Some of the feedback that the QPP gives to submitters can be issued without reference to other users’ submissions, such as returning the values of the calculated total points achieved in a given category.

The feedback should incorporate information relating submission completeness. For example, a user may have only submitted Quality data at this point in time, and not any of the other categories. So, the feedback should indicate the there is still incomplete data in these other categories (point-in-time feedback).

The feedback should indicate all know provider characteristics to reflect our assumptions on scoring methodology.

Some of the feedback that QPP gives to submitters can only be issued after references to other users’ submissions, such as budget neutrality adjustments (final feedback).

The implementation of the scoring feedback may involve using an asynchronous API for small file sizes, and if necessary a system to support delayed notification of results such as email notification.

o Performance goals include optimizing over all of the following goals, achieving all if possible:

Speed of feedback to a single user

• Users submitting data should receive immediate feedback on the scoring of their submission.

Speed of feedback on large volume files

• Users submitting large volumes of data in a single file should receive immediate feedback on the scoring of their submission.

Performance with concurrent users

• Hundreds or thousands of concurrent users should be able to submit data and receive feedback.

• The platform should support large volumes of stored user-submitted data with audit logs o The system is expected to store data on behalf of at least 1.2 million clinicians.

o The system is expected to provide an audit trail for updates to submitted data.

This is important in case a user has a complaint about feedback that was given on now-outdated data.

• The platform should support data validation rules to flag suspicious submissions o Initial development can begin with very basic data validation rules, such as an abnormally high or low score or a lack of submissions

• Implementation allows users to query for their own already-submitted information o The API should allow authenticated users to query for information such as:

Whether data for a given practice or provider has already been submitted and when All of the data submitted for a given practice or provider Scoring feedback for a given practice or provider Any status updates such as “under targeted review” for a submission.

• Implementation allows users to update already-submitted information o If a user submits data before the end of the period of MIPS performance, and wants to update their data after receiving feedback on the submission or generating additional data from their own clinical activities, a workflow should be designed to support updating that data.

o The workflow should indicate the scope of the update to ensure that users are not accidentally “erasing” previous submissions they did not intend to overwrite.

• Implementation allows administrative users to perform administrative services o Administrative users should have the ability to view all of the data that users are able to see about their own profile o Administrators should have the ability to mark a record as ‘under review’ or another such processing stage

• Data validation o At the time of submission, users should receive real-time feedback on whether their data passes validation rules across all the categories for which it is submitted.

• Web analytics framework should track user access statistics to any API endpoints

• Entire platform should have full test coverage of automated unit tests, integration tests, and performance tests.

o All functionality should be covered with unit testing, service boundaries should be covered with contract tests, and lightweight end-to-end testing should be used to verify the overall coordination of the system.

4.3 Development practices:

The Government seeks to develop this software in an agile, iterative, flexible manner. CMS direction will lead to prioritization of the product backlog for spring planning. Because CMS’s direction may change in an agile environment, CMS seeks to purchase development capacity for goals similar to those stated above.

4.4 Development goals:

• Providing simple, systematic frameworks for introducing new measures or changing existing measures, so that new measures are not ‘hard-coded’ into source code but instead are configured in an easy-to-update fashion outside of source code.

• Supporting full parallelization and scaling on standardized commercial cloud infrastructure

• Develop infrastructure-as-code to minimize any manual mutations of infrastructure

• Supporting streaming measure calculation to calculate Quality Payment Program measure scores as data is submitted, rather than waiting for a once-per-year batch calculation. Streaming calculation would help CMS more quickly identify problems with data quality, identify problems with end-to-end system integration, help providers understand their scores and take actions to improve them, and reduce the once-per-year backlog of ‘targeted review’ appeals of measures scores.

• Supporting the use of open source software, which can be easier to maintain than closed commercial products.

• In order to support technically-advanced organizations and third-parties, providing simple integrations for submitting data through easy-to-use interfaces such as RESTful APIs.

• In order to support technically-advanced organizations and third-parties, providing simple integrations for receiving scoring feedback through easy-to-use interfaces such as RESTful APIs.

• Building automated mechanisms for testing data quality that flag invalid or otherwise unusual submissions.

• Designing the scoring architecture to support microservices or alternative design choices that enable best practices for designing enormously complex software.

• Providing comprehensive code coverage with automated unit, integration, and end- to-end testing to enable rapid development without introducing bugs.

• Building with an agile, iterative release schedule to rapidly deploy new versions of the software so that developers can quickly fix problems and provide improvements.

4.5 Collaboration Environment

The contractor shall utilize as their primary collaborative workspace tools the following current CMS-deployed collaboration tools, which are Confluence, JIRA and HipChat. The contractor is required to establish a collaborative workspace using either of these tools or another that both the contractor and the CO can agree upon.

The contractor shall:

1. Ensure that all deliverables, products, licenses, designs, data, documentation, tests, user research notes, source code, configuration settings and files, and materials developed throughout this Contract will be the property of the U.S. Government.

2. Work with the PM and COR from launch to ensure all reference materials and other documents are accessible to the appropriate Government personnel at all times.

3. This documentation may also include but is not limited to user research materials and findings.

4. Ensure any software written should be stored using version control to which the PM and

COR and any other relevant government employees will have at minimum read access.

5. Any and all monitoring and analytics dashboards and tools will be accessible to the appropriate Government personnel at all times.

6. Provide any necessary assistance to the PM and COR and potentially another vendor to stand-up and ensure the applications, systems, databases, platform, and environments are tested and fully operational.

4.6 Transition Activities

During the transition to the Government and/or a new contractor, the Contractor shall perform all necessary transition activities, including, but not limited to:

- continued full services to the Department of Health and Human Services

- participation, at discretion of COR in five or more meetings with the Government or new contractor to effect a smooth transition and provide detailed information on the operation o fall deliverables

- training of new personnel (contractor or government) during the transition period in all system operation and maintenance functions

- appropriate close-out of outstanding technical and related work

- completion of any necessary documentation as requested by the Product Manager, COR, or other government employee

- being available to answer any questions that arise.

Information such as the list of accomplishments, documentation, and customized code developed for HHS should be available to the Government in the collaborative workspace established from contract's initiation. Should the contract be terminated prior to the end of the scheduled base period, the Contractor shall work with the Government to ensure they retain access to this information within two weeks from the termination date.

4.7 Performance Standards, Criteria and Quality Assurance Surveillance Plans The awarded contract will be issued as performance based and will contain performance standards and expectations, a quality assurance surveillance plan (QASP) and performance measurement methodology to ensure performance standards are met. The Notional Quality Control Plan (QCP) which includes the performance standards, QASP, and performance measurement methodology, shall be proposed by the contractor and upon Government approval, the plan to be used to will be located under Attachment A and will be included in the contract award.

4.8 Contractor Use of Commercial Computer Software, Including Open Source Software Open source software is often licensed under terms that require a user to make user’s modifications to the open source software or any software that the user combines with the open source software freely available in source code form pursuant to distribution obligations in the license. In cases where the Contractor proposes to use the open source software while performing under this Contract, regardless of whether the open source software is delivered, the Contractor shall not create, or purport to create, any Government distribution obligation with respect to Government computer software deliverables. Prior to using any commercial computer software, including open source software which is considered commercial computer software, the Contractor shall evaluate each license for commercial computer software, and confirm that each of the following requirements is satisfied:

1. A license for a particular commercial computer software shall be compatible with all licenses for other commercial computer software that are or will be linked to, adapted to, integrated, combined or merged with the particular commercial computer software, including when the particular commercial computer software and the other commercial computer software are used with another computer program

2. A license for commercial computer software shall not impose a future Government obligation that is foreseeable by the Contractor

3. A license for commercial computer software shall not be terminated by the Contractor’s use of the commercial computer software in performing under the contract

4. Contractor’s cost to comply with this requirement presents no additional costs to the Government

If, as a result of the Contractor’s evaluation, the Contractor satisfies all of the requirements in the paragraphs above, then the Contractor shall provide a written summary report of the above findings to the Contracting Officer stating that the Contractor has evaluated the commercial computer software use and the commercial computer software license, and made each determination required in the paragraphs above. The Contractor shall request permission from the Contracting Officer to use the proposed commercial computer software. This notification shall include all information regarding the identification and proposed use(s) of the commercial computer software.

If the Contractor is unable to satisfy all of the requirements in the paragraphs above for a particular commercial computer software license, then the Contractor may not use the commercial computer software covered by the particular license without prior written approval of the Contracting Officer. If the Contractor wants to use the commercial computer software for which the requirements in the paragraphs above within this section are not satisfied, the Contractor shall request approval to use the otherwise prohibited subject commercial computer software from the Contracting Officer by providing written notification addressing the following:

1. The name and version number of the software;

2. The name of applicable license(s);

3. A brief description of the technical use and implementing approach

4. A “yes/no” indication as to whether the Contractor has made, or will make, any modifications to the source code;

5. The software website; and,

6. An identification of the reason(s) that the Contractor was unable to make the determination in the paragraphs above.

5.0 Place of Performance

The preference of CMS is to enable colocation between CMS and the contractor as proximity, collaboration and communication efficiency is incredibly valuable and facilitates the success of the agile framework. The ideal requirement for place of performance for this effort would be that the contractor come to the CMS Colocation space near CMS headquarters in Woodlawn, 2-5 days per week.

The contractor may suggest other ideas and demonstrate how they could maintain a highly effective level of communication through other means. The contractor may need access to Government sites as well. The contractor shall have additional facilities to perform contract functions as necessary. Any off-site development and test environments need to be compliant with HHS and federal security guidelines.

6.0 Kick Off Meeting

The Contractor shall provide and collaborate with the COR on an agenda for the Kick Off meeting. Discussion topics shall include, but not be limited to: introduction of the Contractor and Government Staff; understanding of the specific tasks and subtasks; project management expectations; agreement on meeting schedules; and agreement on initial delivery dates.

The Kick-Off meeting/Post-Award Conference will take place within 10 business days from award.

7.0. Inspection and Delivery

Overview Under the agile methodology, the traditional transition process should not be necessary. Rather, the Government should have access to all code and other relevant documents from day one in a clearly documented and organized electronically shared workspace.

1. The progress of the product will be inspected by the Government Program Manager, Contracting Officer’s Representative (COR) or another Government employee at the completion of each iteration.

2. All documents should be stored electronically such that the COR, PM, and any other relevant Government employees who have been granted permissions can access them at any time.

3. The transition of materials will occur on an ongoing basis. All new materials produced during an iteration will be made available to the Government at the end of that iteration.

4. In addition to the code, documentation should be updated with each iteration. This includes technical documentation including but not limited to setup instructions in the README.md, user research findings etc.

8.0Delivery and Timing The contractor shall ensure proper control and coordination of all deliverables to ensure they are on time. Unless otherwise stated, the Government will review deliverables and notify the contractor of acceptance or non-acceptance within 5 business days. Representatives of the contractor shall meet with the COR and other members of the Government as necessary to review status of deliverables.

9.0Late Delivery The Contractor shall notify the COR, or other authorized representative, as soon as it becomes apparent to the Contractor that a scheduled delivery will be late. The Contractor shall include in the notification the rationale for late delivery, the expected date for the delivery, and the project impact of the late delivery. Such notification in no way limits any Government contractual rights or remedies, including, but not limited to, termination.

10.0Product Owner The Product Owner/Project Manager/Federal Solution Architect will manage designated products and communicate with the stakeholder community, are empowered to make business decisions rapidly, set work priorities within designated products, and will remove obstacles to product success. They help write user stories, manage a product’s backlog, and work with CMS management and partners as customers on a daily basis. Product owners make the final Contract on functionality and features for their products.

11.0End Users End Users may be used in this effort in usability testing and/or customer satisfaction surveying. The team within HHS managing this contract commit to support the vendor in the user research process, and will provide the vendor with access to the Government employees who will be the users of the product.

12.0 APPENDIX

Technical Overview

a. Technical Environment

The platform will contain Sensitive but Unclassified (SBU) and Personally Identifiable Information (PII). No classified information will be contained in these systems. Federal Information Processing Standard (FIPS) 199 classification is likely High for Availability, Moderate for Integrity, and Low for confidentiality.

The following is the representation of the hardware/software of some of the existing systems for quality measures that are in the HCQIS data center. With a potential move to commercial cloud infrastructure, then there is much more flexibility in the hardware/software choices.

HCQIS Hardware/Software Reference Guide

Presentation:

• Apache 2.0.63, 2.2.22

Application:

• Oracle Weblogic 9.2, 10, and 10.3

• Oracle Web Center 10.3 and 11.1.1

• Oracle SOA (Fusion Middleware)

• Oracle BPM

• Oracle Service Bus 10.3 and 11.1.1

• Oracle BPEL Process Manager

• Oracle OpenSSO 8.0

• Oracle Fatwire

• Informatica Power Center 8.6

• Informatica Power Exchange

Database:

• Oracle 11.2.0.2

• Oracle ASM 11.2.0.2

APPLICATION ARCHITECTURE

High Availability:

• Oracle RAC 11.2.0.2

• Veritas Cluster Server 5.1

Business Intelligence and Analytics:

• Oracle Business Intelligence Enterprise Edition (OBIEE)

• SAS 9.1.3, 9.2 and 9.3

• SAS BI

• COGNOS 8.2 and 8.4.1 Reporting

Management Services:

• Serena Dimensions Requirements Management

• Serena Dimensions Configuration Management

• HP Quality Center 11

• BMC Remedy AR 7.5

• BMC Remedy ITSM 7.6

• WebEx Meeting and Support Center

• Data Maker

PLATFORM

• Oracle Solaris 10 Update 9.

For Oracle T4, T3, T2000, T5120, T5140, T5220, T5240, M3000, M4000, M5000, V120, V240,

• Linux RHEL 5.8 & 6.2

• Big F5 Load Balance appliances

• 4 IBM XI50 appliances

• 2 IBM XI52 appliances

EXTERNAL INTEGRATION

• CMS Integrated Data Repository (IDR)

• CMS National Level Repository (NLR)

• Connectivity established via IBM MQ

• Symantec VIP for multi-factor authentication

USER INTERFACE

• Web-based

• J2EE

Definitions AGILE DEVELOPMENT/AGILE SOFTWARE DEVELOPMENT: A proven commercial methodology for software development that is characterized by incremental and iterative processes where releases are produced in close collaboration with the customer. This process improves investment manageability, lowers risk of project failure, shortens the time to realize value, and allows agencies to better adapt to changing needs.

DAY: A calendar day unless stated otherwise. If a deliverable is due on a weekend or holiday, the deliverable shall be considered due the next business day.

QUARTER: A quarter will be defined as the first of January through the end of March, first of April through the end of June, first of July through the end of September, and first of October through the end of December.

BUSINESS DAY: Any day other than a Saturday, a Sunday, a Federal holiday or other day on which the Federal Government by law or executive order is closed. Note: This includes any weather-related office closures if the place of performance is in a Federal Building.

MINIMUM FUNCTIONALITY: The minimum capabilities a product should have to meet the Government's objectives.

AGILE ENVIRONMENT: A team-based setting for IT product development where the Agile development methodology is used.

ITERATION/SPRINT/RELEASE CYCLE: Divisions of time within the Agile development framework. Each iteration is small in scale (i.e., encompasses a single or a few function(s) within a multistep process). Multiple iterations form releases. For more information, see the TechFAR at https://github.com/WhiteHouse/playbook/blob/gh-pages/_includes/techfar-online.md

MILESTONES/EPICS: A necessary step in a process. In this document, used to refer to components ofa given project.

STORY POINT: A measurement of work and effort. Story points are used in an Agile development environment to demonstrate how much work was achieved in a given sprint or iteration. For more information, see the TechFAR:

href='https://github.com/WhiteHouse/playbook/blob/gh- pages/_includes/techfar-online.md

THROUGHPUT: The amount of material or items passing through a system or process; in this document, refers to the work activity of a product development team.

USER STORY: A very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.