Skip to main content

CMS Privacy Program Plan

A plan designed to help CMS staff understand the specific requirements of the Privacy Program at CMS

Last reviewed: 11/3/2022

Contact: Privacy Office | privacy@cms.hhs.gov

Related Resources

​​​​​Privacy program at CMS

Use and disclosure

As authorized by statute, regulation, or Executive Order, CMS conducts activities involving the collection, use, and disclosure of Protected Health Information (PHI) and Personally Identifiable Information (PII). CMS collects, uses, and discloses PII/PHI for payment and health care operations if and only if CMS can identify a statute or Executive Order that provides CMS with the authority for that action. Regulations, internal guidance, or informal guidelines are not sufficient to provide CMS with the authority to take action with reference to PII or PHI.

CMS relies on statutes, regulations, Executive Orders, and CMS’ policies and procedures to determine whether a collection, use, or disclosure of PHI or PII is required or permitted. CMS’s authority to collect is included in its Privacy Act Systems of Records, web site Privacy Act Notices, Privacy Impact Assessments, and in other compliance documents and notices where appropriate.

For internal uses, CMS develops and implements policies and procedures that limit access and use of PII/PHI based on the specific needs and roles of its workforce members, thereby limiting access to that which is required to carry out their duties. To do so, CMS identifies the categories of PII/PHI to which access is needed, and any conditions under which the workforce needs the PII/PHI to do their jobs.

This applies to all CMS employees, contractors, grantees, and all other users of CMS information and information systems supporting the operations and assets of CMS. The following steps detail the CMS-specific process for use and disclosures of PII/PHI.

Step 1: CMS shall evaluate each program’s collection, maintenance, use, and disclosure of PII and PHI to ensure conformance to CMS policy, procedure, and applicable laws.

Step 2: CMS shall use notice and comment rulemaking to publish program regulations in the Federal Register based on the applicable statutory authority, Executive Order(s), and the desired program policies.

Step 3: CMS shall publish Privacy Act Systems of Records in the Federal Register that describe the authority and purpose for the collection, maintenance, use, and disclosure of PII that will be contained in Systems of Records

Step 4: CMS provides a Notice of Privacy Practices for Original Medicare in the annual Medicare and You Handbook that describes the uses and disclosures of PII/PHI and individual’s access rights.

Other permitted uses and disclosures

CMS may use and disclose protected health information (PHI) and personally identifiable information (PII) as allowed by federal law and with an individual’s authorization. If CMS does not have the individual’s authorization, it may only use and disclose PII/PHI as permitted under applicable law, including the HIPAA Privacy Rule (for instances involving PHI) and the Privacy Act (for instances involving PII). Other program specific or specialized laws may impose added requirements or conditions on the disclosure of particular categories of PHI or PII. For example, substance abuse treatment records are subject to HIPAA, the Privacy Act, and Substance Abuse and Mental Health Services Administration (SAMHSA)’s Part 2 (42 CFR Part 2) regulations.

For internal uses, CMS develops and implements policies and procedures that limit access and use of PII/PHI based on the specific needs and roles of its workforce members, thereby limiting access to that which is required to carry out their duties. CMS further limits the role-based access of these individuals such that they can only access the records they need to access, and/or limits access to only the data elements within those records that are relevant to the performance of those specific roles. Finally, CMS may limit access to only the conditions under which those individuals need access to PII/PHI to do their jobs.

Under the Privacy Act, for each system of records, a list of all disclosures permitted without the subject’s notification and consent are found in the system of records notice’s “routine uses” section in accordance with 5 U.S.C. 552a(b)(3).

Subject to certain limitations and requirements, which generally include the minimum necessary concept and disclosure-specific limitations and requirements, the HIPAA Privacy Rule permits covered entities to disclose PHI without the subject individuals’ authorization under the following conditions:

  • Uses and disclosures required by law (45 CFR 164.103; 164.512(a))
    • CMS is permitted to use and disclose PII/PHI when it is required by law (including, but not limited to statute, regulation, or court orders). Permitted uses or disclosures are limited to those permitted by the relevant law.
  • Uses and disclosures for public health activities (45 CFR 164.103; 164.512(a))
  • Uses and disclosures for public health activities, to:
    • A public health authority authorized by law to collect or receive PII/PHI for the purpose of preventing or controlling disease, injury, or disability; or to
    • A public health authority or other appropriate government authority, authorized by law to receive reports of child abuse or neglect.
  • Disclosures about victims of abuse, neglect, or domestic violence (45 CFR 164.501; 164.512(b))
    • CMS supports the disclosure of PII/PHI for purposes of protecting victims of abuse, neglect, or domestic violence.
  • Uses and disclosures for health oversight activities (45 CFR 164.501; 164.512(d))
    • CMS discloses PII/PHI to a health oversight agency for oversight activities authorized by law, including audits; civil, administrative, or criminal investigations; inspections; licensure or disciplinary actions; civil, administrative, or criminal proceedings or actions; or other activities necessary for appropriate oversight of:
    • The health care system;
      1. Government benefit programs for which health information is relevant to beneficiary eligibility;
      2. Entities subject to government regulatory programs for which health information is necessary for determining compliance with program standards; or
      3. Entities subject to civil rights laws for which health information is necessary for determining compliance.
    • Permitted health oversight activity disclosures do not include an investigation or other activity in which the beneficiary is the subject of the investigation or activity unless certain conditions are met:
  • Disclosures for judicial and administrative proceedings (45 CFR 164.512(e))
    • CMS regularly discloses PII/PHI in the course of judicial or administrative proceedings.
  • Disclosures for law enforcement purposes (45 CFR 164.512(f))
    • CMS discloses PII/PHI for law enforcement purposes.
  • In response to a subpoena, discovery request, or other lawful process that is not accompanied by an order of a court of competent jurisdiction, CMS handles the request as a Freedom of Information Act (FOIA) request in accordance with HHS policy.
  • Uses and disclosures about decedents (45 CFR 160.103; 164.502(g)(1); 164.508)
    • CMS may only disclose PII/PHI about decedents in the past fifty years when CMS has the proper documentation necessary to determine the legal authority of the requester or the legal relationship of the requester to the decedent (e.g. executor).
  • Uses and disclosures for research purposes (45 CFR 164.501; 164.512(i))
    • CMS discloses PII/PHI for research purposes when the PII/PHI request is approved by the CMS Privacy Board (i.e. OEDA) and an independent Privacy Board or an Institutional Review Board (IRB) has modified or waived the Privacy Rule authorization requirements. The researcher must receive a HIPAA waiver from an external Privacy Board or IRB as the CMS Privacy Board does not issue HIPAA waivers for external research requests. IRBs may also make findings regarding Human Subjects research, but those findings are distinguishable from the required Privacy Rule waivers or modifications.
  • Uses and disclosures to avert a serious threat to health or safety (45 CFR 164.512(j))
    • CMS uses or discloses PII/PHI if the agency believes it is necessary to prevent or lessen a serious and imminent threat to a person or the public, when such disclosure is made to someone the agency believes can prevent or lessen the threat.
    • CMS also discloses to law enforcement if the information is needed to identify or apprehend an escapee or violent criminal.
  • Uses and disclosures for specialized government functions (45 CFR 164.512(k))
    • CMS uses or discloses PII/PHI for specialized government functions.
  • Disclosures for workers’ compensation (45 CFR 164.512(l))
    • CMS discloses PII/PHI as authorized by, and to comply with, workers’ compensation laws and other similar programs providing benefits for work-related injuries or illnesses.

The following steps detail the CMS-specific process for other permitted use and disclosures of PII/PHI.

General Procedures

When CMS receives a request for PII/PHI from an external organization, a determination is made on whether such use and disclosure is permitted by law. The request is reviewed by the CMS Business Owner in consultation with the Privacy Office, which will consult with the CMS Division of the Office of General Counsel as needed.

Procedures for Disclosures for Judicial and Administrative Proceedings (45 CFR 164.512(e))

  • CMS regularly discloses PII/PHI in the course of judicial and administrative proceedings. This is done in response to an order from a court of competent jurisdiction (Federal District Court or higher), or a subpoena if CMS discloses only the PII/PHI explicitly authorized by the order and/or subpoena.
  • CMS generally seeks a protective order when it receives a court order or subpoena seeking PII/PHI. The protective order restricts or limits the use of the data provided by CMS only for uses as outlined in the court order.
  • Regardless of the origin of the court orders or subpoena, the CMS employee in receipt of the legal document shall forward it to the CMS Privacy Act Officer. The Privacy Act Officer sends all court orders to the Office of General Counsel (OGC) General Law Division, to confirm legal sufficiency. If a protective order is not included in or with the court order or subpoena, then OGC General Law Division returns the request to the requester with instructions on how to resubmit.
  • After OGC GLD confirms legal sufficiency, the court order is sent to the Privacy Act Officer. The Privacy Act Officer acknowledges receipt of the court order or subpoena within 10 working days.
  • The Privacy Act Officer determines if CMS has the responsive documents. If CMS has the documents, authorization is given for the request to be acted on by the data disclosure component (DDC).
  • The disclosure component pulls the requested data. If there are any questions on whether the data is responsive to the court order, the Privacy Act Officer reviews the data, verifies that the data is responsive, and, subject to review for privilege, authorizes its disclosure. Only data that is explicitly requested is released.
  • Before the data is sent to the requester, the DDC notifies the EPPE staff within OEDA and the OEDA staff enter the disclosure into the EPPE tracking system and then releases the data to the requester.
  • If CMS does not have the data that is requested, the Privacy Act Officer, in conjunction with OGC, will communicate with the appropriate parties.

