new york state department of health · technology iterations, serff today is a feature rich web...

NY-HX Project

CSC

Plan Management Business Requirements Document

Release Contract #: C-027853 Date: September 25, 2012

Item Number Topic

4.3 Plan Management Systems or Processes that Support the Collection of QHP

Issuer and Plan Data

New York State

Department of Health

http://www.csc.com/

NY-HX Plan Management Business Requirements Document Page i

September 25, 2012

Revision History

Version Date Change

Implemented By Change Approved By Description of Changes 1.0 9/25/2012 L. Hartmark S. Garner Initial Publication

http://www.csc.com/

NY-HX Plan Management Business Requirements Document Page ii

September 25, 2012

Table of Contents 1 Introduction ............................................................................................................................ 1

1.1 Purpose ....................................................................................................................... 1 1.2 Document Management ............................................................................................... 1 1.3 Intended Audience ....................................................................................................... 2

2 Reference Documents ............................................................................................................ 2 3 Overview ................................................................................................................................ 4

3.1 Business Purpose ........................................................................................................ 5 3.2 Measures of Success ................................................................................................... 8 3.3 Stakeholders ................................................................................................................ 9 3.4 Project Priorities ........................................................................................................... 9 3.5 Project Diagrams ........................................................................................................10

3.5.1 Work Context Diagram .........................................................................................10 4 Assumptions/Constraints/Risks .............................................................................................11

4.1 Assumptions ...............................................................................................................11 4.2 Constraints .................................................................................................................11 4.3 Risks ...........................................................................................................................11

5 Business Requirements .........................................................................................................12 5.1 Business Processes ....................................................................................................12

5.1.1 Initiation of Certification Process for QHP ............................................................12 5.1.2 Receipt of Plan Data via SERFF ..........................................................................12

5.1.2.1 Main Event Diagram for Quality Health Plans ...............................................14 5.1.3 Government Health Care Programs .....................................................................15

5.1.3.1 Receipt of Child Health Insurance Plan (CHIP) Plan Data ............................15 5.1.3.2 Receipt of Medicaid Managed Care (MMC) Plan Data ..................................17 5.1.3.3 Main Event Diagram for Government Health Programs ................................19

5.1.4 Receipt of Quality Data via QARR .......................................................................20 5.1.4.1 Event Diagram for Quality Data ....................................................................20

5.1.5 Receipt of Provider Network Data from DOH PNDS ............................................21 5.1.5.1 Event Diagram for Provider Network Data ....................................................22

5.1.6 Plan Management Entity Relationship Diagram ...................................................23 5.1.7 QHP Recertification, Decertification and Appeals ................................................24

5.2 System Requirements .................................................................................................25 5.3 User Stories Summary ................................................................................................25

6 Glossary ................................................................................................................................26 7 Acronyms ..............................................................................................................................27 Appendix A Rational Requirements Composer Epic User Stories Report ............................29 Appendix B The New York Template ...................................................................................36 Appendix C The CHIP / MMC Template ..............................................................................37

http://www.csc.com/

NY-HX Plan Management Business Requirements Document Page iii

September 25, 2012

Table of Figures

Figure 1: NY Exchange High Level Data Flow ...................................................................... 10 Figure 2: QHP Certification Process Flow ............................................................................... 14

Figure 3: Medicaid & CHIP Flow .............................................................................................. 19

Figure 4: Quality Data Flow ...................................................................................................... 21

Figure 5: Provider Network Data Flow .................................................................................... 22 Figure 6: Plan Management ERD ............................................................................................ 23

Table of Tables

Table 1: Reference Document ................................................................................................... 3

Table 2: Business Processes ..................................................................................................... 7

Table 3: Stakeholders .................................................................................................................. 9

http://www.csc.com/

NY-HX Plan Management Business Requirements Document Page 1

September 25, 2012

1 Introduction

This requirements document applies to the Plan Management area of the New York Health Insurance Exchange (NY-HX) system. The NY-HX is an online exchange where eligible individuals and small business employees will shop to obtain health insurance coverage. A full spectrum of health insurance plans tailored to the specific needs of Exchange applicants will be offered. These plans will range from the Insurance Affordability Programs (IAPs), which include the Medicaid Managed Care (MMCs) and Children’s Health Insurance Program (CHIP) plans, to the Qualified Health Plans (QHPs). The Plan Management component of the Exchange includes all the features and functions which identify, classify, certify, decertify, administer, and maintain the full spectrum of health plans offered on the Exchange for applicant selection and enrollment. The evolution of this document is expected to be iterative and reflective of the Agile Software Development Life Cycle (SDLC) methodology. Many requirements will be defined at a progressively granular level as the project unfolds and progress is made through the development and testing cycles (Sprints). This document will be kept current with relevant early development efforts as per the Agile iterative process. It is expected that this document will accurately reflect the real-time requirements knowledge that results from intensive requirements gathering sessions and SME interviews. Reflective of the Agile process, this document will be more current and less predictive. It will accurately reflect the real-time development and accurately anticipate real-time requirements.

1.1 Purpose

This document provides business requirements for the Plan Management business area of the New York Health Benefits Exchange (NY-HX). The Plan Management business area includes identifying, certifying, and managing Qualified Health Plans (QHPs) and Insurance Affordability Programs (IAPs), and monitoring service delivery by the plans, in the NY-HX. The business processes in this document are expected to be implemented by the NY-HX, supporting Agencies including the Department of Health (DOH) and the Department of Financial Services (DFS), and with assistance from the National Association of Insurance Commissioners (NAIC).

1.2 Document Management

The requirements specified for the business processes in this document will be traced to the appropriate deliverables in the Sprints to ensure that all requirements are properly implemented and tested. The Rational product suite will be used to maintain overall requirements traceability for the entirety of the project. Report extracts from Rational will be included in the appendices of this document to provide an up-to-date snapshot of the requirements repository covering Plan Management.

http://www.csc.com/


September 25, 2012

1.3 Intended Audience

The target audience for this Requirements Document includes business, technical, test, governance and project management stakeholders. Per the desire by the Centers for Medicare and Medicaid Services (CMS) to promote reusability across states involved with Exchange implementation, this document may also be reviewed by other states building similar plan management functionality within their Exchange environment.

2 Reference Documents

Document Name Document Description Document Link Plan Management Blueprint – Exchange Business Architecture Supplement

CCIIO Description of Plan Management Business Area

Available in CALT

CFR Part 433, Medicaid Program: Federal Funding for Medicaid Eligibility Determination and Enrollment Activities; Final Rule

90/10 funding rules http://healthit.hhs.gov/portal/server.pt?open=512&mode=2&objID=3161

Guidance for Exchange and Medicaid Information Technology (IT) Systems Version 2.0

CCIIO description of technology framework expectations

