The CMS TRA describes the technical baseline for all CMS Processing Environments. The CMS TRA cites proven, effective, and tested common controls that meet legislatively mandated mission, security, and privacy requirements. The Agency updates the CMS TRA as required to respond to CMS’s changing needs and direction and to reflect current technical standards.
As CMS’s repository of technical reference standards, the CMS TRA plays a critical role in all contracts. Contracting Officers refer to the CMS TRA topics in task orders and solicitations to ensure that contractors understand and apply technical consistency across data centers and contract efforts.
The TRA focuses on services, outcomes, and effects instead of physical structures, specific products, or system components. Unless explicitly stated, references to specific products and/or vendors within the CMS TRA provide information about the existing technical environment rather than express an Agency preference. The CMS TRA supports the Department of Health and Human Services (HHS) Enterprise Architecture principles and satisfies the CMS ARS security control, CM-2, Baseline Configuration.
CMS relies on the following guiding principles for the CMS TRA:
- Defense-in-Depth
- Least privilege
- Vendor agnostic, amenable to new technologies
- Reuse
- Service-Oriented Architecture (SOA) and Microservices
- Enterprise Services
- Common Platform Services
- Cloud First
- Use of Open Source Software
- Automation
- Sustainability
Defense-in-Depth
Defense-in-Depth employs multiple, coordinated security countermeasures to protect against security issues throughout the infrastructure.
A Services Framework architecture separates services by their function and encapsulates them with their own layers of protection/defense providing adaptable layers of depth.
A multi-zone architecture, which is a type of Services Framework architecture, places multiple layers of protection/defense on each zone by segregating networks and controlling inter-zone communications.
Least Privilege
The CMS TRA adheres to the security concept of least privilege, the security objective of granting users only those accesses they need to perform their official duties. When a user is permitted to “self-elevate” temporarily (e.g., Linux sudo command), this action is logged.
Vendor Agnostic
Unless explicitly stated, the CMS TRA does not advocate a preferred vendor or suite of products. One notable exception to this rule is shared services (including security services), where a specific technology has been selected and is mandated for use of or integration with this shared service. CMS encourages innovation of supportable solutions within the parameters of the CMS TRA.
When selecting software, business owners should assess licensing for competing products before deciding on a product. Emphasis should be on reducing purchase and maintenance costs for CMS and on promoting consistency across CMS applications and environments. Business owners are also encouraged to consider Inter-Agency Agreements (IAA), CMS Enterprise License Agreements (ELA), and Government Furnished Software (GFS).
CMS maintains enterprise licensing information at: Enterprise Software Licensing
For more information on IAA, ELA, or GFS agreements, please contact the Office of Acquisition and Grants Management (OAGM) at SoftwareLicensesCMS@cms.hhs.gov.
Reuse
CMS encourages reuse and sharing wherever practicable to avoid creating redundant services/applications. There can be multiple cloud and physical data centers in the CMS environment. Any application can reside in any combination of CMS data centers (including CMS Clouds) and use software services—for example, Identity Management (IDM) and Enterprise Portal—of the other data centers. Application software in one data center may leverage services in another data center.
The benefits of reuse include:
- Reduced implementation times
- Lower project risk
- Reduced costs
- Minimized redundancy
- Improved security
- Improved interoperability
CMS employs several strategies for reuse: adoption of a Service-Oriented Architecture, use of Microservices, and the implementation and use of Strategic and Preferred Solutions.
Service-Oriented Architecture and Microservices
SOA defines a set of principles for developing software as interoperable, reusable, distributed services to fulfill business functions. For example, the Medicaid Information Technology Architecture (MITA) is a SOA framework that allows CMS and state Medicaid organizations to create, deploy, execute, and manage reusable, modular, and interoperable business, data, and technology services. The Application Development section addresses SOA extensively.
Microservices (MS) are a modern interpretation of SOAs for building distributed software systems. Each component/ module of an application is developed and deployed separately. This contrasts with a traditional, “monolithic” application in which all components are developed and deployed as one piece. Microservices are well suited to DevOps methods and tools. The Application Development section addresses Microservices, with additional detail in the TRB Research Spotlight, “Microservice Architecture,” published April 11, 2023.
Strategic and Preferred Solutions
CMS strongly encourages the use of Strategic and Preferred Solutions. These are solutions which have been designed, tested, and approved for broad use within CMS. Utilizing these existing solutions, which include formally designated Enterprise Shared Services (ESS), shortens the Time-to-Delivery (TTD), facilitates efficient infrastructure use, reduces redundant capabilities, improves access, and leads to more consistent cybersecurity posture.The Office of Management and Budget (OMB) memo M-19-16 (April 26 2019) defines federal IT shared services and policy. (Also see https://ussm.gsa.gov/)
Details and guidance for the use of these services are described in the following section, CMS Strategic Guidance and Preferred Solutions.
Common Platform Services
Common platform services are technology services provided in support of all hosted applications. The CMS ecosystem now supports platform services across both cloud and on-premises environments. These capabilities are designed to standardize and simplify support and management.
Common platform services may include (but are not limited to):
- Network capabilities such as load balancing, domain name services (DNS), dynamic host control protocol (DHCP)
- Event logging (Syslog, SIEM)
- Database Administration
- Operating System (OS) Administration
Application developers should use enterprise shared services and common platform services where possible rather than implementing specialized or single-use software.
Cloud First
The CMS TRA supports the Federal Cloud Computing Strategy’s (OMB/Federal CIO Kundra, February 14, 2011) Cloud First Policy. For details, please refer to the Network Services and Infrastructure Services sections.
Pursuant to this objective, CMS is closing its on-premises data centers and is migrating all on-premise applications to cloud environments. Any residual on-premises functionality is migrating to cloud-connected collocation facilities. This strategy is aligned with OMB M-19-19 regarding the Data Center Optimization Initiative. “Agencies may not budget any funds or resources toward initiating a new agency-owned data center or significantly expanding an existing agency-owned data center without approval from OMB.”. See the full OMB M-19-19 directive for more information. The objective is to drive meaningful improvement to IT infrastructure, achieve cost savings through optimizations and closures, and foster IT modernization.
CMS has a robust set of recommended cloud services and capabilities available to enable rapid migration to and deployment within the cloud. See the CMS Strategic Guidance and Preferred Solutions section for further detail.
Use of Supportable Open Source Software
The CMS TRA permits the use of supportable Open Source software in CMS Processing Environments. For details, please refer to the chapter on Open Source Software in the Application Services Section. Unsupported software in any capacity cannot be patched in a timely manner; accordingly, any Open Source software without a dedicated support matrix violates the CMS ARS.
Development Methodology Agnostic
The CMS TRA applies to all CMS Processing Environments regardless of the approach used to develop and maintain CMS Federal Information Security Modernization Act (FISMA) applications (e.g., using Waterfall, Prototyping, Incremental, Spiral, Rapid Application Development, and Agile).
Automation
The CMS TRA encourages the appropriate use of automation to reduce variability and increase speed. In code development and deployment process, continuous integration automation (code checkout/build, static code analysis, dependency check, unit testing), continuous deployment release orchestration, Infrastructure as code can be used to avoid manual errors and manage complexity. In production, operational monitoring can be automated by vulnerability scanning, system health, alerts, etc.
Sustainability
The CMS TRA encourages projects to consider sustainability as a critical element of architectural solutions. Projects should apply appropriate attention to future scale, cost, security, operational efficiency, technology, and vendor support. The long-term viability of applications and data products must be considered when integrating any solution into the CMS Processing Environments. Risk and mitigation planning for sustainability should address personnel (technical expertise), operational processes (automation), adherence to Service Level Agreements, and total cost of ownership.
In cloud environment the sustainability for cost, scalability, service level agreements can be achieved by adoption of cloud native features like dynamic scaling up/down of resources based on usage, use of shared instances vs reserved instance and optimal sizing of resources.
Accessibility and Section 508 Compliance
Inaccessible technology interferes with an individual’s ability to obtain and use information quickly and easily. Section 508 of the Rehabilitation Act of 1973 was enacted to eliminate barriers in IT, to make available new opportunities for people with disabilities, and to encourage development of technologies that will help achieve these goals. CMS operates many programs that are critically important to people with disabilities. IT is often the vehicle for delivering these programs. The most effective and least costly approach to technology accessibility is for CMS to incorporate accessibility into its IT governance, development, and procurement processes.
Under Section 508, federal agencies must give federal employees and members of the public with disabilities access to Information Communication Technology (ICT) and information that is comparable to the access available to individuals without disabilities. For CMS Processing Environments and applications, adherence to the Agency’s Section 508 policies include:
- External and internal user interfaces
- Hardware and software products, including Commercial Off-the-Shelf (COTS) and custom products
- Development and maintenance tools
- External and internal reports or other artifacts created by CMS applications or tools
- Electronic documentation
- Support services
CMS Guidance
CMS provides resources for Section 508 compliance, including policies, validation procedures, and a list of CMS Section 508 Clearance Officers, at: Section 508 and CMS.
Additional CMS guidance and resources are found in Application Development, Web-based UI Services, as well as in the CMS Design System.
The CMS Section 508 Policy provides a clear rationale and compliance road map for CMS Processing Environments and applications and takes precedence over the CMS TRA. The following paragraphs summarize the basis for these requirements, which is explained further in the CMS Section 508 Policy.
In 1986, Congress added Section 508 to the Rehabilitation Act of 1973. Section 508 established non-binding guidelines for IT accessibility. On August 7, 1998, the president signed into law the Workforce Investment Act of 1998, which included amendments to the Rehabilitation Act. These amendments significantly expanded and strengthened the IT accessibility requirements in Section 508 and made them binding on federal agencies.
Section 508 applies to Information Communication Technology, previously referred to as Electronic and Information Technology (EIT). Section 508, as amended, specifically requires that, when federal agencies develop, procure, maintain, or use ICT:
-
Individuals with disabilities who are federal employees shall have access to and use of information and data that is comparable to the access to and use of the information and data by federal employees who are not individuals with disabilities; and
-
Individuals with disabilities who are members of the public seeking information or services from a federal department or agency shall have access to and use of information and data that is comparable to the access to and use of the information and data by such members of the public who are not individuals with disabilities (FAR 39.201 and 36 CFR 1194.1).
Section 501 of the Act requires CMS to be a model employer of people with disabilities. Section 504 requires CMS to ensure equally effective access to its programs and services. CMS can reach both objectives only if it adheres to the requirements of Section 508.
Relevant Section 508 Standards for CMS IT
The CMS Section 508 policy is based on the standards described in the following subtopics.
U.S. Access Board 508 Standards for Information Communication Technology
The U.S. Access Board’s Information and Communication Technology Revised 508 Standards and 255 Guidelines apply to a wide range of products and services, including but not limited to, the following:
- Computers
- Telecommunications equipment
- Multifunction office machines (e.g., copiers/printers, software, websites, information kiosks, and transaction machines)
- Electronic documents
The final rule jointly updates requirements for information and communications technology covered by Section 508 of the Rehabilitation Act and Section 255 of the Telecommunications Act. The Section 508 Standards apply to electronic and information technology procured by the federal government. The Section 255 Guidelines address access to telecommunications products and services and apply to manufacturers of telecommunication equipment.
Web Content Accessibility Guidelines 2.0
Web Content Accessibility Guidelines (WCAG) 2.0 define how to make web content more accessible to people with disabilities. WCAG 2.0 is developed through the World Wide Web Consortium (W3C) process in cooperation with individuals and organizations around the world. The goal is to provide a shared standard for web content accessibility that meets the needs of individuals, organizations, and governments internationally. WCAG 2.0 is designed to apply broadly to different web technologies now and in the future, and to be testable with a combination of automated testing and human evaluation. WCAG 2.0 has three conformance levels, including A (lowest), AA, and AAA (highest). CMS requires that the WCAG 2.0 standards be met at both the Level A and Level AA conformance level.
Web accessibility depends on accessible content as well as accessible web browsers and other user agents. Authoring tools also have an important role in web accessibility. For an overview of how these components of web development and interaction work together, please refer to the following links:
- Essential Components of Web Accessibility
- User Agent Accessibility Guidelines (UAAG) Overview
- Authoring Tool Accessibility Guidelines (ATAG) Overview
PDF / UA
The PDF/UA (Portable Document Format/Universal Accessibility) standard, defined in the ISO 14289-1 standard (see https://pdfa.org/resource/iso-14289-pdfua/ for additional information) describes technical requirements for universally accessible PDF documents by identifying a set of relevant PDF functions (including text content, images, form fields, comments, bookmarks, and metadata) based on ISO 32000-1 (PDF 1.7) and specifies how they should be used in PDF/UA-compliant documents. Successful access to content within PDFs depends both on compliant documents and compliant PDF programs and assistive technology. PDF/UA therefore also specifies requirements for compliant assistive technology.
For assistive technologies to work properly with PDF/UA, they must meet the following requirements:
- They must be able to recognize all structural elements, attributes, and key values used in the specification and output them for the user of a PDF document.
- They must allow the user to navigate through the document by page number, through the structure tree, or by using bookmarks.
- They must allow the user to easily set and change the magnification of a PDF document at any time.
Document Accessibility at CMS and HHS Section 508 Compliance Checklist
For information about designing accessible documents that adhere to HHS’s requirements, please refer to the HHS Section 508 Accessibility Conformance Checklists.
HHS Guidance
HHS Web Standards apply to all HHS Office of the Secretary (OS) websites—including all Operating Divisions (OPDIVs) / Staff Divisions (STAFFDIVs) and Secretarial Priority websites, whether aimed at internal or external audiences. These standards are required for the design and development of all HHS/OS websites and may be adopted by OPDIVs.
The Framework covers all HHS web sites, internal or external, that are owned, managed, or funded by Operating and Staff Divisions, including CMS, whether developed by staff or acquired through contracts, cooperative agreements, grants, and/or formally established partnerships with other government entities and/or the private sector. The Framework covers traditional web content, including all attached or linked HHS files, and all news and social media, including videos, podcasts, blogs, Wikis, and associated applications on all HHS web sites.
CMS Testing for 508 Compliance
CMS uses the following tools and methods to test IT products and artifacts for Section 508 compliance:
- Manual code review
- Review of system development test plans
- JAWS screen reading software
- Dragon translation software speech-to-text
- Zoom Text screen magnification software