Procedures for Disclosures for Law Enforcement Purposes

  • Law Enforcement (LE) requests may come to CMS through a FOIA request, the Office of General Counsel, a letter to the Privacy Office, or a letter to the Business Owner. All law enforcement requests must be in writing.
  • These requests are forwarded to the Privacy Act Officer.
  • When the request is received, the Privacy Act Officer acknowledges receipt of the request within 10 working days.
  • The request is reviewed to ensure it meets the requirements of the Privacy Act, the HIPAA Privacy Rule and HSS and CMS policy and procedures for a law enforcement letter. Among other things, the request must meet the following requirements:
    • Come from the head of the law enforcement agency (or a delegated authority);
    • Be written on agency letterhead stationery;
    • Be for a legitimate active case;
      • Our criteria is: “to another agency or to an instrumentality of any governmental jurisdiction within or under the control of the Unites States for a civil or criminal law enforcement activitiy if the activity is authorized by law, and if the head of the agency or instrumentality has made a written request to the agency which maintains the record specifiying the particular portion desired and the law enforcement activity for which the record is sought.” -Privacy Act, b(7)
    • Be specific and limited in scope to the purpose for which the information is sought;
    • State the applicable law that authorizes the requester to obtain the information; and
    • Contain an original signature of the head of the law enforcement agency or designee.
  • If the written request does not contain the required elements, the Privacy Act Officer returns the request; along with information on what is missing and how to resubmit.
  • When a completed request is received, the Privacy Act Officer determines if CMS has the responsive documents. If CMS has the documents, authorization is given for the request to be acted on by the data disclosure component.
  • The disclosure component pulls the data. If there are no questions concerning the data, the data is sent to the requester. If there are any questions on whether the data is responsive to the request, the Privacy Act Officer reviews the data, verifies that the data is responsive, and authorizes its disclosure. Only data that is explicitly requested is released.
  • Before the data is sent to the requester, the DDC completes the required entries into CMS’s data tracking system to document and track its release and then releases the data to the requester.
  • If CMS does not have the data that is requested, the Privacy Act Officer, in conjunction with OGC, will communicate with the appropriate parties.

Procedures for Use and Disclosures about Decedents

CMS may only disclose PII/PHI about decedents in the past fifty years when CMS has the proper documentation necessary to determine the legal relationship of the requester or the legal relationship of the requestor to the decedent (e.g. executor). After receiving proper documentation, follow the general procedures for use and disclosure discussed above.

Procedures for Use and Disclosures for Research Purposes

CMS discloses PII/PHI for research purposes when the PII/PHI request is approved by the CMS Privacy Board.

Requests for Research Identifiable Files (RIF) data are reviewed by OEDA to ensure that the beneficiary’s privacy is protected, that the request for identifiable data is legally permitted, and that all required documents are completed, reviewed, and approved.

A list of the required documents for a request for RIF data can be found on the ResDAC website (www.resdac.org). After ResDAC reviews the packet and the packet is finalized by the researcher, they must obtain a waiver from an external IRB then the request will be forwarded to the CMS Privacy Board for review. If the request is approved by the CMS Privacy Board, the Privacy Board notifies the researcher, and the request is processed with a signed CMS data use agreement (DUA).

Minimum Necessary

CMS is required to collect, use, and disclose only the minimum amount of protected health information (PHI) and personally identifiable information (PII) necessary to conduct treatment, payment, and health care operations, and to conduct all other permitted uses and disclosures. For internal uses, CMS develops and implements procedures that limit access and use of PII/PHI based on specific needs of and roles of its workforce members, thereby limiting access to that which is required to carry out their duties. Whenever possible, CMS further limits these individuals’ access such that they can only access the records they need to access, and/or limits access to only the data elements within those records that are relevant to the performance of those specific roles. Finally, CMS may limit access to only the conditions under which those individuals need access to PII/PHI to do their jobs.

CMS makes reasonable efforts to limit the use or disclosure of PII/PHI to the minimum necessary in order to accomplish the intended purpose of the use, disclosure, or request. CMS relies, if such reliance is reasonable under the circumstances, on the wording of the request for disclosure to determine the minimum necessary PII/PHI to be disclosed.

When requesting PII/PHI from other covered entities, CMS limits any such request to that which is reasonably necessary to accomplish the purpose for which it makes the request.

For requests made on a routine and recurring basis, CMS limits the PII/PHI requested to the amount reasonably necessary to accomplish the purpose for which the request is made.

All other requests are reviewed on an individual basis to determine that the PII/PHI sought is limited to the information reasonably necessary to accomplish the purpose for which the request is made.

When collecting, using, and disclosing PII, it is the responsibility of the CMS Business Owner to determine the minimum necessary PII/PHI required to conduct the activity for which the agency is authorized. A Contracting Officer’s Representative, working with the Contracting Officer and the Business Owner, makes the determination. The Privacy Office and the Office of General Counsel are consulted, as necessary.

Verification of Identity

Prior to any disclosure of Protected Health Information (PHI) or Personally Identifiable Information (PII), CMS:

  • Authenticates the identity of a person requesting PII/PHI and, as appropriate, the authority of any such person permitted access to PII/PHI;
  • If the requester represents themselves as the personal representative of a person authorized to receive access to PII/PHI, CMS will authenticate both the identity of the person and of the personal representative. CMS will then treat the personal representative the same as the individual with respect to uses and disclosures of the individual’s PII/PHI as well as the individual’s rights under the HIPAA Privacy Rule; and
  • Obtains any documentation, statements, or representations that serve to authenticate the individual and/or confirm the status and identity of their personal representative, whether oral or written, from the authorized person requesting the PII/PHI.

The following steps detail the CMS-specific process for verifying an individual’s identity.

Authentication of Identity Prior to Disclosure of PII/PHI

For detailed guidance in authenticating identity prior to disclosing PII/PHI, use CMS Program Pub. 100-01 Medicare General Information, Eligibility, and Entitlement, Transmittal 7, dated June 25, 2004. 

Verification of Legal Authority to Act as Personal Representative

CMS relies on documentation, statements, or representations that, on their face, legally authorize a person to act on the beneficiary’s behalf or on behalf of a deceased individual or the decedent’s estate. This documentation, if applicable, should be part of the beneficiary’s record.

After the personal representative’s identity has been authenticated and before disclosure of PII/PHI, CMS checks the beneficiary’s record for the required documentation that authorizes an individual to act as a personal representative (e.g., Guardianship and Letters Testamentary). If the documentation is in the record, then the PII/PHI can be disclosed.

If the documentation is not in the record, then CMS refers the requester to Medicare.gov for information on submitting the required documentation or directs the requester to call 1-800-MEDICARE.

Authorization

CMS requires the individual’s written authorization for any use or disclosure of Protected Health Information (PHI) or Personally Identifiable Information (PII) that is not for treatment, payment, health operations, or otherwise permitted or required by the HIPAA Privacy Rule and/or the Privacy Act. This includes a situation where an individual requests to have their own information shared with a third party.

CMS does not condition payment, enrollment, or benefits eligibility on an individual granting an authorization.

CMS’s requires all written consent to be in plain language and contain specific information, such as the PII/PHI to be used or disclosed, the persons or entities disclosing and receiving the information, the expiration date of the consent, and information providing the right to revoke the authorization in writing if it has not been acted upon already.

The following steps detail the CMS-specific process for requesting and receiving an individual’s written authorization.

CMS has a standard authorization form, “1-800-Medicare Authorization to Disclose Personal Health Information.” The form includes information on how to submit a completed authorization, as well as the required elements needed for a valid authorization under the HIPAA Privacy rule.

Personal Representatives

CMS generally treats a personal representative the same as the individual, with respect to uses and disclosures of the individual’s Personal Identifiable Information (PII) and Protected Health Information (PHI) relevant to that personal representation, as well as the individual’s rights under the HIPAA Privacy Rule. A personal representative is a person legally authorized to make health care decisions on an individual’s behalf or to act for a deceased individual, or of the deceased individual’s estate.

The following steps detail the CMS-specific process for treating a personal representative with respect to uses and disclosures.

  • In making a determination of whether an individual has the authority to act as the personal representative for someone else, CMS relies on documentation, statements, or representations that, on their face, legally authorize a person to act on the beneficiary’s behalf or on behalf of a deceased individual or the decedent’s estate. This documentation must be included in the beneficiary’s record. Examples of the required documentation include, but are not limited to, Guardianship, Letters Testamentary, or Executor/Executrix papers issued by a court.
  • If an individual calls 1-800-MEDICARE, they are instructed to send in the legal documentation that establishes their legal authority to act as a legal representative for the beneficiary. Detailed instructions for submitting this documentation are available at Medicare.gov. The form titled, Authorization to Disclose Personal Health Information Form.

Notice of Privacy Practices

CMS gives a notice of its privacy practices to all beneficiaries of the Medicare Fee-for-Service Program. This notice describes the ways in which Medicare uses and discloses an individual’s protected health information (PHI). The notice states Medicare’s duties to protect the privacy of this information. This notice also describes the individual’s rights, including the right to notify if they believe their privacy rights have been violated.

CMS provides the individual with the Notice of Privacy Practices in several ways, as listed under the Publishing the Notice section below.

CMS reviews the Notice of Privacy Practices at least annually to determine if there are material changes to the uses and disclosures, the individual’s rights, Medicare’s legal duties, or other privacy practices stated in the notice. In addition, CMS makes updates to the Notice of Privacy Practices whenever any material changes are made to the uses and disclosures.

All revisions are made and redistributed per the HIPAA Privacy Rule.

The following details the CMS-specific process for giving proper notice of its privacy practices.

Publishing the Notice

CMS publishes its “Notice of Privacy Practices for Original Medicare” annually in the Medicare & You Handbook. The Handbook is posted on Medicare.gov and is also available by requesting a copy from 1-800-MEDICARE.

The Handbook is distributed to beneficiaries every fall in the following ways:

  1. It is mailed through the U.S. Postal Service.
  2. Beneficiaries can sign up at https://Medicare.gov/go-digital to get the Medicare & You handbook electronically (This is also called the eHandbook).

Modifications to the Notice

Step 1: If the CMS privacy staff, in working with CMS Business Owners and the Office of General Counsel, become aware of material changes in uses and/or disclosures, they will determine if the change triggers a need to modify the current Notice. The Business Owner develops the updated language to be used in the Notice. The changes made to the Notice are cleared by the Office of General Counsel. When cleared, the privacy staff informs the Office of Communications about the updated language to insert into the Notice.

Step 2: In addition, at the time of the annual Medicare & You update, the CMS privacy staff reviews the Notice of Privacy Practices.

Step 3: The updated Notice is generally distributed as part of the updates to the Medicare & You handbook.

Website Privacy Policies