http://cciio.cms.gov/resources/files/exchange_medicaid_it_guidance_05312011.pdf

Medicaid Information Technology Architecture (MITA) supplements

CMS MITA guidance documents http://www.cms.gov/MedicaidInfoTechArch/04_MITAFramework.asp#TopOfPage

Affordable Care Act legislation, related regulations, rulemaking, and guidance:

45 CFR Parts 155 & 156

IRS NPRM

Exchange NPRM

Medicaid NPRM

Health Insurance Exchange legislation, regulations and guidance

http://www.gpo.gov/fdsys/pkg/BILLS-111hr3590enr/pdf/BILLS-111hr3590enr.pdf Regulation 45 CFR Part 155 and 156 (CMS-9989-P) http://www.cciio.cms.gov/programs/exchanges/index.html

Title XIX of the Social Security Act (the Medicaid statute) and related regulations and guidance

Medicaid legislation http://www.cms.gov/home/medicaid.asp

Electronic and Information Technology Accessibility Standards (Section 508)

Regulation governing website accessibility

http://www.access-board.gov/sec508/standards.htm

Plan Management and NAIC SERFF Integration Potential

White paper (written by NY staff) describing the potential for the NAIC SERFF system to provide a substantial portion of plan management workflows and data stores, using a single, multi-state portal with reusable business processes.

\\Nasriv\fox_qa\HX\Early Innovator\Business Areas\Plan Management\Docs

http://www.csc.com/





September 25, 2012

Document Name Document Description Document Link NAIC SERFF HIX Plan Management Business Requirements Summary

Document which defines the Plan Management business requirements for SERFF.

http://www.serff.com/documents/hix_pm_brs_v1.pdf

NAIC SERFF HIX Technical Study Group Preliminary Report

Report which defines high-level data element and relationship requirements, conceptual XML schema, and technical considerations for the SERFF to Exchange Web service.

http://www.serff.com/documents/hix_technical_study_group_preliminary_report_v1.pdf

Table 1: Reference Document

http://www.csc.com/





September 25, 2012

3 Overview

Plan Management is one of the six key business areas of the NY-HX solution. Plan management encompasses all of the business processes which identify, certify, decertify, renew, manage, and administer all of the health plans offered by the NY-HX. Since New York will be developing an Exchange solution that integrates, within one portal, eligibility and enrollment for IAPs and QHPs, this document will not only include the QHP requirements but also the requirements for the IAPs. A key component of the NY-HX solution is the System for Electronic Rate and Form Filing (SERFF) from the National Association of Insurance Commissioners (NAIC). SERFF was initially developed in the early 1990s to provide a cost-effective method for handling insurance policy rate and form filings between regulators and insurance companies. After several technology iterations, SERFF today is a feature rich Web portal through which both insurance companies and state regulators process filings for health, accident, life, and property and casualty insurance coverage. It facilitates communication, management, analysis, and electronic storage of documents and supporting information required for review and approval of regulatory filings. Currently all 50 states, the District of Columbia, Puerto Rico, and over 3000 insurance companies, third-party filers, rating organizations, and other companies use SERFF on a regular basis. Twenty-five states require their issuers to use SERFF. In 2010, 565,475 filings were processed by SERFF, a growth of 208% over the previous five years. In the State of New York, issuers are not mandated to file through the SERFF system, yet more than 98% of all accident and health filings are submitted this way. NAIC has recently decided to enhance SERFF to support the plan management functionality required by states. New York has decided to utilize the SERFF enhancements to support its plan management solution. As a result, SERFF will be used by the QHP issuers, state regulators, and the NY-HX Exchange administrators to support the QHP certification/decertification, renewal, monitoring, and administration processes. This approach leverages and expands upon the existing processes that are currently in place today and used by both the issuer and state regulator community. Plan Management will also leverage existing data gathering tools associated with provider network adequacy and quality assurance/customer satisfaction reporting. The Provider Network Data System (PNDS) will be the system from which the provider network directories will be drawn from and displayed on the web portal. The Quality Assurance Reporting Requirements (QARR) will continue to be gathered and used for display on the web portal as well. The action of certifying a QHP on SERFF will trigger a data exchange event between SERFF and the NY-HX system. Technically, SERFF will invoke a NY-HX Web Service which results in the transfer of all relevant data for the certified QHP. Once received at NY-HX, the data will be loaded into the Exchange Plan Management repository and joined to quality and provider network directory data imported into NY-HX through separate load processes. Validation of all related QHP plan data will occur prior to the plan becoming available in the consumer plan selection module within the Eligibility and Enrollment business area.

http://www.csc.com/


September 25, 2012

New York will not use SERFF for MMC and CHIP plans. Separate import processes will be developed to load these plan types directly from the NY DOH. As with QHP plans, quality and provider network directory data will be joined to these plans within the NY-HX system. Validation of all related MMC and CHIP plan data will occur prior to the plans becoming available in the consumer plan selection module within the Eligibility and Enrollment business area.

3.1 Business Purpose

The business area affected by this requirement document is Plan Management

The CMS business processes defined by this requirement are:

BP-PM-01 – Initiate QHP Issuer Application. This process will be performed by the Exchange or the State Department of Insurance (as designated by the Exchange) in order to initiate the QHP certification process. The process is comprised of validating the Issuer, creating an Issuer account in the system, and collecting application data. Once the application process is complete, the Issuer receives notification of QHP application acceptance. Rate and Benefit data are submitted through a separate process in BP-PM-03. Recertification of Issuers could follow a similar process.

BP-PM-02 – Evaluate QHP Issuer Application. This process will be performed in order to evaluate the QHP Issuer application. Once the evaluation is complete, the Issuer will be notified and account information will be updated. The rate and benefit data collection and analysis may occur concurrently with the evaluation of the QHP Issuer application. State Exchanges and other regulatory authorities, such as the State Department of Insurance, will need to determine which segments of the QHP Issuer application they will evaluate.

BP-PM-03 – Receive Rate and Benefit Data and Information. This process will be performed by the Exchange and/or the State Department of Insurance in order to receive rate and benefit data and information from issuers. Initial automated data checking may be performed. In addition, Issuer representatives will attest to the validity of the data and information submitted.

BP-PM-04 – Revise QHP Issuer Application. This process may be performed at different points in the QHP Issuer Application Evaluation process (BP-PM-02) to allow the Issuer to resubmit portions of its QHP Issuer Application.

BP-PM-05 – Determine Issuer or Plan Non-Certification. This process provides for non-certification of Issuers or specific plans. There are multiple instances within the QHP certification process that would trigger non- certification of an Issuer or a plan.

BP-PM-06 – QHP Certification Agreement. This process is performed at the end of

the certification process to establish an agreement between the Exchange and a QHP Issuer. This process is only performed for those Issuers who met the standards as evaluated by the Exchange in the QHP Issuer application evaluation, rate analysis and benefit evaluation processes. This process will likely vary by state.

