Font Size Print Download Reader HHS Home|HHS News|About HHS

Centers for Medicare & Medicaid Services Privacy Impact Assessments

06.3 HHS PIA Summary for Posting (Form) / Administrative Finance Systems

PIA SUMMARY AND APPROVAL COMBINED

PIA Summary

Is this a new PIA? No

If this is an existing PIA, please provide a reason for revision: PIA Validation

1. Date of this Submission: Jun 26, 2009

2. OPDIV Name: CMS

3. Unique Project Identifier (UPI) Number: 009-38-01-04-01-1090-00 009-38-01-01-01-1020-00

4. Privacy Act System of Records (SOR) Number (If response to Q.21 is Yes, a SORN number is required for Q.4): 09-90-0024

5. OMB Information Collection Approval Number: N/A

6. Other Identifying Number(s): N/A

7. System Name (Align with system Item name): Administrative Finance System

9. System Point of Contact (POC). The System POC is the person to whom questions about the system and the responses to this PIA may be addressed: Antoinette Miller

10. Provide an overview of the system: ATARS: Tracks the progress of an OIG or GAO audit through CMS clearance process, then monitor the monies collected, saved, or written off.

BAAADS: Provides the OFM/FSG administrative budget staff the capability to disperse funding to CMS components. Funding is allocated at the appropriate level and components are notified of their funded amount via an advice of allotment/allowance. BAAADS is interfaced with FACS to provide for funding input and modifications.

BUCS: Agency-wide budget execution system used by Executive Officers and their staff to manage and track administrative funds.

DCS: Allows CMS employees and Medicare contractors to enter, update, and transmit delinquentdebt for the purpose of collecting debt through Treasury offset and cross servicing.

FACS: Accounting, general ledger, and payment functions.

HTS: Allows CMS employees to enter, submit, and approve travel documents for the purpose of receiving reimbursement of travel expenses.

13. Indicate if the system is new or an existing one being modified: Existing

17. Does/Will the system collect, maintain (store), disseminate and/or pass through PII within any database(s), record(s), file(s) or website(s) hosted by this system? (Note: This question seeks to identify any, and all, personal information associated with the system. This includes any PII, whether or not it is subject to the Privacy Act, whether the individuals are employees, the public, research subjects, or business partners, and whether provided voluntarily or collected by mandate. Later questions will try to understand the character of the data and its applicability to the requirements under the Privacy Act or other legislation. Does/Will the system collect, maintain (store), disseminate and/or pass through PII within any database(s), record(s), file(s) or website(s) hosted by this system?): Yes

21. Is the system subject to the Privacy Act? (If response to Q.19 is Yes, response to Q.21 must be Yes and a SORN number is required for Q.4): Yes

23. If the system shares or discloses IIF please specify with whom and for what purpose(s): ATARS: N/A

BAAADS: N/A

BUCS: N/A

DCS: Delinquent receivables sent to HHS/PSC's Debt Management & Collection System. PSC sends data to Treasury for cross servicing and the Treasury Offset Program.

FACS: Delinquent receivables sent to HHS/PSC’s Debt Referral System (DMCS). PSC sends data to Treasury Offset Program (TOPS). Payment files sent to Treasury. 1099-Misc. files sent to IRS. Budget data extracted from a FACS report file by the BUCS.

HTS: N/A

BAAADS: The information CMS collects is from the Office of Management and Budget based on the Congressional appropriation. It does not contain PII.

BUCS: CMS Administrative budget data is collected and maintained in BUCS. Funding records contain CMS accounting information including Allowance Number and Common Account Number, Administrative organization codes and funding data. Spending records are detailed budget transactions and contain name, transaction description, dates, spending amounts, object class, CAN and budget identifying codes. Information contains PII, and submission is mandatory.

DCS: Information associated with principal and interest and individual debtors whether they are individual or corporations. Information contains PII, and submission is mandatory.

FACS: The PII contained in the FACS includes vendor and employee EINs/TINs, names, addresses, and banking information. Submission of this information is mandatory, as it is required to make payments to vendors and individuals. Information on taxable payments is sent to the Internal Revenue Service. Additionally, this information must also be tracked for receivables, as this information will be used when referring delinquent debts to the Treasury for collection.

HTS: Information associated with an employee and travel expenses are collected. The information contains PII, and it was mandatory for employees to receive reimbursement of valid travel expenses.

31. Please describe in detail any processes in place to: (1) notify and obtain consent from the individuals whose PII is in the system when major changes occur to the system (e.g., disclosure and/or data uses have changed since the notice at the time of the original collection); (2) notify and obtain consent from individuals regarding what PII is being collected from them; and (3) how the information will be used or shared.

(Note: Please describe in what format individuals will be given notice of consent [e.g., written notice, electronic notice, etc.]) ATARS: NO.

BAAADS: NO

BUCS: The SSN is only used to systematically retrieve a name on a transaction. When a name is added to a transaction, it is selected from a transaction drop down list that only displays the name of CMS Employees from a reference table. The reference table is maintained by the BUCS technical administrator and is not available to BUCS users.

DCS: The PII information is supplied by individuals and corporations.

FACS: PII is obtained from vendors and employees, who are instructed that this information is required in order to receive payment from the CMS. This is conveyed to them through contract and/or appropriate CMS notification (when they are being reimbursed for travel). Vendors can not sign their contract, and employees can not be reimbursed for travel if they do not want to provide this information to the CMS.

HTS: The PII information is supplied by the personnel file.

32. Does the system host a website? (Note: If the system hosts a website, the Website Hosting Practices section is required to be completed regardless of the presence of PII): No

37. Does the website have any information or pages directed at children under the age of thirteen?: No

50. Are there policies or guidelines in place with regard to the retention and destruction of PII? (Refer to the C&A package and/or the Records Retention and Destruction section in SORN): Yes

54. Briefly describe in detail how the IIF will be secured on the system using administrative, technical, and physical controls.: ATARS:No

BAAADS: No

BUCS: The data is secured by Oracle database security rules and constraints. User authority is granted via the establishment of user ids and database authorities. In addition, BUCS maintains and controls application security by the establishment of user profiles and specific table access authority.

DCS: The data is secured by DB2 database security rules and constraints. User authority is established via a userid/password.

FACS: PII is secured through CMS data center policy, as well as the secure CMS facility. Additionally, user-level security includes RACF security, user classes within the FACS, security groups limiting access based on dataset high-qualifiers and usage requirements, and screen-level security.

HTS: The data is secured by Oracle database security rules and constraints. User authority is established via a userid/password.

PIA Approval

PIA Reviewer Approval: Promote

PIA Reviewer Name: William Saunders

Sr. Official for Privacy Approval: Promote

Sr. Official for Privacy Name: Anthony Trenkle

Sign-off Date: Jun 26, 2009

Approved for Web Publishing: Yes

Date Published: September 1, 2009

_____________________________________________________________________________

06.3 HHS PIA Summary for Posting (Form) / CMS IT Infrastructure IS

PIA SUMMARY AND APPROVAL COMBINED

PIA Summary

Is this a new PIA? No

If this is an existing PIA, please provide a reason for revision: PIA Validation

1. Date of this Submission: Jun 26, 2009

2. OPDIV Name: CMS

3. Unique Project Identifier (UPI) Number: 009-38-01-04-01-1160-00 009-38-01-09-01-1120-00 009-38-02-00-01-1150-00

4. Privacy Act System of Records (SOR) Number (If response to Q.21 is Yes, a SORN number is required for Q.4): 09-70-0538

5. OMB Information Collection Approval Number: N/A

6. Other Identifying Number(s): N/A

7. System Name (Align with system Item name): CMS IT Infrastructure

9. System Point of Contact (POC). The System POC is the person to whom questions about the system and the responses to this PIA may be addressed: Ed Gray