Each Business/Information System Owner must ensure that each of their website privacy policies:

  1. is labeled consistently and clearly as the website’s “Privacy Policy;”
  2. contains a clear introduction stating that information collected about individuals will be appropriately handled;
  3. states whether the website will collect and store any type of PII; how it will be collected (automatically, via e-mail, using web forms, or some other way); what information will be collected; and how it will be used;
  4. states whether the website will collect any PII relevant to detecting privacy or security incidents, and whether CMS will use that information to take action once an incident is detected;
  5. informs visitors whenever providing requested information is voluntary;
  6. informs visitors how to grant consent for CMS’s specific uses of voluntarily- provided information;
  7. informs visitors of (1) authorization requirements for sales of PHI, marketing and psychotherapy notes, (2) the right of an individual to restrict disclosures of PHI to a health plan for health care for which the individual has paid out of pocket, (3) the duty of CMS to provide notice of a breach of unsecured PHI, and (4) the right to opt out of fundraising communications
  8. informs visitors how to grant consent for any CMS use of mandatorily-provided information for other than statutorily-mandated uses or authorized routine uses under the Privacy Act;
  9. where interaction with CMS via the website is voluntary, provides useful information that the public would need to make an informed decision about whether and how to interact with CMS;
  10. is updated whenever CMS makes a change to how PII is collected, stored, maintained, used, or disclosed;
  11. includes a time/date stamp to inform visitors of the last time CMS made a change to the practices the privacy policy describes;
  12. includes a link to the CMS Privacy Program Page; and
  13. is updated to be aligned with the CMS-wide Website Privacy Policy whenever a change is made to that policy.

If Business/Information System Owners will create or maintain a website that will be subject to the Administrative Simplification Rules of the Health Insurance Portability and Accountability Act (HIPAA) of 1996; and in particular, if that website will collect, store, disclose, use, or transfer protected health information (PHI) as that term is defined by the HIPAA Privacy and Security Rules, the website must also contain a Notice of Privacy Practices consistent with the HIPAA Privacy Rule, Section 45 CFR § 164.520, “Notice of privacy practices for protected health information.”

If Business/Information System Owners will create or maintain any website that uses web measurement and customization technologies,7 whether that website is a CMS-owned or operated website or a third-party website or application, they must also ensure that the privacy policy for that website:

  • informs the public that the website will use web measurement and customization technologies, and explains how users8 may make either an opt-out or opt-in decision;
  • provides users who decline to opt-in or decide to opt-out with access to information that is comparable to the information available to users who opt-in or decline to opt-out;
  • if applicable, cites the appropriate Privacy Impact Assessment (PIA) and/or System of Records Notice (SORN) includes:
    • the purpose of the web measurement and/or customization technology;
    • the usage Tier (as that term defined by OMB Memorandum 10-22), session type, and technology used;
    • the nature of the information collected;
    • the purpose and use of the information;
    • whether and to whom the information will be disclosed;
    • the privacy safeguards applied to the information;
    • the data retention policy for the information;
    • whether the technology is enabled by default or not and why;
    • how to opt-out of the web measurement and/or customization technology;
    • a statement that opting-out still permits users to access comparable information or services; and
    • the identities of all third party vendors involved in the measurement and customization process.

Note that compliance with the above item will also assist Business/Information System Owners in complying with ARS control Systems and Communication Protection (SC)-CMS-2, Website Usage.

If Business/Information System Owners will link to, use, or implement third-party websites or applications, they must take actions related to two type of notices. First, they must ensure the CMS-wide Website Privacy Policy, referred to above, accurately addresses within its scope relevant facts about the third-party websites and applications the Business/Information System Owners create or maintain. Second, they must create new privacy notices, specific to each use of third-party websites or applications, and if feasible post them on the websites where the public will access them. For the first category of privacy compliance activities, they must ensure that the CMS-wide Website Privacy Policy notes:

  • the specific purpose of all CMS uses of third-party websites or applications;
  • how the relevant program or office will use PII that becomes available through the use of each third-party website or application;
  • who at CMS will have access to any PII collected via the third-party website or application;
  • with whom CMS will share PII outside CMS;
  • whether and how CMS will maintain PII, and for how long;
  • how CMS will secure PII that it uses or maintains through the third-party website or application; and
  • what other privacy risks exist, if any, and how CMS will mitigate those risks

Business/Information System Owners that use or maintain third-party websites and applications must also:

  • when feasible, provide links to the relevant privacy policies of the third-party websites and applications being used;
  • when feasible, post a separate Privacy Notice on the third-party website or application itself;
  • take all practical steps to ensure the third-party website or application-specific Privacy Notice is easily visible whenever the third-party website or application is accessed, limited in content to information specific to the use of the particular third-party website or application, clearly labeled, written in plain language, and prominently displayed at all locations where the public might make PII available to CMS; and
  • ensure that the Privacy Notice will:
    • explain that the website or application is not a government website or application, that it is controlled or operated by a third party, and that CMS’s Privacy Policy does not apply to the third party;
    • indicate whether and how CMS will maintain, use, or share PII that becomes available through the use of the third-party website or application;
    • explain that by using the website or application to communicate with CMS, individuals may be providing nongovernment third parties access to PII;
    • direct individuals to CMS’s official website;
    • direct individuals to the CMS-wide Website Privacy Policy as described in (1)-(3), above; and
    • be updated periodically to be comprehensive and consistent with the CMS-wide Website Privacy Policy

Individuals’ Rights to Access, Inspect, and Obtain a Copy of their PHI or Health Record

CMS provides individuals the right to access, inspect, and obtain copies of their Protected Health Information (PHI), Personally Identifiable Information (PII), and Electronic Health Record (EHR) in a designated record set or in a CMS Privacy Act System of Records.

The following steps detail the CMS-specific process for providing individuals access.

Step 1: When an individual calls 1-800-MEDICARE requesting access to their records, the individual is instructed to send in a written request, and is provided appropriate instructions on how to submit the request.

Step 2: Written requests are received by the applicable System Manager through various means.

Step 3: All written requests are reviewed to ensure that they include the following authentication information: full name, date of birth, health insurance claim number, and one other piece of information such as address, phone number, and/or effective dates of Part A coverage.

Step 4: If the written request is not complete with the required information, the request is returned. The individual is instructed to complete all required information and resubmit.

Step 5: If the written request is complete, the identity of the individual requesting access to records is determined in accordance with the instructions contained above in “Verification of Identity.”

Step 6: Once verification of identity and authority is complete, the System Manager or designee reviews the request and gathers the requested materials for the individual.

Step 7: For all completed requests where the individual requests a copy of the records, the records are sent to the individual’s address on file.

Step 8: All requests, designations, and correspondence relating to the individual’s request for access are maintained by the agency in the individual’s record.

Step 9: When an individual makes a request to access, inspect, and obtain a copy of his or her PII/PHI, CMS acts upon the request:

  • Within 30 days of receipt of the written request if the information is maintained or accessible onsite, or
  • Within 60 days if it is not maintained or accessible onsite.
  • If CMS is unable to respond to the request within these timeframes, it may extend its response time by up to 30 additional days.

Individuals may request to have a copy of their EHR in an electronic format. Furthermore, the individual can direct CMS to transmit a copy of their EHR to an entity or person designated by the individual if choice is clear, conspicuous, and specific.

Amendment and Correction of PHI

CMS provides individuals the right to amend and correct their Protected Health Information (PHI), Personally Identifiable Information (PII), and Electronic Health Record (EHR) maintained in a designated record set or a CMS Privacy Act System of Records.

The following steps detail the CMS-specific process for amending and correcting PHI.

When an individual requests amendment/correction to PII/PHI, CMS acts on the request no later than 60 days after receiving the request. If CMS is unable to act within this period, CMS will extend the time to complete the written request by no more than 30 additional days after the initial 60 days.

Denial of Correction or Amendment

If the request for correction or amendment is denied, in whole or in part, the MAC will inform the System Manager.

The System Manager or designee will document the denial in the beneficiary’s record and a timely denial notice will be sent to the individual. The denial notice will inform the individual that the individual may submit a written statement of disagreement with the denial of all or part of a requested amendment and the basis of such disagreement.

CMS denies a request for correction or amendment of PHI for reasons, including but not limited to cases where:

  • The individual’s PHI is not part of the record.
  • CMS did not create the record.
  • The record is not available to the individual for inspection under federal law.
  • The record is already accurate and complete.

Any written statement or statement of disagreement by the individual, any response by CMS, and any other document pertaining to the request will become part of the individual’s record.

Accounting of Disclosures

CMS provides individuals the right to an accounting of disclosures of their Protected Health Information (PHI) and Personally Identifiable Information (PII) by CMS or its business associates.

CMS accounts for disclosures as required under the Privacy Act, HIPAA, and Health Information Technology for Economic and Clinical Health (HITECH) Act. The accounting of disclosures records information concerning all disclosures made to organizations external to CMS pursuant to routine uses under the Privacy Act. CMS routine uses are defined in the System of Records Notice for each system. 

CMS also accounts for disclosures as required under the HIPAA Privacy Rule. Under the Privacy Rule, individuals have the right to an accounting of all disclosures of PHI except for disclosures made:

  • To carry out treatment, payment, or operations;
  • To CMS employees who maintain the record and who have a need for the record in the performance of their duties; including but not limited to, payment or health care operations, or for disclosures to the Secretary of HHS, that are required in order to investigate or determine compliance with the HIPAA Privacy Rule requirements;
    • That are required under the Freedom of Information Act (FOIA);
    • To the individual; or
    • Pursuant to the individual’s written authorization. 

The following steps detail the CMS-specific process for accounting of disclosures.

Step 1: An individual calls 1-800-MEDICARE or writes to CMS for an accounting of disclosures of their PHI. The individual is instructed to send in a written request, and is provided appropriate instructions on how to submit the request.

Step 2: Written requests are received by the applicable System Manager through various means.

Step 3: All written requests are reviewed to ensure that they include the following authentication information: full name, date of birth, health insurance claim number, and one other piece of information such as address, phone number, and/or effective dates of Part A coverage.

Step 4: If the written request is not complete with the required information, the request is returned. The individual is instructed to complete all required information and resubmit.

Step 5: If the written request is complete, the identity of the individual requesting an accounting of disclosure is determined in accordance with the instructions contained above in “Verification of Identity.”

