Design Review Evidence Matrix #09 - Silver State Health Insurance ...

Systems Design document artifacts for the HCR EE will be made available in the CALT Exchange Community forNevada upon final approval end of November 2012.Database Design DocumentThe HCR EE does not employ a relational database in its design. It utilizes the IBM Websphere OperationalDecision Manager (WODM V8) to store and operate on the business rules. Specifics regarding the WODM will beprovided in the HCR EE Systems Design document that will be available end of November 2012.Interface Control DocumentThe HCR EE provides interfaces to the Exchange, the FDSH, and to legacy public assistance systems such asNOMADS, AMPS, Access NV. Specifics regarding these interfaces will be provided in the HCR EE Systems Designdocument that will be available end of November 2012.Data Management PlanThe Data Management Plan for the HCR EE will be covered in separate documents, the System Design andConfiguration Management plans scheduled for completion in November 2012 and Implementation Plan that willbe completed in March 2013.Test PlanThe Test Management Plan for the HCR EE is expected to be complete by January 2013.Implementation PlanThe Implementation Plan for the HCR EE is expected to be completed by March 2013.The BOS and HCR EE is being developed specifically with the flexibility to meet the needs of the ACA, whileproviding the option for Nevada to incorporate state healthcare programs into the exchange or use a dispersedmodel for case management of government programs. The BOS and HCR EE systems include all functions requiredfor both the individual and family and the Small Business Health Options Program (SHOP) Exchanges. The diagrambelow depicts the key components of the BOS/HCR EE solution.Figure 1 – BOS Key Components

Provide audit trail of backup/restore processesProduction EnvironmentProduction environment for Xerox application will be in an existing HIX environment in Pittsburg Data Center. Itwill run the followingVirtualized – Cloud infrastructure (Intel based IaaS). Cognos App and Web – BI Reports (Standard and ad-hoc) Pervasive Data Integrator – ETL tool to transform data from Staging to Data Warehouse Control-M – Batch job schedulerPhysical – Intel based dual 8-core or equivalent Oracle 11g Database with 2 node RAC cluster - Data WarehouseNon-Production EnvironmentNon-Production environment for Xerox application will in an existing ESX environment in Pittsburg Data Center.Non-Production will run the followingVirtualized- Intel based dual quad core or equivalent Cognos App and Web – BI Reports (Standard and ad-hoc) Pervasive Data Integrator – ETL tool to transform data from Staging to Data Warehouse Control-M – Batch job schedulerPhysical – Intel based dual quad core CPUs or equivalent Oracle 11g Database with 2 node RAC cluster - Data WarehouseDisaster Recovery Disaster Recovery for production environment is installed in Tarrytown Data Center and it is normally notactive. All OS images are stored on SAN and in event the disaster event has happened and primaryproduction site is inoperable this environment will be brought up. During normal period DR hardware isdormant and in “cold” state (with 72hrs RTO requirements we can recover from tape and servers don’tneed to be up and running). Disaster Recovery for non-production environment will be installed in Atlanta Data Center and it isnormally not active.StorageData volume assumed: 3TB production and 3 TB non-production at the end of Y3Network Components Xerox will provision six T1 circuits to State of Nevada SaaS Exchange will be connected to Xerox’s MPLS using a DS3 circuit. Xerox will be connected by a DS3redundant circuit. Xerox will extend MPLS to the Project Office. The same MPLS Cloud has one node in Dallas Data Centerwhere telephony will be setupNetwork Bandwidth 4 T1-s for data traffic in the project office 5 T1-s for VoIP in the Project Office 5 T1-s for VoIP in the Primary Data Center 6 T1-s PtP to NV State 4 T1-s to Choice 4 T1 going to MPLS for data for Las Vegas 4 Voice PRI’s for Las Vegas

EnvironmentsPlease refer to the attached document for a detailed overview for the environmentsNV Saas Exchange -Reportign & DW.pdfAll bandwidth quantities are in T1-equivalent units, which means we won’t necessarily have T1 if we already havefrac-T3 line (in that case, we’ll just add trunks to increase the bandwidth where needed).Network DiagramThe following represent the second major technical architecture for the BOS where the major elements whichmake up the public exchange are implemented, ranging from an individual to an employer/employee SHOP.The BOS uses a modular, Service-oriented Architecture (SOA) approach. This facilitates integration with externalentities using an ESB operating within an event or batch-driven paradigm. The use of both WSDL Web services andan Enterprise Service Bus (ESB) enables us to easily integrate new capabilities and/or share our capabilities withother vendor or state systems. The use of layers, clear boundaries, and well-defined interfaces in the systemdesign allows quick customization and configuration.Hardware ArchitectureThe BOS is deployed via Software as a Service (SaaS), employing state-of-the-art servers located in redundant datacenters within the continental United States. The hosted solution is purposely built for high availability, utilizingthe concept of the virtual servers built on a Dell computer platform. The solution serving the Exchange is broken

into six environments; Development, Quality Assurance, Training, User Acceptance Testing, System Test, andProduction; each with their own computer and storage resources.The Development Environment serving the Exchange is where the actual coding work by the developers isperformed. This environment represents the beginning of the multiple environments used during the softwaredevelopment life cycle. Within this environment, developers create new software or modify existing software tofix errors or apply enhancements. This environment is comprised of 50 virtual servers which run on 6 physical hostservers. It will utilize the same web and application load balancing technology that powers the productionenvironment and will also use Microsoft Windows Clustering for SQL that will run in an active/passive 2 nodecluster. The Development environment will share physical compute and storage with User Acceptance Testing andthe Training Environment.The Quality Assurance Environment serving the Exchange is where quality assurance testers conduct moreexhaustive tests using manual and automated scripts against the new/revised code. System-wide regressiontesting is performed using automated testing tools. These tests exercise the new or revised features against theirconditions of acceptance, while regression testing ensures against the introduction of new bugs or loss of existingfunctionality. This environment is also used to validate the successful interaction with external systems. Any codethat fails is sent back to the Development environment with detailed analysis of the errors, including how theerrors were created and alternative solutions. This environment is comprised of 50 virtual servers which run on 6physical host servers. It will utilize the same web and application load balancing technology that powers theproduction environment and will also use Microsoft Windows Clustering for SQL that will run in an active/passive2 node cluster. The Development environment will share physical compute and storage with User AcceptanceTesting and the Training Environment.The User Acceptance Testing Environment serving the Exchange contains software ready for testing by the targetusers. While the quality assurance testing process employs the same conditions of acceptance tests conducted byusers and includes exhaustive, comprehensive tests, it is possible that user testing may reveal errors notpreviously found. This environment is also comprised of 50 virtual servers which run on 6 physical host servers. Itwill utilize the same web and application load balancing technology that powers the production environment andwill also use Microsoft Windows Clustering for SQL that will run in an active/passive 2 node cluster. The UserAcceptance Testing environment will share physical computer and storage with Development and the TrainingEnvironment.The Training Environment serving the Exchange accesses either the User Testing environment or the System Testenvironment as a platform to conduct training that does not require access to live and sensitive production data.Our practice is to refresh the training environment on a nightly or weekly basis. This allows trainers and new usersto access a “sandbox” environment with no consequences if data is destroyed or configurations are mixed up. Thisenvironment is populated with test members and no real PHI or PII is ever used for training. This environment isalso comprised of 50 virtual servers which run on 6 physical host servers. It will utilize the same web andapplication load balancing technology that powers the production environment and will also use MicrosoftWindows Clustering for SQL that will run in an active/passive 2 node cluster. The Training Environment will sharephysical compute and storage with Development and the User Acceptance Testing Environment.The System Test Environment serving the Exchange is hosted as an exact replica of the Production environmentand is used for external testing with external components that will be prevalent for a State Exchange interactingwith federal and state systems. Full, round-trip messages are tested (such as state and federal systems) and aseries of automated tests determine if new interactions meet SLAs. Any code that fails is sent back to the QualityAssurance environment with detailed error analysis. Otherwise, it is marked as ready for publishing to theProduction environment. The actual publishing of code into the Production environment will comply with strictcontrols and within scheduled Production time frames. This environment is comprised of 60 virtual servers whichrun on 10 physical host servers. It will utilize the same web and application load balancing technology that powersthe production environment and will also use Microsoft Windows Clustering for SQL that will run in anactive/passive 2 node cluster. The System Test environment will share physical compute and storage with theproduction Environment; however, it will be run as a tier II environment which will release resources toproduction as needed.