http://www.csc.com/


September 25, 2012

BP-PM-07 – Monitor Issuer and Plan Certification Compliance. This process is performed to monitor QHP certification compliance. If this process is performed by the Exchange, close coordination with the State Department of Insurance would be necessary to avoid duplication of oversight activities. Some compliance issues will be specific to QHP participation in the Exchange, such as compliance with operational requirements, while others may be similar to issues traditionally addressed by State Departments of Insurance.

BP-PM-08 – Maintain QHP Operational Data. This process may be performed to

maintain up-to-date operational data received from Issuers, to analyze changes in the data, and to take appropriate actions based on the changes in the data. The data may include: provider network data, issuer administrative information, transparency data, quality information, and marketing materials and notifications to members. This process also includes receipt of consumer complaints and corresponding response as well as the process for changing QHP enrollment availability.

BP-PM-09 – Issuer Account Management. This process will be performed on an ongoing basis throughout the plan year to manage the relationship between a QHP Issuer and the Exchange. This process allows an Account Manager to coordinate between a QHP Issuer and any relevant Exchange business area, such as Financial Management or Enrollment, as needed in order to resolve issues or make updates to Issuer Information.

BP-PM-10 – Analyze Rate and Benefit Data and Information. This process may be performed by the Exchange and/or by the State Department of Insurance to analyze rate and benefit data and information. This process will include review and/or consideration of justification information for rate increases. Issuers will need to update rate and benefit information at least annually. We are cognizant of existing State regulatory authorities; we encourage collaboration between the Exchange and the State Department of Insurance.

BP-PM-11 – Revise Rate and Benefit Data and Information. This process may be performed by the Exchange and/or by the State Department of Insurance to request for issuers to submit revised rate and benefit data and information. The Exchange or the State Department of Insurance may request revisions to be made to the entire submission or a portion of the submission. The revised information will then be sent to rate and benefit analysis process.

http://www.csc.com/


September 25, 2012

New York implementation of these business processes will be achieved as summarized in the table below.

Business Process ID New York Specific

BP-PM-01 – Initiate QHP Issuer Application.

The Exchange will create a form application and will distribute such application via email to issuers and via its web site. The process will be manual until systems mature and an automated process can be created.

BP-PM-02 – Evaluate QHP Issuer Application.

Exchange staff will review the applications against written policies and procedures, and will use a written checklist to ensure all parts of the application are complete.

BP-PM-03 – Receive Rate and Benefit Data and Information.

Issuers will submit the rate and benefit data through SERFF.

BP-PM-04 – Revise QHP Issuer Application.

Exchange plan management staff will work with the issuers to ensure the application information is complete and accurate.

BP-PM-05 – Determine Issuer or Plan Non-Certification.

Exchange plan management staff will determine whether the issuer or a health plan cannot be certified. Notice of such determination will be provided electronically to the issuer or health plan through SERFF and through an email.

BP-PM-06 – QHP Certification Agreement.

Exchange plan management staff will issue a certification agreement to the health plan via electronic distribution.

BP-PM-07 – Monitor Issuer and Plan Certification Compliance.

Exchange plan management staff will work collaboratively with the Department of Health and the Department of Financial Services to ensure issuer compliance.

BP-PM-08 – Maintain QHP Operational Data.

Exchange will work with other agencies to collect operational data from the issuers.

BP-PM-09 – Issuer Account Management.

Exchange plan management staff will be the central point of contact for all QHP issues.

BP-PM-10 – Analyze Rate and Benefit Data and Information.

The Exchange and the Department of Financial Services will simultaneously review the information. The Exchange will leverage the actuarial expertise of the Department of Financial Services to determine adequacy of rate and benefit information

BP-PM-11 – Revise Rate and Benefit Data and Information.

In the event data and information need to be revised, given that the data will be received through the SERFF system, either the issuer or the Department of Financial Services will revise such information.

Table 2: Business Processes

http://www.csc.com/


September 25, 2012

3.2 Measures of Success

Criteria and metrics for evaluating the success of implementing this business area are:

The Exchange initially qualifies and/or certifies health plans in the QHP and IAP (MMC and CHIP) categories

The Exchange is able to renew certification of all categories of health plans, which includes QHP, MMC, or CHIP

The Exchange meets CMS certification criteria by the due date

The Exchange is able to present health plan rates (where applicable), scopes of service, provider networks, geographic coverage, quality, and other enrollment decision drivers to the public

The Exchange is able to offer enrollment in one or more health plans to the public

http://www.csc.com/


September 25, 2012

3.3 Stakeholders

The following table lists those stakeholders relevant to this business process, their role in defining the process, and their approval authority.

Stakeholder Role RACI Level

NY-HX DOH Project Manager

Responsible for managing and overseeing the NY-HX from the State side. RA

DOH PM Product Owner

Responsible for ensuring plan management requirements for New York are identified and included in the design and development effort of the Exchange Systems Integrator RA

DOH Subject Matter Experts (SMEs)

Responsible for setting health insurance policy and the translation of the policy into business requirements. Provides information and feedback to the SI to ensure requirements are translated into Exchange functionality. RCI

Department of Financial Services (DFS – formerly the State Insurance Department) SMEs

Responsible for setting health insurance policy and the translation of the policy into business requirements. Provides information and feedback to the SI to ensure requirements are translated into Exchange functionality. RCI

Exchange Systems Integrator Project Manager

Responsible for managing the design, development, and implementation of the NY-HX. CI

Exchange Systems Integrator Team

Responsible for the design, development and implementation of the NY-HX. CI

Exchange Quality Assurance Team

Responsible for providing QA of the NY-HX and supporting the State’s project management efforts. RCI

Issuers Exchange users and providers of Qualified Health Plan (QHPs) and IAPs. RC

NAIC

Responsible for customizing the System for Electronic Rate Form Filing (SERFF) to support multi-state plan management requirements. RCI

*Review/Authorize/Consult/Inform

Table 3: Stakeholders

3.4 Project Priorities

The business processes in this document, unless marked otherwise, must be substantially designed, developed, and tested by the end of the first half of calendar year 2013 and operationally ready by October 2013.

http://www.csc.com/


September 25, 2012

3.5 Project Diagrams

3.5.1 Work Context Diagram

The figure below shows the work context for the NY-HX/Plan Management module. The work context diagram shows the primary entities that will have knowledge of the NY-HX/Plan Management module and that will interact with it. It highlights the main Plan Management data components and the event flow associated with the work.

Figure 1: NY Exchange High Level Data Flow

http://www.csc.com/


September 25, 2012

4 Assumptions/Constraints/Risks

4.1 Assumptions