Step 6: CMS acts on the request no later than 60 days after receipt of the request and may extend this time for an additional 30 days, so long as it informs the individual in writing of the reason(s) for the delay and the date by which the individual can expect the accounting.

Step 7: The System Manager works in conjunction with the individual to determine the information needed to address the request. The System Manager works in conjunction with the Business Owner of the requested records to determine whether the individual’s records were disclosed.

Step 8: The System Manager will respond in writing and include for each disclosure:

  • Date of the disclosure;
  • Name and address of the person or organization receiving the PHI;
  • A brief description of the PHI disclosed (e.g., health plan beneficiary numbers, Social Security Number, and medical record numbers);
  • A brief statement of the purpose of the disclosure (or include a copy of the written request for disclosure, if appropriate).

Step 9: CMS maintains the correspondence, including the explanation sent to the individual, in the individual’s record.

Temporary Suspensions of an Individual’s Right to Receive an Accounting of Disclosures to Health Oversight Agencies or Law Enforcement Officials

If a health oversight agency or law enforcement official provides a written request that meets the following requirements, CMS must temporarily suspend the individual’s right to an accounting of disclosures for the time period specified in that written request:

  • A health oversight agency or a law enforcement official may submit a written statement to request CMS to suspend an individual’s right to receive an accounting of disclosures to such health oversight agency or law enforcement official. The written statement must specify:
    • The reasons that an accounting to the individual would be likely to impede the agency’s or official’s activities; and
    • The time for which such a suspension is required.
  • If CMS agrees to suspend an individual’s right to receive an accounting of disclosures, the following must occur:
    • During the period of suspension, any disclosures to such health oversight agency or law enforcement official requiring an accounting must still be recorded.
    • At the end of the suspension of access, an individual’s right to receive a complete accounting is reinstated.
  • A health oversight agency or a law enforcement official may orally request a temporary suspension. If an oral request is made, CMS must:
    • Document the identity of the agency or official who made the request; and
    • Exclude the disclosure(s) for no longer than 30 days from the date of the request, unless a written request is provided during that time.

Request for Restriction(s) of the Use and/or Disclosure of PHI

CMS provides individuals the right to request that CMS restrict uses or disclosures of Protected Health Information (PHI) or Personally Identifiable Information (PII) about the individual.

CMS is required to agree to any such restriction; if (1) except as otherwise required by law, the disclosure is to a health plan for purposes of carrying out payment or health care operations (and is not for purposes of carrying out treatment); and (2) the PHI pertains solely to a health care item or service for which the health care provider involved has been paid out of pocket in full.

If the individual who requested the restriction is in need of emergency treatment and the restricted PHI is needed to provide the emergency treatment, CMS may use the restricted PHI, or may disclose such information to a health care provider, to provide such treatment to the

individual. If restricted PHI is disclosed to a health care provider for emergency treatment, CMS will request that such health care provider not further use or disclose the PHI.

The following steps detail the CMS-specific process for handling requests for restrictions.

Request

Step 1: When an individual calls 1-800-MEDICARE to request restrictions of the use and/or disclosure of their PHI, the individual is instructed to send in a written request, and is provided appropriate instructions on how to submit the request.

Step 2: Written requests are received by the applicable System Manager through various means.

Step 3: All written requests are reviewed to ensure that they include the following authentication information: full name, date of birth, health insurance claim number, and one other piece of information such as address, phone number, and/or effective dates of Part A coverage. The individual is not required to provide a reason for the request.

Step 4: If the written request is not complete with the required information, the request is returned. The individual is instructed to complete all required information and resubmit.

Step 5: If the written request is complete, the identity and authority of the individual requesting the restriction is determined in accordance with the instructions contained above in “Verification of Identity.”

* Note: The individual is not required to provide a reason for the request.

Step 6: Once verification of identity is complete, the System Manager or designee reviews the request, determines whether to agree to the request, and notifies the individual of their determination. All documentation is placed in the individual’s record.

Exception

If restricted information is disclosed to a health care provider for emergency treatment, CMS will request that the receiving health care provider not further use or disclose the PHI, using the following language, “This [health care record or other document] is restricted from further release. It is provided for the purpose of emergency treatment, but should not be further disclosed or used without the permission of the individual to whom the information pertains.”

Restriction

A restriction agreed to by CMS shall not prevent the use or disclosure of PHI:

  • To an individual who requests access to their own PHI.
  • As required by the Secretary, HHS, to investigate or determine compliance by CMS with the HIPAA Privacy Rule.
  • As required by law.
  • As required to conduct public health activities.
  • To report information for the purposes of protecting victims of abuse, neglect, or domestic violence.
  • To conduct health oversight activities.
  • In support of judicial and administrative proceedings.
  • For law enforcement purposes.
  • About decedents.
  • For research purposes.
  • To avert a serious threat to health or safety.
  • For specialized government functions.
  • To support a claim for workers' compensation.

Termination of a Restriction

CMS terminates its agreement to a restriction if the individual:

  • Agrees to or requests the termination of the restriction in writing; or
  • Agrees to the termination and through an oral agreement that is then documented.

Confidential Communications

CMS provides individuals the right to request and to receive communications of Protected Health Information (PHI) by alternate means or to an alternate location if the individual makes a request in writing. CMS accommodates all reasonable requests.

The following steps detail the CMS-specific process for handling requests for confidential communications.

Step 1: When an individual calls 1-800-MEDICARE or writes to CMS to make a request for confidential communication by alternate means or location, the individual is referred to the Social Security Administration.

Step 2: Individuals may also log into the MyMedicare webpage, and follow the instruction to direct that their Medicare Summary Notices only be available through a secure login at the MyMedicare website.

​​​​​​​De-Identification of PHI

CMS creates datasets that do not identify individuals and makes them publicly available when there is legal authority permitting their creation and dissemination.

The following steps detail the CMS-specific process for de-identifying PHI.

CMS creates public use files (PUF) as part of the administration of its programs. PUFs are created from data contained in the Privacy Act Systems of Records. There are no restrictions on the use and disclosure of PUFs.

The following procedures are used to de-identify Protected Health Information (PHI) or to determine when health information is not individually identifiable:

Step 1: De-identification is accomplished by removing the following identifiers of the individual or of the individual’s relatives, employers, or household members:

  • Names;
  • All elements of a street address, city, county, precinct, zip code, and their equivalent geocodes, except for the initial three digits of a zip code for areas that contain over 20,000 people;
  • All elements of dates (except year) for dates directly related to the patient, (e.g., birth date, admission/discharge dates, and date of death);
  • All ages over 89 and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older;
  • Telephone numbers;
  • Fax numbers;
  • E-mail address(es);
  • Social security numbers;
  • Medical record numbers;
  • Health plan beneficiary numbers;
  • Account numbers;
  • Certificate/license numbers;
  • License plate numbers, vehicle identifiers, and serial numbers;
  • Device identifiers and serial numbers;
  • Uniform Resource Locator (URL) address(es);
  • Internet Protocol (IP) addresses numbers;
  • Biometric identifiers, including finger and voice prints;
  • Full-face photographic images and comparable images; and
  • Any other unique identifying number except as created by CMS to re-identify the information. This determination also requires that CMS does not have actual knowledge that the remaining information could be used alone or in combination with other information to identify the individual.

Step 2: If a person designated by CMS, with knowledge and experience of generally accepted statistical and scientific methods for rendering information not individually identifiable, applies such methods and determines that the risk is very small that the information could be used alone, or in combination with other available information, by an anticipated recipient of such information to identify the individual, then the information is determined to be de-identified. This designated person with knowledge and experience of statistical and scientific methods must document the methods and results of the analysis that justify the determination.

  • De-identification will be performed at the origin of the data.
  • Hard copy PHI will be de-identified by obliterating (making unreadable and unrecognizable) the individual identifier(s).
  • The original(s) must not be modified.

Step 3: Once a business owner has created a PUF, the business owner completes the Data Governance Board’s “DGB Public Use File Briefing Document.” The document is presented to and reviewed by the Data Governance Board for approval.

Step 4: Once approved, the PUF is available for public use.

​​​​​​​Creating a Limited Data Set

Safeguarding Protected Health Information (PHI) is among the highest priorities of CMS. Therefore, CMS enters into a valid data use agreement (DUA), whenever appropriate, to protect the limited data sets (LDS) that will be used and/or disclosed for purposes of research, public health, or health care operations.

The following steps detail the CMS-specific process for using an LDS.

  • A LDS may be used or disclosed only for research, public health, or health care operations purposes. It is the responsibility of CMS business owners who use and disclose PHI to recognize situations involving the disclosure of a LDS to contact the DUA Mailbox to initiate the preparation of an appropriate CMS DUA. The Office of General Counsel (OGC), the Privacy Act Officer, and OEDA may also help determine whether a particular purpose constitutes research, public health, or health care operations, and whether use or disclosure of an LDS is appropriate in a given situation.
  • Use or disclosure of an LDS may be appropriate in situations where completely de- identified data would not be useful to the recipient, but disclosure of health information accompanied by specific dates, geographic information, and/or unique identifying numbers (e.g., study ID numbers) would be useful. Disclosure of a LDS pursuant to a CMS DUA will be deemed appropriate if the purpose of the use or disclosure is for research, public health, or health care operations purposes, and the use or disclosure complies with CMS’s policies and requirements for obtaining approvals, documenting the terms and conditions, and governing the scope of the particular research, public health, or health care operations activity.
  • An LDS will still contain PHI. HIPAA generally requires that a covered entity obtain a written HIPAA Authorization from an individual prior to using or disclosing the individual’s PHI. An exception exists for use or disclosure of a LDS if the covered entity enters into a DUA with the recipient of the LDS. The DUA gives the covered entity contractual assurances that the LDS recipient will protect the PHI once it is in its possession. An LDS may not be used or disclosed without first entering into a DUA.
  • CMS may approve or deny any LDS request, whether the request is for an initial use or disclosure of an LDS or for an extension of the original DUA. CMS may rely on a researcher’s request that meets the minimum necessary requirements if such reliance is reasonable under the circumstances.
  • CMS may deny any request for the use/disclosure of an LDS if the requirements under the permitted disclosure pursuant provisions in 45 C.F.R. §§164.502(a)) and 164.514(e) are not met. Each data request must also be reviewed to determine whether it meets HIPAA minimum necessary requirements under 45 C.F.R.§164.514(d).