The Production Environment contains all software and data that comprises the operational Exchange solution.Testing is never carried out in the production environment. This environment is comprised of 91 virtual serverswhich run on 10 physical host servers. It will utilize industry leading web and application load balancingtechnology and will also use Microsoft Windows Clustering for SQL that will run in an active/passive 2 nodecluster. Every piece of the solution suite will be built to N+1. When required, additional compute capacity can beadded to the solution, by adding additional servers to the compute stack and rebalancing the virtual servers.Network ArchitectureThe Exchange availability is provided through a secure, highly scalable, and fault-tolerant network infrastructureutilizing the concept of the virtual datacenter built on Dell computers, Cisco and Force10 Networking, and EMCstorage.At the foundation of the network layer is a pair of Cisco Nexus 7000 chassis switches providing a comprehensiveone-platform solution for the data center core. The Cisco Nexus 7000 series offers a variety of flexible features allbased around three primary principals: Infrastructure scalability, Operational continuity, and Transport flexibility.From the Nexus 7000 we’ll be connecting into a pair of Nexus 5000 switches to provide a fiber channel connectionpoint for the EMC VMAX 10K storage solution and then an FCoE bridge for the converged network compute stackthat will be directly connected to Nexus 7K via a pair per chassis Force10 XML 10GB switches. The network layerwill also utilize a pair of Cisco ASR 1002-X edge routers using eBGP with no less than two internet serviceproviders. ASR routers will secure the perimeter of the network with a pair of next generation firewalls such as thePalo Alto 5000 series or SonicWall Supermassive appliances. Directly behind the perimeter firewalls will be amanaged ISP solution from SecureWorks, before the traffic reaches the edge of the virtual datacenter which issecured by vShield edge devices configured in HA pairs. The web and application layers will be load balanced via apair of F5 Viprion 2400 chassis running local traffic management and application security modules.To manage remote partner connectively we’ll be utilizing a pair of Cisco ASA 5585-X firewall IPS devices to provideMPLS and VPN access points into the network.The storage solution is an EMC VMAX 10K using VG8 NAS gateways for file access and recover point appliances tokeep the primary and disaster recovery SAN environments in sync via a MPLS with VPN backup connection fortransport. The SAN will be networked to the Nexus 5K switching with 8 Gb/s fiber connections, with each enginehaving up to 16 connections to the switching fabric. The initial SAN configuration will have 50 TB of capacity,spread throughout three storage tiers (SSD, SAS, and SATA). The VMAX 10K platform can grow to a total of 4processor engines which will allow throughput growth as the platform expands. The platform can also support upto 1,080 drives which, depending on configuration, can equate to 1 to 1.5PB of capacity.Adequate Technology Infrastructure and Bandwidth - Eligibility EngineThe Department of Welfare and Supportive Services is responsible for Eligibility Engine deployment at the State Of Nevada.We are primarily implementing on an IBM PureFlex System. An IBM PureFlex System combines compute, storage, networking,virtualization and management into a single infrastructure system that is expert at sensing and anticipating resource needs tooptimize your infrastructure. A PureFlex System includes integrated patterns of expertise designed to automate and optimizethe deployment and maintenance of your workloads. Deployment expertise can accelerate your time to value up to 100 timesversus traditional systems. Consolidation and management expertise from thousands of successful data center optimizationsdrives automation to significantly reduce manual processes that consumes too many staff hours. Optimization expertise alsoallows your infrastructure to flex to address unexpected demands without requiring expensive surplus capacity.The system as ordered for this project includes: 1Gb and 10gb Ethernet interface8 gig fibre interfaces36 TB of raw spaceo Tiered to include, SSD, Fibre and Sata driveso Storage Systems intelligently move storage to the appropriate tier as determined by policy and systemsuseage.2 computing nodeso Each with 512 GB RAM and 32 IBM P7 CPU’s

Smart Cloud Softwareo To reduce provisioning time and ease managementThe system acquired will Support the following Environments Development (Dev)Site integration and test (Sit)User acceptance and Test (Uat)Pre-Production (pprod)ProductionSoftware AIX 7.x IBM WebSphere Process Server 8.0 IBM WebSphere Application Server 8.0 IBM WebSphere MQ 7.5 IBM DB2 9.6 IBM WebSphere Process Server 6.0 IBM WebSphere Application Server 6.0 IBM WebSphere Portal Server 6.0 Filenet Various versions Novell Access Manager 3.2 Novell IDM 4.x Symantec Scan Engine 11.2 Novell E directory 8.x VMware Vsphere Enterprise Plus VMware ESX 5.xLogical Architecture

Deployment ArchitectureData center location is State Data Center in Carson CityIT Support Staff Located In Carson CityAll environments will be maintained in this locationDisaster Recovery will be In Las Vegas at Switch Networks Co-Location FacilityExtensibility, Scalability and Availability All Components are horizontally scalable. Two-node Clusters will be used when at all possible with the possibility to increasenode in the future Fail over – H/A at Carson City site through Software Clustering Load balancing – F5 BIGIP deployment Business continuity and disaster recovery – DR of servers in an alternate Data CenterBackup & Restore Management Establish Schedule: Implement backup and restore processes to maintain continuedavailability of mission critical data Initial backup and restore test Prepare system and the customer proprietary software for backup (agent install) Provide recommendations regarding backup and recovery procedures or processesthat can improve levels of protection, efficiencies, and cost reductions Perform complete weekly online backups on all systems per requirements Perform daily incremental online backups on all systems per requirements Restore volume/dataset per request of Customer Monitor backup/restore process Verify that the backup/restore has been completed successfully/failed Provide audit trail of backup/restore processes