10. Provide an overview of the system: As a part of the Medicare Modernization Initiative, CMS is changing the way that is does its Medicare claims business. The Medicare Administrative Contracts are being awarded to migrate the traditional fee-for-service Title XVIII contracts over to Federal Acquisition Regulation contracts. Additionally, CMS is taking ownership of the data processing portion of this business its award of the Enterprise Data Center (EDC) contract in March 10, 2006. This contract will migrate the workloads and Medicare Claims processing systems that are currently running at 14 Medicare data centers in different physical locations to one of the three EDC contractors, (CDS' Cloumbia SC Data Center, EDS' Tulsa Chrokee Data Center and IBM's Southbury Data Center.)

Additionally, this site now supports CMS' web hosting application, (e.g., Medicare.gov, cms.hhs.gov. and HPMS). This GSS does not directly collect, maintain, or disseminate information. It provides platform support infrastructure for other CMS MA's to performm their function.

Part A Shared System: Hospital insurance claims process through the Fiscal Intermediaries Shared System, which performs claims processing and benefit payment functions for institutional providers under Parts A and B of the program.

Part B Shared System: The PArt B Shared System supports the processing of Medicare Part B claims, Medicare Part B is supplemental medical insurance, which covers physician services and other outpatient services. The Shared System for Part B Medicare in the Multi Carrier System. Medicare Part B claims processing contractors are known as Carriers, and include the Railroad Retirement Board. They process physician and supplier claims provided under MEdicare Part B coverage.

Durable Medicare Equipment Regional Contractor Shared Syste: CMS has designated four carriers to have exclusive responsibility for handling Medicare Part B claims, for Durable Medicare Equipment Prosthetics, Orthotics, and Supplies claims in specific geographic regions of the United States. They are commonly referred to as the DMERCs. The selected DMERCs currently use the VMS DME Shared system to process DMEPOS claims. This GSS provides compute platforms, telecommunications, electronic storage infrastructure, and operations support services for the collection, maintenance, and access of data and information to support the business functions of CMS.

13. Indicate if the system is new or an existing one being modified: Existing

21. Is the system subject to the Privacy Act? (If response to Q.19 is Yes, response to Q.21 must be Yes and a SORN number is required for Q.4): Yes

23. If the system shares or discloses IIF please specify with whom and for what purpose(s): Information is shared to verify patient data between Medicare Supplemental Insurers, if necessary, as well as entitlement and accuracy of payment.

(Note: Please describe in what format individuals will be given notice of consent [e.g., written notice, electronic notice, etc.]) Information is collected from two CMS forms, the 1450 and 1500. All Medicare Claims Processing Contractors are called 'satellites' under CWF. Satellites access the HOST CWF databases to obtain needed beneficiary information. Satellites submit claims to the CWF Host for prepayment review and approval. Medicare beneficiaries are provided healthcare services where their personal information is collected and required for payment and reimbursement purposes. Beneficiaries receive HIPAA disclosure information by providers and Medicare directly. A complaint process is in place for individuals to raise their privacy concers.

32. Does the system host a website? (Note: If the system hosts a website, the Website Hosting Practices section is required to be completed regardless of the presence of PII): Yes

37. Does the website have any information or pages directed at children under the age of thirteen?: No

50. Are there policies or guidelines in place with regard to the retention and destruction of PII? (Refer to the C&A package and/or the Records Retention and Destruction section in SORN): Yes

PIA Approval

PIA Reviewer Approval: Promote

PIA Reviewer Name: William Saunders

Sr. Official for Privacy Approval: Promote

Sr. Official for Privacy Name: Anthony Trenkle

Sign-off Date: Jun 26, 2009

Approved for Web Publishing: Yes

Date Published: September 1, 2009

_____________________________________________________________________________

06.3 HHS PIA Summary for Posting (Form) / Customer Service Systems

PIA SUMMARY AND APPROVAL COMBINED

PIA Summary

Is this a new PIA? No

If this is an existing PIA, please provide a reason for revision: PIA Validation

1. Date of this Submission: Jun 26, 2009

2. OPDIV Name: CMS

3. Unique Project Identifier (UPI) Number: 009-38-01-09-01-1020-00 009-38-01-04-01-1060-00

4. Privacy Act System of Records (SOR) Number (If response to Q.21 is Yes, a SORN number is required for Q.4): 09-70-0535, 09-70-0500, 09-70-0540, 09-70-0513, 09-70-0542, 09-70-0544

5. OMB Information Collection Approval Number: N/A

6. Other Identifying Number(s): N/A

7. System Name (Align with system Item name): Customer Service System

9. System Point of Contact (POC). The System POC is the person to whom questions about the system and the responses to this PIA may be addressed: 1. Ketan Patel, 2. Greg Overland, 3. Dave Nelson, 4. Dave Nelson, 5. Flosetta Rowry, 6. Dennis Bogley, 7. David Nelson, 8. Ketan Patel

10. Provide an overview of the system: 1. The applications that comprise CMS' Customer Service System-

Medicare.gov Website enable the Agency to educate the public, specifically Medicare beneficiaries, on the Medicare program. Originally launched in 1998, Medicare.gov allows consumers to compare health plans, nursing home, home health agenciec, prescription drug coverage, and participating physicians.

2. cms.hhs.gov is the official public Agency website of the Centers for Medicare & Medicaid Services, accessible at www.cms.hhs.gov. The cms.hhs.gov website was launched on September 13, 2001. This site was a replacement for the Agency’s prior website, www.hcfa.gov. The Health Care Financing Administration launched the hcfa.gov website in 1995. While the cms.hhs.gov contained much of the same content as hcfa.gov, it did feature a new design and organization scheme.

3. Provide Accurate and up-to-date information regarding the operations of the various Beneficiary Contact Center (BCC) systems to provide CMS with the ability to make data-based decisions regarding the BCC operations and planning.

4. The BCC serves citizens nationwide by accepting and responding to inquiries relating to Medicare and Medicaid benefits and other related services through CMS. Support services provided include: Responding to telephone inquiries using scripted and plain language, escalating calls as needed; Answering e-mail and written correspondence; Maintaining and delivering a training program,; Fulfilling static and print-pn-demand publication requests; Installing and maintaining telecommunications networks and network-based applications; Employing Intelligent Call Routing (ICR) for call delivery.

5. The MBP provides Medicare beneficiaries with a browser-based graphical user interface to retrieve relevant beneficiary information.

6. The NGD and Medicare.gov is a customer relationship management (CRM) system implemented with Siebel technology (a commercial-off-the-shelf product). The Customer Service Representative desktop was developed to handle inquiries for the 1-800-Medicare Helpline and Medicare Intermediary Cotractors (Med A, Med B, and DMERC). The design of NGD is designed to support the VCS initiatives of OBIS.

7. Provides Learning requirements, content, training material, and history for CSRs at the BCC locations.

8. The applications that are integral parts of Medicare.gov Website - enables the Agency to educate the public, specifically Medicare beneficiaries, on the Medicare program. Launches as part of the Medicare Part D program (MMA): Plan Finder allows consumers to compare health plans and prescription drug coverage; Formulary Finder allows consumers to check for plan and drug coverage at a state level; Drug Manager allows users to individualize and manage their drugs; and Online Enrollment Center (OEC) allows consumers to enroll in Part C and D plans.

13. Indicate if the system is new or an existing one being modified: Existing

21. Is the system subject to the Privacy Act? (If response to Q.19 is Yes, response to Q.21 must be Yes and a SORN number is required for Q.4): Yes

23. If the system shares or discloses IIF please specify with whom and for what purpose(s): 1. Shared with print vendors to mail publications. Also shared with 1-800-Medicare CSR to assist beneficiaries with personalized drug plan information. Information is also shared with online enrollment center to assist beneficiaries with personalized drug plan information. Information is also shared with online enrollment center. 2. The system shares or discloses IIF with the CMS employee conference coordinator in order to register the attendee for the conference and also discloses IIF with the business owners for Creditable Coverage Form. Information is shared with the appropriate staff within the agency. Subject matter experts are asked to respond to inquireied in their field of knowledge. 3. Authorized and Authenticated NDW users with appropriate permissions are able to generate reports that may include IIF. 4. Vangent shares IIF with CMS and subcontractors to perform duties defined under the Business Associate Agreement. 5. Beneficiaries for the purpose of providing self service and with call center customer service agents to assist the beneficiaries with inquiries. 6. Beneficiaries for the purpose of providing self service and with call center customer service agents to assist beneficiaries with inquiries. 7. N/A. 8. Posted on website for information peurposes; Online enrollments are downloaded by Plans. Also shared with plan sponsors so that they can download and process the medicare Part C or D enrollments and verify eligibility.

2. Data is collected to: improve the Agency’s website; allow visitors to ask specific questions of Agency staff; and support conference registration for outreach and educational purposes. The only data element explicitly requested is an email address. This is a voluntary submission. These feedback requests are triaged automatically to the appropriate business component for response. Additionally, we have an onle conference registration system available. This system captures contact information from registrants, including name, business, address, phone, fax and email. This information submission is voluntary and is automatically sent to the conference coordinator and removed from the website after 60 days.

3. As part of the contact with beneficiaries, pertinent information about the contact such as HICN, name, address, city, state, zip, and DOB are collected for generating statistics on activity. PII is populated based on demographic information in the Medicare Beneficiary Database.

4. The information collected, maintained, or disseminated contains PII. Submission is voluntary. Information includes Privacy Act data elements which are used to access and provide information being requested by Medicare beneficiaries.

5. The MBP will collect Beneficiary Login information (Medicare number and Password) for identification and authentication purposes. For registration, the MBP will collect the user's Medicare Number, Last Name, DOB, Gender and Zip Code for identification. A user cannot register without providing this information. Once registered, the user can access the application via their username and password.

6. The NGD collects and stores information about Medicare beneficiaries. Access to beneficiary Medicare information requires callers to submit identifying information. The Health Insurance Claim Number is utilized as required to identify information about the beneficiary and validated with additional PII information such as Beneficiary Name, address, date of birth, etc.

7. The PII collected is Name of employee, business email address, job position, BCC site, NGD login ID, employment states code, required training and training results, SUbmission of information is mandatory to provide access to the Learning Management System for required job training and related amterials.

8. Information is collected from users of Online enrollment Center during the enrollment process and the required data elements include: Name, Address, Phone Number, E-mail address, HICN, date of birth, and monthly premium withhold preference. Other inforamtion collected from users are of a voluntary nature, such as Mailing address and emergency contacts. Information is used to enroll users in Part C or D programs. Collection of required information is necessary so that plan sponsors can validate personal information of users enrolling in their plan as well as to validate user's eligibility status with CMS and SSA.

(Note: Please describe in what format individuals will be given notice of consent [e.g., written notice, electronic notice, etc.]) 1. At all data collection points, a link to the website privacy policy is provided (the privacy policy is linked from the website footer so that it is available on all pages). The policy indicates that CMS will protect the personal information that the user shares with us and that CMS does not disclose, give, sell, or transfer any personal information to third parties.

2. None in place

3. PII contained in the National Data Warehouse is loaded from source systems tha tinterface directly with the indviduals.

4. None in Place

5. None in place

6. The users of the NGD are required to use HIPAA compliant disclosure procedures before disclosing any PII information about a Medicare beneficiary. The NGD tracks disclosure activities of the customer service representative. The NGD will provide Medicare related general, eligibility and claim information to the Medicare beneficiaries in the form of phone calls and written requests.

7. Electronic notification of the privacy policy is provided each time the system is accessed. Users are required to agree to the policy before access is granted to the system.

8. At all data collection points, a link to the website privacy policy is provided as well as multiple warning messages are displayed throughout the online enrollment process for intended use of collected data (the privacy policy i slinked from the website footer so that it is available on all pages). The policy indicated that CMS will protect the personal information that the user shares with us and the CMS does not disclose, give, sell, or transfer any personal information to third parties. In addition to formates prescribed by Medicare-gov, electronic notices are provided as part of the enrollment process and users must provide their consent.

32. Does the system host a website? (Note: If the system hosts a website, the Website Hosting Practices section is required to be completed regardless of the presence of PII): Yes

37. Does the website have any information or pages directed at children under the age of thirteen?: No

50. Are there policies or guidelines in place with regard to the retention and destruction of PII? (Refer to the C&A package and/or the Records Retention and Destruction section in SORN): Yes

54. Briefly describe in detail how the IIF will be secured on the system using administrative, technical, and physical controls.: 1. All PII is secured behind user Ids and passwords. PII collected through the website is not publicly accessible. In addition, the publications ordering application, which collects more PII than the user feedback, is secured by SSL encryption. Physical access controls are provided by EDS and EDC, Tulsa, OK.

2. All PII is secured behind user IDs and passwords. PII collected through the website is not publicly accessible.

3. Data is protected through layers of security such as logical password controls, firewall and data network access controls, and physical access controls over the servers.

4. Vangent has internal controls to protect the confidentiality, integrity, and availability of PII using existing administrative, technical and physical controls including Standard Operating Procedures for Business Continuity and Disaster Recovery; Environmental Safeguards; Operating system/application/network level logging, physical and logical identification and authentication. Intrusion Prevention Systems; Firewalls; Virtual Private Networks; Guards and CCTV.

5. The MBP system is designed to secure information while in transit on the network. When user information is in transit, the MBP system uses SSL and Siebel Internet Session Protocol to provide data confidentiality.

6. The NGD system secures PII by implementing and mutli-tiered architecture using multiple types and layers of firewall and intrusion detection technology. The Siebel infrastructure allows for strict role mased use access control that restricts access on both. Physical controls include ID badges, Key Cards, Cipher Locks, and CCTV.

7. Logical and physical access to the system is restricted on a "need to know" basis. Formal authorization based on user roles and need to know is required prior to physical or logical access to the system being granted. The system is housed in a physically secure facility with two factor authentication required to enter the data center. Logical access is restricted by username and password combinations, with two factor authentication being required for remote administration.

8. PII collected through website is not publicly accessible and all collected PII is secured by encryption. All information is only accessible via SSL. Plan sponsors must utilize unique userIDs and passwords to access and download enrollment data for their plan. They are not able to view/access any other PII data for other plans. In addition, support personnel (hel desk) are not able to view the PII data and PII data is only available to plan sponsors. Physical access controls are provided by SAVVIS data center at el Segundo, CA.

PIA Approval

PIA Reviewer Approval: Promote

PIA Reviewer Name: William Saunders

Sr. Official for Privacy Approval: Promote

Sr. Official for Privacy Name: Anthony Trenkle

Sign-off Date: Jun 26, 2009

Approved for Web Publishing: Yes

Date Published: September 1, 2009

_____________________________________________________________________________

06.3 HHS PIA Summary for Posting (Form) / Electronic Health Record System

PIA SUMMARY AND APPROVAL COMBINED

PIA Summary

Is this a new PIA? No

If this is an existing PIA, please provide a reason for revision: -

1. Date of this Submission: Jun 26, 2009

2. OPDIV Name: CMS

3. Unique Project Identifier (UPI) Number: 009-38-01-99-02-1126-00

4. Privacy Act System of Records (SOR) Number (If response to Q.21 is Yes, a SORN number is required for Q.4): 09-70-0501, 09-70-0502, 09-70-0503

5. OMB Information Collection Approval Number: NA

6. Other Identifying Number(s): NA

7. System Name (Align with system Item name): Electronic Health Record System

9. System Point of Contact (POC). The System POC is the person to whom questions about the system and the responses to this PIA may be addressed: Tony Trenkle

10. Provide an overview of the system: My Personal Health Record (MPHR): is a tool that helps a consumer gather, store, manage, and share their health data. The tool gives beneficiaries the opportunity to manage information from a variety of sources, including self-entered data. The system will maintain pre-populated Medicare fee-for-service and TRICARE medication claims data.

Medicare PHR Choice (MPC): The system will validate a Medicare beneficiary's identity and then move their Medicare claims data to the PHR tool selected by the beneficiary.

13. Indicate if the system is new or an existing one being modified: Existing

21. Is the system subject to the Privacy Act? (If response to Q.19 is Yes, response to Q.21 must be Yes and a SORN number is required for Q.4): Yes

23. If the system shares or discloses IIF please specify with whom and for what purpose(s): MPHR: Medicare Claims and eligibility information and TRICARE for Life medication data will be available to Medicare beneficiaries and those with TRICARE for Life coverage via the PHR portal. the information is used by beneficiaries to manage their personal health care. Additionally, the purpose of the project is to evaluate outreach methods to educate benficiaries about PHRs, explain the benefits of PHRs, and encourage PHR registration. MPC: Medicare claims will be shared with the PHR selected by the beneficiary. The beneficiary will then access the information through the PHR tool. The information will be used to help the beneficiary manage their health and health care.

30. Please describe in detail: (1) the information the agency will collect, maintain, or disseminate; (2) why and for what purpose the agency will use the information; (3) in this description, explicitly indicate whether the information contains PII; and (4) whether submission of personal information is voluntary or mandatory: MPHR: The Agency does not use the information collected for the PHR project. The data contains Individually Identifiable information. Beneficiaries my voluntarily request for their data to be populated into their PHR. Data consists of: hospitalizations (pre-populated): diagnoses which caused the inpatient stay, admission and discharge dates; procedures and/or surgeries (pre-populated): associated diagnoses, procedure dates; office visits (pre-populated) diagnoses; Emergency contact information: name, relationship, phone number (self-populated); Medications (self-populated unless the individual has TRICARE for Life); prescriptions, over-the-counter medication, vitamins, supplements; Allergies: to medications, animals, insects and other substances (self-populated); Laboratory tests (pre-populated if possible); Provider information (pre-populated) name phone number and specialty. In addition, the beneficiary may self-enter any of the above information at his or her discretion into the PHR. TRICARE for Life medication (pre-populated) on request. The information within the PHR belongs to the beneficiary and is only viewable by the beneficiary and those granted access by the beneficiary.

MPC: Medicare claims data from Part A and PArt B (hospitalizations, procedures, surgeries, office visits, diagnosis, laboratory tests.

(Note: Please describe in what format individuals will be given notice of consent [e.g., written notice, electronic notice, etc.]) MPHR: During the initial registration process, the beneficiary must authorize the population of their data into the pHR. No information transfers into the PHR without the beneficiary's on-line consent. Individuals are prompted by the tool itself to self-identify as a TRICARE for Life beneficiary and proceed to an authorization page to direct the TMA to populate the PHR with the beneficiary's TRICARE data. If there are major changes to the system, beneficiaries will be notified when data use or disclosure changes occur in the system. Subsequently the beneficiary will have to provide consent with respect to the changes when the sign into their PHR.

MPC: Beneficiaries with Original Medicare in Arizona and Utah will be informed of the Medicare PHR Choice pilot. If they choose to participate they will choose a PHR and then authorize us to move their data to the PHR on their behalf. Beneficiaries may choose one of four PHRs. all four PHR vendors will sign data use agreements with CMS.

32. Does the system host a website? (Note: If the system hosts a website, the Website Hosting Practices section is required to be completed regardless of the presence of PII): Yes

37. Does the website have any information or pages directed at children under the age of thirteen?: No

50. Are there policies or guidelines in place with regard to the retention and destruction of PII? (Refer to the C&A package and/or the Records Retention and Destruction section in SORN): Yes

54. Briefly describe in detail how the IIF will be secured on the system using administrative, technical, and physical controls.: MPHR: The contractor and its business associates shall meet the requirements of the CMS Information Security Program. The policies, standards, and procedures that govern the pilot must conform to the CMS Information Security Program and have a two-fold purpose: (1) to enable CMS' business process to function in an environment with adequate security protections, and (2) to meet the security requirements of federal laws, regulations, and directives, including the Privacy Act of 1974 (as amended), HIPAA, and FISMA, as well as various rules, regulations, policies, and guidance developed by DHHS, OMB, Homeland Security and NIST. Addityionally, the security of the pHR meets the requirements of the Interconnection Security Agreement between CMS and the TMA for data transfer, security and privacy.

MPC: The Noridian Medicare MAC meets the requirements of the CMS Information Security Program and meets HIPAA and FISMA requirements.

PIA Approval

PIA Reviewer Approval: Promote

PIA Reviewer Name: William Saunders

Sr. Official for Privacy Approval: Promote

Sr. Official for Privacy Name: Anthony Trenkle

Sign-off Date: Jun 26, 2009

Approved for Web Publishing: Yes

Date Published: September 1, 2009

_____________________________________________________________________________

06.3 HHS PIA Summary for Posting (Form) / Health Care Quality Improvement Systems

PIA SUMMARY AND APPROVAL COMBINED

PIA Summary

Is this a new PIA? No

If this is an existing PIA, please provide a reason for revision: PIA Validation

1. Date of this Submission: Jun 26, 2009

2. OPDIV Name: CMS

3. Unique Project Identifier (UPI) Number: 009-38-01-06-01-1030-00 009-38-01-06-01-1010-00

4. Privacy Act System of Records (SOR) Number (If response to Q.21 is Yes, a SORN number is required for Q.4): 09-70-0528, 09-70-0521, 09-70-0565, 09-70-0520, 09-70-0531, 09-70-0543, 09-70-0591, 09-70-0574, 09-70-0547, 09-70-0519, 09-70-0522, 09-70-0512, 09-70-0593, 09-70-0594, 09-70-0598, 09-70-0575, 09-70-0569, 09-70-0573, 09-70-0580, 09-70-0584

5. OMB Information Collection Approval Number: 0938-0581

6. Other Identifying Number(s): N/A

7. System Name (Align with system Item name): Health Care Quality Improvement System

9. System Point of Contact (POC). The System POC is the person to whom questions about the system and the responses to this PIA may be addressed: Debbra Hattery

10. Provide an overview of the system: The Consolidated Renal Operations in a Web-enabled Network (CROWN) will facilitate the collection and maintenance of information about the Medicare End Stage Renal Disease (ESRD) program.

CROWN is being developed to modernize the collection and retrieval of ESRD data in a secure, Web-enabled environment. The new capabilities will allow dialysis facilities to enter information electronically and transmit it to the appropriate ESRD Network, and CMS also will be able to send feedback to the Networks and the facilities through the new environment. CROWN consists of the following major modules:

The Vital Information System to Improve Outcomes in Nephrology (VISION), which will support electronic data entry and encrypted transmission of ESRD patient and facility data from dialysis facilities.

The ESRD Standard Information Management System (SIMS) supports the business processes of the ESRD Network Organizations.

The Renal Management Information System (REMIS) which determines the Medicare coverage periods for ESRD patients and serves as the primary mechanism to store and access ESRD patient and facility information.

The Standard Data Processing System (SDPS) consists of many data and reporting requirements and was designed and developed in response to the ongoing information requirements of the Quality Improvement Organizations (QIOs) and other affiliated partners, such as the Clinical Data Abstraction Centers (CDACs) to fulfill their contractual requirements with CMS. This system, which became operational in May 1997, interfaces with CMS Central Office, 53 QIOs and CDACs.

QIES is an application that provides states with the ability to collect assessment data from providers and transmit that data to a central repository for analysis and support of prospective payment systems. The QIES data management system supports a suite of applications/tools designed to provide states and CMS with the ability to use performance information to enhance on-site inspection activities, monitor quality of care, and facilitate providers' efforts related to continuous quality improvement.

Quality Improvement Initiative (QII) is a CMS initiative designed to assist Medicare beneficiaries and their caregivers by promoting the availability of quality measures, helping to ensure that they understand what the measures mean, and encouraging them to use the measures as a part of their health care decision making process. QII touches every aspect of the healthcare system, Partnerships are a key feature of all QII and can include federal and state partners, researchers and academic experts, external stakeholder and consumer organizations, federal contractors, providers and advocates. QIOs will assist Medicare beneficiaries and their caregivers by promoting the availability of the quality measures, helping to ensure that they understand what the measures mean, and encouraging them to use the measures as a part of their healthcare decision making process.

Value-Based Purchasing Program (VBP), which links payment more directly to the quality of care provided, is a strategy that helps to transform the current payment system by rewarding providers for delivering high quality, efficient clinical care. Through a number of public reporting programs, demonstration projects, pilot programs, and voluntary efforts, CMS has launched VBP initiatives in hospitals, physician offices, nursing homes, home health services and dialysis facilities.

13. Indicate if the system is new or an existing one being modified: Existing

21. Is the system subject to the Privacy Act? (If response to Q.19 is Yes, response to Q.21 must be Yes and a SORN number is required for Q.4): Yes

23. If the system shares or discloses IIF please specify with whom and for what purpose(s): Consolidated Renal Operations in a Web-Enabled Environment (CROWN) is a Major Application (MA) whose purpose is to facilitate the collection and maintenance of information about the Medicare ESRD program, its beneficiaries, and the services provided to beneficiaries. The major CROWN applications provide support for CMS organizational business processes by conducting activities that meet the following CMS goals for the ESRD program:

Improve the quality of health care service and quality of life for ESRD beneficiaries;

Improve data reliability, validity, and reporting among ESRD providers/facilities, Networks and CMS (or other appropriate agency).

Establish and improve partnerships and cooperative activities among and between the ESRD Networks, Quality Improvements Organization (QIOs), State survey agencies, ESRD providers/facilities, ESRD facility owners, professional groups, and patient organizations.

Each participating ESRD facility and network will be required to have a workstation with a minimum system configuration as specified by QualityNet Exchange. QualityNet Exchange will provide the ability for ESRD Networks to securely exchange multiple types of data files such as MSWord, Excel, Text, and PowerPoint, in real-time via the Internet. These files could be used for letters, static reports, comparative clinical data, and general information.

Additionally, QualityNet Exchange will provide an interactive, secure web site that will allow End Stage Renal Disease (ESRD) Facilities to transmit electronic patient data to their corresponding ESRD Network. ESRD Networks will use the QualityNet Exchange to transmit "seed" patient databases to Facilities, receive electronic patient data files from Facilities, and provide feedback to Facilities regarding data transmission. QualityNet Exchange will be responsible for routing files to/from the appropriate ESRD Facilities and Networks and ensuring that each Facility and Network can only access their data files.

REMIS will allow users to view ESRD beneficiary and provider information from the eighteen ESRD Network organizations housed in the Standard Information Management System (SIMS) Central Repository.

Internal users:

· ESRD Networks

· CMS OCSQ staff (i.e., the Analysts)

· Application Administrators (i.e., Supervisors, etc.)

· System Administrators (i.e., DBA’s)

· Other CMS users (i.e., Actuaries)

· Developers (i.e., Programmers).

External users:

· ESRD Facilities

· National Institutes of Health (NIH)

· Health Insurance Companies (Medicare Secondary Payers)

Users of the SDPS data systems include: CMS Central and Regional offices, QIOs, Medicare certified inpatient providers, and authorized PMS vendors.

Any ‘sharing’ of this information outside of the group mentioned above can only be approved by CMS. A Data Use Agreement is submitted to CMS for approval.

The Standard Data Processing System (SDPS) is a Major Application (MA) whose purpose is to provide hardware and software tools to enable Quality Improvement Organization personnel to fulfill the requirements of the QIO programs. The primary purpose of the system is to aid in the administration and monitoring of the tasks mandated by the QIO program. These tasks include:

· Improving Beneficiary Safety and Health Through Clinical Quality Improvement in provider settings of: a. Nursing Home; b. Home Health; c. Hospital; d. Physician Office; e. Underserved and Rural Beneficiaries; and f. Medicare + Choice Organizations (M+COs).

· Improving Beneficiary Safety and Health Through Information and Communications by: a. Promoting the Use of Performance Data; b. Transitioning to Hospital-Generated Data; and c. Other Mandated Communications Activities.

· Improving Beneficiary Safety and Health Through Medicare Beneficiary Protection Activities through: a. Beneficiary Complaint Res

VISION provides an electronic data entry and reporting system for the nearly 4000-dialysis facilities in the United States. The information stored in VISION is collected by the ESRD dialysis facility or transplant unit and submitted to the ESRD Networks via Quality Net Exchange. The data collected via the VISION tool is mostly patient registry data to track the patients through their dialysis treatments and transplants. The VISION system also collects some Quality Improvement data via the Clinical Performance Measures tool that will be rolled out this spring. Currently, there are about 135 facilities out of 4600 facilities nationally that are using this system.

Data from VISION is uploaded via Quality Net Exchange to the ESRD Networks. The ESRD Networks import this data into their local SIMS System and perform additional validation and edit checks on the integrity of the data. SIMS, in addition to the patient registry data, also houses clinical data such as vascular access information, and in the near future, electronic laboratory data. Currently, SIMS is used by all employees at every ESRD Network to which all 4600 dialysis facilities and transplant facilities report.

SIMS focuses on the mission critical operations of the ESRD Networks. These operations have been categorized into 5 major areas.

· Form Entry/Submission and Tracking

· Reporting

· Administration

· Database Utilities

· Other SIMS Features

The REMIS (Renal Management Information System) is a web-based interactive database of ESRD patient and provider information located at CMS Data Center in Baltimore, MD. It is used by CMS and the renal community to perform their duties and responsibilities in monitoring Medicare status, transplant activities, dialysis activities, and Medicare utilization (inpatient and physician supplier bills) of ESRD patients and their Medicare providers. REMIS provides a central database for CMS ESRD information.

REMIS will support and improve data collection, validation, and analysis of the ESRD patient population over its predecessor system, REBUS. It will provide timely and accurate analysis information to the ESRD Network organizations, dialysis facilities, transplant centers, and research organizations. This will be accomplished via a Web-based data administration facility and decision support system. REMIS will provide improved support for ESRD program analysis, policy development, and epidemiological research.

REMIS will allow users to view ESRD beneficiary and provider information from the eighteen ESRD Network organizations housed in the Standard Information Management System (SIMS) Central Repository. The Networks provide Beneficiary, Provider, Medical Evidence, Death Notice, and Patient Event data. This information, along with information from CMS systems of record (Medicare Enrollment Data Base, the Common Working File, and the National Claims History, and from the United Network for Organ Sharing (UNOS), is integrated via REMIS.

The data that the SDPS system collects, maintains, and disseminates is as follows:

· summarized data for payment error rates by state and nationally.

· claims,

· case review,

· medical record abstractions,

· payment information

· tracking of medical records,

· helpline and beneficiary complaint information

· raw and rolled up Part A and Part B claims

· tracking information for abstraction of surveillance data,

· beneficiary demographic information for all Medicare beneficiary enrollees,

· clearinghouse of information related to quality improvement information, tools, and techniques.

(Note: Please describe in what format individuals will be given notice of consent [e.g., written notice, electronic notice, etc.]) CROWN: No

SDPS: No

QIES: No

QII: No

VBP: No

32. Does the system host a website? (Note: If the system hosts a website, the Website Hosting Practices section is required to be completed regardless of the presence of PII): Yes

37. Does the website have any information or pages directed at children under the age of thirteen?: No

50. Are there policies or guidelines in place with regard to the retention and destruction of PII? (Refer to the C&A package and/or the Records Retention and Destruction section in SORN): Yes

54. Briefly describe in detail how the IIF will be secured on the system using administrative, technical, and physical controls.: CMS Information Security (IS) Acceptable Risk Safeguards (ARS), FINAL, Version 3.1, April 24, 2008 contains a broad set of required security standards based upon NIST SP 800-53 Revision 1, Recommended Security Controls for Federal Information Systems, data December 2006, and NIST 800-63 Version 1.0.2, Electronic Authentication Guideline, dated, April 2006 as well as additional standards based on CMS Policies, Procedures, and Guidance, other Federal and non-Federal guidance resources and industry leading security practices. This document provides technical guidance to CMS and its contractors as to the minimum level of security controls that must be implemented to protect CMS' information and information systems.

CMS Policy for the Information Security Program, December 31, 2008 (CMS-CIO-POL-SEC02-03.2) sets the ground rules under which CMS shall operate and safeguard its information and information systems to reduce the risk and minimize the effect of security incidents. It serves as the primary source of IT systems security information for all CMS IT users. The policy described therein applies to all users of CMS hardware, software, information and data. The CMS OIS Security Program ensures the existence of adequate safeguards to protect personal, proprietary, and other sensitive data in automated systems and ensures the physical protection of all CMS General Support Systems and Major Applications that maintain and process sensitive data.

QualityNet System Security Policy, Version 5, september 2008, further defines and establishes security controls that apply to all QualityNet systems and users. This QualityNet Policy must be followed by the 3 QualityNet Complexes, 53 QIO sites responsible for each US state, territory, and the District of Columbia; 1 Clinical Data Abstraction Center; and 18 End Stage Renal Disease netowrks.

This policy was established to provide a standard for QualityNet Functional Component users to ensure the confidentiality, integrity, and availability of sensitive medicare information. Users need to understand that taking personal responsibility for the handling, storage, and destruction of sensitive information is an essential part of their job.

This policy document meets the requirements set forth by the Computer Security act of 1987 (P.L. 100-235), the Health Insurance Portability and Accountability Act of 1997 (P.L. 104-191), Appendix III to OMB Circular No. A-130 (50 FR 52730; December 24, 1985), and the CMS Policy for the Information Security Program, November 15, 2007 (CMS-CIO-POL-SEC02-02).

PIA Approval

PIA Reviewer Approval: Promote

PIA Reviewer Name: William Saunders

Sr. Official for Privacy Approval: Promote

Sr. Official for Privacy Name: Anthony Trenkle

Sign-off Date: Jun 26, 2009

Approved for Web Publishing: Yes

Date Published: September 1, 2009

_____________________________________________________________________________

06.3 HHS PIA Summary for Posting (Form) / Healthcare Integrated General Ledger Accounting System

PIA SUMMARY AND APPROVAL COMBINED

PIA Summary

Is this a new PIA? No

If this is an existing PIA, please provide a reason for revision: PIA Validation

1. Date of this Submission: Jun 26, 2009

2. OPDIV Name: CMS

3. Unique Project Identifier (UPI) Number: 009-38-01-01-1020-00-402-124

4. Privacy Act System of Records (SOR) Number (If response to Q.21 is Yes, a SORN number is required for Q.4): 09-70-0501, 09-70-0503, 09-90-0024

5. OMB Information Collection Approval Number: N/A

6. Other Identifying Number(s): N/A

7. System Name (Align with system Item name): Healthcare Integrated General Ledger Accounting System (HIGLAS)

9. System Point of Contact (POC). The System POC is the person to whom questions about the system and the responses to this PIA may be addressed: Janet Vogel

10. Provide an overview of the system: To provide, in a production environment, a dual entry US Standard General Ledger accounting system and standardized accounting and financial management reporting process for CMS central office administrative program accounting activity and for the Medicare Program Benefits administered by the Medicare Fee-For-Service Claims Processing Contractors.

13. Indicate if the system is new or an existing one being modified: Existing

21. Is the system subject to the Privacy Act? (If response to Q.19 is Yes, response to Q.21 must be Yes and a SORN number is required for Q.4): Yes

23. If the system shares or discloses IIF please specify with whom and for what purpose(s): N/A

HIGLAS incorporates financial data that is focused on CMS' Administrative Program Accounting (APA), Budget Execution, Purchasing, Payable, Receivable, and Grant activities. The main information maintained is supplier/customer values, ACS values, cross validation rules, security rules, and CAN/BACS Crosswalks (CAN, Object Classes and USSGL) information in order to accurately account for all APA accounting events. All accounting events, except for Medicaid and CHIP government awards and funding related to this event, is collected by the CMS Legacy Financial and Accounting Control System (FACS) which in turn, via a FACS Staging Layer, populated HIGLAS with data needed to record accounting events to facilitate the generation of Financial Statements.

CMS Accoutning Staff utilize HIGLAS directly to record and process accounting events (funding, obligations, advances, and expenditures) for the Medicaid/CHIP government awards.

(Note: Please describe in what format individuals will be given notice of consent [e.g., written notice, electronic notice, etc.]) HIGLAS does not collect IIF.

32. Does the system host a website? (Note: If the system hosts a website, the Website Hosting Practices section is required to be completed regardless of the presence of PII): No

37. Does the website have any information or pages directed at children under the age of thirteen?: No

50. Are there policies or guidelines in place with regard to the retention and destruction of PII? (Refer to the C&A package and/or the Records Retention and Destruction section in SORN): Yes

54. Briefly describe in detail how the IIF will be secured on the system using administrative, technical, and physical controls.: HIGLA uses state-of-the-art technological methods to secure IIF. HIGLAS provides a much higher level of information security than previously available by meeting the following requirements for effective records security:

- Ensures that only authorized personnel have access to electronic records

- Ensures that appropriate agency personnel are trained to safeguard sensitive or classified electronic records

- Ensures that appropriate contractor staff working as agents for the agency are trained to safeguard sensitive or classified electronic records

- Minimizes the risk of unauthorized alteration or erasure of electronic records

- Ensures that electronic records security is included in computer systems security plan prepared sersuant to the Computer Security Act of 1987, HIPAA of 1996, Privacy Act of 1974, OMB Circulars A-123, A-127 and A-130, Government Information Security Reform Act of 1996, Federal Financial Management Improvement Act of 1996 (FFMIA), FSIO OFFM Core Financial System Requirements (OFFM-No-0106, January 2006).

Users have access only to the data required to perform their dutied in the ORG to which they are assigned.

PIA Approval

PIA Reviewer Approval: Promote

PIA Reviewer Name: William Saunders

Sr. Official for Privacy Approval: Promote

Sr. Official for Privacy Name: Anthony Trenkle

Sign-off Date: Jun 26, 2009

Approved for Web Publishing: Yes

Date Published: September 1, 2009

_____________________________________________________________________________

06.3 HHS PIA Summary for Posting (Form) / Human Resources Management Systems

PIA SUMMARY AND APPROVAL COMBINED

PIA Summary

Is this a new PIA? No

If this is an existing PIA, please provide a reason for revision: PIA Validation

1. Date of this Submission: Jun 26, 2009

2. OPDIV Name: CMS

3. Unique Project Identifier (UPI) Number: 009-38-02-00-01-1150-00

4. Privacy Act System of Records (SOR) Number (If response to Q.21 is Yes, a SORN number is required for Q.4): 09-70-3005

5. OMB Information Collection Approval Number: No

6. Other Identifying Number(s): No

7. System Name (Align with system Item name): Human Resources Management Systems

9. System Point of Contact (POC). The System POC is the person to whom questions about the system and the responses to this PIA may be addressed: Faraja Bryant-Ricketts, OOM/APSS, 410-786-2068

10. Provide an overview of the system: *10. Provide an overview of the system:

CHRIS - The CMS Human Resources Information System is a portal for all CMS Human Resources and Personnel related data. This portal is a respository of information related to CMS employees. This portal is used by Human Resources and Management type personnel.

ITSP-CBT – The 2002 FISMA requires all users of the Federal information systems to be exposed to security awareness materials at least annually. The ITSP-CBT provides CMS with the means to meet this requirement by providing basic information security awareness training to all individuals who have been issued a CMS USERID and have access to CMS information systems, to include but not limited to: CMS employees, contractors, students, guest researchers, visitors and others.

FLSATRAV - The CMS FLSA Travel Tool allows CMS employees to arrive at results decisions for Travel Overtime and Compensatory Time In Lieu of Overtime travel. The static document (Travel Worksheets) has been automated to assist employees in deriving the appropriate conclusion as to whether or not time is compensable or not according the regulation and law.

HOCTS- The HOCTS is used to track cases/appeals received in the Office of Hearings. The system tracks actions taken on each case/appeal; tracks the participants associated with each case/appeal; tracks issues associated with each case/appeal; tracks hearing dates; and generates letters and reports as needed.

OATS – The OATS application is a desktop application that allows selected users to review, update, add and report tasks and assignments at various designated levels.

MGCRB Case Tracker - The system is used to track cases/appeals received in the Office of Medicare Adjudication.

MGCRB Calc - The system is used to track cases/appeals received in the Office of Medicare Adjudication.

PRRB – The PRRB Case Tracker is used to track cases/appeals received in the Office of Medicare Adjudication. The system tracks actions taken on each case/appeal; tracks the participants associated with each case/appeal; tracks issues associated with each case/appeal; tracks hearing dates; and generates letters and reports as needed. The PRRB Case Tracker is written in Visual Basic and was developed for the Office of Hearings. The PRRB Case Tracker is a module of the Office of Hearings case tracking system. PRRB Case Tracker was implemented in 05/03. PRRB Case Tracker consists of a Microsoft Access database located on a shared drive in the CMS Data Center.

OIGHTLNE – The OIG Hotline is used to store OIG Hotline complaints for Medicare Frauds & Abuses purposes.

ONREG – The CMS Online Registration System (ONREG) allows CMS employees to register for training courses and calendar events on-line via a web interface. The ONREG system is an integrated system that allows immediate access to training information, as well as, the ability to add and track training courses and calendar events.

CMS Badge System – The CMS Badge system is an application that collects and houses necessary data to ensure that access to CMS Building, during both regular and security hours is restricted and to guard against unauthorized entry.

13. Indicate if the system is new or an existing one being modified: Existing

21. Is the system subject to the Privacy Act? (If response to Q.19 is Yes, response to Q.21 must be Yes and a SORN number is required for Q.4): Yes

23. If the system shares or discloses IIF please specify with whom and for what purpose(s): No

CHRIS contains personally identifiable information of Name, SSN, DOB, Vehicle ID, Education, Employment Status, this information is used by Personnel and is only accessed by persons with management authority. The information is password protected with security protocols.

ITSP-CBT - N/A

FLSATRAV - N/A

HOCTS - N/A

OATS - N/A

PRRB - N/A

OIGHTLNE - N/A

MGCRB contains Name, Mailing Address, Phone Numbers and Email Address, this information is used by Personnel and is only accessed by persons with management authority. The information is password protected with security protocols.

ONREG contains Names and Email Addresses,

CMS Badge contains Name, Work Location, Work Address and Phone Number and Photo Identification, this information is used by Personnel and is only accessed by persons with management authority. The information is password protected with security protocols.

(Note: Please describe in what format individuals will be given notice of consent [e.g., written notice, electronic notice, etc.]) The subject individual should write to the system manager who will require the system name, health insurance claim number, address, age, and sex and for verification purposes, the subject individual's name (woman's maiden name, if applicable) and social security number.

32. Does the system host a website? (Note: If the system hosts a website, the Website Hosting Practices section is required to be completed regardless of the presence of PII): No

37. Does the website have any information or pages directed at children under the age of thirteen?: No

50. Are there policies or guidelines in place with regard to the retention and destruction of PII? (Refer to the C&A package and/or the Records Retention and Destruction section in SORN): Yes

54. Briefly describe in detail how the IIF will be secured on the system using administrative, technical, and physical controls.: CHRIS contains personally identifiable information of Name, SSN, DOB, Vehicle ID, Education, Employment Status, this information is used by Personnel and is only accessed by persons with management authority. The information is password protected with security protocols.

ITSP-CBT - N/A

FLSATRAV - N/A

HOCTS - N/A

OATS - N/A

PRRB - N/A

OIGHTLNE - N/A

ONREG contains Names and Email Addresses,

PIA Approval

PIA Reviewer Approval: Promote

PIA Reviewer Name: William Saunders

Sr. Official for Privacy Approval: Promote

Sr. Official for Privacy Name: Anthony Trenkle

Sign-off Date: Jun 26, 2009

Approved for Web Publishing: Yes

Date Published: September 1, 2009

_____________________________________________________________________________

06.3 HHS PIA Summary for Posting (Form) / Integrated Data Repository

PIA SUMMARY AND APPROVAL COMBINED

PIA Summary

Is this a new PIA? No

If this is an existing PIA, please provide a reason for revision: PIA Validation

1. Date of this Submission: Jun 26, 2009

2. OPDIV Name: CMS

3. Unique Project Identifier (UPI) Number: 009-38-01-06-01-1120-00

4. Privacy Act System of Records (SOR) Number (If response to Q.21 is Yes, a SORN number is required for Q.4): 09-70-0571

5. OMB Information Collection Approval Number: NA

6. Other Identifying Number(s): NA

7. System Name (Align with system Item name): Integrated Data Repository

9. System Point of Contact (POC). The System POC is the person to whom questions about the system and the responses to this PIA may be addressed: William Craig Mooney

10. Provide an overview of the system: IDR - The Integrated Data Repository is the Agency storage structure for detailed Medicare and Medicaid claims information.

13. Indicate if the system is new or an existing one being modified: Existing

21. Is the system subject to the Privacy Act? (If response to Q.19 is Yes, response to Q.21 must be Yes and a SORN number is required for Q.4): Yes

23. If the system shares or discloses IIF please specify with whom and for what purpose(s): CMS staff & contractors, Federal & state agencies, researchers, OIG, GAO, DOJ for various studies, program oversight and fraud & abuse

(Note: Please describe in what format individuals will be given notice of consent [e.g., written notice, electronic notice, etc.]) NA

32. Does the system host a website? (Note: If the system hosts a website, the Website Hosting Practices section is required to be completed regardless of the presence of PII): No

37. Does the website have any information or pages directed at children under the age of thirteen?: No

50. Are there policies or guidelines in place with regard to the retention and destruction of PII? (Refer to the C&A package and/or the Records Retention and Destruction section in SORN): Yes

54. Briefly describe in detail how the IIF will be secured on the system using administrative, technical, and physical controls.: IDR operates in the CMS Data Center

PIA Approval

PIA Reviewer Approval: Promote

PIA Reviewer Name: William Suanders

Sr. Official for Privacy Approval: Promote

Sr. Official for Privacy Name: Anthony Trenkle

Sign-off Date: Jun 26, 2009

Approved for Web Publishing: Yes

Date Published: September 1, 2009

_____________________________________________________________________________

06.3 HHS PIA Summary for Posting (Form) / IT Management Systems

PIA SUMMARY AND APPROVAL COMBINED

PIA Summary

Is this a new PIA? No

If this is an existing PIA, please provide a reason for revision: PIA Validation

1. Date of this Submission: Jun 26, 2009

2. OPDIV Name: CMS

3. Unique Project Identifier (UPI) Number: 009-38-03-00-02-1010-00 009-38-02-00-01-1150-00

4. Privacy Act System of Records (SOR) Number (If response to Q.21 is Yes, a SORN number is required for Q.4): 09-70-3005

5. OMB Information Collection Approval Number: N/A

6. Other Identifying Number(s): N/A

7. System Name (Align with system Item name): IT Management Services

9. System Point of Contact (POC). The System POC is the person to whom questions about the system and the responses to this PIA may be addressed: Jerry J. Williams

10. Provide an overview of the system: The Correspondence Inquiry System (CIS) is the agency’s

correspondence tracking, receiving and document workflow system.

It is used to collect and store internal and external document request,

program inquiries, congressional inquiries, and the agency's responses

to these inquiries and requests. It also allows the tracking and

progress of work items and reassign them to different users, or

components as necessary. It replaces hard-copy folders and documents

with electronic files that can be routed easily to the next user or group

involved with the document processing. It is currently a 16 bit

application and can not be modified or upgraded with out significant

cost.

13. Indicate if the system is new or an existing one being modified: Existing

21. Is the system subject to the Privacy Act? (If response to Q.19 is Yes, response to Q.21 must be Yes and a SORN number is required for Q.4): Yes

23. If the system shares or discloses IIF please specify with whom and for what purpose(s): System does not discloses or allow any information to be shared with other applications, agencies or outside sources.

(Note: Please describe in what format individuals will be given notice of consent [e.g., written notice, electronic notice, etc.]) No consent has been required, since any changes to the system will have no effect as to how the IIF data can be accessed. Storage of the information follows the privacy act guidelines and No information is shared or actively collected.

32. Does the system host a website? (Note: If the system hosts a website, the Website Hosting Practices section is required to be completed regardless of the presence of PII): No

37. Does the website have any information or pages directed at children under the age of thirteen?: No

50. Are there policies or guidelines in place with regard to the retention and destruction of PII? (Refer to the C&A package and/or the Records Retention and Destruction section in SORN): Yes

54. Briefly describe in detail how the IIF will be secured on the system using administrative, technical, and physical controls.: Restrictive Access to the System and Data. Only the administrator and selected users c an modify the data without accessing the system. this is done using a utility that was written to help maintain the integrity of the data, Access is restricted, and can be granted only by the administrator.

PIA Approval

PIA Reviewer Approval: Promote

PIA Reviewer Name: William Saunders

Sr. Official for Privacy Approval: Promote

Sr. Official for Privacy Name: Anthony Trenkle

Sign-off Date: Jun 26, 2009

Approved for Web Publishing: Yes

Date Published: September 1, 2009

_____________________________________________________________________________

06.3 HHS PIA Summary for Posting (Form) / Medicaid & State Children's Health Insurance Systems

PIA SUMMARY AND APPROVAL COMBINED

PIA Summary

Is this a new PIA? No

If this is an existing PIA, please provide a reason for revision: PIA Validation

1. Date of this Submission: Jun 26, 2009

2. OPDIV Name: CMS

3. Unique Project Identifier (UPI) Number: 009-38-01-06-01-1010-00 009-38-01-04-01-1060-00

4. Privacy Act System of Records (SOR) Number (If response to Q.21 is Yes, a SORN number is required for Q.4): 09-70-0541, 09-70-0510, 09-70-0578

5. OMB Information Collection Approval Number: CMS-416 OMB#0938-0354 Expiration Date: 03-31-2009;

CMS-64 OMB# 0938-0067 Expiration Date: 06/30/2008,

CMS-21 & 21B OMB# 0938-0731 Expiration Date 06/30/2008, CMS-37 OMB# 0938-0101 Expiration Date 06/30/2008;

OMB# 0938-0707, Expiration Date 05

6. Other Identifying Number(s): CMS-R-0284

7. System Name (Align with system Item name): Medicaid & Children's Health Insurance System

9. System Point of Contact (POC). The System POC is the person to whom questions about the system and the responses to this PIA may be addressed: Dona Coffman; Cora Burch; Marcus Koenig; David Baugh

10. Provide an overview of the system: EPSDT: The Early and Periodic Screening, Diagnostic and Treatment (EPSDT) Data System is a web-based Intranet application for use by the Centers for Medicare & Medicaid Services (CMS).

The annual EPSDT Report (Form CMS-416) provides basic information on participation in the Medicaid child health program. The information is used to assess the effectiveness of State EPSDT programs in terms of the number of children (by age group and basis of Medicaid eligibility), who are provided child health screening services, referred for corrective treatment, and the number receiving dental services. Child health-screening services are defined, for purposes of reporting on Form CMS-416, as initial periodic screens required to be provided according to a State’s screening periodicity schedule.

The complete report demonstrates the State’s attainment of its participant and screening goals. Participant and screening goals are two different standards against which EPSDT participation is measured on the Form CMS-416. From the completed reports, trend patterns and projections are developed for the nation and for individual States or geographic areas, from which decisions and recommendations can be made to ensure that eligible children are given the best possible health care. This information is also used to respond to congressional and public inquires.

FULs: The Federal Upper Limit System (FULs) determines the highest allowable Medicaid price for Federal Drug Administration (FDA) approved drugs. This price is derived from manufacturer prices obtained from external sources: Medispan, Blue Book and Red Book. The primary output from this system is the “Payment for Services Report” which lists all products along with their strengths, dosage form, route of administration, package size, the FULs price and source.

SPW: The State Plan Amendment and Waiver Tracking System (SPW) is an information tracking system that tracks State Plan Amendments and Waivers from their initial submittal to their final determination in a common format and Central Office database. This system tracks the following: State Plan Amendments (SPA), PACE SPAs, SCHIP SPAs, 1115 waivers, 1115 Independence Plus waivers, 1915(b) waivers, 1915(c) waivers, and 1915(c) Independence Plus waivers.

MDR: The Medicaid Drug Rebate (MDR) System is composed of an online and batch system that collects drug manufacturers product and price information and state drug utilization data for drugs given to State Medicaid recipients. The system calculates the quarterly unit drug rebates that are then sent to the states for invoicing drug manufacturers each quarter.

MBES/CBES: MBES\CBES collects and stores States Medicaid budgets & expenditure information. The system is used by states to submit budget and expenditure data for the Medicaid and State Children’s Health Insurance Program to CMS. CMS’ Regional Office personnel review the state submissions and enter analysis into the system. All activity is reviewed and certified by CMS Central Office personnel. Summarized data from this information is publicly available on the CMS Public web site.

CHIP/SEDS: The Children’s Health Insurance Program (CHIP) Statistical Database Enrollment System (SEDS) is a system that states use to submit enrollment and demographic data for the CHIP Program to CMS. CMS' Regional Office personnel review the state submissions and enter analysis into CHIP SEDS. All of this activity is reviewed and certified by CMS Central Office personnel.

IBNRS: The Incurred But Not Reported Survey system is a web-based application used by CMS biannually both to report estimated expeditures for the Medicaid Programs and State Children's Health Insurance Program. The purpose of the IBNRS application is to create an online version of two forms - the CMS-R199, Form for the Medicaid Accounts Payable and Accounts Receivable as well as the CMS-10180, Form for the SCHIP Accounts Payable and Accounts Rece

13. Indicate if the system is new or an existing one being modified: Existing

21. Is the system subject to the Privacy Act? (If response to Q.19 is Yes, response to Q.21 must be Yes and a SORN number is required for Q.4): Yes

23. If the system shares or discloses IIF please specify with whom and for what purpose(s): EPSDT: N/A

FULs: N/A

SPW: N/A

MDR: N/A

MBES/CBES: N/A

CHIP SEDS: N/A

IBNRS: N/A

S&C/CLIA: N/A

MSIS/MAX: Census Bureau for state population, Congressional Budget Office

and for analysis and research purposes and organizations operating under an

approved Data User Agreement such as the Urban Institute.

CARTS: N/A

DDR: N/A

FULs: N/A

SPW: Name: required to request access to the system.

MDR: Name: required for the purpose of establishing company contact information or determining system internal application permissions; Email: company email address, optional for the purpose of business correspondence.

MBES/CBES: Name: required to request access o the system and determining system internal application permissions; Email: company email address, required for the purpose of business correspondence.

CHIP/SEDS: Name: required to request access to the system and determining system internal application permissions; Email: company email address, required for the purpose of business correspondence.

IBNRS: Name: required to request access to the system and determining system internal application permissions; Email: company email address, required for the purpose of business correspondence.

S&C/CLIA: Name: required to request access to the system and determinign system internal application permissions; Email: company email address, required for the purpose of business correspondence.

MSIS/MAX: Date of Birth, Social Security Number

CARTS: Name: required to request access to the system and determining system internal application permissions; Email: company email address, required for hte purpose of business correspondence.

DDR: Name: required to request access to the system and determining system internal application permissions; Email: company email address, required for the purpose of business correspondence.

(Note: Please describe in what format individuals will be given notice of consent [e.g., written notice, electronic notice, etc.]) EPSDT: N/A

FULs: N/A

SPW: N/A

MDR: N/A

MBES/CBES: N/A

CHIP SEDS: N/A

IBNRS: N/A

S&C/CLIA: N/A

MSIS/MAX: N/A

CARTS: N/A

DDR: N/A

32. Does the system host a website? (Note: If the system hosts a website, the Website Hosting Practices section is required to be completed regardless of the presence of PII): Yes

37. Does the website have any information or pages directed at children under the age of thirteen?: No

50. Are there policies or guidelines in place with regard to the retention and destruction of PII? (Refer to the C&A package and/or the Records Retention and Destruction section in SORN): Yes

54. Briefly describe in detail how the IIF will be secured on the system using administrative, technical, and physical controls.: EPSDT: Rules of Least Privilage; Authorized personell with approved user ID and password; firewall and intrusion detection; Guards;

Identification Badges; Key Cards

FULs: Rules of Least Privilage; Authorized personell with approved user ID and password; firewall and intrusion detection; Guards;

Identification Badges; Key Cards

SPW: Rules of Least Privilage; Authorized personell with approved user ID and password; firewall and intrusion detection; Guards;

Identification Badges; Key Cards

MDR: Rules of Least Privilage; Authorized personell with approved user ID and password; firewall and intrusion detection; Guards; Identification Badges; Key Cards

MBES/CBES: Rules of least privilege; authorized personnel with approved user Id and password; firewall and intrusion detection; Identification Badges; Key Cards; Closed Circuit TV (CCTV)

CHIP/SEDS: Rules of least privilege; authorized personnel with approved user Id and password; firewall and intrusion detection; Identification Badges; Key Cards; Closed Circuit TV (CCTV)

IBNRS: Rules of least Privilege; authorized personnel with approved user ID and password; firewall and intrusion detection; Identification Badges; Key Cards; Close Circuit TV

S&C/CLIA: Rules of least privilege; authorized personnel with approved user Id and password; firewall and intrusion detection; Identification Badges; Key Cards; Closed Circuit TV (CCTV)

MSIS/MAX: Rules of Least Privilage; Authorized personell with approved user ID and password; firewall and intrusion detection; Guards;

Identification Badges; Key Cards

CARTS: Rules of least privilege; authorized personnel with approved user Id and password; firewall and intrusion detection; Identification Badges; Key Cards; Closed Circuit TV (CCTV)

DDR: Rules of least Privilege; authorized personnel with approved user ID and password; firewall and intrusion detection; Identification Badges, Key Cards, Closed Circuit TV

PIA Approval

PIA Reviewer Approval: Promote

PIA Reviewer Name: William Saunders

Sr. Official for Privacy Approval: Promote

Sr. Official for Privacy Name: Anthony Trenkle

Sign-off Date: Jun 26, 2009

Approved for Web Publishing: Yes

Date Published: September 1, 2009

_____________________________________________________________________________

06.3 HHS PIA Summary for Posting (Form) / Medicaid Integrity Systems

PIA SUMMARY AND APPROVAL COMBINED

PIA Summary

Is this a new PIA? No

If this is an existing PIA, please provide a reason for revision: PIA Validation

1. Date of this Submission: Jun 26, 2009

2. OPDIV Name: CMS

3. Unique Project Identifier (UPI) Number: -

4. Privacy Act System of Records (SOR) Number (If response to Q.21 is Yes, a SORN number is required for Q.4): 09-70-0599

5. OMB Information Collection Approval Number: NA

6. Other Identifying Number(s): NA

7. System Name (Align with system Item name): Medicaid Integrity Systems (MIG)

9. System Point of Contact (POC). The System POC is the person to whom questions about the system and the responses to this PIA may be addressed: Mark Anderson

10. Provide an overview of the system: The MIG data engine is a data repository for Medicaid claims and associated data. The system will support the analysis or provider claims to help detect fraud, waste, and abuse within the Medicaid program.

13. Indicate if the system is new or an existing one being modified: Existing

21. Is the system subject to the Privacy Act? (If response to Q.19 is Yes, response to Q.21 must be Yes and a SORN number is required for Q.4): Yes

23. If the system shares or discloses IIF please specify with whom and for what purpose(s): PII data will be accessible to MIG analysts and Medicaid Integrity contractors and group analysts for analytical fraud, waste and abuse detection.

(Note: Please describe in what format individuals will be given notice of consent [e.g., written notice, electronic notice, etc.]) NA as the system is not the collector of PII data.

32. Does the system host a website? (Note: If the system hosts a website, the Website Hosting Practices section is required to be completed regardless of the presence of PII): Yes

37. Does the website have any information or pages directed at children under the age of thirteen?: -

50. Are there policies or guidelines in place with regard to the retention and destruction of PII? (Refer to the C&A package and/or the Records Retention and Destruction section in SORN): -

54. Briefly describe in detail how the IIF will be secured on the system using administrative, technical, and physical controls.: PII is secured useing a layered "Defense in Depth" model.

PIA Approval

PIA Reviewer Approval: Promote

PIA Reviewer Name: William Saunders

Sr. Official for Privacy Approval: Promote

Sr. Official for Privacy Name: Anthony Trenkle

Sign-off Date: Jun 26, 2009

Approved for Web Publishing: Yes

Date Published: September 1, 2009

_____________________________________________________________________________

06.3 HHS PIA Summary for Posting (Form) / Medicare Advantage and Prescription Drug Plan Operation System

PIA SUMMARY AND APPROVAL COMBINED

PIA Summary

Is this a new PIA? No

If this is an existing PIA, please provide a reason for revision: PIA Validation

1. Date of this Submission: Jun 26, 2009

2. OPDIV Name: CMS

3. Unique Project Identifier (UPI) Number: 009-38-01-04-01-1090-00 009-38-01-04-02-1080-00 009-38-01-04-02-1095-00 009-38-01-04-01-1085-00 009-38-01-04-01-1075-00 009-38-02-00-01-1150-00

4. Privacy Act System of Records (SOR) Number (If response to Q.21 is Yes, a SORN number is required for Q.4): 09-70-4001, 09-70-0500, 09-70-0552, 09-70-0553, 09-70-0557, 09-70-0564

5. OMB Information Collection Approval Number: N/A

6. Other Identifying Number(s): N/A

7. System Name (Align with system Item name): Medicare Advantage and Prescription Drug Plan Operation System

9. System Point of Contact (POC). The System POC is the person to whom questions about the system and the responses to this PIA may be addressed: Ed Howard

10. Provide an overview of the system: AAPCC: Supports payment to Medicare Advantage plans by feeding essential information and data into the Medicare Advantage System. The AAPCC application captures Medicare enrollment and demographic dat that is used as input to the Medicare Advantage application which calculated payment rates to managed care organizations. A by-product of this system is the tabulation of annual Medicare reimbursement and enrollment on a county basis. the enrollment includes all medicare beneficiaries, whereas the reimbursement includes only claims paid by intermediaries and carriers, i.e., it excludes capitation payments made to HMO and similar organizations.

APPS - PROCESS AND MAINTAIN PAYMENT INFORMATION FOR MEDICARE ADVANTAGE PLAN AND PRESCRIPTION DRUG PLANS.

DDPS – This system processes all Medicare covered and non-covered drug events, including non-Medicare drug events for Medicare beneficiaries participating in the Part D programs. The system processes Prescription Drug Event (PDE) transactions and related data as necessary to validate/authenticate Medicare payment of covered drugs made by plans for enrolled Medicare beneficiaries.

HPMS – HPMS is a web-enabled information system that supports the ongoing business operations of the Medicare Advantage and Prescription Drug programs. HPMS software modules collect data for and manage the following MA and PArt D plan enrollment processes: application submission, formulary submission, bid and benefit package submissions, marketing material reviews, plan monitoring and oversight, complaints tracking, plan connectivity, financial reporting, financial and plan bid audits, plan surveys, operational data feeds for enrollment, payment, and premium withhold, and data support for the Medicare & you handbook and the www.medicare.gov website.

MARX – MARx is an enhancement of the Medicare Managed Care System (MMCS), with changes for the implementation of the Medicare Modernization Act (MMA).

MIIR – MIIR is a data repository created to report on Medicare Beneficiary Part D information at the aggregate level in support of MMA reporting requirements. It is a reporting tool using information from various sources to support the Part D drug coverage benefit, used to measure effectiveness and manage enrollment and utilization efforts. This system is used by CMS internal staff only.

PWS – The Premium Withhold Subsystem tracks Part C and/or Part D beneficiary level premium payments for the entire Medicare population (approximately 40 million beneficiaries) who elect either Part C - Medicare Advantage - or Part D - Medicare prescription drug coverage, including managing the data exchange for Medicare beneficiaries who elect to have their premiums withheld by OPM, SSA, or RRB.

RAS – The Risk Adjustment Suite of Software are modules within the Medicare Modernization Act (MMA) program. The Risk Adjustment Suite of Software receives diagnostic and beneficiary data from other systems, stages the data, calculates Risk Adjustment Factors (RAFs), feeds the RAFs to other systems within MMA, and provides reports on the resulting factors.

TROOP - This system provides MBD and COB info to the TrOOP facilitator.

SPDBS- The SPDBS is the CMS system of record for billing and processing the collection on monies from the states to defray a portion of the Medicare drug expenditures for individuals whose projected Medicaid drug coverage is assumed by Medicare Part D. The SPDBS was developed as a COBOL program and flat file batch process and resides on the mainframe at the CMS Computer Center. The SPDBS does not interface with any databases of CICS.

MPC: Determines the Medicare Plus Choice payment rates for every State by county. These rates are fed into the Automated Plan Payment System Database. The APPS uses these rates to make payments on behalf of MEdicare beneficiaries who choose to obtain Medicare benefits through private health plans under the MEdicare Advantage program.

PRS - PRS

13. Indicate if the system is new or an existing one being modified: Existing

21. Is the system subject to the Privacy Act? (If response to Q.19 is Yes, response to Q.21 must be Yes and a SORN number is required for Q.4): Yes

23. If the system shares or discloses IIF please specify with whom and for what purpose(s): APPS – None

DDPS – All reporting/data access is restricted to mandated and authorized users of the data with statutory authority as described in the MMA legislation, which includes:

Those necessary to implement, operate, and support the developed system;

The CSSC at Palmetto requiring PDE and beneficiary data access;

The MDBG within CBC responsible for benefit implementation, program administration, and program oversight;

The Medicare PIG within OFM responsible for protecting program integrity and detecting waste, fraud, and abuse of the program;

The QIO contracted by OCSQ responsible for clinical quality and evaluation of health care outcome of the benefit; and

The 723 initiative being coordinated by ORDI responsible for developing integrated databases.

HPMS – HPMS will make the complaints tracking data available via reports and extracts to CMS staff for plan oversight and monitoring. It may also be necessary to share these data with other federal agencies (e.g., FBI, OIG) if further investigation of a Part D organization is required.

MARX – Internal – MBD for determining beneficiary demographic data and identifying information, RAS for risk adjustment rates, PWS for withholding data Gentran / EFT for communicating beneficiary and plan data, NGD for processing disenrollments from the 1800Medicare, Retiree Drug Subsidy (RDS) for rejected enrollments, and IACS for identity management of users.

MIIR – Yes, developers/contractors may see IIF data only for development of MIIR, not to be displayed to users.

PWS – External – SSA, to be able to provide withholding information for beneficiaries

Internal – MARx, MBD to get information about beneficiaries and plans.

RAS – Internal – MARx, MBD for determining beneficiary demographic data and identifying information, NMUD for diagnosis data of a beneficiary

TROOP – Pharmacies and Part D plan sponsors for administration of the Part D benefit

SPDBS: N/A.

MPC: N/A.

AAPCC: N/A PRS: System shares IIF with Part D plans in which these individuals are enrolled for purposes of explaining costs and payments used in calculating the reconciliation.

DDPS – The system contains both detailed and summary prescription drug claim information on all Medicare covered and non-covered drug events, including non-Medicare drug events, for Medicare beneficiaries of the Medicare program. This system contains both detailed and summary prescription drug claim data, health insurance claim number, card holder identification number, date of service, gender, and optionally, the date of birth. The system contains provider characteristics, prescriber identification number, assigned provider number (facility, referring/servicing physician), and national drug code. The system contains beneficiary, plan, and supplemental payment amounts. Submission of PII is mandatory - as a condition of payment, all Part D plans must submit data and information necessary for CMS to carry out payment provisions.

HPMS – HPMS collects the name, mailing address, e-mail address, and/or phone number of the beneficiary reporting a complaint related to the Part D program. All fields are optional. CMS will use these data to resolve beneficiary complaints and track plan performance.

MARX – MARX is not the system of record (SOR) for PII , but it does store and process PII regarding system users, beneficiary’s healthplan enrollment and plan payment information. The enrollment of beneficiaries into healthplans is provided from the plans, or from the deeming and autoenrollment enrollments from MBD. Policies regarding the voluntary or mandatory nature of the PII are the responsibility of the systems that provide the enrollment transactions to MARx.

MIIR – MIIR maintains Beneficiary demographics, LIS, and enrollment information from other CMS source systems to be used for reporting aggregate numbers by CMS staff in support of Executive management needs for MMA Part D reporting and analysis.

PWS – PWS is not the system of record (SOR) for PII , but it does store and process PII regarding beneficiary’s healthplan enrollment, plan payment information., and individual’s social security status and identifiers. Policies regarding the voluntary or mandatory nature of the PII are the responsibility of the systems that provide the beneficiaries or plan data to PWS.

RAS – RAS assesses the health risk presented by Beneficiaries to enable the MMCS to produce an appropriate risk based payment to the Managed Care Organizations (MCO). Additionally, RAS requires information from several other application systems. RAS is not the system of record (SOR) for ANY of the PII, but it does store and process PII. Policies regarding the voluntary or mandatory nature of the PII are the responsibility of the SORs for that PII.

TROOP – Disseminate eligibility/ enrollment and 4Rx data to pharmacists and COB info to plans.

SPDBS: Once a month, the SPDBS receives as input three flat files provided by CMS internal components. CMSO and the MBD provide one dataset containing a count of the number of new MEdicare beneficiary enrollments and disenrollments for which the states are to be held responsible. OACT provides on dataset containing the monthly state billing rates to be applied. OFM provides on dataset containing a record of the state payments that have been posted in the previous month. SPDBS simply receives the new state enrollment counts from the MBD, multiplies those numbers by the billing rates from OACT to generate a new state liability charge. SPDBS then develops a Summary Accounting Statement showing the previous months balance, the payments posted provided by OFM, the new liability charges that have been calculated, and the resulting new account balance. All this information is also recorded in a state account ledger and other CMS billing summary documentation.

AAPCC: Supports payment to MEdicare Advantage plans by feeding essential information and data into the Medicare Advantage System. The AAPCC application captures Medicare enrollment and demographic d

(Note: Please describe in what format individuals will be given notice of consent [e.g., written notice, electronic notice, etc.]) APPS – NONE

DDPS – Participation in Part D is voluntary and requires an affirmative election to join. When an individual enrolls in a Part D Plan, as part of the application package, the beneficiary has to sign the Agreement page; thus, MMA Part D enrollment equates beneficiary consent.

Authority for maintenance of this system is given under provisions of the

Medicare Prescription Drug, Improvement, and Modernization Act,

amending the Social Security Act (the Act) by adding Part D under Title XVIII (§ 1860D–15(c)(1)(C) and (d)(2), as described in 42 Code of Federal

Regulation (CFR) 423.401.

The Privacy Act permits us to disclose information without an individual’s consent if the information is to be used for a purpose that is compatible with the purpose(s) for which the information was collected. Any such disclosure of data is known as a ‘‘routine use.’’

This system contains Protected Health Information as defined by HHS regulation ‘‘Standards for Privacy of Individually Identifiable Health Information’’ (45 CFR Parts 160 and 164, 65 FR 82462 (Dec. 28, 00), as amended by 66 FR 12434 (Feb. 26, 01)). Disclosures of Protected Health Information authorized by these routine uses may only be made if, and as, permitted or required by the ‘‘Standards for Privacy of Individually identifiable Health Information.’’

In addition, our policy will be to prohibit release even of non-identifiable information, except pursuant to one of the routine uses, if there is a possibility that an individual can be identified through implicit deduction based on small cell sizes (instances where the patient population is so small that individuals who are familiar with the enrollees could, because of the small size, use this information to deduce the identity of the beneficiary).

In addition, CMS will make disclosure from the proposed system only with consent of the subject individual, or his/her legal representative, or in accordance with an applicable exception provision of the Privacy Act.

CMS, therefore, does not anticipate an unfavorable effect on individual privacy as a result of the disclosure of information relating to individuals.

HPMS – All major system changes concerning PII are published for comment in the Federal Register as part of a modification for the HPMS System of Records.

MARX – MARx is fed PII from MBD, and healthplan systems, and passes information to MBD and healthplans. MARx is not the SOR for the PII, so there are no agreements in place from MARx with the individuals regarding PII.

MIIR – NO

PWS – PWS is fed PII from MBD and MARx internal CMS systems, and data from external SSA and RRB systems via CMS Enterprise Data Exchange. PWS is not the SOR for the PII.

RAS – RAS is fed PII from MBD, and RAS internal CMS systems, and passes information to MARx. RAS is not the SOR for the PII.

TROOP – NO

SPDBS - N/A

AAPCC: N/A

MPC: N/A

PRS: This data does not involve collection or sharing of PII with anyone other than the plan in which the individual enrolled and to whom the individual granted permission to use this information.

32. Does the system host a website? (Note: If the system hosts a website, the Website Hosting Practices section is required to be completed regardless of the presence of PII): Yes

37. Does the website have any information or pages directed at children under the age of thirteen?: No

50. Are there policies or guidelines in place with regard to the retention and destruction of PII? (Refer to the C&A package and/or the Records Retention and Destruction section in SORN): Yes

54. Briefly describe in detail how the IIF will be secured on the system using administrative, technical, and physical controls.: APPS – NA.

DDPS – CMS has safeguards in place for authorized users and monitors such users against excessive or unauthorized use. Personnel having access to the system have been trained in the Privacy Act and information security requirements. Employees who maintain records in this system are instructed not to release data until the intended recipient agrees to implement appropriate management, operational and technical safeguards sufficient to protect the confidentiality, integrity and availability of the information and information systems and to prevent unauthorized access. This system will conform to all applicable Federal laws and regulations and Federal, HHS, and CMS policies and standards as they relate to information security and data privacy. These laws and regulations include but are not limited to: the PRivacy Act of 1974; the Federal Information Security Management Act of 2002; the Computer Fraud and Abuse Act of 1986; the Health Insurance Portability and Accountability Act of 1996; The EGovernment Act of 2002, the Clinger-Cohen Act of 1996; the MEdicare Modernization Act of 2003, and the corresponding implementating regulations. OMB Circulr A-130, Management of Federal Resources, Appendix III, Security of Federal Automated Information Resources also applies. Federal, HHS, and CMs policies and standards include but are not limited to: all pertinent National Institute of Standards and Technology publications; the HHS Infomation Systems Program Handbook and the CMS Information Security Handbook.

HPMS – HPMS utilizes the following control mechanisms: user ID and password-controlled access, firewall, Virtual Private Network technology, encryption, and intrusion detection (technical controls); guards, identification requirements, key cards (physical controls at hosting facility); systems security plan, contingency plan, regular backups, and personnel training (administrative controls).

MARX – RACF controls are in place per the GSS and EUA systems as far as technical and administrative electronic access to records, and the data center controls physical access.

MIIR – Users of MIIR do not have beneficiary level (PII) access. Prior to access to aggregate data being granted, a business owner listed within EUA receives a request from a user. The user must first have MIIR Training, submit a DUA, and provide a business reason for requiring the access. If all of that is satisfactory, the business owner approves the request for access to the aggregate level information. This process is handled through CMS’s CAA, EUA, and LDAP processes so that all agency related policies for access request, approval, and password protection are utilized.

PWS – RACF controls are in place per the GSS and EUA systems as far as technical and administrative electronic access to records, and the data center controls physical access.

RAS – RACF controls are in place per the GSS and EUA systems as far as technical and administrative electronic access to records, and the data center controls physical access.

TROOP – Contractor must follow the CMS “System Security Plan and Risk Assessment Guidelines” which is based on the NIST special publication “Guide for Developing Security Plans for Information Technology Systems”

AAPCC: N/A

MPC: N/A

SPDBS: N/A

PRS: PRS beneficiary level data resides on the mainframe and is accessible only by the PRS application and reports. Access controls are user access to establish for reports and the data is protected by the mainframe GSS controls.

PIA Approval

PIA Reviewer Approval: Promote

PIA Reviewer Name: William Saunders

Sr. Official for Privacy Approval: Promote

Sr. Official for Privacy Name: Anthony Trenkle

Sign-off Date: Jun 26, 2009

Approved for Web Publishing: Yes

Date Published: September 1, 2009

_____________________________________________________________________________

06.3 HHS PIA Summary for Posting (Form) / Medicare Appeals Systems

PIA SUMMARY AND APPROVAL COMBINED

PIA Summary

Is this a new PIA? No

If this is an existing PIA, please provide a reason for revision: PIA Validation

1. Date of this Submission: Jun 26, 2009

2. OPDIV Name: CMS

3. Unique Project Identifier (UPI) Number: 009-38-01-04-01-1180-00

4. Privacy Act System of Records (SOR) Number (If response to Q.21 is Yes, a SORN number is required for Q.4): 09-70-0566

5. OMB Information Collection Approval Number: N/A

6. Other Identifying Number(s): N/A

7. System Name (Align with system Item name): Medicare Appeals System

9. System Point of Contact (POC). The System POC is the person to whom questions about the system and the responses to this PIA may be addressed: Cyqwenthia Boyd

10. Provide an overview of the system: The Medicare Appeals System allows both tracking of and reporting on the Medicare appeals process. This system is used to support the new Medicare process established by the Medicare Prescription Drug, Improvement, and Modernization Act of 2003 (MMA) and the Benefits Improvement and Protection Act of 2000 (BIPA).

13. Indicate if the system is new or an existing one being modified: Existing

21. Is the system subject to the Privacy Act? (If response to Q.19 is Yes, response to Q.21 must be Yes and a SORN number is required for Q.4): Yes

23. If the system shares or discloses IIF please specify with whom and for what purpose(s): The Office of Medicare Hearings and Appeals (OMHA), CMS, and the CMS contractors who process Medicare appeals. The PII is necessary to record and adjudicate the Medicare appeals.

(Note: Please describe in what format individuals will be given notice of consent [e.g., written notice, electronic notice, etc.]) The MAS System of Record provides notification of the data that will be collected and maintained. Written notice is provided in the MAS system of records.

32. Does the system host a website? (Note: If the system hosts a website, the Website Hosting Practices section is required to be completed regardless of the presence of PII): Yes

37. Does the website have any information or pages directed at children under the age of thirteen?: No

50. Are there policies or guidelines in place with regard to the retention and destruction of PII? (Refer to the C&A package and/or the Records Retention and Destruction section in SORN): Yes

54. Briefly describe in detail how the IIF will be secured on the system using administrative, technical, and physical controls.: Users are required to wear Identification Badges / Key Cards in order to gain access to the facilities. The user must then access the system through a T1 line that is dedicated to CMS. Firewalls are in place to block unauthorized access. The user can only access the system with their CMS userid and password. This password expires after 60 days, has a minimum length of eight characters, and accounts are locked after three incorrect attempts. Accounts are also logged out after 15 minutes of inactivity. User accounts are also role based to protect unnecessary access to PII.

PIA Approval

PIA Reviewer Approval: Promote

PIA Reviewer Name: William Saunders

Sr. Official for Privacy Approval: Promote

Sr. Official for Privacy Name: Anthony Trenkle

Sign-off Date: Jun 26, 2009

Approved for Web Publishing: Yes

Date Published: September 1, 2009

_____________________________________________________________________________

06.3 HHS PIA Summary for Posting (Form) / Medicare Beneficiary Enrollment Systems

PIA SUMMARY AND APPROVAL COMBINED

PIA Summary

Is this a new PIA? No

If this is an existing PIA, please provide a reason for revision: PIA Validation

1. Date of this Submission: Jun 26, 2009

2. OPDIV Name: CMS

3. Unique Project Identifier (UPI) Number: 009-38-01-09-01-1120-00 009-38-01-04-01-1150-00

4. Privacy Act System of Records (SOR) Number (If response to Q.21 is Yes, a SORN number is required for Q.4): 09-70-0502, 09-70-0536

5. OMB Information Collection Approval Number: N/A

6. Other Identifying Number(s): N/A

7. System Name (Align with system Item name): Medicare Beneficiary Enrollment Systems

9. System Point of Contact (POC). The System POC is the person to whom questions about the system and the responses to this PIA may be addressed: Anthony Culotta

10. Provide an overview of the system: The EDB is a collection of automated systems that support the collection and maintenance of information (e.g., demographics, enrollment, insurance, premium payments) about Medicare beneficiaries.

The MBD was developed to provide CMS with a centralized database that supports the collection and maintenance of information about Medicare Program beneficiaries. The Medicare beneficiary information contained in the MBD is used to support managed care enrollments, payments to Managed Care Organizations, and the Prescription Drug Program. Specifically for DBS, to produce appropriate and accurate bills for and track the collection of Medicare Hospital Insurance (HI) premiums (Part A) and Supplementary Medical Insurance (SMI) premiums (Part B). Specifically for TPS, to perform third party premium billing and collection operations.

13. Indicate if the system is new or an existing one being modified: Existing

21. Is the system subject to the Privacy Act? (If response to Q.19 is Yes, response to Q.21 must be Yes and a SORN number is required for Q.4): Yes

23. If the system shares or discloses IIF please specify with whom and for what purpose(s): Public citizens, business partners/contacts (Federal, State, local agencies), etc., as stated under the Routine Uses outlined in the System of Records for the MBD and EDB.

30. Please describe in detail: (1) the information the agency will collect, maintain, or disseminate; (2) why and for what purpose the agency will use the information; (3) in this description, explicitly indicate whether the information contains PII; and (4) whether submission of personal information is voluntary or mandatory: The agency collects information related to Medicare enrollment and entitlement and Medicare Secondary Payer data containing other party liability insurance information necessary for appropriate Medicare claim payment. It contains hospice election, premium billing and collection, direct billing information, and group health plan enrollment data. It also contains the individual’s health insurance numbers, name, geographic location, race/ethnicity, sex, and date of birth. Information is collected on individuals age 65 or over who have been, or currently are, entitled to health insurance benefits under Title XVIII of the Act or under provisions of the Railroad Retirement (RR)Act, individuals under age 65 who have been or currently are, entitled to such benefits on the basis of having been entitled for not less than 24 months to disability benefits under Title II of the Act or under the RR Act, individuals who have been, or currently are, entitled to such benefits because they have ESRD, individuals age 64 and 8 months or over who are likely to become entitled to health insurance benefits upon attaining age 65, and individuals under age 65 who have at least 21 months of disability benefits who are likely to become entitled to Medicare upon the 25th month of their being disabled. It is a voluntary collection.

(Note: Please describe in what format individuals will be given notice of consent [e.g., written notice, electronic notice, etc.]) The information is collected from Medicare beneficiaries and obtained by CMS. The beneficiaries are informed that CMS will only disclose the minimum personal data necessary to achieve the purpose of the Enrollment Database and under what routine uses the information will be disclosed. By law, CMS is required to protect the privacy of individual’s personal medical information. CMS is also required to give individuals notice telling them how CMS may use and disclose their personal medical information. Individuals are made aware in the ‘Medicare and You Handbook’ published yearly and sent out to each Medicare beneficiary. Individuals have the right to amend any medical information that they believe to be incorrect, get a listing of anyone the information is disclosed to, and ask CMS to limit how their personal medical information is used and given out to pay claims and run the Medicare program.

32. Does the system host a website? (Note: If the system hosts a website, the Website Hosting Practices section is required to be completed regardless of the presence of PII): No

37. Does the website have any information or pages directed at children under the age of thirteen?: No

50. Are there policies or guidelines in place with regard to the retention and destruction of PII? (Refer to the C&A package and/or the Records Retention and Destruction section in SORN): Yes

54. Briefly describe in detail how the IIF will be secured on the system using administrative, technical, and physical controls.: The system is certified and accredited to process MBES data until 9/1/2009. A draft of the System Security Plan (SSP) and Risk Assessment (RA) was completed for review 02/09 and 03/09 respectively. SSP Security controls are routinely reviewed, a contingency plan is in place and files are backed up and stored offsite regularly. All personnel (users, administrators, developers, contractors) using the system have been trained and made aware of their responsibility to protect the data collected and maintained.

PIA Approval

PIA Reviewer Approval: Promote

PIA Reviewer Name: William Saunders

Sr. Official for Privacy Approval: Promote

Sr. Official for Privacy Name: Anthony Trenkle

Sign-off Date: Jun 26, 2009

Approved for Web Publishing: Yes

Date Published: September 1, 2009

_____________________________________________________________________________

06.3 HHS PIA Summary for Posting (Form) / Medicare Claims Processing Systems

PIA SUMMARY AND APPROVAL COMBINED

PIA Summary

Is this a new PIA? No

If this is an existing PIA, please provide a reason for revision: PIA Validation

1. Date of this Submission: Jun 26, 2009

2. OPDIV Name: CMS

3. Unique Project Identifier (UPI) Number: 009-38-01-06-01-1110-00 009-38-01-06-01-1120-00 009-38-01-06-01-1130-00 009-38-01-06-01-1140-00 009-38-01-06-02-1150-00 009-38-01-04-01-1160-00

4. Privacy Act System of Records (SOR) Number (If response to Q.21 is Yes, a SORN number is required for Q.4): 09-70-0526, 09-70-0505, 09-70-0537, 09-70-0572, 09-70-0574, 09-70-0536, 09-70-0546

5. OMB Information Collection Approval Number: 0938-1016, CMS-10157, 0938-0960, 0938-0915

6. Other Identifying Number(s): n/a

7. System Name (Align with system Item name): Medicare Claims Processing Systems

9. System Point of Contact (POC). The System POC is the person to whom questions about the system and the responses to this PIA may be addressed: Kevin Potter

10. Provide an overview of the system: CCI-IMS: This system is a 3-tier relational database, residing wholly on the MDCN, which contains claims, EDB and other records pertaining to beneficiaries in the MMA 721 Medical Health Support Pilot. It is the data warehouse and dissemination point for this program.

DBids: The purpose of DBids is to allow Medicare Fee-for-Service DMEPOS suppliers to submit bids for DMEPOS products to CMS via a web-based system. Suppliers bid on the product categories in the competitive bidding areas using the DBids application. Bids will be submitted over a 60-day period known as the bid window. Once the 60-day bid window is closed, the Competitive Bidding Implementation Contractor will use the data captures by DBids in a bid evaluation process to determine which suppliers will or will not receive contracts to supply DME products and supplies to Medicare beneficiaries.

eChimp: eChimp 2.0 is a web-based intranet application that was developed to streamline and automate the Medicare Contractor Change Management Process.

HETS: Beginning in July 2005, health care provider entities that wish to submit X12 270 transactions to Medicare on a real-time basis were permitted to submit 270a via the CMS AT&T communication extranet. This extranet is a secure closed private network currently used to transmit data between medicare FFS contractors and CMS, as well for transmission of electronic transactions in some cases from certain peroviders and clearinghouses to FFS contractors. This system is a HIPAA compliant solution for 270/271 Eligibility Inquiry/Response for Medicare FFS.

NHIC: NHIC is piloting a project to evaluate the feasibility of migrating medicare Provider customer Service Activities from written and telephone correspondence to electronic, on-line transactions over the public internet using a secure website.

UARS: This system collects claim and reimbursement data from hospitals, physicians, and ambulance companies for services rendered to undocumented aliens under Section 1011 of MMA.

MCPSS: This is a survey data collection system. Each year, CMS will obtain feedback from up to 25,000 Medicare Providers via a survey about satisfaction, attitudes and perceptions regarding the services provided by Medicare Fee-for-Service Carriers, Fiscal Intermediaries, Durable Medical Equipment Suppliers, and Regional Home Health Intermediaries and Medicare Administrative Contractors. The data are accessed through a secure web tool. No personal identifiers are available through this web reporting tool - the identities of the survey respondents are maintained solely by the survey vendor.

MAISTRO: functions as a tool to record, track, and monitor complaints and issues from the public relating to Medicare Part A and Part B systems and program matters. It also provides a mechanism for reporting data on a national level and facilities strategic analysis of trends and CMS resolutions.

WPS: is conducting a pilot project to allow a select number of providers in to access Medicare eligibility and claims status information via the internet. In addition to eligibility and claims status information, the pilot application also contains Provider Registration and Customer Service components. The pilot does not, however, include Medicare claims submissions.

13. Indicate if the system is new or an existing one being modified: Existing

21. Is the system subject to the Privacy Act? (If response to Q.19 is Yes, response to Q.21 must be Yes and a SORN number is required for Q.4): Yes

23. If the system shares or discloses IIF please specify with whom and for what purpose(s): PII is shared with patients, business partner/contacts, and vendors/supplier/contractors to verify receipt of service and properly pay claims.

DBids:the data is used by the CBIC and CMS to evaluate the bids during and at the end of the bid cycle to determine which suppliers are eligibile to receive contracts for providing DME products.

eChimp: NA

HETS: An entity wishing to conduct this business with CMS over the MDCN network must complete an Access Form and agree to certain conditions before their access to the system is granted.On the Access Forn we collect the following information: organization name, medicare billing contractor, Medicare Proider Identification Number, NPI, name, phone, email address, connection remote IP address, SSN.

NHIC: Users of the application are approved by NHIC and have user Ids and passwords to enter the system. The purpose of the application is to reduce the number of calls received by the NHIC Medicare FFS contractor call centers. In order to receive the eligibility information the provider must first be validated in the system and supply the patient HICN, first initial, last name, date of birth and gender.

UARS: The Section 1011 program includes the provider name and identification number, provider address, provider employer identification number, provider banking information, provider federal tax id, patient's control number, medical record number, date of service, patient's gender, zip code, state and county, the principal diagnosis code, admitting diagnosis code, and total charges. It also includes claims information related to Section 1011 payment requests, and other research information needed to pay claims and administer the Section 1011 program.

MCPSS: CMS collects, maintains and disseminates information on provider satisfaction with Medicare Contractors.

MAISTRO: will record, track and monitor beneficiary and provider level inquiries and complaints. PII is collected in MAISTRO include: name, address, date of birth, Medicare number, email address and phone number. Submission of PII is voluntary; however some inquiries may not be resolvable without basic indentifying information.

WPS: The application allows select providers to perform Internet queries. the users of the application are approved by WPS and have user Ids and password to enter the system.

(Note: Please describe in what format individuals will be given notice of consent [e.g., written notice, electronic notice, etc.]) CCI-IMS: N/A

DBids: The requested processes are covered under the MSIS.

eChimp: N/A

HETS: The MCARE HElp Desk uses a listserv to communicate with users of this system. Email and phone notifications are used to communicate directly with users regarding individual organization issues.

NHIC: System of records and Medicare & You Handbook.

UARS: CMS will make disclosure from the proposed system only with consent of the subject individual, of his/her legal representative, or in accordance with an applicable exception provision of the Privacy Act.

MCPSS: N/A

MAISTRO: N.A.

WPS: System of records and Medicare & You Handbook.

32. Does the system host a website? (Note: If the system hosts a website, the Website Hosting Practices section is required to be completed regardless of the presence of PII): Yes

37. Does the website have any information or pages directed at children under the age of thirteen?: No

50. Are there policies or guidelines in place with regard to the retention and destruction of PII? (Refer to the C&A package and/or the Records Retention and Destruction section in SORN): Yes

54. Briefly describe in detail how the IIF will be secured on the system using administrative, technical, and physical controls.: CCI-IMS: the system is fully compliant with OIS/CMS Systems Security Guidance. A combination of 3-tier architecture, firewalls, encryption, and strict policies help to assuer that no PII/PHI in the system is retrievable outside the guidelines in place for the system.

DBids:Data pertaining to SMEPOS suppliers is kept in soft copy only and is accessed through a web-based portal that requires a unique ID and password for each user. All changes to the data are tracked with a user ID and time/date stamp.

eChimp: NA

HETS: PII pertaining to Medicare HETS trasing partners is kept in soft copy only. PII is accessed through a web based portal that requires unique ID and password for each user. All changes to the PII forms are tracked with a user ID and time/date stamp. Application used to access/store PII data is only accessed from secure locations dedicated to CMS businesses. All components of the application run in the CMS Data Centers. Physical access to CMS datacenters are controlled by security guards and card readers. All servers are protected by firewalls and user id and passwords from electronic access.

NHIC: Access to the system is given based on PKI Certificates and job responsibilities to process Medicare claims. NHIC verifies providers who request access to the system. the user passwords follow CMS guidelines regarding length, complexity, and reset requirements. Technical controls used include user identification, passwords, firewalls, virtual private networks, and intrusion detection systems. Physical controls include guards, identification badges, key cards, cipher locks, and closed circuit televisions.

UARS: The CDS data center uses many security controls to monitor the installation and updates to hardware, operating system software, and other system software to ensure that the hardware and software functions as expexted and that a historical record is maintained of system changes. Configuration Management protocols and policies have been developed to ensure that a consistent process and change control documentation is used to establish baselines for the controls regarding GSS changes.

MCPSS: Westat operates web server, database servers, and other specialized application servers for hosting project-related web sites and other Internet supported services, The security policies and procedures used to manage these systems conform to general WESTAT practices.

MAISTRO: All data are secured in accordance with CMS controls within the CMS Data Center.

WPS: Access to the system is given based on need to know and job responsibilities to process Medicare claims. WPS verifies providers who request accedd to the system. the user passwords follow CMS guidelines regarding length, complexity, and reset requirements. Technical controls used include user indentification, passwords, firewalls, virtual private networks, and intrusion detection systems. Physical controls include guards, identification badges, key cards, cipher locks, and closed circuit televisions.

PIA Approval

PIA Reviewer Approval: Promote

PIA Reviewer Name: William Saunders

Sr. Official for Privacy Approval: Promote

Sr. Official for Privacy Name: Anthony Trenkle

Sign-off Date: Jun 26, 2009

Approved for Web Publishing: Yes

Date Published: September 1, 2009

_____________________________________________________________________________

06.3 HHS PIA Summary for Posting (Form) / Medicare Data Centers

PIA SUMMARY AND APPROVAL COMBINED

PIA Summary

Is this a new PIA? No

If this is an existing PIA, please provide a reason for revision: PIA Validation

1. Date of this Submission: Jun 26, 2009

2. OPDIV Name: CMS

3. Unique Project Identifier (UPI) Number: 009-38-01-04-01-1030-00

4. Privacy Act System of Records (SOR) Number (If response to Q.21 is Yes, a SORN number is required for Q.4): 09-70-0503

5. OMB Information Collection Approval Number: N/A

6. Other Identifying Number(s): N/A

7. System Name (Align with system Item name): Medicare Data Centers

9. System Point of Contact (POC). The System POC is the person to whom questions about the system and the responses to this PIA may be addressed: Ed Gray

10. Provide an overview of the system: Congress established the Medicare Program in 1965 when it enacted Title XVIII of the Social Security Act. The Medicare Program is a Federal health insurance program and now serves over 40 million beneficiaries and processes over 900 million claims per year. To ensure a quick and smooth implementation of the Medicare program in 1965, Congress adopted an administrative structure, which was compatible with the historical pattern of administration used by the private health insurance industry. This allowed the Federal Government to contract with existing public or private organizations to facilitate services to beneficiaries and providers of health care services. It also allowed many systems to be developed for Medicare claims processing.

Traditional Fee-For-Service (FFS) coverage in the Medicare Program consists of two distinct parts. Hospital insurance (Part A of the Program) covers expenses for medical services furnished in institutional settings, such as hospitals or skilled nursing facilities, or services provided by a home health agency or hospice. Supplemental medical insurance (Part B of the Program) covers physician and other practitioner services; certain durable medical equipment, prosthetics, orthotics, and supplies (DMEPOS) services; and other outpatient services.

Medicare FFS Claims are processed by Fiscal Intermediaries (FIs), Carriers, and Durable Medical Equipment Regional Carriers (DMERCs) using the family of shared systems described below:

Part A Shared System

Hospital insurance claims process through the Fiscal Intermediaries Shared System (FISS), which performs claims processing and benefit payment functions for institutional providers under Parts A and B of the program. The Medicare contractors that use FISS are known as “fiscal intermediaries” (FIs).

Part B Shared System

The Part B Shared System supports the processing of Medicare Part B claims. Medicare Part B is supplemental medical insurance, which covers physician services and other outpatient services. The Shared System for Part B Medicare is the Multi Carrier System (MCS). Medicare Part B claims processing contractors are known as Carriers, and include the Railroad Retirement Board. They process physician and supplier claims provided under Medicare Part B coverage.

Durable Medical Equipment Regional Contractor (DMERC) Shared System

CMS has designated four carriers to have exclusive responsibility for handling Medicare Part B claims for Durable Medicare Equipment Prosthetics, Orthotics, and Supplies (DMEPOS) claims in specified geographic regions of the United States. They are commonly referred to as the “Durable Medical Equipment Regional Carriers (DMERCs).” The selected DMERCs currently use the VMS DME Shared system to process DMEPOS claims.

13. Indicate if the system is new or an existing one being modified: Existing

21. Is the system subject to the Privacy Act? (If response to Q.19 is Yes, response to Q.21 must be Yes and a SORN number is required for Q.4): Yes

23. If the system shares or discloses IIF please specify with whom and for what purpose(s): The agency may share the collected information with a variety of Federal, state, local, and tribal government audiences and professional audiences, including the medical community. This includes, Providers, Ambulance Services, Medigap Companies / Supplemental Insurers, Clinical Labs, CMS contractors, DME Suppliers, Health Plans, Hospitals, Home Health Agencies, Physicians, Potential Contractors, Researchers, Skilled Nursing Facilities, and Suppliers.

Please see hyperlinks to CMS forms below.

Use of information collected

This information is used to process claims and payments for the Medicare Program beneficiaries. Submission of this information is mandatory and includes IIF.

Collection requirements

The Agency, through Medicare contractors and beneficiaries collects information through CMS forms CMS-1450 and CMS-1500. These are OMB approved forms.

Information is collected primarily through electronic means.

Form CMS-1450 (UB-92):

The UB-92 form and instructions are used by institutional and other selected providers to complete a Medicare Part A paper claim for submission to Medicare Fiscal Intermediaries. The paper UB-92 (Form CMS-1450) is neither a government printed form nor distributed by the CMS. The National Uniform Billing Committee (NUBC) is responsible for the design of the form (http://www.nubc.org/).

Form CMS-1500: Non-institutional providers and suppliers use CMS-1500 form and instructions to bill Medicare Part B covered services. It is also used for billing some Medicaid covered services. CMS -1500 (Health Insurance Claims Form) answers the needs of many health insurers. It is the basic form prescribed by CMS for the Medicare and Medicaid programs for claims submitted by physicians and suppliers, except for ambulance services. It has also been adopted by CHAMPUS and has the approval of the AMA Council on Medical Services. See link below for an electronic copy of form 1500.

Electronic Data Interchange (EDI) Enrollment Form

An organization comprising of multiple components that have been assigned Medicare provider numbers, supplier numbers, or UPINs may elect to execute a single EDI Enrollment Form on behalf of the organizational components to which these numbers have been assigned. The organization as a whole is to be held responsible for the performance of its components. The CMS Standard EDI Enrollment Form must be completed prior to submitting electronic media claims (EMC) to Medicare. Each provider of health care services, physician, or supplier that intends to submit EMC must execute the agreement. Each new EMC biller must sign the form and submit it to their local Medicare carrier or fiscal intermediary. Any existing EMC billers who have not completed the CMS Standard EDI Enrollment Form must complete and sign this form and submit it to their local Medicare carrier or fiscal intermediary also.

Please see the CMS Web page link listed below for information on:

Form CMS-1450 (UB92)

Form CMS-1500

Medicare Part A EDI Helpline

Medicare Part B EDI Helpline

EDI Enrollment Form and Instructions

http://www.cms.hhs.gov/electronicbillingeditrans/

(Note: Please describe in what format individuals will be given notice of consent [e.g., written notice, electronic notice, etc.]) Information is collected from two CMS forms, the 1450 and 1500. All Medicare Claims Processing Contractors are called ‘satellites’ under CWF. Satellites access the Host CWF databases to obtain needed beneficiary information. Satellites submit claims to the CWF Host for prepayment review and approval. Medicare beneficiaries are provided healthcare services where their personal information is collected and required for payment and reimbursement purposes. Beneficiaries receive HIPAA disclosure information by providers and Medicare directly. A complaint process is in place for individuals to raise their privacy concerns.

32. Does the system host a website? (Note: If the system hosts a website, the Website Hosting Practices section is required to be completed regardless of the presence of PII): No

37. Does the website have any information or pages directed at children under the age of thirteen?: No

50. Are there policies or guidelines in place with regard to the retention and destruction of PII? (Refer to the C&A package and/or the Records Retention and Destruction section in SORN): Yes

54. Briefly describe in detail how the IIF will be secured on the system using administrative, technical, and physical controls.: The Medicare Claims Processing Systems incorporate a variety of security measures to protect PII. These security measures include physical (e.g. use of access card readers, locked doors, cipher locks, and guards to control, restrict and monitor access), administrative (e.g. annual training of staff on security awareness and roles and responsibilities as well as background checks for new and existing employees), and technical (e.g. use of firewalls and intrusion detection systems to detect, restrict and monitor access to the systems and data/information - and secondary identification and authentication access controls).

PIA Approval

PIA Reviewer Approval: Promote

PIA Reviewer Name: William Saunders

Sr. Official for Privacy Approval: Promote

Sr. Official for Privacy Name: Anthony Trenkle

Sign-off Date: Jun 26, 2009

Approved for Web Publishing: Yes

Date Published: September 1, 2009

_____________________________________________________________________________

06.3 HHS PIA Summary for Posting (Form) / Medicare Financial Management & Payment Systems

PIA SUMMARY AND APPROVAL COMBINED

PIA Summary

Is this a new PIA? No

If this is an existing PIA, please provide a reason for revision: PIA Validation

1. Date of this Submission: Jun 26, 2009

2. OPDIV Name: CMS

3. Unique Project Identifier (UPI) Number: 009-38-01-06-02-1150-00 009-38-01-04-02-1105-00 009-38-01-09-01-1010-00

4. Privacy Act System of Records (SOR) Number (If response to Q.21 is Yes, a SORN number is required for Q.4): 09-70-0501, 09-70-0503, 09-70-0568, 09-70-0598, 09-70-0546

5. OMB Information Collection Approval Number: N/A

6. Other Identifying Number(s): CMS ART: OFM 463; PIMR: OFM 225; HCRIS: FMIB 415

7. System Name (Align with system Item name): Medicare Financial Management & Payment Systems

9. System Point of Contact (POC). The System POC is the person to whom questions about the system and the responses to this PIA may be addressed: Antoinette Miller

10. Provide an overview of the system: Medicare Finance Management & Payment System (MFMPS):

CAFM: The CAFM system is the vehicle for tracking all benefit payments, banking issues, and CFO data.

CAFMII: The CAFMII system is the main vehicle for planning, administering and monitoring the administrative expenses of the Medicare contractor community

CAPTS: The CAPTS system will provide an efficient and effective method for tracking Corrective Action Plans related to audit findings as well as the most current status of those plans.

CASR: The CASR System tracks budgeted and incurred costs for the Part A contractor audit and settlement functions by type of activity and type of provider or reporting entity.

CERT: The CERT system produces national, contractor specific, and benefit category specific paid claim error rates.

CMIS: The CMIS has two main components: CMIS and Pulse. The CMIS component receives financial and workload information on a monthly basis and allows users to generate a variety of reports to manage and oversight the Medicare contractors. The Pulse system received and displays daily workload information for each contractor.

CMS ART: The CMS ART captures and tracks selected government contractor's costs, hours, workload data, contract deliverables and other schedules and information as required for all task orders and contracts using the system.

COB: The purpose of the COB Program is to identify the health benefits available to a Medicare beneficiary and involves the collection, management, and reporting of other insurance coverage.

COB/MRA: Section 111 of the Medicare, Medicaid and SCHIP Extension Act of 2007 adds a new Medicare Secondary Payer mandatory reporting requirements for group health plan arrangements and for liability insurance, no-fault insurance and workers' compensation. The purpose of the Section 111 MSP reporting process is to enable CMS to correctly pay for secondary payer responsibility. Section 111 responsible reporting entities may use the Section 111 COB Secure Web site to submit files for Section 111 MSP reporting. Additionally, this application will also provide a means for responsible reporting entities to review the status of current file submissions and statistical information related to historical submissions.

CROWD: The CROWD system provides CMS with a timely way to monitor each Medicare Contractor’s performance in processing claims and paying bills.

DPS: The DPS system provides payment data for issuance to demonstration providers and sites through the Financial Accounting Control System (FACS).

HCRIS: The HCRIS system collects provider cost report information.

PIMR: The PIMR system supports the tracking of Medicare fraud and abuse.

PS&R: The PS&R system summarizes claims data information (statistical and payment data) for use in settling Medicare cost reports.

PULSE: The PULSE system monitors Medicare Fee-for-Service contractor process counts.

RAC: The Recovery Audit Contractors (RACs) are charged with identifying and correctling improper payments made use FFS Medicare. The program started as a three-state demonstration; it was made permanent by Section 302 of the Tax Relief and Healthcare Act 2006 and is required to statute to be implemented mationwide to January 2010. The RAC Data Warehouse allows CMS to monitor RAC activities, track collections/restorations of underpayments and prevent interference with program integiry or law enforcement investigations.

STAR: The STAR system is used by FIs to track the cost reporting process from due date to final settlement and the staff time associated with each task performed on a provider’s cost report.

13. Indicate if the system is new or an existing one being modified: Existing

21. Is the system subject to the Privacy Act? (If response to Q.19 is Yes, response to Q.21 must be Yes and a SORN number is required for Q.4): Yes

23. If the system shares or discloses IIF please specify with whom and for what purpose(s): Yes: CAPTS: with the Administrator, COB: IRS and SSA, DPS: demonstration providers.

NO: CAFM, CAFMII, CASR, CERT, CMIS, CMS ART, CROWD, DPS, HCRIS, PIMR, PS&R, PULSE, RAC, STAR

CAFMII collects data from 11 input forms to accommodate new reporting requirements for the revised Medicare Contractor environment.

CAPTS collects data on Corrective Action Plans to enable in the decision making process in helping to implement these plans.

CASR data is collected from six input forms for monitoring purposes.

CMIS collects monthly data from the Contractor Reporting of Operational and Workload Data (CROWD), the Medicare Contractor Process Counts Monitor System (PULSE) and the Contractor Administrative Financial Management System (CAFMII).

CMS ART: Data is entered about contractor costs, workload and deliverables.

COB: The purpose of the COB Program is to identify the health benefits available to a Medicare beneficiary and involves the collection, management, and reporting of other insurance coverage. as the sole COB contractor and maintainer of the COB System, GHI's Government Programs Division is responsible for ensuring the accuracy and timeliness of updates to Medicare's eligibility and entitlement databases, i.e., the Common Working File (CWF) and MEdicare Beneficiary Database (MBD) through the following tasks; Initial Enrollment Questionnaire (data on other insurance); IRS/SSA/CMS Data Match (information on whether or not a beneficiary ot their spouse is working); Medicare Secondary Payer Claims Investigation (additional information related to the beneficiary's health benefit coverage); Coordination of Benefots Agreement (defines the criteria for transmitting enrollee eligibility data and Medicare adjudicated claim data to other insurers; Workman's Compensation Case Control (imaged copies of incoming cases); Voluntary Data Sharing Agreements to electronically exchange health insurance benefit entitlement; Medicare Prescription Drug Program Part D (collection and maintenance of prescription drug coverage data far Medicare Beneficiaries); National Call Center (trained staff charged with helping customers with COB questions.)

CROWD: Data is collected from 30 input forms and is maintained on direct on-line storage for fiscal years 1986 through the current fiscal year.

DPS: The system collects the minimally necessary identifying, medical and demographic information needed to reimburse demonstration providers for the services rendered to Medicare beneficiaries. The data collection is based on the individual demonstration legislation and only that information needed to pay correctly is collected.

HCRIS: The information pertains to the providers’ cost of doing business and various medical expenses.

PIMR: PIMR collects, validates and consolidates on a monthly basis, operational and workload data from 70 Medicare contractors across the country as well as contractor administrative budget and financial management data from CMS systems into a single reporting system at CMS.

PS&R: PS&R processes all Medicare Part A post-payment claims, breaking each claim into sub-claims based on fee and cost-based reporting criteria, then further summarizing the claims into an aggregate amount per report type per provider. In order for the provider to reconcile its data and prepare for its cost report submission, it must be able to tie back the aggregated report amounts to the individual detail claims. The aggregated summary reports do not contain any sensitive information. It is only at the input paid claims and detail level that privacy-related information is present. The detail claims level is the minimum necessary to accomplish the purpose for the system, as, from an auditing and reimbursement perspective, the provider and intermediary must be able to tie summary totals back to the detailed claims records.

PULSE: On a nightly basis, Medicare contractors transmit their CMS-1565, CMs-1566, and CMS-1522 report files to the CMS data

(Note: Please describe in what format individuals will be given notice of consent [e.g., written notice, electronic notice, etc.]) The CAFM, CAFMII, CASR and CROWD personal information is only accessed by the system administrator and the individual. Every system user must be registered and identified by their HDC User ID. The system administrator also enters their name. The first time a user accesses the system, he/she is prompted to enter their business address and phone number. Periodically, they are prompted to update this information.

CAPT will obtain the information via mandated spreadsheets from the Medicare Contractor.

CERT: Information is obtained directly from Medicare contractors' claims processing systems. Medicare beneficiaries sign a privacy act notice when they become eligible for Medicare that informs them that information they provide to justify payments will be used to determine the appropriate of payment.

CMIS: There is no PII data.

CMS ART: There is no PII data.

DPS: The information is obtained electronically and hardcopy in a HIPAA compliant format. The suppliers of the information have been informed about data usage through either a contract or an informed consent form. These signed agreements are obtained as the supplier or beneficiary enters the demonstration.

HCRIS: There is no PII data.

PS&R: The information is present on the paid claims record, the format of which is specified by the FISS shared system. Claims, submitted by providers or billing houses, adjudicated by the Common Working File system, are placed into this paid claims format for input into PS&R. This information is not shared with individuals nor is consent given for the data to be shared with individuals. The data is available to providers who provide services to Medicare beneficiaries, and is available to providers in summary and detail form.

PULSE: Information is being collected from existing CMS reports here at CMS.

RAC: There is no PII data.

STAR: The information in STAR does contain personally identifiable information within the STAR database about Medicare providers (employee names and TIN for providers). The STAR time keeping system lists name of FI employees and an employee number. These data are used only by the FI to track employees’ time when the individual is working on a provider cost report. Employee data are not share by the FI or included in the National STAR database.

32. Does the system host a website? (Note: If the system hosts a website, the Website Hosting Practices section is required to be completed regardless of the presence of PII): Yes

37. Does the website have any information or pages directed at children under the age of thirteen?: No

50. Are there policies or guidelines in place with regard to the retention and destruction of PII? (Refer to the C&A package and/or the Records Retention and Destruction section in SORN): Yes

54. Briefly describe in detail how the IIF will be secured on the system using administrative, technical, and physical controls.: COB: GHI has a Security Program that includes the CAST self-assessment with 441 administrative, physical and technical controls. The program includes security training, corrective action plans, Business Continuity Planning, external tests of security controls contracted to Cybertrust, SDLC, Change Control, Risk Assessments, System Security Plans. Full detail is available in the COB RA's, COB SSPs and COB BCP.

DPS: All PII is processed and maintained within a secured CMS environment and complies withe all CMS security policy. CMS policy includes security training, corrective action plans, Business Continuity Planning, external tests of security controls, Change Control, Risk Assessments, System Security Plans, and Contingency Plans.

PIA Approval

PIA Reviewer Approval: Promote

PIA Reviewer Name: William Saunders

Sr. Official for Privacy Approval: Promote

Sr. Official for Privacy Name: Anthony Trenkle

Sign-off Date: Jun 26, 2009

Approved for Web Publishing: Yes

Date Published: September 1, 2009

_____________________________________________________________________________

06.3 HHS PIA Summary for Posting (Form) / Medicare Pricing Systems

PIA SUMMARY AND APPROVAL COMBINED

PIA Summary

Is this a new PIA? No

If this is an existing PIA, please provide a reason for revision: PIA Validation

1. Date of this Submission: Jun 26, 2009

2. OPDIV Name: CMS

3. Unique Project Identifier (UPI) Number: 009-38-01-04-02-1105-00

4. Privacy Act System of Records (SOR) Number (If response to Q.21 is Yes, a SORN number is required for Q.4): N/A

5. OMB Information Collection Approval Number: N/A

6. Other Identifying Number(s): N/A

7. System Name (Align with system Item name): Medicare Pricing System

9. System Point of Contact (POC). The System POC is the person to whom questions about the system and the responses to this PIA may be addressed: Robert Beck

10. Provide an overview of the system: The systems that comprise the Medicare Pricing Systems Family provide software and data files to Medicare contractors and other entities for use in processing claims for Medicare covered services and provide support for the development of Medicare fee-for-service payment policies and payment rates. The names of the MPS systems are as follows:

Clinical Laboratory Fee Schedule (CLFS),

Durable Medical Equipment Fee Schedule (DMEFS),

Grouper,

HCFA Common Procedures Coding System (HCPCS),

Investigational Device Exemption System (IDE),

FDA Mammography Database (MQMS),

Prospective Payment System (PPS),

PPS Pricing Software for Inpatient Stays System (PRICER),

Physician Fee Schedule System (PSPRICER),

PPS Skilled Nursing Facility Pricer (SNFPRICER),

Sustainable Growth Rate (SGR),

Wage Index (WI)..

13. Indicate if the system is new or an existing one being modified: Existing

21. Is the system subject to the Privacy Act? (If response to Q.19 is Yes, response to Q.21 must be Yes and a SORN number is required for Q.4): No

23. If the system shares or discloses IIF please specify with whom and for what purpose(s): No

(Note: Please describe in what format individuals will be given notice of consent [e.g., written notice, electronic notice, etc.]) No

32. Does the system host a website? (Note: If the system hosts a website, the Website Hosting Practices section is required to be completed regardless of the presence of PII): No

37. Does the website have any information or pages directed at children under the age of thirteen?: No

50. Are there policies or guidelines in place with regard to the retention and destruction of PII? (Refer to the C&A package and/or the Records Retention and Destruction section in SORN): No

54. Briefly describe in detail how the IIF will be secured on the system using administrative, technical, and physical controls.: No

PIA Approval

PIA Reviewer Approval: Promote

PIA Reviewer Name: William Saunders

Sr. Official for Privacy Approval: Promote

Sr. Official for Privacy Name: Anthony Trenkle

Sign-off Date: Jun 26, 2009

Approved for Web Publishing: Yes

Date Published: September 1, 2009

_____________________________________________________________________________

06.3 HHS PIA Summary for Posting (Form) / Medicare Utilization Data Collection & Access Systems

PIA SUMMARY AND APPROVAL COMBINED

PIA Summary

Is this a new PIA? No

If this is an existing PIA, please provide a reason for revision: PIA Validation

1. Date of this Submission: Jun 26, 2009

2. OPDIV Name: CMS

3. Unique Project Identifier (UPI) Number: 009-38-01-04-01-1160-00 009-38-02-00-01-1150-00 009-38-01-09-01-1010-00

4. Privacy Act System of Records (SOR) Number (If response to Q.21 is Yes, a SORN number is required for Q.4): 09-70-0558, 09-70-0514

5. OMB Information Collection Approval Number: N/A

6. Other Identifying Number(s): N/A

7. System Name (Align with system Item name): Medicare Utilization Data Collection & Access System

9. System Point of Contact (POC). The System POC is the person to whom questions about the system and the responses to this PIA may be addressed: Rason Taru

10. Provide an overview of the system: Data Extract System (DESY) – Enterprise Data Extract System for Enterprise Data

Data Agreement and Data Shipping (DADSS) –

Created to provide an automated and easy-to-use system for tracking foreign media shipped from the CMS Data Center. DADSS provides data coordinators and CMS data release staff with the means to follow the movement of foreign media shipped from the CMS. This system maintains the accountability for the shipment of data from the CMS Tape Library.

HCIS/HCISMod (Health Care Information System/Health Care Information System Modernization) – HCIS/HCISMod is a multi-dimensional software application that provides an easy-to-use access path for non-programmers to manipulate Medicare data into information. HCIS provides Graphical User Interface (GUI) views and reports on the different types of Medicare services.

Incurred But Not Reported (IBNR) – The IBNR estimates represents the cost of services provided to Medicare beneficiaries but not paid at the end of the fiscal year, and is needed as part of the CMS financial statements.

Medicare Actuarial Data System (MADS) – The Medicare Actuarial Data Systems (MADS) incorporates monthly summarized Part A and quarterly summarized Part B data in relational statistical tables. The legislation authorizing this activity is OMB Circular A-130.

Monthly Bill and Payment Record Processing (MBPRP) – This system creates monthly and quarterly skeleton files that are used in a variety of other systems. Part A and Part B institutional claims data is used to create these skeleton files. Every input record processed has identifiable data but only select output files require identifiable data.

Medicare Provider Analysis and Review (MEDPAR) – The MEDPAR file is a representation of a beneficiary stay in an Inpatient hospital or Skilled Nursing Facility (SNF).

NCH – The National Claims History CMS' data repository of CWF = processed detailed claims transactions, beginning with service year 1991.

National Medicare Utilization Database (NMUD) – NMUD is the new storage structure for the Medicare claims data. NMUD has been developed to replace the existing sequential flat files NCH with a DB2 environment as the enterprise Medicare utilization repository. NMUD houses CWF-processed detail claims transactions, beginning with service year 1998.

PBA - Created to provide access to Part B claims information. PBA is replacing the current Part B Extract Summary System (BESS). This new system will allow for a more robust ad hoc capability for analyxing Part B data. The data will be contained within the IDR. This system will use BI tools, in particular MicroStrategy, to create reports and perform much of the ad hoc functionality. Operates in a mid-tier environment.

13. Indicate if the system is new or an existing one being modified: Existing

21. Is the system subject to the Privacy Act? (If response to Q.19 is Yes, response to Q.21 must be Yes and a SORN number is required for Q.4): Yes

23. If the system shares or discloses IIF please specify with whom and for what purpose(s): Data Extract System (DESY) – Other government agencies for fraud and abuse and disease management. Appropriate Data Use Agreement (DUA) is required.

DADSS – Data Agreement and Data Shipping – N/A

HCIS/HCISMod (Health Care Information System/Health Care Information System Modernization) – Other government agencies for fraud and abuse. Appropriate Data Use Agreement (DUA) is required.

IBNR - NA

Medicare Actuarial Data System (MADS) – N/A

Monthly Bill and Payment Record Processing (MBPRP) –

CMS staff/contractors

Medicare Provider Analysis and Review (MEDPAR) –

CMS Staff (including contractors)

DESY

DOJ

OIG

NIH

Hospitals And

Researchers.

Consistent With CMS Mission Purposes,

And With Required DUAs.

NCH – CMS staff/contractors, federal and state agencies, researchers, hospitals, OIG, GAO, DOJ

National Medicare Utilization Database (NMUD) – CMS staff/contractors; Federal and State agencies; researchers;

hospitals, OIG, GAO, DOJ

PBA - NA.

DADSS – Data Agreement and Data Shipping – DADSS data contains no Personal identifiers of any kind. It houses information related to legally binding Data Use Agreements and information used for shipping of data from the Data Center.

HCIS/HCISMod (Health Care Information System/Health Care Information System Modernization) – N/A

Incurred But Not Reported (IBNR) – N/A

Medicare Actuarial Data System (MADS) – N/A

Monthly Bill and Payment Record Processing (MBPRP) – N/A

Medicare Provider Analysis and Review (MEDPAR) – NCH Inpatient/SNF claims information, with the included IFF, is used as inputs to the MEDPAR system to create a stay record, a representation of a beneficiary’s stay in an Inpatient Hospital or Skilled Nursing Facility (SNF)

NCH – Medicare Part A and PArt B claims data. The data in this repository is used for a variety of purposes. From this claims data, numerous analytical files are created by CMS to support a variety of CMS business requirements. The NCH repository contains IIF data.

National Medicare Utilization Database (NMUD) – Medicare Part A and Part B claims data. The data in this repository is used for a variety of purposes. From this claims data, numerous analytical files are created by CMS to support a variety of CMS business requirements.

PBA - Medicare Part B data.

(Note: Please describe in what format individuals will be given notice of consent [e.g., written notice, electronic notice, etc.]) Data Extract System (DESY) – NA

DADSS – Data Agreement and Data Shipping – N/A

HCIS/HCISMod (Health Care Information System/Health Care Information System Modernization) – N/A

Incurred But Not Reported (IBNR) – N/A

Medicare Actuarial Data System (MADS) – N/A

Monthly Bill and Payment Record Processing (MBPRP) – N/A

Medicare Provider Analysis and Review (MEDPAR) – N/A

NCH – N/A

National Medicare Utilization Database (NMUD) – N/A

PBA - NA

32. Does the system host a website? (Note: If the system hosts a website, the Website Hosting Practices section is required to be completed regardless of the presence of PII): Yes

37. Does the website have any information or pages directed at children under the age of thirteen?: No

50. Are there policies or guidelines in place with regard to the retention and destruction of PII? (Refer to the C&A package and/or the Records Retention and Destruction section in SORN): Yes

54. Briefly describe in detail how the IIF will be secured on the system using administrative, technical, and physical controls.: DESY, MEDPAR, NCH, NMUD -APCSS RUNS THIS SYSTEM IN THE DATA CENTER.

HCIS/HCISmod, PBA, MADS, MBPRP, IBNR, PBA - is run in the data center

PIA Approval

PIA Reviewer Approval: Promote

PIA Reviewer Name: William Saunders

Sr. Official for Privacy Approval: Promote

Sr. Official for Privacy Name: Anthony Trenkle

Sign-off Date: Jun 26, 2009

Approved for Web Publishing: Yes

Date Published: September 1, 2009

_____________________________________________________________________________

06.3 HHS PIA Summary for Posting (Form) / Payment Quality Review Systems

PIA SUMMARY AND APPROVAL COMBINED

PIA Summary

Is this a new PIA? No

If this is an existing PIA, please provide a reason for revision: PIA Validation

1. Date of this Submission: Jun 26, 2009

2. OPDIV Name: CMS

3. Unique Project Identifier (UPI) Number: 009-38-01-09-01-1010-00

4. Privacy Act System of Records (SOR) Number (If response to Q.21 is Yes, a SORN number is required for Q.4): 09-70-0534, 09-70-0527, 09-70-0599, 09-70-0578, 09-70-0501

5. OMB Information Collection Approval Number: 0937-1012, 0938-0974, 0938-0994

6. Other Identifying Number(s): FID-OFM-253

7. System Name (Align with system Item name): Payment Quality Review Systems

9. System Point of Contact (POC). The System POC is the person to whom questions about the system and the responses to this PIA may be addressed: Antoinette Miller

10. Provide an overview of the system: PSOR: Tracks Part B overpayment and collections.

PORS: Tacks physician overpayment and collections.

REMAS: In most instances, Medicare is the primary payer for Medicare covered services furnished to Medicare beneficiaries. This means that Medicare’s full authorized payment is made without considering any other insurance available to the Medicare beneficiary. In some instances where other insurance is available to pay for the furnished services and other conditions are satisfied, Medicare payment is secondary to the payment obligation of the other insurance. The applicable statute is 42 U.S.C. 1395y(b) and the applicable regulations are 42 C.F.R411 Subparts B-H. If Medicare makes a mistaken primary payment in such a situation, Medicare pursues recovery of the mistaken primary payment from an appropriate party. Appropriate parties include providers, suppliers, insurers, employers, beneficiaries and other applicable parties. Once identified, the mistaken primary payments are considered debts to the United States and accounted for on that basis in Medicare’s accounting system and financial statements. ReMAS identifies instances where Medicare made a mistaken or conditional primary payment when it should have been the secondary payer. Claims are then identified and put into cases for the applicable debtor.

FID: The Fraud Investigation Database (FID) is a nationwide database directed to the accumulation of instances of potential and actual Medicare fraud and abuse cases, and the tracking of Medicare payment suspensions.

PERM: CMS has contracted with 3 federal contractors to identify error rates within the Medicaid and CHIP programs. These systems collect FFS claims, managed care payments, and eligibility information for both programs.

PSCAS: HIPAA gave CMS authority to enter into contracts, consistent with the Federal Acquisition Regulations (FAR) to promote the integrity of the Medicare program. In May 1999, CMS awarded 13 PSC contracts to perform some, or all, of the program safeguard functions, i.e., medical review, benefit integrity, cost report audit, data analysis, MIP provider education. CMS has awarded more than 40 individual task orders under the PSC Umbrella contract. PSCs maintain claims and eligibility data for beneficiaries and providers in their service areas. The data is used for prevention and prosecution of Medicare fraud, abuse and waste.

SMART resides on two Websphere application servers each having multiple virtual sessions. The application servers host users via a secure Citrix session. The backend data resides on a clustered SQL server environment. The system is maintained by multiple Websphere Application Servers and has a clustered SQL data environment. Access is granted via a user secure Citrix session. SMART resides in the Cahaba GBA Riverchase building in Birmingham. The application is maintained by VIPs via MDCN. Application availability is contingent upon MDCN availability, terminating circuits at each MSPRC location as well as the MDCN cloud.

MARTI is oftern referred to generically as a liability system although it also includes no-fault and workers' compensation cases. the system is maintained by multiple WebSphere Application Servers and has a clustered SQL data environment. Access is granted via a user secure Citrix session. MARTI resides at the Cahaba GBA Riverside building, Birmingham. The application is maintained by VIPs via MDCN. Application availability is contingent upon MDCN availability, terminating circuits as each MSPRC location as well as the MDCN cloud.

13. Indicate if the system is new or an existing one being modified: Existing

21. Is the system subject to the Privacy Act? (If response to Q.19 is Yes, response to Q.21 must be Yes and a SORN number is required for Q.4): Yes

23. If the system shares or discloses IIF please specify with whom and for what purpose(s): ReMAS: Shares data with Debt Collection System, DOJ, Attorneys, OGC for the purpose of recovering monies due to the Trust Fund.

FID: Shares information with OIG/DHHS, DOJ, FBI, Medicaid PI directors, Medicare fraud control units PURPOSE: To track specific case development and trends in Medicare fraud.

PERM: The 3 PERM contractors only share PERM data among themselves, as each is responsible for a piece of the entire PERM system. No other entity gets this data. PSCAS: The system discloses information to the Department of Justice and the Office of the Inspector General for DHHS. SMART and MARTI: Beneficary's attorneys after verification of consent to release.

PSOR: This system collects Part B overpayment at collection (i.e., recovery) information. A minimal level of data is collected due to privacy consideration.

REMAS: ReMAS collects identifying information (name, address, etc.) about beneficiaries that should have been covered under another insurance. Claim information for those beneficiaries is also collected so that users of ReMAS can identify whether each specific claim paid by Medicare was a mistaken or conditional payment that needs to be recouped. Identifying information (name, address, etc.) about providers and suppliers is also captured because that information is needed in order to develop a demand letter to the appropriate party.

FID: The agency accumulates information on cases of potential Medicare fee-for-service fraud and on payment suspensions.

PERM: CMS published a SOR for the 3 PERM system on May 16, 2006. The primary purpose of the PERM systems is to collect and maintain individually identifiable claims information in order to calculate payment error rates for the Medicaid and CHIP programs.

Information on Medicaid and CHIP beneficiary elegibility from the annual random sample is also connected. Collection of this information has been identified as a "routine use" under the Privacy Act.

PSCAS: The system will maintain and disseminate Medicare claims history and Medicare Provider characteristics to DOJ and OIG for the purposes of detecting, preventing, prosecuting Medicare fraud, abuse and waste.

SMART and MARTI: Collect beneficiary information related to Medicare claims from Remas, the SOR. This information includes name, address, HICN, and SSN. Additional or updated information may be gathered from the beneficiary such as updated address and phone number. This information is used by the MSPRC to verify the identity of the beneficiary prior to discussing any case.

(Note: Please describe in what format individuals will be given notice of consent [e.g., written notice, electronic notice, etc.]) PORS: Information is obtained from post-payment review and is collected from providers. It is cenveyed by written demand letter.

PSOR: Information is obtained from post-payment review and is collected from providers. It is conveyed by written demand letter.

REMAS: ReMAS has several electronic interfaces with other systems. Beneficiary data will be collected from the Medicare Beneficiary Database (MBD). Claims data will be collected from National Claims History (NCH) and National Medicare Utilization Database (NMUD) via the Data Extract System (DESY). Provider data will be obtained from the OSCAR, NSC and UPIN systems. Memorandums of Understanding between ReMAS and all other interfacing systems have been established.

FID: The FID information is entered by one of the following two groups: Medicare program safeguard contractors and Medicare Durable Medical Equipment Regional Carrier benefit integrity units. By it’s nature, the subjects of potential fraud investigations are not generally advised that they are under scrutiny. The information itself is information that a Medicare carrier or intermediary would maintain on a provider or supplier that has billed the Medicare program for reimbursement, and includes all available identifying pieces of information given by that provider or supplier on their enrollment application and/or their bill or claim for payment. Information in the FID could also include summary of findings from Medical or other review of submitted and/or paid claims.

PERM: CMS collects only the information necessary to carry out its statutory mandate to estimate the amount of improper payments made in the MEdicaid and CHIP programs. Per the PERM SOR, CMS will make disclosures from the PERM only with the consent of the subject individual, or his/her legal representative, or in accordance with the applicable exception provision of the Privacy Act. Information in the system is aquired either directly from the states or from Medicaid or CHIP providers.

PSCAC: Individuals whose PII is in the system when major changes occur to the system are notified through publication in the Federal Register of an update to the SOR for Medicare data. Consent of individuals regarding PII this system collects is obtained through the initial Medicare beneficiary agreement that is part of the application for Medicare benefits.

SMART and MARTI: They are not designated as SOR's. PII data is supplied to these systems by ReMAS. Consent to release forms are available to beneficiaries to allow their attorneys to interact with MSPRC associates on their behalf. All data in these systems is available only to MSPRC personnel.

32. Does the system host a website? (Note: If the system hosts a website, the Website Hosting Practices section is required to be completed regardless of the presence of PII): Yes

37. Does the website have any information or pages directed at children under the age of thirteen?: No

50. Are there policies or guidelines in place with regard to the retention and destruction of PII? (Refer to the C&A package and/or the Records Retention and Destruction section in SORN): Yes

54. Briefly describe in detail how the IIF will be secured on the system using administrative, technical, and physical controls.: Normal CMS Data Center physical security applies to all systems. Additionally:

PSOR: ID and password are required to enter the system.

REMAS: The data in ReMAS will be secured through application security at the user level. Access to specific sets of data has also been set up at the database level.

FID: Users need a valid CMS user id and password to access the system. User ids and passwords are authenticated through CMS

PERM: IDs and Passwords are required to enter the system. Physical security measures and environment protection controls are in place, as well as System Rules of Behavior for contractor staff.

PSCAS: Federal Information Security Management Act requirements are implemented for this system including risk assessments, contingency plans, system security plans, and a self assessment.

SMART and MARTI: The Site is not available outside the MDCN. All personnel having system access are screened by their respective HR departments. Technical security requirements include but are not limited to: user accounts, passwords, access limitation, reset procedures, suspension requirements, auditing procedures, and authenticator requirements. SMART and MARTI information is processed through mainframe applications and a systematic inventory of all library tapes is maintained electronically by a tape management system and is handled according to IT procedures.

PIA Approval

PIA Reviewer Approval: Promote

PIA Reviewer Name: William Saunders

Sr. Official for Privacy Approval: Promote

Sr. Official for Privacy Name: Anthony Trenkle

Sign-off Date: Jun 26, 2009

Approved for Web Publishing: Yes

Date Published: September 1, 2009

_____________________________________________________________________________

06.3 HHS PIA Summary for Posting (Form) / Procurement & Property Management Systems

PIA SUMMARY AND APPROVAL COMBINED

PIA Summary

Is this a new PIA? No

If this is an existing PIA, please provide a reason for revision: PIA Validation

1. Date of this Submission: Jun 26, 2009

2. OPDIV Name: CMS

3. Unique Project Identifier (UPI) Number: 009-38-02-00-01-1150-00

4. Privacy Act System of Records (SOR) Number (If response to Q.21 is Yes, a SORN number is required for Q.4): 09-70-0515, 09-70-0518, 09-70-0529

5. OMB Information Collection Approval Number: No

6. Other Identifying Number(s): COVD, PRISM, RMS, WL

7. System Name (Align with system Item name): Procurement and Property Management Systems

9. System Point of Contact (POC). The System POC is the person to whom questions about the system and the responses to this PIA may be addressed: Brenda Pickering/Rod Bemson/Olen Clybourn

10. Provide an overview of the system: PRISM – This COTS system tracks CMS contract and purchase order activity and produces documents and data for the FPDS-NG system.

RMS – The Records Management System (RMS) tracks the physical location of temporary Agency files stored in the Mezzanine level of the Centers for Medicare and Medicaid Services (CMS) Warehouse on a Kardex movable track filing system.

COVD - COVD exists to provide a data source for the Aperture space management software used by the OOM Administrative Services Group (ASG).

13. Indicate if the system is new or an existing one being modified: Existing

21. Is the system subject to the Privacy Act? (If response to Q.19 is Yes, response to Q.21 must be Yes and a SORN number is required for Q.4): Yes

23. If the system shares or discloses IIF please specify with whom and for what purpose(s): PRISM – Contractor/Vendor data is disclosed to the DHHS DCIS system, which then passes it on to the FPDS_NG system. The purpose is to comply with regulation on reporting of awarded contracts and purchase orders . RMS - N/A. WL-N/A. COVD-N/A.

RMS – Collects accession numbers, a CMS customers’ name-location-phone number-component, brief description of records stored, destroy date, number of boxes associated with each accession of record. The date collected is necessary in order to retrieve/return/dispose of records in storage.

COVD - The agency will use information collected by the ASG Customer Service Team as part of the Administrative Services Group move-order process.

PRISM - The information that is collected is voluntary information which is public information also contained in the federal CCR. This information is contained in the PRISM Vendor File. It included all information contained in SF 179. This data included vendor name, address, phone number, TIN, EIN, and DUNS numbers. The agency only used this data in order to mail documents to the vendor and to report to the Federal Procurement Data System.

(Note: Please describe in what format individuals will be given notice of consent [e.g., written notice, electronic notice, etc.]) PRISM - Vendors can be contacted if necessary by way of generating mailing labels from the PRISM vendor file data. Any change in the use of this data would only be mandated by a change in federal statute or regulation.

RMS - N/A

WL - N/A

COVD - N/A

32. Does the system host a website? (Note: If the system hosts a website, the Website Hosting Practices section is required to be completed regardless of the presence of PII): No

37. Does the website have any information or pages directed at children under the age of thirteen?: No

50. Are there policies or guidelines in place with regard to the retention and destruction of PII? (Refer to the C&A package and/or the Records Retention and Destruction section in SORN): Yes

54. Briefly describe in detail how the IIF will be secured on the system using administrative, technical, and physical controls.: PRISM - The PRISM system is available to a small user base (100 users), and IIF is secured using network authentication for tool access and database authentication for data access.

COVD - The COVD tool is available to a small user base, and PII is secured using network authentication for tool access and database authentication for data access.

RMS - N/A

WL - N/A

PIA Approval

PIA Reviewer Approval: Promote

PIA Reviewer Name: William Saunders

Sr. Official for Privacy Approval: Promote

Sr. Official for Privacy Name: Anthony Trenkle

Sign-off Date: Jun 26, 2009

Approved for Web Publishing: Yes

Date Published: September 1, 2009

_____________________________________________________________________________

06.3 HHS PIA Summary for Posting (Form) / Provider Enrollment Systems

PIA SUMMARY AND APPROVAL COMBINED

PIA Summary

Is this a new PIA? No

If this is an existing PIA, please provide a reason for revision: PIA Validation

1. Date of this Submission: Jun 26, 2009

2. OPDIV Name: CMS

3. Unique Project Identifier (UPI) Number: 009-38-01-09-01-1110-00 009-38-01-09-01-1115-00 009-38-01-09-01-1010-00 009-38-01-04-01-1110-00

4. Privacy Act System of Records (SOR) Number (If response to Q.21 is Yes, a SORN number is required for Q.4): 09-70-0532, 09-70-0525, 09-70-0517, 09-70-0008, 09-70-0530, 09-70-0524, 09-70-0534, 09-70-0597

5. OMB Information Collection Approval Number: PECOS: 0938-0685, 0938-01056; MED: OFM907; IRIS: 0938-0456

MED: OFM 907

6. Other Identifying Number(s): NA

FMIB OFM-246 (PECOS)

500-02-0041 (MED) / Computer matching agreement between CMS and SSA for PECOS: CMA 2001-05

7. System Name (Align with system Item name): Provider Enrollment Systems

9. System Point of Contact (POC). The System POC is the person to whom questions about the system and the responses to this PIA may be addressed: Antoinette Miller, 410-786-1011

10. Provide an overview of the system: NPPES: This initiative was mandated by the administrative simplification provisions of P.L. 104-191, the Health Insurance Portability and Accountability Act of 1996 (HIPAA). HIPAA mandates the adoption of a standard health care provider identifier and its assignment to every health care provider that transacts electronically any of the transactions specified in that law.

MED: MED receives excluded provider data from OIG each month. The data is formatted and verified, and then distributed to all CMS contractors in accordance with sections 1128A & B and 1162(e) of the Social Security Act.

IRIS: IRIS is comprised of both a mainframe subsystem and a mid-tier subsystem called IRISV3. Teaching hospitals use IRISV3 to log the time worked by interns and residents at their hospitals. This data is tied to the hospitals cost report and is used as a determining factor on how much reimbursement the hospitals get in lieu of care given to Medicare and Medicaid patients. CMS collects the data and produces a periodic duplicate report which points out intrastate overlaps in periods worked by an intern or resident between two or more hospitals.

PECOS: The Medicare Federal Health Care Provider/Supplier Enrollment Application (CMS 855A, 855B, 855I, 855R, and 855S) has been designed by the Centers for Medicare and Medicaid Services (CMS) to assist in the administration of the Medicare program and to ensure that the Medicare program is in compliance with all regulatory requirements. The information collected in this application will be stored in the Provider Enrollment, Chain and Ownership System and used to ensure that payments made from the Medicare trust fund are only paid to qualified health care providers, and that the amounts of the payments are correct. The Centers for Medicare and Medicaid Services (CMS) is authorized to collect the information requested on this form by sections 1124(a)(1), 1124A(a)(3), 1128, 1814, 1815, 1833(e), and 1842(r) of the Social Security Act [42 U.S.C. §§ 1320a-3(a)(1), 1320a-7, 1395f, 1395g, 1395(l)(e), and 1395u(r)] and section 31001(1) of the Debt Collection Improvement Act [31 U.S.C. § 7701(c)]. The OMB approval number for this information collection is 0938-0685, and is renewed each time changes are made to the information collected.

NPICS: Data is extracted from NRRES and the provider files (PECOS) and compared to determine what Medicare legacy number and NPI should be mapped.

13. Indicate if the system is new or an existing one being modified: Existing

21. Is the system subject to the Privacy Act? (If response to Q.19 is Yes, response to Q.21 must be Yes and a SORN number is required for Q.4): Yes

23. If the system shares or discloses IIF please specify with whom and for what purpose(s): CMS Staff, Other Federal Agencies, CMS contractors (IRIS)

Health plans as required by regulations, other federal agencies as described by SOR (NPPES)

NPPES will make all data (excluding the SSN and DOB) available in a downloadable file. This follows FOIA requirements. A file with DOB will only be available to those who have an approved DUA with CMS and only when the SSA and name of the provider is supplied and matchezs what is in NPPES.

Carriers, FI’s, States, PSC’s, and Medicare Advantage Players – to identify and refuse payment to excluded providers. (MED)

NPICS: Verify legacy/NPI pairs.

MED: The only data taken from the OIG file is the data required to uniquely identify the provider in order to exclude the right guy (name, ssn, dob), as well as the pertinent exclusion data.

IRIS: Information is collected on 3½ inch floppy disks which are mailed to IRIS system maintainer. The information is used to create a periodic duplicate report and is released for research purposes. The minimum amount of data is collected to facilitate production of reports.

PECOS: The Medicare Federal Health Care Provider/Supplier Enrollment Application (CMS 855A, 855B, 855I, 855R, and 855S) has been designed by the Centers for Medicare and Medicaid Services (CMS) to assist in the administration of the Medicare program and to ensure that the Medicare program is in compliance with all regulatory requirements. The information collected in this application will be used to ensure that payments made from the Medicare trust fund are only paid to qualified health care providers, and that the amounts of the payments are correct. This information will also identify whether the provider is qualified to render health care services and/or furnish supplies to Medicare beneficiaries. To accomplish this, Medicare must know basic identifying and qualifying information about the health care provider that is seeking billing privileges in the Medicare program. Medicare needs to know: (1) the type of health care provider enrolling, (2) what qualifies this provider as a health care related provider of services and/or supplies, (3) where this provider intends to render these services and/or furnish supplies, and (4) those persons or entities with an ownership interest, or managerial control, as defined in this application, over the provider.

NPICS: Data is extracted from NPPES and PECOS, NSC and NCPDP and compared tp determine what Medicare legacy number and NPI should be mapped.

(Note: Please describe in what format individuals will be given notice of consent [e.g., written notice, electronic notice, etc.]) NPPES: Information collected via the NPPES web site (internet) of paper application. Notification of NPI given via e-mail (if application was via web) or paper letter if application was via paper.

MED: All our data and information comes from OIG. They provide us with a file, and Team MED pulls of the data we require to identify an excluded provider.

IRIS: The information is obtained from Fiscal Intermediaries on 3 ½ inch floppy disks who in turn receive the information from teaching hospitals.

PECOS: The information will be collected from all health care providers and suppliers who render services or supplies to Medicare beneficiaries and bill the Medicare program for those services and supplies. This information will be collected via the completion of the CMS 855, Provider/Suppler Enrollment Application. All of this information is conveyed to the providers of the information in writing directly on the CMS 855 and in the certification signature page of the form.

NPICS: Consent of individuals regarding IIF this system collects is obtained through the intitial Medicare beneficiary agreement that is part of the application for Medicare benefits.

32. Does the system host a website? (Note: If the system hosts a website, the Website Hosting Practices section is required to be completed regardless of the presence of PII): Yes

37. Does the website have any information or pages directed at children under the age of thirteen?: No

50. Are there policies or guidelines in place with regard to the retention and destruction of PII? (Refer to the C&A package and/or the Records Retention and Destruction section in SORN): Yes

54. Briefly describe in detail how the IIF will be secured on the system using administrative, technical, and physical controls.: NPPES: Users can get to their NPPES information via a valid user id and password. See the NPPES SSP for more information on system security.

MED: The data is housed on the CMS mainframe, and is subject to standard CMS Data Center security policy.

PECOS: Users need a valid CMS user id and password to access the system. User ids and passwords are authenticated through CMS.

NPICS: The data is housed on the CMS mid-tier, and is subject to standard CMS Data Center security policy.

PIA Approval

PIA Reviewer Approval: Promote

PIA Reviewer Name: William Saunders

Sr. Official for Privacy Approval: Promote

Sr. Official for Privacy Name: Anthony Trenkle

Sign-off Date: Jun 26, 2009

Approved for Web Publishing: Yes

Date Published: September 1, 2009

_____________________________________________________________________________

06.3 HHS PIA Summary for Posting (Form) / Q-Net

PIA SUMMARY AND APPROVAL COMBINED

PIA Summary

Is this a new PIA? No

If this is an existing PIA, please provide a reason for revision: PIA Validation

1. Date of this Submission: Jun 26, 2009

2. OPDIV Name: CMS

3. Unique Project Identifier (UPI) Number: 009-38-01-06-01-1030-00

4. Privacy Act System of Records (SOR) Number (If response to Q.21 is Yes, a SORN number is required for Q.4): 09-70-0520

5. OMB Information Collection Approval Number: 0938-0581 12/2007

6. Other Identifying Number(s): N/A

7. System Name (Align with system Item name): Q-Net

9. System Point of Contact (POC). The System POC is the person to whom questions about the system and the responses to this PIA may be addressed: Debbra Hattery

10. Provide an overview of the system: QualityNet (QNet) is a General Support System (GSS). CMS maintains the QNet network infrastructure, a network environment that uses shared database servers and WAN/LAN resources to monitor and improve utilization and quality of care for Medicare and Medicaid beneficiaries. The program consists of the CMS Data Center Complex 1 located at the CMS central offices in Baltimore, MD; Complex 2, located at the Iowa Foundation for Medical Care (IFMC) in Des Moines, IA; Complex 3, located at Buccaneer Computer Systems & Services, Inc. (BCSSI) in Warrenton, VA; a national network of 53 Quality Improvement Organization (QIO) sites responsible for each US state, territory, and the District of Columbia; 1 Clinical Data Abstraction Center (CDAC); 18 End Stage Renal Disease (ESRD) networks; and the two BCSSI and IFMC Contractor support locations.

This legislation is under the Social Security Act, Title XVIII, Section 1864: “93.777 State Survey and Certification of Health Care Providers and Suppliers”

This legislation is under Title XI of the Social Security Act, Part B, as amended by the Peer Review Improvement Act of 1982.

This legislation is under Title XI--General Provisions, Peer Review, and Administrative Simplification

The Balanced Budget Act of 1997 created section 1932 (c)(2) of the Act, which would replace section 1902 (a)(30)(C) with a new requirement for annual, external quality review (EQR) of Medicaid MCOs.

13. Indicate if the system is new or an existing one being modified: Existing

21. Is the system subject to the Privacy Act? (If response to Q.19 is Yes, response to Q.21 must be Yes and a SORN number is required for Q.4): Yes

23. If the system shares or discloses IIF please specify with whom and for what purpose(s): The Quality Improvement System for Managed Care (QISMC) standards and guidelines are key tools for use by CMS and States in implementing the quality assurance provisions of the Balanced Budget Act of 1997 (BBA), as amended by the Balanced Budget Refinement Act of 1999. The QISMC standards and guidelines are intended to achieve four major goals:

· To clarify the responsibilities of CMS and the States in promoting quality as value-based purchasers of services for vulnerable populations.

· To promote opportunities for partnership among CMS and the States and other public and private entities involved in quality improvement efforts.

· To develop a coordinated Medicare and Medicaid quality oversight system that would reduce duplicate or conflicting efforts, and send a uniform message on quality to organizations and consumers.

· To make the most effective use of available quality measurement and improvement tools, while allowing sufficient flexibility to incorporate new developments in the rapidly advancing state of the art.

For further detailed information, please refer to the following Health Care Quality Improvement Systems (HCQIS) PIA’s:

Consolidated Renal Operations in a Web-Enabled Environment (CROWN)

Quality Improvement Evaluation System (QIES)

Standard Data Processing System (SDPS)

· Standard Data Processing System (SDPS)

· Consolidated Renal Operations in a Web-Enabled Environment (CROWN)

· Quality Improvement Evaluation System (QIES)

- Value Based Purchasing (VBP)

- Quality Improvement Initiatives (QII)

The QNet WAN/LAN infrastructure supports the following CMS organizational business processes and data collection requirements:

· The capability for collection and management of clinical, survey, and project data from Medicare and Medicaid providers.

· The management and analysis of that clinical, survey, and project data with various SDPS programs by the Quality Improvement Organization (QIO).

· The collection of data by ESRD Network Organizations to administer the national Medicare ESRD program.

· The collection of provider and beneficiary-specific outcomes of care and performance data using QIES across a multitude of delivery sites (such as nursing homes and Rehabilitation and Long Term Care Hospitals, etc.) for use to improve the quality and cost effectiveness of services provided by the Medicare and Medicaid programs.

· The management and provision of Medicare and Medicaid information to providers that include but are not limited to Hospitals, physician or family practice clinics, dialysis clinics, Skilled Nursing Facilities, Home Health Agencies, and various specialized clinics.

For further detailed information, please refer to the following Health Care Quality Improvement Systems (HCQIS) PIA’s:

Consolidated Renal Operations in a Web-Enabled Environment (CROWN)

Quality Improvement Evaluation System (QIES)

Standard Data Processing System (SDPS)

Value Based Purchasing (VBP)

Quality Improvement Initiatives (QII)

(Note: Please describe in what format individuals will be given notice of consent [e.g., written notice, electronic notice, etc.]) For further detailed information, please refer to the following Health Care Quality Improvement Systems (HCQIS) Privacy Impact Assessments:

Consolidated Renal Operations in a Web-Enabled Environment (CROWN)

Quality Improvement Evaluation System (QIES)

Standard Data Processing System (SDPS)

Value Based Purchasing (VBP)

Quality Improvement Initiatives (QII)

32. Does the system host a website? (Note: If the system hosts a website, the Website Hosting Practices section is required to be completed regardless of the presence of PII): Yes

37. Does the website have any information or pages directed at children under the age of thirteen?: No

50. Are there policies or guidelines in place with regard to the retention and destruction of PII? (Refer to the C&A package and/or the Records Retention and Destruction section in SORN): Yes

54. Briefly describe in detail how the IIF will be secured on the system using administrative, technical, and physical controls.: For further detailed information, please refer to the following Health Care Quality Improvement Systems (HCQIS) Privacy Impact Assessments:

Consolidated Renal Operations in a Web-Enabled Environment (CROWN)

Quality Improvement Evaluation System (QIES)

Standard Data Processing System (SDPS)

Value Based Purchasing (VBP)

Quality Improvement Initiatives (QII)

PIA Approval

PIA Reviewer Approval: Promote

PIA Reviewer Name: William Saunders

Sr. Official for Privacy Approval: Promote

Sr. Official for Privacy Name: Anthony Trenkle

Sign-off Date: Jun 26, 2009

Approved for Web Publishing: Yes

Date Published: September 1, 2009

_____________________________________________________________________________

06.3 HHS PIA Summary for Posting (Form) / Retiree Drug System (RDS)

PIA SUMMARY AND APPROVAL COMBINED

PIA Summary

Is this a new PIA? No

If this is an existing PIA, please provide a reason for revision: PIA Validation

1. Date of this Submission: Jun 26, 2009

2. OPDIV Name: CMS

3. Unique Project Identifier (UPI) Number: 009-38-01-04-01-1200-00

4. Privacy Act System of Records (SOR) Number (If response to Q.21 is Yes, a SORN number is required for Q.4): 09-70-0550

5. OMB Information Collection Approval Number: 0938-0957/0938-0977

6. Other Identifying Number(s): FMIB # 6547

7. System Name (Align with system Item name): Retiree Drug Subsidy System

9. System Point of Contact (POC). The System POC is the person to whom questions about the system and the responses to this PIA may be addressed: David Gardner

10. Provide an overview of the system: The RDS system is designed to provide information, enrollment, payment, and customer service for Plan Sponsors enrolled in the RDS Program. It is also designed to allow CMS to manage and track expenditures to Plan Sponsors as well as Plan eligibility and compliance.

13. Indicate if the system is new or an existing one being modified: Existing

21. Is the system subject to the Privacy Act? (If response to Q.19 is Yes, response to Q.21 must be Yes and a SORN number is required for Q.4): Yes

23. If the system shares or discloses IIF please specify with whom and for what purpose(s): RDS shares PII with Federal Law Enforcement Agencies and with CMS information systems such as the MBD to verify retirees' ability to be claimed by an Employer Plan Sponsor as a qualifying covered retiree under the RDS program. In additional PII may potentially be shared with Federal Law Enforcement Agencies.

(Note: Please describe in what format individuals will be given notice of consent [e.g., written notice, electronic notice, etc.]) CMS is required to provide updated Notices of Privacy Practices .

32. Does the system host a website? (Note: If the system hosts a website, the Website Hosting Practices section is required to be completed regardless of the presence of PII): Yes

37. Does the website have any information or pages directed at children under the age of thirteen?: No

50. Are there policies or guidelines in place with regard to the retention and destruction of PII? (Refer to the C&A package and/or the Records Retention and Destruction section in SORN): Yes

54. Briefly describe in detail how the IIF will be secured on the system using administrative, technical, and physical controls.: All data is secured in accordance with the RDS System Security Plan

PIA Approval

PIA Reviewer Approval: Promote

PIA Reviewer Name: William Saunders

Sr. Official for Privacy Approval: Promote

Sr. Official for Privacy Name: Anthony Trenkle

Sign-off Date: Jun 26, 2009

Approved for Web Publishing: Yes

Date Published: September 1, 2009

_____________________________________________________________________________

06.3 HHS PIA Summary for Posting (Form) / WAN Services MDCN

PIA SUMMARY AND APPROVAL COMBINED

PIA Summary

Is this a new PIA? No

If this is an existing PIA, please provide a reason for revision: PIA Validation

1. Date of this Submission: Jun 26, 2009

2. OPDIV Name: CMS

3. Unique Project Identifier (UPI) Number: 009-38-02-00-01-1150-00

4. Privacy Act System of Records (SOR) Number (If response to Q.21 is Yes, a SORN number is required for Q.4): N/A

5. OMB Information Collection Approval Number: N/A

6. Other Identifying Number(s): N/A

7. System Name (Align with system Item name): WAN Services/MDCN

9. System Point of Contact (POC). The System POC is the person to whom questions about the system and the responses to this PIA may be addressed: Ed Gray

10. Provide an overview of the system: This GSS provides compute platforms, telecommunications, electronic storage information and operations support services for the collection, maintenance, and access of data and information to support the business functions of CMS.

13. Indicate if the system is new or an existing one being modified: Existing

21. Is the system subject to the Privacy Act? (If response to Q.19 is Yes, response to Q.21 must be Yes and a SORN number is required for Q.4): No

23. If the system shares or discloses IIF please specify with whom and for what purpose(s): No

(Note: Please describe in what format individuals will be given notice of consent [e.g., written notice, electronic notice, etc.]) No, this GSS does not directly collect, maintain, or disseminate information. It provides platform support infrastructure for other CMS MA’s to perform their function.

32. Does the system host a website? (Note: If the system hosts a website, the Website Hosting Practices section is required to be completed regardless of the presence of PII): No

37. Does the website have any information or pages directed at children under the age of thirteen?: No

50. Are there policies or guidelines in place with regard to the retention and destruction of PII? (Refer to the C&A package and/or the Records Retention and Destruction section in SORN): No

54. Briefly describe in detail how the IIF will be secured on the system using administrative, technical, and physical controls.: The CMS WAN Services/MDN provides telecommunications infrastructure for use by other CMS business application Website functions, but does not directly provide a data or information content Website.

PIA Approval

PIA Reviewer Approval: Promote

PIA Reviewer Name: William Saunders

Sr. Official for Privacy Approval: Promote

Sr. Official for Privacy Name: Anthony Trenkle

Sign-off Date: Jun 26, 2009

Approved for Web Publishing: Yes

Date Published: September 1, 2009

_____________________________________________________________________________