Listed below are the assumptions that guided the identification and development of the requirements stated in this document. These assumptions are intended to promote mutual understanding, partnership, and quality communication among project stakeholders.

1. NAIC will develop the enhancement requirements of SERFF to support plan management for States. They will develop these requirements with continual input from participating states, including New York.

2. NAIC will complete the necessary SERFF enhancements to support New York’s Exchange Plan Management needs.

3. SERFF will invoke a Web service in the NY-HX to transfer QHP data to New York’s Exchange.

4. New York will leverage existing internal systems and processes to meet the provider network directory and quality data requirements of plan management.

4.2 Constraints

Listed below are the constraints that exist for this project. These constraints may prevent or restrict reaching the desired results (e.g., satisfying requirements, meeting project goals and priorities, achieving measures of success) stated in this document.

1. All NY-HX Plan Management functionality must be operational in time to support open enrollment starting October 2013. To meet this date, plans must be certified/approved and loaded into the Exchange prior to October 2013.

4.3 Risks

Listed below are recognized project risks. These risks may create issues that have an uncertain effect on the project which in turn affects achieving the desired results (e.g., satisfying requirements, meeting project goals and priorities, achieving measures of success) stated in this document.

1. Implementation of NY-HX’s plan management functionality is dependent upon the completion of an external development project- the SERFF Plan Management enhancement project.

2. The system implementation window is extremely compressed and system testing must be conducted over a short period of time.

3. Issuers will have limited time to prepare their New York plan submittals and to load these plans into SERFF and the Exchange.

http://www.csc.com/


September 25, 2012

5 Business Requirements

5.1 Business Processes

The following sections describe the key Exchange business processes and the associated business requirements for NY-HX Plan Management. The business processes and requirements are organized by plan type – QHP and IAP (Medicaid and CHIP). For each plan type area, we define associated processes and the business requirements within each process. We also provide any associated event diagrams for the plan type. It should be noted that if New York offers a Basic Health Plan (BHP), the business requirements for this plan type will be very similar to those associated with Medicaid and CHIP plans.

5.1.1 Initiation of Certification Process for QHP

The NY-HX will initiate the certification process by issuing a Notice of Intent to Participate to all issuers in the state. This Notice will be distributed electronically and available on the NY-HX web site (and/or other agency web sites) in January 2013. The purpose of this Notice of Intent is to assess issuer level of interest regarding participation, metal levels, types and number of products available in each market. The Notice will outline all the deadlines for submission of application and data to the NY-HX.

5.1.2 Receipt of Plan Data via SERFF

1. Issuer must have submission access to SERFF.

2. The SERFF Plan Management module will be separate and distinct from other parts of

SERFF. In SERFF, the creation and submission of a Rate and Form filing is a separate workflow and approval process than traditional filings. The traditional rate and form filing will be conducted in addition to the QHP filing.

3. Issuer will log onto SERFF. The QHP submission will include an indication of market type (individual or small group) and metal level. There will be one binder for Individual plans and one for SHOP plans.

4. The Issuer will need to create the Issuer Plan ID for the plans submitted through SERFF. This Issuer Plan ID is important since it will tie the provider network data and quality data to the particular issuer and QHP.

5. The issuer will need to complete three components for the Exchange portion of SERFF: a. Standard SERFF screens used to identify the general QHP data. The process

followed for QHP certification builds upon legacy SERFF functionality currently in place to support existing SERFF filings. Standard data validations, such as field size and format, will be performed.

b. Standard SERFF template to indicate the benefits. This is submitted as an attachment.

c. A template for rates. This rate template will be modified to accommodate New York’s rating requirements, which includes community rating. It will be labeled “the New York rate template”. This is submitted as an attachment.

http://www.csc.com/


September 25, 2012

4. When a binder fails a validation, the Issuer will need to resubmit the information in

SERFF. All validations will be done on the resubmission as well. 6. The required data elements for rates are identified in the New York Template. Please

see Appendix B for the New York Template. 7. A calculator for actuarial values will also be available through SERFF to calculate the

actuarial value of the plan and assign the metal level.

8. SERFF will provide data validation on the standard information submitted through SERFF. The Exchange may perform validations on the information for the New York Template and will use DFS guidelines to perform these validations. The data will be transferred as a temporary table within the Exchange to have the validation step done. When the data passes validation, it gets moved to the staging table. If validation fails, the Exchange will notify the plan.

9. Final Exchange approval and certification is at the binder level.

10. Once the forms and rates have been approved by DFS, the issuer data is then moved to

the Exchange. The issuer plan data will then be joined with quality and provider network data as described in Sections 5.1.4 and 5.1.5.

http://www.csc.com/


September 25, 2012

5.1.2.1 Main Event Diagram for Quality Health Plans

SERFF will provide QHP data to the Exchange. The below figure represents the path of a Quality Health Plan being certified in SERFF, routed to NY-HX, and then is validated by the Issuer and Exchange to be available in the Exchange.

Figure 2: QHP Certification Process Flow

http://www.csc.com/


September 25, 2012

5.1.3 Government Health Care Programs

5.1.3.1 Receipt of Child Health Insurance Plan (CHIP) Plan Data

There are no co-payments for services under Child Health Plus. The benefit structure is standard among all CHIP plans and benefit changes only occur when mandated by law. Each Issuer will submit one CHIP plan. 1. The Bureau of Child Health Plus Policy within the Department of Health manages the CHIP

plans. This Bureau will continue to be responsible for collecting the required plan data for CHIP plans that will be offered on the Exchange.

2. The Exchange created an excel spreadsheet for all data elements that will be required to

build a complete CHIP plan record for the Exchange web portal (CHIP Template). See Appendix C: The CHIP / MMC Template. Since the benefits are standard across all CHIP plans, the benefits table within the Exchange will be pre-populated prior to implementation. Any benefits changes mandated by NYS law will be made by the Exchange. The data in the CHIP Template will be passed to the Exchange via email.

3. When the email is received, the Exchange will upload the data to a common location (sFTP

server). 4. When the CHIP Plans are received the following steps are taken:

1. The flat file is received via sFTP 2. The BPEL picks up the file and sends it to Informatica 3. Informatica converts the data and generates the XML file 4. The XML is sent to a validation web service to perform data and business validations.

The business rules defined by the Exchange will be captured in the iLog rules engine and will be applied on the fly after the data validations are successfully passed.

5. If a record fails validation, the validation process will continue to check all remaining records, consolidate the other error messages (if any) and send a notification email to the Exchange with the complete list of error messages.

6. If no validation failures occur, the XML file is sent to a web service to transform it into POJO objects.

7. The data retrieved from the POJO is persisted into the data base using Spring and JPA (Java Persistence API)

5. Files will not be partially accepted and processed. If a single record fails any validation the