Disaster RecoveryNetwork ComponentsNetwork BandwidthDisaster Recover will be install in Las Vegaso Will consistent of Nearly Identical PUREFLEX hardwareo Carson and Las Vegas IBMV7000 storage arrays to be kept in sync with IBM’sDisk Mirror Technologyo This is a cold siteMost communications will be kept internal within the PRUFLEX hardwareLAN supported by Enterprise Class Cisco 65xx series equipment provided and maintained byEnterprise information Technology SupportFirewall are Cisco Enterprise pix XXX series and maintained by Enterprise information TechnologySupport250 MB Ethernet Link to Internet (2 separate ISP’s)26 office connections vary from 1.5mbs to 250mbs dependent on officeFinal physical Network infrastructure diagramsDESCRIPTIONProposed Bos\Exchange to Eligibility EngineBOS\EXCHANGEMPLS CircuitINTERNETState FirewallDWSS Access GatewaysDWSS FirewallELEGIBILITY ENGINEPublicState EmployeeOperations and maintenance (O&M) manualso Are currently being developed based on final implementation specificsStress Test resultsoTBD after developments ends. DWSS has procured tools and Delloite is required to write andperform stress test at the appropriate points in the development lifecycle. Once this occurs DWSSwill update this document with the results.9.3 IV&V, Quality Management and Test Procedures(the language in this section is applicable for the DWSS HCR EE Project)