Use of a DUA

  • The appropriate CMS LDS DUA must be used when it is appropriate for CMS to enter into a DUA.
  • An LDS should not be used or disclosed until both parties have signed a DUA.

Accounting for Disclosures

HIPAA does not require CMS to account for disclosures of a LDS; however, a LDS is considered Personally Identifiable Information (PII) under the Privacy Act of 1974. Disclosures of a LDS to the intended recipient pursuant to a DUA must be accounted for in order for CMS to comply with the Privacy Act, 5 USC §552a(c).

Compliance

Any CMS employee who becomes aware of a pattern of activity or practice by a LDS recipient that may constitute a material breach or violation of the CMS DUA between such recipient and CMS must immediately inform the Privacy Office and provide a description of the facts giving rise to such belief. CMS does not retaliate against any employee who reports known or suspected compliance issues or violations to the OGC.

​​​​​​​Business Associates

Any person or organization that performs functions or activities that involve the use or disclosure of Protected Health Information (PHI) on behalf of CMS must have a Business Associate Agreement (BAA) in their contract. Examples of functions or activities on behalf of CMS include claims processing, data analysis, and utilization review. The CMS Business Associate Clause should be utilized.

The BAA establishes the uses and disclosures of PII/PHI by the business associate. It also provides satisfactory assurance that the business associate will appropriately safeguard the information. Examples of these safeguards include administrative, physical, and technical safeguards. It also includes the reporting of breaches of PII/PHI, as well as the return or destruction of PII/PHI upon termination of the contract.

The following steps detail the CMS-specific process for involving Business Associates in the use and disclosure of PHI.

  • CMS Office of Acquisition and Grants Management is responsible for ensuring that all contracts involving the collection, use, or disclosure of PII/PHI include the Business Associate Agreement.
  • Contracts that do not involve the collection, use, and disclosure of PII/PHI do not include the Business Associate Agreement.
  • Contracting Officers working with their Contracting Officer’s Representative ensure that the provisions of the Business Associate Agreement are executed.

Breach Notification

HITECH Act imposes data breach notification requirements for unauthorized uses and disclosures of "unsecured PHI." These notification requirements are similar to many state data breach laws related to personally identifiable financial information (e.g. banking and credit card data). Under the HITECH Act "unsecured PHI" essentially means "unencrypted PHI."

CMS is required to notify individuals of any unsecured breach. If a breach impacts 500 individuals or more then HHS must also be notified. Notification will trigger posting the breaching entity's name on HHS' website. Under certain conditions local media will also need to be notified. Furthermore, notification is triggered whether the unsecured breach occurred externally or internally.

CMS uses a risk-based analysis for privacy breaches using OMB, HITECH, and HIPAA guidance. This guidance requires organizations to determine the sensitivity of its data, based on the information and the context in which the information appears, and then to determine the level of response, based on the resultant privacy risk to the organization and to affected individuals.

CMS defines a breach as the loss of control, compromise, unauthorized disclosure unauthorized acquisition, unauthorized access, or any similar term referring to situations where persons other than authorized users and for an other than authorized purpose have access or potential access to personally identifiable information, whether physical or electronic.

CMS defines an incident as a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.

The following steps detail the CMS-specific process for privacy breach notification:

  • Step 1: The Breach Analysis Team (BAT) conducts a Breach Analysis and their findings conclude whether breach notification is required.
  • Step 2: The Business Owner, in coordination with the Director of the Division of Security, Privacy Policy, and Governance (DSPPG), gives proper notice to the required parties under HITECH (i.e. notification letter to HHS Office of Civil Rights).

Administrative Procedures

CMS develops and implements written privacy policies and procedures that are consistent with the HIPAA Privacy Rule and the Privacy Act.

The following steps detail the CMS-specific process for procedures ensuring compliance with the requirement to maintain administrative procedures under the HIPAA Privacy Rule and the Privacy Act.

Personnel Designations

CMS designates the Senior Official for Privacy (SOP) as its lead for the agency’s development and implementation of privacy policies and procedures.

The Office of the Ombudsman is responsible for receiving complaints. The Office triages complaints and works in coordination with the Office of the SOP to address the complaint.

Training

CMS trains all members of its workforce, including contractors, on privacy policies and procedures as necessary and appropriate to carry out their functions within and in support of CMS.

CMS provides training on its privacy policies and procedures for:

  • Each new member of the workforce and each contractor, all of whom will receive training beginning on their first day of orientation. Training is required for each employee to acquire access to CMS computer systems.
  • Each member of the workforce and each contractor receive training annually as part of the annual certification to maintain access to CMS computer systems; and
  • Each member of CMS’s workforce and each contractor, whose functions are affected by a material change in policies or procedures, receive training prior to the change becoming effective.

Safeguards

CMS maintains policies and procedures to safeguard Protected Health Information (PHI) and Personally Identifiable Information (PII) in accordance with federal requirements for both electronic and paper records to include administrative, technical, and physical safeguards. These are documented in the CMS Information Security Acceptable Risk Standards (ARS) for accrediting CMS information technology (IT) systems; the CMS IS2P2, and this Risk Management Handbook. Examples include:

  • Administrative Safeguards – policies and procedures related to security management, assigned security responsibility, workforce security, information access management, security awareness and training, security incident procedures, contingency plans, and periodic evaluation.
  • Technical Safeguards – policies and procedures that include user access and restriction controls, audit controls, integrity controls, person or entity authentication controls, and transmission security controls.
  • Physical Safeguards – policies and procedures that include facility access controls, workstation use controls, workstation security controls, and device and media controls.

Complaints

  • The complaint process is explained in the CMS Notice of Privacy Practices. As described in the Notice, individuals are directed to call 1-800-MEDICARE. The customer service representative directs the individual to send in a written complaint to the Office of the Ombudsman.
  • All mail communication goes to the Office of the Ombudsman. The Office of the Ombudsman triages the complaints and works in coordination with the Office of the SOP to address it. All complaints are documented in the individual’s records.
  • The customer service representative may also provide information on filing a complaint with the U.S. Department of Health and Human Services or Office for Civil Rights.

Employee Sanctions

Sanctions for members of the workforce who fail to comply with the privacy policies and procedures can be found in the CMS Master Labor Agreement.

Mitigation

When CMS becomes aware of the use or disclosure of PII/PHI in violation of applicable federal law and/or of its policies or procedures by one or more of its workforce, contractors, or business associates, CMS follows the procedures documented in the Risk Management Handbook Incident Response Plan (copy can be found on the ISPG Library).

Refraining from Intimidating or Retaliatory Acts

CMS does not intimidate, threaten, coerce, discriminate against, or take retaliatory action against employees or contractors for exercising their rights under the HIPAA Privacy Rule, the Privacy Act, or participating in any process for:

  • Filing privacy complaints;
  • Testifying, assisting, or participating in an investigation;
  • Conducting a compliance review, proceeding, or hearing related to the HIPAA Privacy Rule or Privacy Act; and
  • Opposing any act or unlawful practice under the HIPAA Privacy Rule or Privacy Act and the manner of opposition is reasonable and does not involve a disclosure of PHI not permitted (HIPAA Privacy Rule §164.530 (g)(1)).

These requirements are included in the CMS Master Labor Agreement.

Waiver of Rights

Individuals shall not be required to waive their rights including, but not limited to, their right to file a complaint as a condition for the provision of payment, eligibility, or other benefits.

Standard Policies and Procedures

CMS implements standard policies and procedures in accordance with the HIPAA Privacy Rule and Privacy Act.

Changes to Policies or Procedures

CMS changes its policies and procedures as necessary and appropriate to comply with changes in HIPAA regulations and the Privacy Act.

Documentation

CMS maintains:

  • Its policies and procedures in written and electronic form;
  • All communication, actions, activities, or designations that are required to be documented; and
  • Documentation sufficient to meet its burden of proof under HIPAA Privacy Rule §164.414(b).

Privacy Program and FISMA

The following is a list of privacy program polices that map to controls that must be complied with per the Federal Information Security Management Act (FISMA). CMS operates a Fair Information Practice Principles (FIPPs)-centric model for protecting any personal information collected by the agency.

​​​​​​​Authority to Collect

Before collecting PII, CMS determines whether the contemplated collection of PII is legally authorized. Authorization must be provided by a statute or executive order: regulations, best practices, or agency-level policies do not by themselves provide adequate authority to collect. Program officials consult with the Senior Official for Privacy (SOP), and legal counsel regarding the authority of any program or activity to collect PII. The authority to collect PII is documented in the System of Records Notice (SORN) and/or Privacy Impact Assessment (PIA) or other applicable documentation such as Privacy Act Statements or Computer Matching Agreements.

The following steps detail the CMS-specific process for obtaining authority to collect PII.

The Business Owner, with SOP support, determines and documents the legal authority that permits the collection, use, maintenance, and sharing of PII, either generally or in support of specific programs and the needs of information systems.

​​​​​​​Purpose Specification

Often, statutory language expressly authorizes specific collections of PII. When statutory language is written broadly and thus subject to interpretation, organizations ensure, in consultation with the Senior Official for Privacy (SOP) and legal counsel, that there is a close connection between the general authorization and any specific collection of PII. Once the specific purposes have been identified, the purposes are clearly described in the related privacy compliance documentation, including but not limited to PIAs, SORNs, and Privacy Act Statements provided at the time of collection (e.g., on forms organizations use to collect PII). Further, in order to avoid unauthorized collections or uses of PII, personnel who handle PII receive training on the organizational authorities for collecting PII, authorized uses of PII, and on the contents of the notice.

The following steps detail the CMS-specific process for identifying and documenting, purpose specification.

Step 1: The System Owner/Maintainer, in consultation with the Business Owner, describes the purpose(s) for which PII is collected, used, maintained, and shared in privacy compliance documentation and in its privacy notices (e.g., PIAs, SORNs, Privacy Act Statements, and/or Computer Matching Agreement (CMAs)).