entire record will be failed. The file will be returned to the Department of Health for correction and resubmission. An email notification will be created and sent to the Exchange email address to alert them of the failure. All validations will be checked before the file is returned to the Exchange.

6. A manual reconciliation will be conducted after the file load to ensure that all records in the

CHIP Template were successfully loaded into the Exchange. 7. The initial load of CHIP plans will be received prior to implementation of the Exchange.

There is no limit on the frequency of updates. Updates and changes will come as full replacement files from the Exchange via the CHIP Template.

http://www.csc.com/


September 25, 2012

8. The Quality data on CHIP plans is submitted to the DOH Quality Assurance Reporting

Requirements (QARR) system. A process will be created to allow the Exchange to receive the quality data via QARR. The quality data will be reviewed and approved by the Exchange before the plan record is pushed to the Exchange. The existing quality data will be used for implementation of the Exchange. Going forward, this process will be an annual load. This data will be stored within the PLAN QUALITY DTL table within the Exchange. Refer to the section in this document on Quality data.

9. The Provider Network data for CHIP plans is submitted to DOH Provider Network Data

System (PNDS). A process will be created to allow the Exchange to receive the provider network data via PNDS. The provider network data will be reviewed and approved by the Exchange before the plan record is pushed to the Exchange. There will be an initial load of data followed by updates received at specified intervals. This data will be stored within the PROVIDER NETWORK ANCILLIARY DTL and PROVIDER NETWORK PHYSICIAN DTL tables within the Exchange. Refer to the section in this document on Provider Network data.

10. Rates that apply to incomes less than 400%of FPL for CHIP plans are standard and apply to

all CHIP plans. Rates that apply to incomes greater than 400%of FPL are determined by the Issuer. The “Type of Subscriber” field is used determine the monthly premium amount owed. Once the 400% of FPL threshold is reached the “Type of Subscriber” field will not be needed. All CHIP rates are reviewed and approved by the Division of Financial Service (DFS), and this process is coordinated with the DOH Bureau of Child Health Plus Policy Unit. The rates for CHIP plans will be approved before the CHIP spreadsheet is sent to the Exchange. The rate data will be stored in the CHIP PREMIUM DTL table within the Exchange.

11. There are no metal levels associated with CHIP. Each CHIP plan offered will contain the

standard set of benefits. This data will be stored in the PLAN BENEFIT SERVICES REF table within the Exchange.

12. When an individual enters his or her information on the Exchange, the enrollment and

eligibility process will use the MAGI rules to determine eligibility for various government programs. If the individual is determined to be eligible for CHIP, a list of all available CHIP plans will be returned to them via the plan selection feature. This rate, benefit and quality data is pulled from the above mentioned tables and is displayed to assist the member with their plan choice. The provider network data is available for searches based on specific criteria entered.

http://www.csc.com/


September 25, 2012

5.1.3.2 Receipt of Medicaid Managed Care (MMC) Plan Data

Families and individuals may be eligible for Medicaid based on income and family size. When eligibility is established, the covered individuals must enroll in a Medicaid Managed Care (MMC) plan. The list of available Medicaid Managed Care plans will be displayed in the plan selection results on the Exchange. The benefit structure is standard among all MMC plans and benefit changes only occur when mandated by law. 1. The Department of Managed Care within the Department of Health manages the MMC

plans. This Department will continue to be responsible for collecting the required plan data for MMC plans that will be offered on the Exchange.

2. The Exchange created an excel spreadsheet for all data elements that will be required to build a complete MMC plan record for the Exchange web portal (MMC Template). The MMC template contains the same fields as the CHIP Template. See Appendix C: The CHIP / MMC Template. The data in the MMC Template will be passed to the Exchange via email.

3. When the email is received, the Exchange will upload the data to a common location (sFTP

server). 4. When the MMC Plans are received the following steps are taken:

1. The flat file is received via FTP 2. The BPEL picks up the file and sends it to Informatica 3. Informatica converts the data and generates the XML file 4. The XML is sent to a validation web service to perform data and business validations.





5. Files will not be partially accepted and processed. If a single record fails any validation the

entire record will be failed. The file will be returned to the Exchange for correction and resubmission. An email notification will be created and sent to the Exchange email address to alert them of the failure. All validations will be checked before the file is returned tothe Exchange.

6. A manual reconciliation will be conducted after the file load to ensure that all records in the

MMC Template were successfully loaded into the Exchange. 7. The initial load of MMC plans will be received prior to implementation of the Exchange.

There is no limit on the frequency of updates. Updates and changes will come as full replacement files from the Exchange via the MMC Template.

http://www.csc.com/


September 25, 2012

8. The Quality data on MMC plans is submitted to the DOH Quality Assurance Reporting

Requirements (QARR) system. A process will be created to allow the Exchange to receive the quality data via QARR. The quality data will be reviewed and approved by the Exchange before the plan record is pushed to the Exchange. The existing quality data will be used for implementation of the Exchange. Going forward, it will be an annual load. This data will be stored within the PLAN QUALITY DTL table within the Exchange.

9. The Provider Network data for MMC plans is submitted to DOH Provider Network Data

System (PNDS). A process will be created to allow the Exchange to receive the provider network data via PNDS. The provider network data will be reviewed and approved by the Department of Managed Care before the plan record is pushed to the Exchange. There will be an initial load of data followed by updates received at specified intervals. This data will be stored within the PROVIDER NETWORK ANCILLIARY DTL and PROVIDER NETWORK PHYSICIAN DTL tables within the Exchange.

10. There are no rates applicable to Medicaid Managed Care plans. 11. There are no metal levels associated with MMC plan. Each MMC plan offered will contain

the standard set of benefits. This data will be stored in the PLAN BENEFIT SERVICES REF table within the Exchange.

12. When an individual enters his or her information on the Exchange, the enrollment and

eligibility process will use the following general rules:

If eligibility is based on MAGI rules, the member needs to enroll in an MMC plan. The available plans will be presented in the plan selection results and the member will choose one. An 834 enrollment transaction will be created and sent to that MMC plan.

If eligibility is based on non-MAGI rules, the member will be referred to their local Dept of Social Services for enrollment assistance.

13. For the first rule above, a list of all available MMC plans will be returned to them via the plan

selection feature. This rate, benefit and quality data is pulled from the above mentioned tables and is displayed to assist the member with their plan choice. The provider network data is available for searches based on specific criteria entered.

http://www.csc.com/


September 25, 2012

5.1.3.3 Main Event Diagram for Government Health Programs

DOH will provide Medicaid and CHIP data to the Exchange and the flow is illustrated in the following diagram:

Figure 3: Medicaid & CHIP Flow

http://www.csc.com/


September 25, 2012

5.1.4 Receipt of Quality Data via QARR

