Data Sharing & Governance
- Among CMS authorization boundaries with the same authorizing official (CIO). Managed with data use MOUs.
- Between CMS and its contractors, Application Development Organizations (ADOs), and researchers. Managed with DUAs
- Between CMS and other Federal Agencies. Managed with ICSAs and CMAs
- Between CMS and State & Local organizations. Managed with ICSAs and CMAs
Existing Guidance
The CMS TRA currently contains these business rules that relate to data governance, but each is stated in a limited context:
- BR-F-5: Any System That Processes CMS Data Must Be Covered by a CMS ATO
- BR-CCIC-01: Security Authorization of Systems
- BR-EFT-12: CMS Data in ATO’d Environments May Not Be Transferred to Non-ATO’d Environments
- BR-EFT-13: CMS Data May Not Be Transferred Outside of CMS Processing Environments without a Prior Agreement
- BR-SAAS-2: SaaS Must Have a CMS ATO
CMS strongly recommends that all CMS data remain within CMS authorization boundaries, except for public data released by CMS. Any CMS data used outside a CMS boundary must be protected in accordance with CMS privacy and security requirements and data release policies, as specified in a Data Use Agreement (DUA) or other governance measure. Colloquially, the preference is for this data to remain “inside CMS firewalls.” Its replication to external contractor facilities may only be permitted with additional governance measures.
Business Rules
BR-DG-1: All CMS enterprise data must be stored within a CMS authorization boundary
This is a corollary of BR-F-5. CMS data may be shared under the terms of a data governance vehicle (see below), but any persistent storage must be within a boundary authorized by the CMS CIO. If under an ATO from a different authorizing official, it is still subject to security controls required by CMS. The only exception being public data released by CMS.
Rationale:
CMS is required to protect the integrity and privacy of its enterprise data. Whether a SaaS or PaaS FedRAMP environment — or other contractor-owned/ contractor-operated facility, this requirement still applies. In addition to PII and PHI, CMS must manage other types of sensitive information.
RP-DG-2: Any CMS enterprise data sharing beyond CMS authorization boundaries should “share-in-place” where feasible, for example, a workspace or a remote API , avoiding file export or replication
Cloud-based deployments can now mitigate the capacity, processing, and network limitations that made it necessary to copy entire datasets for local processing. A workspace, accessed remotely, can provide analytics for particular views or datasets. Multiple workspaces could also help to segregate costs for individual external organizations.
Rationale:
Implementation of sharing as a virtual workspace or API enables dynamic authorization, which is a key Zero Trust principle. CMS capabilities that support this are mature enough for most use cases.
References
Essential data governance vehicles include:
- CMS Data Use Agreement (DUA) defines how Protected Health Information (PHI) will be disclosed to organizations requesting data from CMS. Applicable CMS TRA Business Rule: BR-EFT-13
- CMS Information Exchange Agreement (IEA) for Business Owners and Privacy Advisors working together to determine the terms of sharing PII with other federal or state agencies
- CMS Interconnection Security Agreement (ISA) defines the relationship between CMS information systems and external systems. Applicable CMS TRA Business Rule: BR-CCIC-01
- HHS Computer Matching Agreements (CMA) is created when CMS records are matched with records from another Federal or State agency and the results of such match may have an adverse impact on an individual in relation to a Federal benefit program.
Further information is found at Access to CMS Data & Application: CMS Contractor Data Communications Support Policy.