IV&VAttached are IV&V Documents (the HCR-EE WP Final 09_28_2012 is in CALT (doc 14043).HCR-EE Quality HCR-EE VVP FinalAssurance Plan 09_10_2012 09_28_2012.docFinal.docNevada HCR-EE IVV Nevada HCR-EE IVV NevadaIVV Communication Plan IVV 09_ Risk 13_2012 Management Final.doc HCR-EE-IVV-IVV Plan Final 09_12_12.doc Project Health Check DED V1.0.docxNevada recognizes the importance of obtaining an independent perspective on the Health Care Reform EligibilityEngine (HCR-EE) and Business Operations Solution (BOS) projects. In February 2012, the Nevada Department ofHealth and Human Services released a Request for Proposal (RFP 1956) to obtain Independent Verification andValidation (IV&V) services for the HCR-EE project. This procurement effort resulted in the selection of PublicConsulting Group (PCG) as Nevada’s IV&V Vendor for the HCR-EE project that was approved by the Board ofExaminers in June 2012. In support of the Centers for Medicare and Medicaid Services (CMS) encouragement toview the HCR-EE project and the BOS project as a single endeavor, RFP 1956 was leveraged to secure PCG as theIV&V Vendor for the BOS project, which was approved by the Board of Examiners in August 2012. The IV&Vactivities commenced with the selection of the Design, Development and Implementation (DD&I) vendors and arescheduled to occur through January 2014. The primary goals of Nevada’s IV&V effort are to:Provide an independent perspective on project activitiesValidate the project’s deliverables and processes to ensure compliance with defined requirementsFacilitate early detection and correction of variancesSupport project life cycle processes to ensure compliance with regulatory, performance, schedule, and budgetrequirementsEnhance management insight into project processes and identified risksEnsure that the project can be completed within the established schedule and budgetThe purpose of IV&V is to help the State build quality into the system during the project life cycle by providing anobjective assessment of the project’s products and processes. This assessment demonstrates whether therequirements are correct, complete, accurate, consistent, and testable. IV&V processes also determine whetherthe development products of a deliverable conform to the requirements of that activity and whether the productsatisfies its intended use and user needs. Determination includes the assessment, analysis, evaluation, review,inspection of a deliverable. PCG’s IV&V activities comply with the Institute for Electrical and Electronics Engineers(IEEE) Standard 1012-2012 for system and software verification and validation and applied in accordance with IEEE12207-2008, Software Life Cycle Processes. As required, PCG developed a Verification and Validation Plan (VVP)to outline the methodology for conducting independent assessments and providing quality assurance services.The VVP identifies the scope, methodology, approach and deliverables of the IV&V project. It also identifies thespecific tasks and attributes related to completing the IV&V activities, which are captured in the table below.# IV&V Activity Tasks / Attributes1 IV&V of Project Management Federal reference2 IV&V of Contractor’s Project Management3 IV&V of General Activities (pertinent to all assessments)4 IV&V of Requirements Management5 IV&V of Quality Management6 IV&V of Operating Environment7 IV&V of Design and Development NV RFP Reference Methods and Criteria Inputs Outputs/Deliverable Project Phase(s) Resources Applicable Standards

# IV&V Activity Tasks / Attributes8 IV&V of Testing Risks / Assumptions / Constraints9 IV&V of Data ManagementAs an outcome of the independent assessments, the IV&V Project Team will prepare the following deliverables:Monthly Project Status Reports – The Monthly IV&V Status report includes sections that provide a high-levelsummary of the IV&V team’s activities such as findings, high-level risks, and general activity status. Includedwith the Monthly Status report is the IV&V Assessment Workbook / Risk Register.IV&V Assessment Workbook / Risk Register – The IV&V Assessment Workbook / Risk Register is preparedmonthly or as needed, to report findings, deviations, and errors found in documentation, deliverables,products, or processes reviewed by the IV&V team. The table below provides a description of the informationprovided in the workbook.Quality ManagementThere are three primary components of an effective quality management program. The first is quality planning todrive the execution of consistent and well-define quality management activities. The fruition of our team’s overallquality planning effort is captured via this plan. The second area of focus is quality assurance which refers to theplanned and systematic activities implemented to ensure that requirements for a product or service will befulfilled. Performing quality assurance requires standards-based measurement and monitoring of developmentprocesses along with an associated feedback loop that confers error prevention. The third area of focus, qualitycontrol, takes a similar approach, but focuses exclusively on outputs.The Exchange’s approach to quality management provides multiple management controls to drive thedevelopment of a Solution that is “fit for purpose" and “right the first time."The Exchange will follow industry leading practices (e.g., the Project Management Body of Knowledge) to facilitatethe quality management process. Our quality management lifecycle has three primary components which aredepicted below.Additional details can be found in the Exchange’s Project Management Plan, Quality Management Chapter(attached).12. Quality DeliverableManagement Plan 2012.10.02.pdfManagement Plan 2012 10 09 V3.pdfTestingThe Exchange is in the process of completing detailed requirements for the BOS. In addition to this, the Exchangeis in the process of developing an integrated Test Management Plan for the BOS. Once this plan has beendeveloped, it will be shared with CMS via CALT.

9.4 Project Management: Assessment/Control/Risk Management(the language in this section is also suitable for the DWSS HCR EE Project)The Exchange’s Project Management Methodology is based on PMBOK guidelines and the Institute of Electricaland Electronics Engineers (IEEE) Standards.The Exchange provides a deliberate and proactive process for identifying potential risks and assessing theprobability and potential consequences of identified risks. We follow a thorough risk response planning processthat identifies mitigation strategies and the criteria for early detection of risk, ensuring that we can rapidlyimplement risk mitigation actions and minimize negative project impacts. Risk monitoring and control include thetracking of previously identified risks, triggers, response plans, and mitigation actions. It also includes continualmonitoring for the identification of new and changing risksThe Exchange’s risk management strategy includes the following primary processes:Risk identificationRisk assessmentRisk mitigation planningRisk mitigation implementationMonitoring and controlRisk Identification. The identification of project risks is a continual process that begins at the outset and continuesthroughout the life of the contract. The thoroughness with which risk identification is accomplished will determinethe effectiveness of the risk management process. The Exchange’s Risk Management team is composed of keystakeholders. The team focuses on identifying areas of risk, assigning responsibilities and actions, and reporting onrisk reduction efforts.Risk Assessment. Risk assessment, also referred to as risk analysis, is the process of quantifying and evaluatingidentified risks. The Exchange collects and categorizes potential risks to better understand the nature and sourceof each risk. We include an evaluation of stakeholder tolerance for the risk. Risks are categorized according to theprobability of their occurrence and the severity of the consequences should they occur. They are ranked as high,medium, or low risk. This approach allows the Exchange to quantify the risk level and to provide objectivity andfocus in mitigation activities.All risks are entered into the risk management list in the project repository in SharePoint. High-exposure risks areaddressed in the risk mitigation plan. Medium-exposure risks may be addressed with a risk mitigation plan,depending upon the characteristics of the individual risk. Low-exposure risks are not normally addressed in therisk mitigation plan. All previously identified risks are regularly reviewed, regardless of the assigned exposurerating, to determine the need to adjust project plans and activities. This methodology, in combination with themonitoring and control activities discussed below, represents the best balance between the costs and benefits ofrisk management.Risk Mitigation Planning. Because the effectiveness of the response directly affects whether the risk increases ordecreases, the Exchange ensures the risk response is appropriate to the category, probability, and impact of eachrisk. Risk responses generally fall into one of four categories: avoidance, mitigation, transference, or acceptance.The Exchange Risk Management Team works to prioritize risks to meet project objectives, and we document riskmitigation plans in the project repository. For all high-priority risks, a risk mitigation plan is defined to eliminate orreduce the impact of the risk to an acceptable level and to prevent the risk from occurring. The mitigation planincludes contingency activities to be implemented if the risk does occur.When determining an approach to mitigation, subject matter experts are required to suggest alternate strategies,assess the effectiveness of each potential alternative (including cost and schedule impact), determine the risksinvolved with each alternative, and arrive at a recommended approach.

Risk Mitigation Implementation. The Exchange implements a risk mitigation plan when the contingency trigger isreached. We alert all appropriate project stakeholders when the contingency trigger has been activated.Mitigation and contingency plans are documented in the risk log located in the online project repository. Each riskis assigned to the manager whose area of responsibility the risk most seriously affects and whose group is bestequipped to implement the risk response. The risk owner is responsible for monitoring risk mitigation activity.Risk Monitoring and Control. The Exchange identifies, logs, and tracks risks throughout the life of the project.Each week, risk owners and the Exchange Risk Management Team examine the items in the risk log and updatethe risk characteristics, response plans, and response actions as appropriate. They also review the risk triggers todetermine if they have occurred or are likely to occur and, if so, ensure response actions are appropriate. Theresults of these updates are immediately available through the project repository, and the associated metrics arereported in the project status reports. Status reports contain a specific discussion of the most significant projectrisks and the actions taken in response to them as well as an overall risk analysis for the project.Risk monitoring and control processes are continual and not limited solely to risks that have already beenidentified. If new risks are identified, they are analyzed and a response plan is developed. Monitoring and controlactivities include:Review weekly reports and risk logs to determine if each risk is still valid, the probability or severity haschanged, the trigger for the risk has occurred, mitigation plans remain relevant and accurate, and thecontingency plan remains valid as the risk maturesTrack and update the status of the risk on a weekly basiso Change status from open to occurring when the risk has been triggeredo Change status from closed if the risk has not occurred, the expiration date has passed, and the statuschange has been approved by the Exchangeo Change status from closed if a contingency plan has been successfully implemented, the risk is nolonger possible, and the status change has been approved by the ExchangeCommunicate risks and their status to team members and stakeholdersMonitor and evaluate metrics to help ensure adequate notice of changes is providedIdentify and assess risks continuously and develop mitigation strategies as neededRe-plan risk response strategy based on new informationAnalyze the results of the risk response plan for effectiveness and lessons learnedThe Exchange Communications Matrix is shown below:(this matrix is very similar to the DWSS HCR EE communications matrix, the exception being that the HCR EEsteering committee update is held monthly and an HCR EE joint project manager meeting is held every two weeks)

Workstream LeadTeam MemberPMO ManagerSr. Mgmt TeamProject ManagerExchangeChoiceNatomaMicrosoft WordTeleconferenceE-mailPresentationParticipantsMediumTopicPurposeLeader/FacilitatorRequiredDocsFrequencyIndividualStatusReportProvideinformationaboutindividualprogressTeamMemberStatusReportTemplateX X Weekly XTeam StatusMeetingsDiscussteamprogressand issuesWorkstreamLeadIndividual StatusReportsX X Weekly XTeam StatusReportsProvideinformationabout teamprogressWorkstreamLeadStatusReportTemplate,Individual StatusReportsX X Weekly X XSeniorManagement StatusMeetingsDiscussprojectwideprogressand issuesPMOManagerProjectStatusReportX X X X X Weekly XExchangeStatusMeetingsDiscussprojectprogresswithExchangemanagement teamProjectManagerProjectStatusReportX X X X X Semi-MonthlyX X XProject Provide PMO Project X X X Weekly X X

Workstream LeadTeam MemberPMO ManagerSr. Mgmt TeamProject ManagerExchangeChoiceNatomaMicrosoft WordTeleconferenceE-mailPresentationParticipantsMediumTopicPurposeLeader/FacilitatorRequiredDocsFrequencyStatusReportinformationaboutprojectprogressManagerStatusReportTemplateSteeringCommitteeMeetingsShareprojectprogressand issuesExchangeExecutiveDirectorProjectStatusReportX X AsrequestedX X XProjectKickoffMeetingReviewmission,goals.scope,approach,timeline andoutcomesProjectManagerPowerPointX X X X X X At start ofprojectX X XChangeControlBoard (CCB)MeetingsDiscuss,prioritize,approve/rejectsystem andscopechangesProjectManagerChangeRequest(CR)X X X X X X AsrequestedX X XAd hocMeetingsProvideupdates,thoughtleadershiprequestedby ExchangePMOManagerX X X AsrequestedX X X

The Exchange has completed a Quality Management Plan and a Deliverable Management Plan.Both these plans are included as attachments to our response. Please note that the projectschedule is being refined and once it is approved, will be shared with CMS.In addition to this, the Exchange is in the process of completing an integrated Project ManagementPlan, as well as the following supplemental plans:Project ScheduleRisk RegisterCommunication MatrixChange Management PlanConfiguration Management PlanStaff Management PlanFinancial Status ReportPerformance Measurement PlanPerformance MeasuresTraining PlanRelease PlanOnce these plans have been completed and approved, they will be shared with CMS via CALT.HCR EE project management plans completed are as follows:Detailed Project PlanStaffing PlanCommunication PlanTraining PlanChange Management PlanQuality Assurance PlanRisk Management PlanProject Closeout PlanKnowledge Transfer PlanTransition PlanThe following HCR EE project management plans are not yet completed Configuration Management Plan Test Management Plan Implementation Plan/Site Readiness Report Defect Management Plan Release Management Plan System Test9.5 Stakeholder Requirements Definition Process(This section is applicable to the HCR EE requirements process. Artifacts are provided forBusiness Rules Development, RSD, and RTM)Requirements development and documentation is an iterative process that involves discussionswith key SMEs (that have been identified by the Exchange including representatives from theExchange, DWSS, DOI etc.), review of federal and state legislations, and review of businessprocesses. Through this iterative process, the objective is to create requirements that meet thecriteria of good requirements and can be baselined.

The diagram below depicts, at a high level, the approach that the Exchange will use to gather andmanage requirements.Figure 3 – Requirements Management ApproachThe process of requirements management is broken into the following elements:Key activities of requirements definitionProcess used for obtaining and validating requirementsKey artifacts / inputs and outputs expected from each stage and at the end of therequirements phaseTo develop and manage the BOS and HCR EE technical solution requirements, the Exchange as wellas DWSS are following an Agile system development methodology that includes numerousactivities aimed at defining and refining the requirements. The diagram below shows the activitiesare iterative and provide a means to update and refine the requirements throughout the lifecycle.Requirements Elicitation. The focus is on obtaining the requirements from the stakeholders andSMEs who participate in requirements gathering sessions. This activity includes preliminaryrequirements, as well as further defining requirements through Requirement and Configuration(RAC) sessions. In addition, this activity focuses on determining “what” the business needs are.During this activity, there is a need to conduct business process reviews as well. Finally, during this

activity, there is a need to determine any gaps that may exist between the requirements and theproduct functionality.Requirements Analysis. Once the preliminary, initial requirements have been defined, the teamconducts an analysis of the requirements and compares them with applicable federal and statelegislation to determine if there are any adjustments that may be needed. In addition, the analysisactivity focuses on taking account of the possible conflicting requirements of the variousstakeholders. Requirements analysis involves verifying, estimating and prioritizing newly capturedrequirements for remaining application lifecycle steps. Finally, this activity helps determinewhether the stated requirements are clear, complete, consistent, and unambiguous, and resolveany apparent conflicts.Requirements Specification. Requirement specification involves developing the narrative thatfurther defines each individual requirement, and documenting the information gathered duringthe elicitation and analysis discussions. In essence, requirements specification is defined asdocumentation of the complete description of the behavior of a system to be developed. Requirements Validation. Once the requirements have been documented, they are reviewed foraccuracy and completion by the project team (including the SMEs that provided therequirements). Any gaps identified are addressed and requirements specifications are updated.Validation of preliminary requirements are required, as well as formal sign-off of finalrequirements.Requirements Management. Once all the requirements are validated, they are baselined in arequirements management tool. These baselined requirements are used to establish traceabilityto downstream artifacts (for example design elements, test scenarios and scripts etc.). Finally, thebaselined requirements are assigned to the appropriate releases. These baselined requirementsalso serve as a mechanism through which potential change requests / scope changes can bediscussed and prioritized. 9.6 Requirements Analysis ProcessBased on the general requirement definition activities mentioned above in section 9.5, theExchange’s requirements will be developed, refined, and managed through a series of phases.While initial, preliminary requirements were developed prior to the selection of the BOS vendor,additional phases and their timelines are illustrated in the Figure below

The HCR EE requirements are being developed, refined, and managed through two Agile iterationphases. While initial, preliminary requirements were developed prior to the selection of the HCREE vendor, additional phases and their timelines are illustrated in the Figure belowJun-12 Jul-12 Aug-12 Sep-12 Oct-12 Nov-12 Dec-12 Jan-13 Feb-13 Mar-13Preliminary Baseline RFP Requirements Attachment OUpdated Baseline RequirementsRequirements Specification Document - Iteration 1Requirements Traceability Matrix - Iteration 1Requirements Specification Document - Iteration 2Requirements Traceability Matrix - Iteration 2Components and functions included in HCR EE Iteration 1 include:1. Business Rules Enginea. Business Rules Applicationsi. Eligibility Determination Processii. Invocation of Eligibility Determination from NOMADS2. Changes to existing systems and interfacesa. NOMADSb. MMIS Interfacec. AMPSd. Access NV3. System securitya. Auditing and Logging4. System Administration5. System Standards

Components and functions included in HCR EE Iteration 2 are:1.Silver State Health Insurance Exchange (HIX) Interfaces and Seamless Co-ordination2. CHIP Interface3. Federal Hub Interface4. Access Nevada EnhancementsHCR EE Business Rules Requirements Analysis and Design ApproachThe HCR-EE requirements analysis and design approach, as it relates to MAGI for FMC, includes breaking thedesign sessions into seven (7) distinct groups as indicated below.Group 1 – Non Financial Criteria including Caretaker Relative, Citizenship, Deprivation, Pregnancy,Residency, Student Status, Social Security Numbers, Renewals, Prior Medicaid, Restorations, Changes, etc.Group 2 – Household Composition, Tax Filing Status, Tax Dependents (Filers and Non-Filers)Group 3 – Income Calculation including Earned Income, IRS Rule 36B, Income of Minor Child(ren),Unearned Income, Deemed Income, Minor Parent Income, Sneede vs. Kizer, Fluctuations in Income,Income VerificationGroup 4 – Hierarchy, Churn, Effective DatesGroup 5 – Notices Specific to FMC and CHIPGroup 6 – Management ReportingEach group discussed current policy that is unchanged which will be a part of the Eligibility Engine, new MAGIpolicy, including the addition of Nevada Check-Up and Expanded Medicaid. In addition, pending decisions and/oraction items were tracked with documentation of such being delivered at the end of each session.Prior to starting the design sessions, a FMC Deep Dive kick-off meeting was held. The purpose of the meetingwas to outline the structure of the sessions, explain the processes being used, receive feedback fromstakeholders, get approval on the documentation outcomes, as well as set expectations for the Deep Dive designsessions.A sample of the High Level Process Flows and the Detailed Process Flows (see the following Figure and Table)were reviewed at the kick off meeting and are illustrated below. As each Aid Code is converted into WebsphereOperational Decision Management for both existing rules and as new MAGI rules are created, the process flowsand detailed process flows will be created as part of the Detailed Design Deliverable.Each process flow has anassociated narrative describing the business process. Results of the requirements analysis and design sessionswere documented in the Business Rules Development document (BRD), the Requirements Specificationdocument (RSD), and the Requirements Traceability Matrix (RTM).HCR EE High Level Process Flow Example

HCR EE High Level Process Flow Rules ExampleMember is present in the household andon house arrest.Member Financial Resource Tests(AEA05A)Is the Home Presence Test Overridden?Home Presence Test - House Arrest (AEA05P9)YGO ON (to next rule)THENN Set the home presence test to TEST PASSED Go to Child Age TestCheck of NON temporary absence reason codes: M, O, V, E (Remember MOVE, in moving)Member-Level Non-Financial Tests(AEA03A)Home Presence Test - Permanent absenceIs the household left reason code ="VISITING" or "AWAY FOR EDUCATION"AND is the number of days between theEligibility Requested Period begin date ofthe Household left date more than 45AND the Member is NOT In the HomeAND the household left reason is notEMPTY?YNSet the home presence test result code to TEST FAILEDSet the home presence test failure reason code toMEMBER NOT APPLYING FOR ASSISTANCEClient Passes TestTHENGO ON (to next rule)

Preliminary RequirementsInitial requirements were developed by the Exchange in spring 2012 as the basis for selecting a vendor to buildand host the BOS. The Exchange identified these preliminary requirements based on the ACA requirements,Centers for Medicare and Medicaid Services (CMS) guidance, and other state and federal requirements. TheExchange also leveraged draft requirements identified by other states for comparison and reuse purposes, whereapplicable. Initial requirements for the Eligibility Engine were developed in the winter 2011 as the basis forselecting a vendor to design, develop and implement the HCR EE. These initial requirements were based on theACA as well as Institute of Electrical and Electronics Engineers (IEEE), International Standards Organization (ISO),Information Technology Infrastructure Library (ITIL) framework, the National Information Exchange Model (NIEM), National Institute of Standards and Technology (NIST), and applicable State of Nevada Revised Statutes (NRS) andstate policies.Requirements Validation Review (RVR)The RVR process will include a thorough review and validation of all requirements specified in the Exchange’s BOSRequest for Proposal (RFP). The goal of the RVR is to make sure that requirements are consistent, complete,realistic, and unambiguous. The RVR will provide the opportunity for the Exchange and BOS vendor to review theoriginal requirements provided in the RFP and verify they are still accurate, considering the possibility thatchanges may have occurred in Federal Policy or CMS guidelines. The review will also provide an additionalopportunity for the Exchange and BOS vendor to clarify questions prior to initiating downstream requirementsactivities (e.g., Requirements and Configuration Sessions (RACS)). It will also help identify any missingrequirements. In addition, a review of changes to the appropriate programs and policies will be conducted todetermine if there are any changes to the requirements or if there are any additional requirements. The goal is toarrive at a baseline of requirements, which will form the foundation of future requirements and developmentwork throughout the life of the project.As part of the RVR effort, additional columns will be added to the original requirements spreadsheet so that it canbe used to document the requirement status, potential gaps, new requirements, policy decisions, and clarificationpoints that are agreed upon in the RVR session(s). The updated spreadsheet will form the output of the RVR andit will be distributed for approval. This Consolidated Requirements Matrix will then be used as an input to the RACsessions, where requirements will be further decomposed to generate detailed requirements. These detailedrequirements will be documented in the Requirements Specification Document (RSD) and traceability will beprovided by the Requirements Traceability Matrix (RTM).Similarly, DWSS conducted a requirements validation review with the HCR EE vendor to examine initialpreliminary requirements against current Federal Policy and CMS guidelines and State of Nevada public assistanceprograms business operations to generate requirements for the Eligibility Engine that were accurate and reflectiveof current conditions. The goal was to arrive at a baseline of requirements to form the foundation of futurerequirements and development work throughout the life of the project. The baseline of requirements will beutilized for the duration of the project for further decomposition into business rules, detailed system design anddevelopment requirements, and traceability,Requirements and Configuration Sessions (RACS)Once the RVR is complete and initial requirements baselined, the Exchange will conduct RACS to review thefeatures and functionality of the BOS system to identify areas where the solution must be adapted or enhanced tosupport the Exchange’s business operations. These sessions are organized around the major businessfunctionality, and associated requirements.There are three primary phases of RAC sessions that align with the project’s SDLC, which is following an Agiledevelopment approach. For the month leading up to the development sprints, the Exchange will conduct RACsessions with the Exchange to elaborate on requirements targeted for the upcoming sprints. A detailed planoutlining which business topics will be reviewed, the applicable business requirements, required inputs, expectedoutputs, and key Subject Matter Experts is developed prior to kicking off the phase of RAC sessions. As the RACSare conducted, the Exchange will capture the detailed decomposition of business requirements along with processflows, data elements, and context diagrams in User Story documents that trace back to the original businessrequirements. The final output of each phase of RAC sessions is the RSD for that phase and a snapshot of the

Requirements Traceability Matrix. The RSD is simply a consolidation of the entire set of user stories developedduring the RACS phase.DWSS Business Operations and Information Systems conducted a series of business requirements sessionsbetween April 2012 and July 2012 to develop Use Cases and process flows reflective of future DWSS businessoperations under the Health Care Reform initiative. This effort proved invaluable in refining the baselinerequirements with the HCR EE vendor.Once the HCR EE vendor was engaged, specific features and functions of the HCR EE requirements were definedaround major business categories targeted for the first development iteration. As these sessions were conducted,HCR EE RSD and RTM documents were updated with the additional details.TraceabilityThroughout the project lifecycle, the Exchange will track requirements from their inception through testing,capturing additions, deletions, and refinements to the business and technical requirements. The Exchange willutilize a standard industry tool, IBM Rational DOORS (herein referred to as DOORS) as the requirementsrepository, thus providing a means to track detailed requirements, associated attributes, and downstream projectartifacts (e.g., user stories and test scripts).DOORS, the Exchange’s requirements repository tool, will be used to publish iterations of the RTM, including thefollowing:Initial Requirements. Captures the initial requirements, as articulated in the RFP Attachment O, and any editsmade during contract negotiations.Post RVR. Captures updates to the initial requirements based on the RVR sessions, which are intended toconfirm the team’s understanding of the scope, purpose, and implication of each requirement, as well asidentify any changes based on programmatic or policy changes since the RFP.Post Release A Requirements and Configuration Sessions. Captures edits and updates based on RACS forRelease A functionality.Post Release B RACS. Captures edits and updates based on requirements and configuration sessions forRelease B functionality.Post Release C RACS. Captures edits and updates based on requirements and configuration sessions forRelease C functionality.To develop the RTM, and to maintain requirements in the tool, the following steps will be conducted:Load the approved baseline business requirements that are the output of the RVR.Establish the tracing and control links:o Verify each Requirement has been associated to at least one User Story, Technical Design document, TestCondition, and Test Caseo Identify if there are Requirement Orphans (requirements that are not traced to downstream artifacts)o Confirm the User Story documentation captures all related Requirements and their associated DesignArtifactso Determine if the Test Results completely, or partially, trace each Requirement to all related DesignArtifactso Verify that the Requirements are fully, or partially, met in the Test ResultsChoose attributes and detail data required for tracking requirementsChoose traceability matrix format and configure in DOORSIdentify individuals who will supply each type of link information, and the person who will coordinate thetraceability activitiesEducate the Project Management Office (PMO), Development, Independent Verification and Validation(IV&V), and Test teams on the requirements tracing approach and expectations of data integrity in therequirements repository and RTM

DWSS and the HCR EE vendor will maintain the RSD and RTM documents in MS Excel format which are stored onthe DWSS shared collaboration tool called VIBE. This repository maintains versioning and is only updated bydesignated resources following formal review and approval. Requirements Traceability Matrix artifacts for theHCR EE are made available in the CALT Exchange Community for Nevada (CALT doc15039)Manage and ControlAs the Exchange and DWSS progress through the SDLC, it anticipates that requirements will evolve as new federaland state policies are developed, and as new business needs are identified. To control the project’s scope, it isimportant that the Exchange and DWSS continue to manage the requirements in a manner that prevents scopecreep and facilitates the project’s on-time completion. The Exchange and DWSS are utilizing the followingmethods and activities to manage and control the requirements.Formal Requirements Sign-Off. The Exchange and DWSS will formally approve and sign-off on the acceptanceof requirements at key points in time. Initially, after conducting the RVR, the Exchange will sign-off on thebaseline requirements. These baselined, approved requirements will be used to conduct the RAC sessionsassociated with one of three software releases. At the completion of each phase of RAC sessions, theExchange will approve and sign-off on the documentation produced from the RACS, including any changesmade to the requirements stemming from the RACS; documentation includes the RSD and updates to theRTM. DWSS has similarly approved the baselined requirements for the HCR EE. As the requirements analysisevolve into detailed design sessions, DWSS will conduct formal reviews and approvals of the produced HCR EEdocumentation.Change Management/Change Control Processes. If changes are made to the requirements during the RVR orRAC sessions, and the changes are material (impacting the cost, schedule, or quality of the system) thechanges will be managed through a formal Change Management Process. The intent of the ChangeManagement Process is to formally identify, document, and approve changes to requirements and thus thescope of the project. The process also defines the steps taken to document the needed change, submit aChange Request (CR), analyze the impacts, escalate for approval, approve the Change Order (CO), and thenexecute the approve change order. The process also includes the roles and responsibilities of the variousparties, including the Change Control Board (CCB). DWSS has also instituted a Change Control Process formaterial changes to the baselined project plan. Impact assessments (cost, schedule and scope) associatedwith the change from both the HCR EE vendor and DWSS are documented and presented to the HCR EEProject Sponsor for formal submission to the HCR EE Change Control Board. Changes approved by the CCBthat affect the HCR EE vendor’s contract will result in a contract amendment.9.7 Architectural Design ProcessArchitectural Design ProcessThe overall architecture design is still in progress. Once it has been completed, it will be shared with CMS.Systems Design DocumentThe system design document is still under development and will be shared with CMS once it has been approvedby the ExchangeInterface Control DocumentThe interface control document is still under development and will be shared with CMS once it has been approvedby the ExchangeDatabase Design DocumentThe database design document is still under development and will be shared with CMS once it has been approvedby the ExchangeLogical Data ModelThe Exchange is logically separated into a set of databases: Shopping – Handles shopping activities for a group or individual Enrollment – Handles enrollment activities for a group or individual

Users – Handles users of the systemSubscriber – Handles group and individual subscriber policies and billingAgent – Handles agent/broker/producer activitiesFinance – Handles all accounting activitiesEDI – Handles EDI 834 and 820 generation and trackingData Warehouse – collects data from system for reporting and analysisCustomer Care – Handles customer care activitiesDocument Management – Handles the document storage and workflowAll database tables have a primary key that is an identity column to uniquely identify each row within the table.These primary keys are referenced as foreign keys in related tables. Each table also has a set of required and a setof optional columns as shown below.Type TablesAll database lookup/enumeration tables have the same format as shown below and their name always ends in“Type”

Owner TypesAll accounts and many other entities are “owned” by a Tenant, Exchange or Program. An example of this threelevel hierarchy is: Tenant = State, Exchange = FHC Program = Small GroupUserAll users are defined in the Security User tables and are assigned roles and permissions

OverviewEntityThings that are common to all Persons and OrganizationsOrganizationThings that are common to all Organizations

PersonsThings that are common to all PersonsDate TablesTables like the PersonDate table shown below are used to record and historically track dates for peopleStored Procedure returns data based on Effective Date

ContactOrganizations and Persons can have contacts as shown belowTwo primary types of contacts Person to Person Organization to PersonPerson GroupsPerson Groups define families or household residents for Group Employees or Individual (IFP) Account holders

AccountAn Account always has a single Owner (Tenant, Exchange or Program). An account is a: Individual GroupCaseAn Account can have zero or more Cases. A case is created when a group or individual (IFP) purchases a policy.Cases have data common to all policies written under the case

PolicyA Case can have zero or more Policies. Policies have data common to all product lines written under the policy

Policy Product LineA Policy can have zero or more Product Lines.Plan/Carrier DataA Product Line can have zero or more Plans.

EnrollmentA person can enroll in zero or more Product Line Plans. Enrollments can be across different cases and policiesconcurrently.Enrollment WaiverA person can waive zero or more Product Line Plans.

Status TablesTables like the EnrollmentStatus table shown below are used to record and historically track enrollment statusesfor people.Data WarehouseThe Data Warehouse collects information from the various source systems using an ETL (Extract Transform Load)to populate the data warehouse.

Data Warehouse SchemasThe Data Warehouse is basically a set of star schemas consisting of Facts and Dimensions. As an example, theschema for the Broker Application schema is shown below.Physical Data ModelThe physical data model is still being developed by the Exchange. Once it is ready, it will be shared with CMSData Management PlanThe data management plan is still under development and will be shared with CMS once it has been approved bythe ExchangeImplementation PlanThe implementation plan is still under development and will be shared with CMS once it has been approved bythe ExchangeData Conversion PlanNo formal data conversion is planned for the implementation of the Nevada solution. Our solution through SOAwill discover data which is present in other systems and incorporate/resolve that data to the degree needed at thetime the data is needed (runtime). Thus we eliminate any formal data conversion through the process of applyingfor Health insurance through the Exchange. We are also performing batch data interfaces which will load largedatasets based on existing data stored in Nevada and will use these interfaces for processing any bulk data loadsfrom interfacing systems where direct data access is not feasible.Contingency / Recovery PlanHosting EnvironmentThe Exchange has contracted with Xerox to perform hosting services. The exchange is delivered via a SaaS model.This means all software is hosted by the Xerox and accessible by all user types through an Internet-enabledbrowser.The Xerox Team hosts the exchange solution on highly secure, state-of-the-art servers located in our data centersin the continental United States. These hardened locations are Tier 4 data centers. The data centers are built forredundancy, availability, and security with: Redundant internet service provider (ISP) connections Dual loop power

2n+1 uninterruptable power supplyRedundant generators with 96 hours of fuelPerimeter security, entry credentialing, biometric floor, and cage entrySSAE 16 compliance.The network services component of the exchange includes monitoring and protection services to ensurecommitments such as availability, response-time, secure access, and guaranteed delivery are met.Disaster Recovery and System Integrity ArchitectureThe Exchange is built for high availability. The use of multiple virtual machines running on multiple hardwareplatforms ensures that even several hardware failures will not take the system off line.Databases reside in clustered environments that minimize the likelihood of component failure impacting systemperformance or data loss; these failovers are automatic and seamless. In the unlikely event of a disruption sosignificant that it takes down the entire primary facility, the Exchange can be architected to replicate data on anear-continuous basis to a second, graphically-distant data center. Test scenarios can be generated todemonstrate the ability of the secondary site to take over the processing in the event of a disaster. Best practicesuggests exercising this test within an established maintenance window to guard against unexpected difficulties,although it is possible to have a credible test without taking the primary infrastructure off line.Analysis of the recovery time objectives (RTO) and acceptable threshold for data loss will be examined with theExchange as part of the disaster recovery (DR) planning process. In some configurations, a very short window tomove to the secondary site with minimal or no data loss is possible; at minimum, a less than 72-hour recovery canbe achieved.The Exchange has a mature data backup and DR plan that centers on redundancy and high availability ofinfrastructure with an additional safety net of a hot site availability contract. Data is protected using recurringinterim backups, while our database clusters provide near immediate failure recovery. Periodic point-in-time tapebackups are stored offsite and available in case of extreme disaster. Failover to redundant components happensautomatically.Our disaster recovery plan categorizes the recovery order of systems based on their impact. Each disaster scenariois different and the plan calls for assessments and decision points throughout the process. Those systems actuallyaffected by any disaster can impact priorities; multiple priorities can be handled at the same time, depending onthe resources required and available. The general documented approach for a full disaster scenario is:Priority One – Phone services and Call Center (within 24 hours)Priority Two – Domain/DNS, Main customer facing application servers and websites (within 48 hours)Priority Three – Secondary application servers, FTP services, EDI (within 56 hours)Priority Four – Back office systems, file servers, etc.( within 64 hours)Priority Five – Full printing and outbound mail functions, image storage and restoration, any remaining inhouse processing systems (within 72 hours)Disaster recovery plans are updated annually. Every year the IT group tests the ability to complete a true recoveryon foreign hardware at a SunGard Recovery location (usually in Scottsdale, AZ) using the updated plans as a guide.Business continuity plans are documented at the department level, rolled up to the business unit level, andaligned with the IT recovery plan with coordination by compliance and security staff. The plans focus on thebusiness recovery aspects and leverage alternate facilities under contract as well as other locations and remoteaccess strategies. We train and test on these plans at least annually through a number of mechanisms includingTable Top, Limited Scope and Simulated Full Scope tests. Business continuity plans for the exchange are updatedannually.The Exchange is diligent in its efforts to protect data and equipment from any kind of damage, destruction, ortampering, whether intentional or accidental. We do this through highly-trained and screened personnel, highsecurity facilities, active monitoring, and multiple backups stored in multiple locations. We make frequent point-

in-time backups to allow rollbacks to known good data structures if a problem should be replicated to a backupstorage location.Actual recovery from a destroyed or damaged resource is typically not dependent on the cause of the destruction.If the destruction is believed to possibly be intentional, additional testing on the integrity of data to be restoredmay be instigated. Also, our security team would immediately begin to investigate any damage that was thoughtto possibly be deliberate.The final determinations for incidents qualifying as a disaster condition depend, to a large extent, on the highavailability target for the system. As previously described, the Exchange is built for high availability; therefore, asingle or even multiple component failures are unlikely to create a disaster scenario. Our disaster planning doesextend to worst case scenario and the following categorizations are used in those kinds of events when assessingthe need to declare and activate a recovery scenario:Category 1 Event: Minor Damage The anticipated downtime is less than 24 hours. Little or no mobilization of the disaster recovery team is required. Depending upon the extent of the damage, SunGard may not need to be placed on alert. Processing can be restarted in a short time, with little or no modification to schedule workload. There is possible damage to hardware, software, mechanical equipment, electrical equipment, or the facility.Category 2 Event: Moderate damage The estimated downtime is greater than 24 hours and less than 72 hours. Partial or full mobilization of the disaster recovery team may be necessary. SunGard will be placed on alert, with a possible disaster declaration forthcoming after complete damageassessment. Depending on the extent of the damage, some restoration of systems and data recovery may need to beinitiated. There is moderate damage to hardware and/or facility. Modifications to workloads may be necessary to allow the most critical functions to resume operations assoon as possible. Most functions will resume normal operations following the restoration and recovery process.Category 3 Event: Catastrophic damage A disaster is declared with SunGard if business interruption is estimated to possibly reach 72 hours. The damage is extensive. Restoration of primary servers may be required. The computer room or facility could be completely destroyed. Full mobilization of the disaster recovery team is declared. Depending on an assessment of the specific damage, the appropriate SunGard Recovery Center(s) will beselected.Cessation of a disaster event is also based on an assessment of the actual situation. Typically, this would occurwhen all systems resumed online functionality and when all personnel had fully functional locations in which toperform their functions. While the actual disaster recovery was completed, depending on what had occurred (astructure loss, for example), it is possible that alternative locations and business processing mechanisms might beused for some time.We have identified alternative sites for each of our primary operations and data center facilities, should there bean impact to one or more of our locations due to a disaster incident. Geographically-diverse locations throughoutthe US for the primary and recovery sites help support the quick recovery of applications and operations,supported by our established back-up processes and disaster recovery and business continuity planning. Recoverytime objectives (RTOs) are defined in accordance with contract requirements and incorporated into the projectspecificrecovery planning. We have a long established partnership with SunGard Recovery Services as our hot sitedisaster recovery vendor.

In accordance with the disaster recovery (DR) plan and guidelines, appropriate management determines thescope, severity, and response of all incident-related activities, from the decision to declare an emergency/disasterto control and resolution. Once a disaster is declared and DR procedures are initiated, key Exchange staffmembers are notified, including the program manager. The program manager, in turn, immediately notifiesdesignated Exchange management, as well as other major stakeholders as defined in the DR call tree andcontract-required notification timeframes.Throughout the DR process, the Exchange communicates progress to designated staff. The frequency of thesecommunications are defined in the DR plan and approved by the Exchange during implementation.SummaryThe information above provides the necessary evidence of completion to close out this section of the Design Review andprovides the necessary information for the completion of the Blueprint. Should you have any questions, please do nothesitate to contact me at sderousse@exchange.nv.gov or 775-687-9927.