Quality reviews of plan data for all plan types (QHP, Medicaid, and CHIP) are performed by the legacy Department of Health system called the Quality Assurance Reporting Requirements (QARR). The quality data will be received from QARR via spreadsheet, sent to the Exchange, and loaded into the Exchange portal. When the QARR data are received, the following steps are taken:

1. The flat file is received via FTP 2. The BPEL picks up the file and sends it to Informatica 3. Informatica converts the data and generates the XML file 4. The XML is sent to a validation web service to perform data and business validations.





Files will not be partially accepted and processed. If a single record fails any validation the entire record will be failed. The file will be returned to the Exchange for correction and resubmission. An email notification will be created and sent to the Exchange email address to alert them of the failure. All validations will be checked before the file is returned tothe Exchange.

5.1.4.1 Event Diagram for Quality Data

The plan management team will be the point of contact for Quality data. QARR will provide Quality data to the Exchange and the flow is illustrated in the following diagram:

http://www.csc.com/


September 25, 2012

Figure 4: Quality Data Flow

5.1.5 Receipt of Provider Network Data from DOH PNDS

The Exchange must ensure that the provider networks for all plans (QHP, Medicaid, and CHIP) meets provider network adequacy standards set forth in the federal regulations. The following steps will achieve these requirements.

1. The current Department of Health Provider Network Data System (PNDS) maintains all

required provider data. This system is a legacy system and will be enhanced in order to meet the needs of the Exchange.

2. The Issuers will take the following steps to submit their provider network data.

1. Issuer logs onto the DOH PNDS System and follows template to enter Provider Network Data.

2. Data is categorized as Provider Data (physicians and smaller providers) and Ancillary Data (hospital, nursing homes, clinics etc).

3. Format for the data elements is defined in the PNDS Data Dictionary. 4. Provider Network Data is submitted. 5. The Exchange receives data and performs the Network Adequacy test. 6. If test fails, the Exchange will communicate with the Issuer. 7. If test passes, data is available for use on the Exchange.

3. The data is pulled from PNDS and the following tables are loaded:

· PROVIDER NETWORK ANCILLARY DTL TABLE · PROVIDER NETWORK PHYSICIAN DTL TABLE

4. No validation is performed on the data pulled from PNDS and the data will be loaded as it is

received. The PNDS submission instructions must alert the Issuers to use the new Issuer Plan ID on their PNDS submission. The Exchange will use this ID to merge the provider network data with the plan submission data from SERFF.

http://www.csc.com/


September 25, 2012

5.1.5.1 Event Diagram for Provider Network Data

PNDS will provide Provider Network data to the Exchange and the flow is as follows:

Figure 5: Provider Network Data Flow

http://www.csc.com/


September 25, 2012

5.1.6 Plan Management Entity Relationship Diagram

The entity relationship diagram below depicts the data tables that store plan data and their relationships.

Figure 6: Plan Management ERD

http://www.csc.com/


September 25, 2012

5.1.7 QHP Recertification, Decertification and Appeals

The recertification process will take effect by September 1 of each year prior to the Plan Year. For example, recertification will take place by September 1, 2014 for Plan Year 2015. The process for certification will be similar to the process for recertification. In the event that a QHP is decertified, either voluntarily (at the Issuer’s request) or involuntarily (at the Exchange’s request), appropriate measures are taken to notify the Issuer. The Issuer is then removed from the NY-HX system per Exchange instructions. In some cases a QHP may be suspended, allowing the QHP to take corrective measures. For example, suspension may be required during the appeal of a decertification. A process will be in place to suspend new enrollment into a plan while the issue is being resolved. In the event a suspension is revoked, a process will be in place to remove the restriction and once again allow new enrollments into the plan. Voluntary requests for decertification of a plan will be submitted by the Issuer via SERFF. Involuntary Decertification actions will be initiated by the Exchange. A process will be in place to alert existing members of the decertified so that they can enroll in new plans.

http://www.csc.com/


September 25, 2012

5.2 System Requirements

The NY-HX Plan Management system requires the following system components and interfaces:

SERFF

An accessible web service to transmit or submit data.

A portal for the Issuers and Exchange administrators to allow data validation.

File import services for MMC and CHIP plans

An interface for Provider Network Data Services

An interface for QARR data For further details refer to the Infrastructure and System Design Documents. Users interacting with the Plan Management area of the NY HX system will include:

NY-HX Exchange Administrators

NY-HX Exchange Plan Management staff

Issuers

Regulators Other business areas interacting with the Plan Management area of the NY-HX system will include:

NY-HX Eligibility & Enrollment

NY-HX Customer Service

5.3 User Stories Summary

The Agile software development methodology (SDLC) has been applied to the NY-HX project. User stories, which are elements of the Agile approach, have been prepared to document the business requirements articulated in the sections above. These user stories have been loaded into the requirements management system (the Rational product suite) to form the basis of the project’s plan management requirements traceability matrix. Please refer to Appendix A: Rational Requirements Composer User Stories Report

http://www.csc.com/


September 25, 2012

6 Glossary

Business Requirement (BR) A BR is a statement of the functions needed in order to accomplish the business objectives. It is the highest level of requirement, developed through the dictation of policy and process by the business owner. Business Rule (RU) An RU is a statement that defines or constrains some aspect of the business. It is intended to assert business structure, or to control or influence the behavior of the business. The RUs that concern the project are atomic in that they cannot be further decomposed and they are not process-dependent, so that they apply at all times. Business rules typically fall into one of five categories: terms, facts, derivations, assertions or action enablers. Functional Requirement (FR) An FR is a statement of an action or expectation of what the system will take or do. It is measured by concrete means like data values, decision making logic and algorithms. Nonfunctional Requirement (NR) An NR is a low-level requirement that focuses on the specific characteristics that must be addressed in order to be acceptable as an end product. NRs have a focus on messaging, security, and system interaction. Scenario A scenario is a sequence of steps taken to complete a user requirement, similar to a use case. User Requirement (UR) A UR is a statement of what users need to accomplish. It is a mid-level requirement describing specific operations for a user (e.g., a business user, system administrator, or the system itself). They are usually written in the user’s language and define what the user expects from the end product.

http://www.csc.com/


September 25, 2012

7 Acronyms

ACRONYM Literal Translation

ARS Acceptable Risk Safeguards

BR Business Requirement

DOH

FR

Department of Health

Functional Requirement

BHP Basic Health Plan

CCIIO Center for Consumer Information and Insurance Oversight

CHIP Children's Health Insurance Program

CHP Child Health Plus

CMS Centers for Medicare and Medicaid Services

DFS Department of Financial Services aka NYSID ( New York State Insurance Department) and NYSDOI (New York State Department of Insurance)

DHHS U.S. Department of Health and Human Services

DOH Department of Health (State of New York)

DSS Department of Social Services

EE Eligibility Determination & Enrollment

EHR Electronic Health Record

EI Early Innovator