Step 2: The System Owner/Maintainer, in consultation with the Business Owner, ensures the following:

  • The system only collects and uses PII relevant to its purposes
  • PII entering the system from other systems is limited to predetermined data elements.
  • Generation of new PII is restricted to pre-determined data elements;
  • PII output is properly labeled regarding permissible uses and restrictions on usage of the PII;
  • PII is transferred to authorized entities only for predetermined, documented purposes and business needs;
  • If transferring PII to other agency systems or to third parties via the user interface, the system notifies the user of the permissible uses and restrictions on usage of the PII;
  • User interfaces provide a notification when saving PII outside the system or printing PII, reminding the user of the permissible uses and restrictions on usage of the PII; and
  • The system limits disclosure of PII to those data elements that are necessary for the purposes of the syste

Governance and Privacy Program

Effective implementation of privacy and security controls requires collaboration among the Senior Official for Privacy (SOP), Chief Information Officer (CIO), and Chief Information Security Officer (CISO). To maximize organizational compliance with privacy requirements and best practices, the organization should ensure its privacy professionals engage with both its security community and the Federal privacy community to remain current and to share lessons- learned or other privacy-related information.

The development and implementation of a comprehensive governance and privacy program demonstrates organizational accountability for and commitment to the protection of individual privacy. Accountability begins with the appointment of a SOP with the authority, mission, resources, and responsibility to develop and implement a multifaceted privacy program.

Step 1: CMS appoints a Senior Official for Privacy (SOP) accountable for developing, implementing, and maintaining an organization-wide governance and privacy program to ensure compliance with all applicable laws and regulations regarding the collection, use, maintenance, sharing, and disposal of PII by programs and information systems.

Step 2: SOP monitors federal privacy laws and policy for changes that affect the privacy program.

Step 3: SOP requests and advocates for an appropriate allocation of budget and staffing resources to implement and operate the organization-wide privacy program.

Step 4: SOP develops a strategic organizational privacy plan for implementing applicable privacy controls, policies, and procedures.

Step 5: SOP develops, disseminates, and implements operational privacy policies and procedures that govern the appropriate privacy and security controls for programs, information systems, or technologies involving PII.

Step 6: SOP updates privacy plan, policies, and procedures, as required to address changing requirements, but no less often than every two years.

Privacy Impact and Risk Assessment

In the latest revision of NIST 800-53, this control was re-named to include risk. The reason is that organizations are moving towards a risk-based assessment of privacy and it is important that when completing a PIA, the risk involved are accounted for and mitigated wherever possible.

Effective implementation of privacy risk management processes requires both organizational and information system processes across the life cycle of the mission, business processes, and information systems. Privacy Impact Assessments are structured reviews (qualitative and quantitative) of both the risk and effect of how information is handled and maintained, as well as the potential impacts or harms to individuals and organizations that would result from mishandling or losing control of PII. The term “PIA” can refer either to the process of conducting the assessment, or to the document, that is the outcome of that process.

Organizational privacy risk assessment processes consider the entire life cycles of all business processes that involve collecting, using, maintaining, sharing, or disposing of PII. The tools and processes for assessing risk may vary across offices and information systems.

The following steps detail the CMS-specific process for privacy impact and risk assessments.

Step 1: Senior Official for Privacy documents and implements a process for assessing privacy risk to individuals that would result from incidents or events involving the collection, sharing, storing, transmitting, use, and disposal of PII.

Step 2: System Owner/Maintainer conducts PIAs for information systems or electronic collections of information in accordance with applicable law, OMB policy, or any existing organizational policies and procedures.

Step 3: System Owner/Maintainer reviews the PIA whenever a significant change occurs to the system, or no less than every three (3) years, and publishes the PIA in accordance with HHS guidance.

Privacy Requirements for Contractors and Service Providers

Contracts and other acquisition-related documents permit CMS to communicate and enforce the implementation of privacy and security controls by contractors and service providers. As a general principle, contractors and service providers must protect PII in the same way and to the same extent that CMS does.

The following steps detail the CMS-specific privacy requirements for contractors and service providers.

Senior Official for Privacy (SOP), in consultation with the Chief Information Officer (CIO), establishes privacy roles, responsibilities, and access requirements for contractors and service providers. This includes privacy requirements in contracts and other acquisition-related documents. SOP shall review, every two (2) years, a random sample of agency contracts that provide for the maintenance of a system of records on behalf of the agency to accomplish an agency function, in order to ensure that the contracts include clauses that make all requirements of the Privacy Act apply to the system and that make the criminal penalty provisions of the Privacy Act apply to the contractor or service provider and its personnel.

Privacy Monitoring and Auditing

Monitoring and auditing activities ensure privacy controls are implemented and operating effectively. To promote accountability, CMS regularly assesses the implementation of privacy controls, and identifies and addresses any gaps. These assessments can be self-assessments or third-party audits that result in reports detailing compliance gaps identified in programs, projects, and information systems.

​​​​​​​Privacy Awareness and Training

Privacy Awareness and Training are an effective means to reduce privacy risk within an organization. Training is designed to teach a skill, while awareness is a reminder, which may include a reminder to use and apply that skill (such as spotting or reporting a privacy incident). Through implementation of a privacy training and awareness strategy, the organization promotes a culture of privacy. Privacy training and awareness programs address many topics, but often include discussions of specific staff responsibilities and the consequences of failing to carry out those responsibilities.

Organizations update awareness and training material based on changing statutory, regulatory, mission, program, business process, and information system requirements, or on the results of compliance monitoring and auditing. Where appropriate, organizations may provide privacy training in conjunction with existing information security training.

​​​​​​​Privacy Reporting

Privacy reporting helps organizations remain accountable to external authorities. The process may also serve as a check on assessment of privacy risks and implementation of privacy controls.

Through internal and external privacy reporting, organizations promote accountability and transparency in organizational privacy operations. Reporting also helps organizations determine progress in meeting privacy compliance requirements and privacy controls, compare performance across the federal government, identify vulnerabilities and gaps in policy and implementation, and identify success models.

​​​​​​​Accounting of Disclosures

Both the Privacy Act and the HIPAA Privacy Rule require accounting of disclosures in certain circumstances. There are differences in the requirements to account for disclosures under the Privacy Act and under the HIPAA Privacy Rule.

The Senior Official for Privacy (SOP) periodically consults with managers of organization systems of records to ensure that the required accountings of disclosures of records are being properly maintained and provided to persons named in those records consistent with the dictates of the Privacy Act. Organizations are not required to keep an accounting of disclosures when the disclosures are made to individuals within CMS with a need to know in order to carry out duties consistent with the purpose of the collection, are made pursuant to the Freedom of Information Act, or are made to a law enforcement agency pursuant to statutory requirements.

Data Quality

An organization’s data quality assurance process must be commensurate with the sensitivity of the PII. The level of assurance of data quality must be appropriate given the risks that a privacy incident could have on an individual’s rights, benefits, privileges, health, or safety as determined by the system owner in consultation with the organization’s privacy office. CMS takes reasonable steps to confirm the accuracy and relevance of PII. Such steps may include, for example, editing and validating addresses as they are collected or entered into information systems using automated address verification look-up application programming interfaces (API).

The types of measures taken to protect data quality are based on the nature and context of the PII, how it is to be used, and how it was obtained. Measures taken to validate the accuracy of PII that is used to make determinations about the rights, benefits, or privileges of individuals under federal programs may be more comprehensive than those used to validate less sensitive PII. Additional steps may be necessary to validate PII that is obtained from sources other than individuals or the authorized representatives of individuals.

​​​​​​​Validate PII

Validating PII that is used to determine a right, benefit, or privilege for an individual ensures that the determination is based on accurate, timely, and relevant information. Procedures for validating PII should be commensurate with the impact to an individual’s rights, benefits, or privileges as determined by the system owner in consultation with the organization’s privacy office.

The following steps detail the CMS-specific process for validating PII.

Authentication of Identity

For detailed guidance in authenticating identity, use CMS Program Pub. 100-01 Medicare General Information, Eligibility, and Entitlement, Transmittal 7, dated June 25, 2004

Verification of Legal Authority to Act as Personal Representative

  • CMS relies on documentation, statements, or representations that, on their face, legally authorize a person to act on the beneficiary’s behalf or on behalf of a deceased individual or the decedent’s estate. This documentation, if applicable, should be part of the beneficiary’s record.
  • After the personal representative’s identity has been authenticated and before disclosure of PII/PHI, CMS checks the beneficiary’s record for the required documentation that authorizes an individual to act as a personal representative (e.g., Guardianship and Letters Testamentary). If the documentation is in the record, then the PII/PHI can be disclosed.
  • If the documentation is not in the record, then CMS refers the requester to Medicare.gov for information on submitting the required documentation or directs the requester to call 1-800-MEDICARE.

Re-Validate PII

Re-validation of PII used to determine a right, benefit, or privilege for an individual, is necessary to ensure the determination is based on the most accurate, timely, and relevant information.

Frequency of revalidation should be commensurate with the impact to an individual's rights, benefits, or privileges as determined by the system owner in consultation with the CMS’ privacy office.

The following steps detail the CMS-specific process for re-validating PII.

CMS requests that the individual or individual’s authorized representative revalidate that PII collected is still accurate no less often than once every 365 days or as directed by the Data Integrity Board.

Authentication of Identity

For detailed guidance in authenticating identity, use CMS Program Pub. 100-01 Medicare General Information, Eligibility, and Entitlement, Transmittal 7, dated June 25, 2004. 

​​​​​​​Data Integrity and Data Integrity Board

If conducting or participating in Computer Matching Agreements (CMAs) with other federal agencies or non-federal agencies, regarding applicants for and recipients of financial assistance or payments under federal benefit programs or regarding certain computerized comparisons involving federal personnel or payroll records, an agency must establish a Data Integrity Board to oversee and coordinate their implementation of such matching agreements. In the case of CMS, they leverage with the HHS Data Integrity Board for this purpose. The Data Integrity Board ensures that controls are in place to maintain both the quality and the integrity of data shared under CMAs.

​​​​​​​Publish Agreements on Website

In a privacy context, the principle of “access” recommends that whenever feasible, individuals should have the ability to review PII about themselves held within systems of records. Such access should be timely, simplified, and inexpensive. Organizational processes for allowing access to records may differ based on resources, legal requirements, or other factors.