ELC Exchange Life Cycle

EMC Electronic Media Claims

ESB Enterprise Service Bus

ESD Enterprise System Development

FTP File Transfer Protocol

GUI Graphical User Interface

HA/DR High Availability/Disaster Recovery (Red Hat)

HBE Health Benefits Exchange

HIE Health Information Exchange

HIPAA Health Insurance Portability and Accountability Act

HIT Health Information Technology

HITECH Health Information Technology for Economic and Clinical Health

HIX Health Insurance Exchange

IAP Insurance Affordability Program

http://www.csc.com/


September 25, 2012

ICD Interface Control Documents

IP Internet Protocol

IT Information Technology

JAD Joint Application Design

MMIS Medicaid Management Information System

N/A Not Applicable

NAIC National Association of Insurance Commissioners

NY New York

NY-HX New York State Health Benefit Exchange

NYC New York City

NYS New York State

NYS-MMIS New York State Medicaid Management Information System

PHSP Prepaid Health Service Plan

PNDS Provider Network Data System

QARR Quality Assurance Reporting Requirements

QHP Qualified Health Plan

SERFF System for Electronic Rate and Form Filing

SQL Structured Query Language

UI User Interface

WSDL Web Services Description/Definition Language

XSD Xml Schema Definition

http://www.csc.com/


September 25, 2012

Appendix A Rational Requirements Composer Epic User Stories Report

Listed below are the epic user stories that describe the work that the Plan Management track has undertaken to do. Three epics identified as numbers 7439, 7440 and 7441 represent the work that the Exchange Regulators will perform associated with the QHP certification process. The remaining epics represent the work that the Exchange Administrators will perform to make the plan available in the Exchange. Plan Management

ID Short Name Primary Text Category Title 6907 PM.B.1Annual Load

MMC "As an Exchange Administrator, I want to create a process to receive the Medicaid Managed Care (MMC) Plan data from the Department of Health so I can make the plans available on the Exchange."

Annual Load of Medicaid Managed Care (MMC) Plan Data

Annual Plan Load - 1. Annual Load of Medicaid Managed Care (MMC) Plan Data

6908 PM.B.2Annual Load CHIP

"As an Exchange Administrator, I want to create a process to receive the Child Health Insurance Plan (CHIP) data from the Department of Health so I can make the plans available on the Exchange."

Annual Load of Child Health Insurance Plan (CHIP) Data

Annual Plan Load - 2. Annual Load of Child Health Insurance Plan (CHIP) Data

6909 PM.B.3Annual Load BHP

"As an Exchange Administrator, I want to create a process to receive the Basic Health Plan (BHP) data from the Department of Health so I can make the plans available on the Exchange."

Annual Load of Basic Health Plan (BHP) Data

Annual Plan Load - 3. Annual Load of Basic Health Plan (BHP) Data

6910 PM.B.4Annual Load Multi

"As an Exchange Administrator, I want to create a process to receive the Multi-State Plan data from the Department of Health (or SERFF) so I can make the plans available on the Exchange."

Annual Load of Multi-State Plan Data

Annual Plan Load - 4. Annual Load of Multi-State Plan Data

http://www.csc.com/


September 25, 2012

6911 PM.C.1Pull Provider Network

"As an Exchange Administrator, I want to create a process to pull provider network data from the Department of Health PNDS so I can make the plan’s provider network available on the Exchange."

Pull Provider Network Data from the Provider Network Data System (PNDS)

Provider Network - 1. Pull Provider Network Data from the Provider Network Data System (PNDS)

6912 PM.C.2Pull Geo Axis "As an Exchange Administrator, I want to create a process to pull GEO Axis data from the Department of Health PNDS so I can return providers within a specific requested geographic location on the Exchange."

Pull GEO-Axis Data from the Provider Network Data System (PNDS)

Provider Network - 2. Pull GEO-Axis Data from the Provider Network Data System (PNDS)

6914 PM.C.3Process Provider Net Changes

"As an Exchange Administrator, I want to build a function to process changes to a plan’s s provider network data so I can ensure that the most current provider network data is available on the Exchange."

Process Changes to Provider Network Data

Provider Network - 3. Process Changes to Provider Network Data

6913 PM.C.4Store Provider Network

"As an Exchange Administrator, I want to create a process to store provider network data received from the Department of Health PNDS so I can associate the network providers with the correct plan on the Exchange."

Store Provider Network Data from the Provider Network Data System (PNDS)

Provider Network - 4. Store Provider Network Data from the Provider Network Data System (PNDS)

6915 PM.D.1Receive Quality Data

"As an Exchange Administrator, I want to create a process to receive plan quality data from the Department of Health QARR system so I can make the plan's quality data available on the Exchange."

Receive Quality Data from the Quality Assurance Reporting Requirements (QARR) System

Plan Quality - 1. Receive Quality Data from the Quality Assurance Reporting Requirements (QARR) System

http://www.csc.com/


September 25, 2012

6916 PM.D.2Store Quality Data

"As an Exchange Administrator, I want to create a process to store plan quality data received from the Department of Health QARR system so I can associate the quality data with the correct plan on the Exchange."

Store Quality Data from the Quality Assurance Reporting Requirements (QARR) System

Plan Quality - 2. Store Quality Data from the Quality Assurance Reporting Requirements (QARR) System

6917 PM.E.1Recertification "As an Exchange Administrator, I want to build a function to process recertification actions so I can make the new/updated plan available on the Exchange."

Process Recertification Actions

Operation Maintenance and Compliance Monitoring - 1. Process Recertification Actions

6918 PM.E.2DeCertification "As an Exchange Administrator, I want to build a function to process decertification actions so I can remove decertified plans from the Exchange."

Process Decertification Actions

Operation Maintenance and Compliance Monitoring - 2. Process Decertification Actions

6919 PM.E.3Decertification Appeal

"Note: This process will be done by DFS/DOH.As an Exchange Administrator; I want to create a process to respond to an appeal of a decertification decision so I can respond to and adjudicate an Issuer’s request for an appeal."

Process Appeal of Decertification Decision

Operation Maintenance and Compliance Monitoring - 3. Process Appeal of Decertification Decision

6920 PM.E.4Suspend Enrollment

"As an Exchange Administrator, I want to build a function to suspend new enrollment into a plan so the plan is not available for new enrollment on the Exchange."

Suspend New Enrollment

Operation Maintenance and Compliance Monitoring - 4. Suspend New Enrollment

6921 PM.E.5Lift Suspension "As an Exchange Administrator, I want to build a function to remove the suspension on new enrollments into a plan so I can make the plan available on the Exchange for new enrollment."

Lift Suspension on New Enrollment

Operation Maintenance and Compliance Monitoring - 5. Lift Suspension on New Enrollment

http://www.csc.com/


September 25, 2012