In support of this principle, CMS has determined that computer-matching agreements (CMAs) are appropriate for publication on its website.

The following details the CMS-specific process for publishing agreements on their website. The Data Integrity Board (DIB) publishes CMAs on the public website.

​​​​​​​Minimization of Personally Identifiable Information

Reducing PII to the minimum required to accomplish the legally authorized purpose of collection and retaining PII for the minimum necessary period of time reduces the risk of PII breaches and will reduce the risk of the organization making decisions based on inaccurate PII.

Organizations take appropriate steps to ensure that the collection of PII is consistent with a purpose authorized by law or regulation. The minimum set of PII elements required to support a specific organization business process may be a subset of the PII the organization is authorized to collect.

​​​​​​​Locate/Remove/Redact/Anonymize PII

Anonymized information is defined as previously identifiable information that has been de- identified and for which a code or other association for re-identification no longer exists.

Anonymizing information usually involves the application of statistical disclosure limitation techniques to ensure the data cannot be re-identified, such as generalizing the data, suppressing the data, introducing noise into the data, swapping the data, and replacing data with the average value. Using these techniques, the information is no longer PII, but may remain useful for some research and policy development purposes.

The following details the CMS-specific process for locating/removing/redacting/anonymizing PII.

Office of Information Technology (OIT), where feasible and within the limits of technology and the law, locates and removes/redacts specified PII and/or uses anonymization and de- identification techniques to permit authorized use of the retained information while reducing its sensitivity and reducing the risk resulting from disclosure.

​​​​​​​Data Retention and Disposal

Both the Privacy Act and the Federal Records Act require records to be maintained and disposed of in accordance with a published records schedule. Disposal and destruction of PII must be done securely so that it may not be reconstructed, following NIST SP 800-88 Guidelines for Media Sanitization.

National Archives and Records Administration provides retention schedules that govern the disposition of federal records. Program officials and business owners coordinate with records officers, Cyber Risk Advisor, and with NARA to identify appropriate retention periods and disposal methods. NARA may require organizations to retain PII longer than is operationally needed. In those situations, organizations describe such requirements in the notice. Methods of storage include, for example, electronic, optical media, or paper.

System Owner/Maintainer configures its information systems to record the date PII is collected, created, or updated and when PII is to be deleted or archived under a NARA-approved records schedule.

​​​​​​​Minimization of PII Used in Testing, Training, and Research

When developing and testing information systems, PII is at a heightened risk for accidental loss, theft, or compromise. Therefore, CMS needs to take measures to reduce that risk.

Organizations often use PII for testing new applications or information systems prior to deployment. Organizations also use PII for research purposes and for training. The use of PII in testing, research, and training increases risk of unauthorized disclosure or misuse of the information. If PII must be used, organizations take measures to minimize any associated risks and to authorize the use of and limit the amount of PII for these purposes.

​​​​​​​Risk Minimization Techniques

Anonymizing PII is one technique to reduce risk and decreases the potential impact if the PII is compromised. Organizations can minimize risk to privacy of PII by using techniques such as de- identification. When PII is of a sufficiently sensitive nature, to the maximum extent possible, PII should be anonymized in accordance with one of the techniques discussed in NIST SP 800-122 Guide to Protecting the Confidentiality of Personally Identifiable Information (PII) prior to its use in development or testing.

The following steps detail the CMS-specific process for risk minimization.

Office of Information Technology shall use techniques to minimize the risk to privacy of using PII for research, testing, or training.

​​​​​​​Consent

Consent is fundamental to the participation of individuals in the decision-making process regarding the collection and use of their PII and the use of technologies that may increase risk to personal privacy. To obtain consent, organizations provide individuals appropriate notice of the purposes of the PII collection or technology use and a means for individuals to consent to the activity. Organizations tailor the public notice and consent mechanisms to meet operational needs. Organizations achieve awareness and consent, for example, through updated public notices.

Organizations may obtain consent through opt-in, opt-out, or implied consent. Opt-in consent is the preferred method, but it is not always feasible. Opt-in requires that individuals take affirmative action to allow organizations to collect or use PII/PHI.CMS ensures that opt-in consent is provided in all cases where it is required by law or other binding authorities.

The following steps detail the CMS-specific process for obtaining consent.

Step 1: Business Owner provides means, whenever required, and otherwise as feasible and appropriate, for individuals to authorize the collection, use, maintaining, and sharing of PII/PHI prior to its collection.

Step 2: Business Owner provides appropriate means for individuals to understand the consequences of decisions to approve or decline the authorization of the collection, use, dissemination, and retention of PII/PHI.

Step 3: Business Owner obtains consent, whenever required, and otherwise as feasible and appropriate, from individuals prior to any new uses or disclosure of previously collected PII/PHI.

Step 4: Business Owner ensures that individuals are aware of and, whenever required by law and in other cases when feasible, consent to all uses of PII not initially described in the public notice that was in effect at the time the organization collected the PII/PHI.

Mechanisms Supporting Itemized or Tiered Consent

Individual consent or authorization is required under the HIPAA Privacy Rule for uses and/or disclosures of an individual’s protected health information (PHI).

Organizations can provide, for example, individuals’ itemized choices as to whether they wish to be contacted for any of a variety of purposes. In this situation, organizations construct consent mechanisms to ensure that organizational operations comply with individual choices.

The following details the CMS-specific process for mechanisms supporting itemized or tiered consent.

Business Owner implements mechanisms to support itemized or tiered consent for specific uses of data.

​​​​​​​Individual Access

Access affords individuals the ability to review PII about them held within organizational systems of records. Access must be timely, provided in a format that the individual is able to understand, and provided as inexpensively as possible. Organizational processes for allowing access to records may differ based on resources, legal requirements, or other factors. The Senior Official for Privacy (SOP) working with the Privacy Act Officer is responsible for the content of Privacy Act records request processing, in consultation with legal counsel.

Access to certain types of records may not be appropriate, however, and heads of agencies may promulgate rules exempting particular systems from the access provision of the Privacy Act. In addition, individuals are not entitled to access to information compiled in reasonable anticipation of a civil action or proceeding.

The following steps detail the CMS-specific process for giving individuals access.

Step 1: When an individual calls 1-800-MEDICARE requesting access to their records, the individual is instructed to send in a written request, and is provided appropriate instructions on how to submit the request.

Step 2: Written requests are received by the applicable System Manager through various means.

Step 3: All written requests are reviewed to ensure that they include the following authentication information: full name, date of birth, health insurance claim number, and one other piece of information such as address, phone number, and/or effective dates of Part A coverage.

Step 4: If the written request is not complete with the required information, the request is returned. The individual is instructed to complete all required information and resubmit.

Step 5: If the written request is complete, the identity of the individual requesting access to records is determined in accordance with the instructions contained above in Section 3.4 “Verification of Identity.”

Step 6: Once verification of identity and authority is complete, the System Manager or designee reviews the request, determines whether disclosure is possible and appropriate, and notifies the individual.

Step 7: For all completed requests where the individual requests a copy of the records, the records are sent to the individual’s address on file.

Step 8: All requests, designations, and correspondence relating to the individual’s request for access are maintained by the agency in the individual’s record.

Step 9: When an individual makes a request to access, inspect, and obtain a copy of his or her PII/PHI, CMS acts upon the request:

  1. Within 30 days of receipt of the written request if the information is maintained or accessible onsite, or
  2. Within 60 days if it is not maintained or accessible onsite.

CMS provides a 30-day extension to complete action on the written request.

Step 10: System Manager publishes rules and regulations governing how individuals may request access to records maintained in a Privacy Act system of records

Step 11: System Manager publishes access procedures in SORNs

Step 12: System Manager adheres to Privacy Act requirements and OMB policies and guidance for the proper processing of Privacy Act requests

​​​​​​​Redress

Redress supports data integrity requirements for PII by providing a process for individuals to request correction of, or amendment to, their PII maintained by an organization. Redress supports the ability of individuals to ensure the accuracy of PII held by organizations.

Effective redress processes demonstrate organizational commitment to data quality especially in those business functions where inaccurate data may result in inappropriate decisions or denial of benefits and services to individuals. Organizations use discretion in determining if records are to be corrected or amended, based on the scope of redress requests, the changes sought, and the impact of the changes. Individuals may appeal an adverse decision and have incorrect information amended, where appropriate.

The following steps detail the CMS-specific process for redress.

Step 1: When an individual calls 1-800-MEDICARE requesting an amendment/correction of their PII/PHI, the individual is instructed to send in a written request, and is provided appropriate instructions on how to submit the request. If an individual telephones CMS to request a change to his/her demographic information (e.g., name and address), CMS refers the individual to the Social Security Administration (SSA).

Step 2: Written requests are received by the applicable System Manager through various means.

Step 3: All written requests are reviewed to ensure that they include the following authentication information: full name, date of birth, health insurance claim number, and one other piece of information such as address, phone number, and/or effective dates of Part A coverage.

Step 4: If the written request is not complete with the required information, the request is returned. The individual is instructed to complete all required information and resubmit.

Step 5: If the written request is complete, the identity of the individual requesting amendment/correction to an individual’s records is determined in accordance with the instructions contained above in Section 3.4 “Verification of Identity.

Step 6: Once verification of identity and authority is complete, the System Manager or designee reviews the request, makes a determination whether an amendment, addition or correction to the individual’s record is appropriate, and notifies the individual. All documentation is placed in the individual’s record, including a record of having made any addition or amendment in response to the individual’s request.

Step 7: If an individual writes to CMS to request a change to his/her demographic information (e.g., name, address), the CMS Customer Service Representative (CSR) will call the beneficiary about contacting the SSA. If the CSR is unable to reach the beneficiary by phone, the CSR will follow up with a letter to the beneficiary with this information.

Step 8: Other requests for amendments/changes to PII/PHI are forwarded to the beneficiary’s Medicare Administrative Contractor (MAC) for resolution. If the MAC determines that the request is appropriate, then the MAC makes the correction to the record. The MAC notifies CMS and the individual in writing that the correction was made.

Denial of Correction or Amendment

  • If the request for correction or amendment is denied, in whole or in part, the MAC will inform the System Manager.
  • The System Manager or designee will document the denial in the beneficiary’s record and a timely denial notice will be sent to the individual. The denial notice will inform the individual that the individual may submit a written statement of disagreement with the denial of all or part of a requested amendment and the basis of such disagreement. This statement of disagreement will be maintained in the individual’s record.

CMS denies a request for correction or amendment of PII/PHI for reasons, including but not limited to:

  • The individual’s PII/PHI is not part of the record.
  • CMS did not create the record.
  • The record is not available to the individual for inspection under federal law.
  • The record is already accurate and complete.

Any written statement or statement of disagreement by the individual, any response by CMS, and any other document pertaining to the request will become part of the individual’s permanent record.

​​​​​​​Complaint Management

Complaints, concerns, and questions from individuals can serve as a valuable source of external input that ultimately improves operational models, uses of technology, data collection practices, and privacy and security safeguards. Organizations provide complaint mechanisms that are readily accessible by the public, include all information necessary for successfully filing complaints (including contact information for the Senior Official for Privacy (SOP) or other official designated to receive complaints), and are easy to use. Organizational complaint management processes include tracking mechanisms to ensure that all complaints received are reviewed and appropriately addressed in a timely manner.

The following steps detail the CMS-specific process for complaint management.

SOP implements a process for receiving and responding to complaints, concerns, or questions from individuals about organizational privacy practices.

  • The complaint process is explained in the CMS Notice of Privacy Practices (detailed in Section 3.4 of this Handbook). As described in the Notice, individuals are directed to call 1-800-MEDICARE. The customer service representative directs the individual to send in a written complaint to the Office of the Ombudsman.
  • All mail communication goes to the Office of the Ombudsman. The Office of the Ombudsman triages the complaints and works in coordination with the Office of the SOP to address each. All complaints are documented in the individual’s records.
  • The customer service representative may also provide information on filing a complaint with the U.S. Department of Health and Human Services or Office for Civil Rights.

Response Times

Timely communication and resolution of complaints from individuals demonstrates responsiveness by the organization and reduces the organization’s risk of reputational damage and potential violations of HIPAA and the Privacy Act.

The following steps detail the CMS-specific process for response times.

Step 1: CMS acknowledges complaints, concerns, or questions from individuals within ten (10) working days.

Step 2: CMS completes review of requests within thirty (30) working days of receipt, unless unusual or exceptional circumstances preclude completing action by that time.

Step 3: CMS responds to any appeal as soon as possible, but no later than thirty (30) working days after receipt of the appeal unless the appeal authority can show good cause to extend the response period.

​​​​​​​Inventory of Personally Identifiable Information

The PII inventory identifies the organization’s information assets and identifies those assets collecting, using, maintaining, or sharing PII. The PII inventory identifies those assets most likely to impact privacy; provides a starting point for organizations to implement effective administrative, technical, and physical security policies and procedures to protect PII; and to mitigate risks of PII exposure.

​​​​​​​Privacy Incident Response

CMS uses a risk-based analysis for privacy breaches using OMB, HITECH, and HIPAA guidance. This guidance requires organizations to determine the sensitivity of its data, based on the information and the context in which the information appears, and then to determine the level of response, based on the resultant privacy risk to the organization and to affected individuals.

CMS defines a breach as the loss of control, compromise, unauthorized disclosure unauthorized acquisition, unauthorized access, or any similar term referring to situations where persons other than authorized users and for an other than authorized purpose have access or potential access to personally identifiable information, whether physical or electronic.

CMS defines an incident as a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.

Please see the Figure 4. Privacy Incident Response for an overview of the incident and breach response process.

The following is the CMS-specific process for privacy incident response.

Step 1: A suspected or confirmed incident/breach is discovered and reported to CMS IT Service Desk. If the incident is reported by the Medicare Administrative Contractors (MAC) they report incidents to the CMS IT Service Desk and Center for Medicare (CM) mailbox simultaneously.

Step 2: The CMS IT Service Desk reports the issue to Incident Management Team (IMT) or Center for Medicare (CM) depending upon the nature of the reported issue

Step 3: If the incident is sent to CM, they conduct a risk assessment and provide the assessment to IMT for concurrence and then apply any necessary remediation.

Step 4: If the incident is sent to IMT, they contact the applicable Business Owner(s) to collaborate on incident management. Including, conducting an investigation and gathering any additional information required to determine if the issue is an incident or a breach. If the issue is determined to be an incident they follow the applicable procedures detailed in the IMT Handbook and IMT Playbook

Step 5: If the IMT/CM determines there is a breach, they will request that a breach analysis is conducted, as appropriate. The Breach Analysis Team (BAT) will conduct an analysis to determine the impact/harm by following the BAT Standard Operating Procedure (found on the ISPG Library). The BAT consists of the applicable Business

Owner, ISSO, and select members of IMT and DSPPG. The BAT will reach a finding on whether breach notification is necessary.

Step 6: Should breach notification be determined necessary by the BAT. The BAT will coordinate the drafting of a breach notification and obtaining approval from the HHS Privacy Incident Response Team.

Step 7: Proper remediation occurs to the satisfaction of CMS, which can include, but is not limited to: corrective action, mitigating harm, re-training, or individual sanctions.

​​​​​​​Privacy Notice

Providing the appropriate notification of privacy practices to the individual enables the individual to make an informed decision when they provide their consent.

Effective notice, by virtue of its clarity, readability, and comprehensiveness, enables individuals to understand how an organization uses PII generally and, where appropriate, to make an informed decision prior to providing PII to an organization. Effective notice also demonstrates the privacy considerations that the organization has addressed in implementing its information practices. The organization may provide general public notice through a variety of means, as required by law or policy, including system of records notices (SORN), privacy impact assessments (PIA), or in a website privacy policy. As required by the Privacy Act, the organization also provides direct notice to individuals via Privacy Act Statements on the paper and electronic forms it uses to collect PII, or on separate forms that can be retained by the individuals.

​​​​​​​Real-Time or Layered Notice

Real-time notice facilitates informed consent and promotes trust from the individual when collecting sensitive PII. Real-time notice used in conjunction with a Privacy Act Statement or Privacy Advisory, based on the sensitivity of the PII provided or collected, ensures the individual provides informed consent.

Real-time notice is defined as notice at the point of collection. A layered notice approach involves providing individuals with a summary of key points in the organization’s privacy policy. A second notice provides more detailed/specific information.

The following details the CMS-specific process for real-time or layered notice.

Business Owner provides real-time notice (i.e. notice at all points of collections) and where appropriate, layered notice, whenever any system or business process it collects PII.

​​​​​​​System of Records Notices and Privacy Act Statements

SORNs and Privacy Act Statements, i.e., (e)(3) notices, provide transparency, in advance of collection, use, maintenance, or sharing of PII when in a system that meets the statutory definition of a “system of records” under the Privacy Act. The Privacy Act defines “maintain” as “maintain, collect, use or disseminate.” These requirements impact decisions made during planning, design, development, and operation of programs and systems.

Organizations issue SORNs to provide the public notice regarding PII collected in a system of records, which the Privacy Act defines as “a group of any records under the control of any

agency from which information is retrieved by the name of an individual or by some identifying number, symbol, or other identifier.” SORNs explain how the information is used, retained, and may be corrected, and whether certain portions of the system are subject to Privacy Act exemptions for law enforcement or national security reasons.

The following steps detail the CMS-specific process for system of records notices and privacy act statements.

CMS, through the HHS Privacy Act Officer, OpDiv Privacy Subject Matter Experts, and the HHS Office of General Counsel:

Step 1: Publishes SORNs in the Federal Register and on the agency website, subject to required oversight processes, for systems containing PII;

Step 2: Keeps SORNs current; and

Step 3: Includes Privacy Act Statements on its forms that collect PII, or on separate forms that can be retained by individuals, to provide additional formal notice to individuals from whom the information is being collected.

​​​​​​​Public Website Publication

Publications on the organization websites improves transparency by providing individuals easier access to information about how their PII will be collected, used, maintained, or shared; and centralizing the information regarding to whom an individual should submit a request for access or amendment to their information covered by the SORN.

The following steps detail the CMS-specific process for public website publication. Privacy Act Officer shall publish all SORNs on a designated page of CMS’ public website.

​​​​​​​Dissemination of Privacy Program Information

Making information about an organization’s privacy program readily available to the public reduces the burden on individuals wanting to better understand an organization’s privacy practices. It also reduces the burden on privacy offices and program officials by providing answers to common privacy questions through an easily accessible forum.

Organizations employ different mechanisms for informing the public about their privacy practices. Mechanisms include, but are not limited to, privacy impact assessments (PIA), system of records notices (SORN), privacy reports, publicly available web pages, email distributions, blogs, and periodic publications (e.g., quarterly newsletters).

​​​​​​​Internal Use

Organizations take steps to ensure that they use PII only for legally authorized purposes and in a manner compatible with uses identified in the Privacy Act and/or in public notices. These steps include monitoring and auditing organizational use of PII and training organizational personnel on the authorized uses of PII. With guidance from the Senior Official for Privacy (SOP) and where appropriate, legal counsel, organizations document processes and procedures for evaluating any proposed new uses of PII to assess whether they fall within the scope of the organizational authorities. Where appropriate, organizations obtain consent from individuals for the new use(s) of PII.

Information Sharing with Third Parties

Sharing PII with third parties introduces new risks to the individual that, as applicable, requires organizations to establish formal agreements with the third party and ensure the sharing is compatible with the purposes described in notice to, and consent from, the individual.

Consideration of privacy risks for sharing PII apply regardless of the method used or whether the information remains stored in the system of records. Data removed from an information system covered by a system of records notice (e.g., a Human Resources database) and shared in another format (e.g., an Excel spreadsheet) must still meet purpose and use requirements of the associated notice. PII not in a system of records that is shared with a third party still must meet the Purpose Specification and, relatedly, Use Limitation FIPPs (i.e. data extracts of PII shared via an Excel spreadsheet or database archive).

A third party is an individual or organization besides CMS and the individual about whom CMS collects and uses information.

The organization Senior Official of Privacy and, where appropriate, legal counsel review and approve any proposed external sharing of PII, including with other public, international, or private sector entities, for consistency with uses described in the existing organizational public notice(s).