6922 PM.E.6Rate Change "As an Exchange Administrator, I want to build a function to process rate changes so I can make the appropriate rate available in the plan selection results on the Exchange."

Process Rate Change

Operation Maintenance and Compliance Monitoring - 6 Process Rate Change

6923 PM.E.7Benefit Change

"As an Exchange Administrator, I want to build a function to process benefit changes so I can make the appropriate benefits available in the plan selection results on the Exchange."

Process Benefit Change

Operation Maintenance and Compliance Monitoring - 7. Process Benefit Change

6924 PM.E.8Monitor Provider Network Changes

"As an Exchange Administrator, I want to create a process to monitor and assess changes to a plan's s provider network data so I can ensure that all network adequacy requirements are met."

Monitor and Assess Provider Network Changes

Operation Maintenance and Compliance Monitoring - 8. Monitor and Assess Provider Network Changes

6925 PM.F.1QHP Formulary "As an Exchange Operator, I want to receive the QHP plan's formulary URL via SERFF so I can display it as part of the plan data on the Exchange."

Accept QHP Plan Formulary URL via SERFF

Formulary - 1. Accept QHP Plan Formulary URL via SERFF

6926 PM.F.2CHIP Formulary

"As an Exchange Operator, I want to receive the CHIP plan's formulary URL via the CHIP template so I can display it as part of the plan data on the Exchange."

Accept CHIP Plan Formulary URL via CHIP Template

Formulary - 2 Accept CHIP Plan Formulary URL via CHIP Template

6927 PM.F.3MMC Formulary

"As an Exchange Operator, I want to receive the MMC plan's formulary URL via the Medicaid template so I can display it as part of the plan data on the Exchange."

Accept MMC Plan Formulary URL via Medicaid Template

Formulary - 3. Accept MMC Plan Formulary URL via Medicaid Template

http://www.csc.com/


September 25, 2012

6928 PM.F.4BHPFormulary "As an Exchange Operator, I want to receive the BHP plan's formulary URL via the Medicaid template so I can display it as part of the plan data on the Exchange."

Accept BHP Plan Formulary URL via Medicaid Template

Formulary - 4. Accept BHP Plan Formulary URL via Medicaid Template

6929 PM.G.1Design PM System

"As an Exchange Administrator, I want to design a Plan Management System to support the collection and storage of plan data so I can make plans available on the Exchange."

Design Plan Management System

Initial NY-HX Load - 1. Design Plan Management System

6930 PM.G.2PM Integration "As an Exchange Administrator, I want to ensure that Plan Management integrates with other Exchange Business Areas so the data flow within the Exchange is accurate and meets consumer needs. "

Integrate Plan Management with other Exchange Business Areas

Initial NY-HX Load - 2.Integrate Plan Management with Other Exchange Business Areas

6931 PM.G.3Initial Load QHP

"As an Exchange Administrator, I want to create a process to receive the QHP data from SERFF and move it from the UAT tables to Production so I can make the plans available on the Exchange."

Initial Load of QHP Data from SERFF moved from UAT Tables to Production

Initial NY-HX Load - 3. Initial Load of QHP Data from SERFF moved from UAT Tables to Production

6932 PM.G.4Initial Load MMC

"As an Exchange Administrator, I want to create a process to move the Medicaid Managed Care (MMC) Plan data from the UAT Table to Production so I can make the plans available on the Exchange."

Initial Load of Medicaid Managed Care (MMC) Plan Data moved from UAT Tables to Production

Initial NY-HX Load - 4. Initial Load of Medicaid Managed Care (MMC) Plan Data moved from UAT Tables to Production

http://www.csc.com/


September 25, 2012

6933 PM.G.5Initial Load CHIP

"As an Exchange Administrator, I want to create a process to move the Child Health Insurance Plan (CHIP) data from the UAT Tables to Production so I can make the plans available on the Exchange. "

Initial Load of Child Health Insurance Plan (CHIP) Data moved from UAT Tables to Production

Initial NY-HX Load - 5. Initial Load of Child Health Insurance Plan (CHIP) Data moved from UAT Tables to Production

6934 PM.G.6Initial Load BHP

"As an Exchange Administrator, I want to create a process to move the Basic Health Plan (BHP) data from the UAT Tables to Production so I can make the plans available on the Exchange."

Initial Load of Basic Health Plan (BHP) Data moved from UAT Tables to Production

Initial NY-HX Load - 6. Initial Load of Basic Health Plan (BHP) Data moved from UAT Tables to Production

6935 PM.G.7Initial Load Provider

"As an Exchange Administrator, I want to create a process to move the Provider Network data from the UAT Tables to Production so I can make the Provider Network data available on the Exchange. "

Initial Load of Provider Network Data moved from UAT Tables to Production

Initial NY-HX Load - 7. Initial Load of Provider Network Data moved from UAT Tables to Production

6936 PM.G.8Initial Load Quality

"As an Exchange Administrator, I want to create a process to move the Quality data from the UAT Tables to Production so I can make the plan's Quality data available on the Exchange. "

Initial Load of Quality Data moved from UAT Tables to Production

Initial NY-HX Load - 8. Initial Load of Quality Data moved from UAT Tables to Production

7439 PM.A.1Plans Solicitation

"There is No RRC Story associated with this Sub-category. This work is being done by DOH. "

State Solicitations for Plans

Plan Certification - 1. State Solicitations for Plans

7440 PM.A.2Support QHP Certification Process

"There is No RRC Story associated with this Sub-category. This work is being done by DFS/DOH."

Provide Support for the QHP Certification Process

Plan Certification - 2. Provide Support for the QHP Certification Process

7441 PM.A.3Ensure Ongoing QHP Comp

"There is No RRC Story associated with this Sub-category. This work is being done by DFS/DOH."

Ensure Ongoing QHP Compliance with QHP Certification

Plan Certification - 3. Ensure Ongoing QHP Compliance with QHP Certification

http://www.csc.com/


September 25, 2012

8052 PM.B.5.Annual Load Quality

"As an Exchange Administrator, I want to create a process to receive the Quality data from the Department of Health (QARR) so I can make the plans updated quality data available on the Exchange."

Annual Load of Quality Data

Annual Plan Load - 5. Annual Load of Quality Data

8067 PM.G.9Initial Load Multi State

"As an Exchange Administrator, I want to create a process to move the Multi-State Plan data from the UAT Tables to Production so I can make the plans available on the Exchange."

Initial Load of Multi-State Plans Data moved from UAT Tables to Production

Initial NY-HX Load - 9 - Initial Load of Multi-State Plans Data moved from UAT Tables to Production

http://www.csc.com/


September 25, 2012

Appendix B The New York Template Template is under design

http://www.csc.com/


September 25, 2012

Appendix C The CHIP / MMC Template Template is under design

http://www.csc.com/