Assessments of a health-related matter of interest, importance, or worry to a patient, patient’s authorized representative, or patient’s healthcare provider that could identify a need, problem, or condition.
Description (*Please confirm or update this field for the new USCDI version*)
Assessment of a patient’s physical, cognitive, or psychiatric disabilities.
Examples include but are not limited to American Community Survey, Veterans RAND Health Survey, and Patient-Reported Outcomes Measurement Information System (PROMIS).
Applicable Vocabulary Standard(s)
Applicable Standards (*Please confirm or update this field for the new USCDI version*)
Logical Observation Identifiers Names and Codes (LOINC®) version 2.77
Represents information or details about an individual's physical, cognitive, intellectual, or psychiatric disabilities.
Use Case Description(s)
Use Case Description
Individuals living with disabilities face barriers to receiving proper medical care when their doctors and care teams are not aware of existing disabilities. Consequently, these barriers exacerbate health disparities and result in inferior care and poor outcomes. Appointments may need to be rescheduled, care may not be coordinated properly, breakdowns in communication and trust will also negatively impact patient care without carefully documenting disability status. If properly documented, an alert could notify appropriate care team members and staff to address any physical access barriers, arrange for interpreters, plan for various forms of communication and patient support tools.
Applications for disability benefits could be further automated and streamlined with the addition of this data element.
If we are going to improve the lives and care of individuals living with disabilities, we must prioritize capturing and sharing this data accordingly.
Estimate the breadth of applicability of the use case(s) for this data element
Not currently captured or accessed with an organization
Extent of exchange
N/A
Potential Challenges
Restrictions on Standardization (e.g. proprietary code)
Unknown
Restrictions on Use (e.g. licensing, user fees)
Unknown
Privacy and Security Concerns
Unknown
Estimate of Overall Burden
Unknown
ONC Evaluation Details Each submitted Data Element has been evaluated based on the following criteria. The overall Level classification is a composite of the maturity based on these individual criteria. This information can be used to identify areas that require additional work to raise the overall classification level and consideration for inclusion in future versions of USCDI
Criterion #1 Maturity - Current Standards
Level 2 - Data element is represented by a terminology standard or SDO-balloted technical specification or implementation guide.
Criterion #2 Maturity - Current Use
Level 0 - Data element is captured, stored, or accessed in limited settings such as a pilot or proof of concept demonstration.
Criterion #3 Maturity - Current Exchange
Level 0 - Data element is electronically exchanged in limited environments, such as connectathons or pilots.
Criterion #4 Use Case(s) - Breadth of Applicability
Level 1 - Use cases apply to several care settings or specialties.
Submitted By: James Patterson
/ PACIO Project
Data Element Information
Data Element Description
A self-reported status that identifies individuals with disabilities or conditions that impact major life activities, used to ensure equal access and may inform accommodation needs.
Examples include, but are not limited to, the required responses for the American Community Survey six-question set (ACS-6) and optional capture of other surveys such as the Washington Group Short Set on Functioning (WG-SS).
Rationale for Separate Consideration
The USCDI “Disability Status” data element (for which we recommend USCDI change its name to “Disability Assessment”), currently encapsulates both (1) demographic information, which is used to support population-level health surveillance and accommodation access, and (2) individual-level patient information, which is used to inform clinical decisions. These are two different and distinct types of data used for different purposes, with the population-level demographic data being defined using the “Disability Status” name and the individual-level patient information not aligned with the idea of a disability status.
The distinct difference between these two different types of data encapsulated in the current USCDI data element is articulated by the example measures included in “Disability Status,” which include the American Community Survey six-question set (ACS-6), Veterans RAND Health Survey (VR-12), and Patient-Reported Outcomes Measurement Information System (PROMIS) as equivalent examples under a single data element.[1] The ACS six-question set is defined as a demographic self-report instrument developed by a federal interagency committee for population-level identification—the same category of data collection as the race, ethnicity, sex, and primary language standards established under the same statute.[2,3] The VR-12 and PROMIS are clinical health assessment instruments that measures functioning and health-related quality of life to inform clinical decision-making. Compared to the ACS-6, the VR-12 and PROMIS instruments serve a fundamentally different purpose, are collected by different actors, at different points in the health journey of people with disabilities, and under different legal authorities.
Given the fundamental differences between collecting information about a population for service and accommodation access vs. about an individual patient to inform clinical decisions, we are requesting a new “Disability Status” data element under the Patient Demographics/Information data class to clearly separate out legally required demographic data from health assessment data.
[1] Draft USCDI V7 Disability Status data element and Accommodation data element, ASTP/ONC (healthit.gov).
[2] ACA Section 4302 (2010).
[3] U.S. Department of Health and Human Services Implementation Guidance on Data Collection Standards for Race, Ethnicity, Sex, Primary Language, and Disability Status. ASPE, Office of Health Policy (October 2011).
Use Case Description(s)
Use Case Description
Disability status data, as measured via population-level demographic data, is required for several federal efforts. The Affordable Care Act requires under Section 4302 the collection of disability status data as part of standardized population-level demographic data collection.[7] It is collected along with other demographic data, such as race, to inform population health work.
To align with this requirement, the Enhancing Oncology Model (EOM) requires, as of July 2024, collection of six well-tested disability questions that have been endorsed by the Office of the Assistant Secretary for Planning and Evaluation and the CDC, among others, as part of a CMS Innovation Center initiative to advance the collection of disability status data. These six questions have been used as part of the American Community Survey and many federal government surveys over the years.[7] Given this question set has been widely used and tested, EOM is requiring the collection and reporting of disability status as a population-level demographic via their sociodemographic data elements (SDEs) [8,9]:
“Disability status is a patient-reported demographic characteristic. Documentation of SDEs is necessary for providing high-quality. For some people with disabilities, their disability is a part of their identity and may affect how others perceive or interact with them, making it valuable to collect this information” (p. 6).[10]
Estimate the breadth of applicability of the use case(s) for this data element
The Enhancing Oncology Model (EOM) is a nationwide, episode-based payment model covering Medicare fee-for-service beneficiaries. At launch in 2023, the program included 44 oncology physician group practices encompassing 561 sites of care and more than 2,800 unique practitioners across approximately 37 states, with 3 commercial payer participants.
The DEC is a community of healthcare systems, clinicians, researchers, and others who are working to improve implementation of evidence-based, accessible healthcare for patients with disabilities. DEC hosts a national collaborative of 50+ health systems who are all working on disability accessibility initiatives. Most of the health systems are collecting or are in the planning stages of collecting patient disability status as a demographic in their electronic health records (EHRs). Health systems report collecting disability status to (1) identify and prepare for patients in need of accommodations; and (2) track health outcomes and improve the quality of care provided to patients with disabilities.
(1) In a published qualitative study, Dr. Megan Morris, Founder and Director of DEC, and her research team interviewed 17 participants representing 15 healthcare organizations (HCOs) that had active initiatives to implement systematic collection of disability status in the EHR. The study found that healthcare organizations reported their main purpose for collecting disability status was to prepare for patients with disabilities and their accommodation needs.[11] Not only does this information facilitate patients’ access to care, but it enables HCOs to better comply the Americans with Disabilities Act and other federal laws mandating they provide disability accommodations to patients when requested.
(2) Dr. Morris is currently leading an NIH-funded project (R01DC020188) to support primary care clinics at five health systems across the United States with the implementation of documenting patient’s communication disabilities in the EHR and provide necessary disability communication accommodations. All of the sites have developed EHR builds in which disability is collected and displayed in the patient’s demographics section of the chart.
(3) NYU Langone Health, where DEC is based, has used patient disability status as a demographic characteristic for quality improvement initiatives. For example, in 2025, NYU-affiliated Federally Qualified Health Centers found that patients who were deaf and used American Sign Language (ASL) scored lower on patient satisfaction scores. As a result, system leadership facilitated a focus group to understand these patients’ experiences. Patients shared obstacles they faced when accessing care, including limited availability of in-person interpreters, technology issues with video remote interpreting, inaccessible scheduling options, inaccessible after-visit summaries, and more. Using this information, system leadership developed a quality improvement plan to improve the experiences and quality of care delivered to their deaf patients.
[11] Morris MA, Sarmiento C, Eberle K. Documentation of Disability Status and Accommodation Needs in the Electronic Health Record: A Qualitative Study of Health Care Organizations Current Practices. Jt Comm J Qual Patient Saf. 2024;50(1):16-23. doi:10.1016/j.jcjq.2023.10.006
Estimate the breadth of applicability of the use case(s) for this data element
The Disability Status data element under the Patient Demographics/Information data class will apply across all healthcare settings and patient interactions with HCOs, from scheduling to after-visit summaries. Collecting patient disability status along with other demographic information they already collect allows HCOs to ensure that they are providing the same quality of care to all of their patients.
Mitigate health and health care inequities and disparities
Address the needs of underserved communities
Address public health interoperability needs of reporting, investigation, and emergency response
Maturity of Use and Technical Specifications for Data Element
Applicable Standard(s)
LOINC (recommended required fields): https://loinc.org/69919-9
LOINC Panel 69919-9, “Race, ethnicity, sex, primary language, disability - Health and Human Services (HHS) panel [HHS.ACA Section 4302]”, which includes the ACS six-question set.
LOINC (recommended optional fields): https://loinc.org/98067-2
LOINC Panel 98067-2, “Patient-centered disability questionnaire”, which questions comparable to the WG-SS on functioning plus optional question related to communication disabilities as well as the need for accommodations. https://loinc.org/69919-9
Additional Specifications
US Core 8.0.1 IG: https://hl7.org/fhir/us/core/STU8.0.1/screening-and-assessments.html
The US Core 8.0.1 IG includes the needed standard for the ACS through a value set in VSAC. Though this is currently under the disability related data element under Health Status Assessment, it still provides the standard to enable this new data element as it is untangled from the existing one.
The VSAC Disability Status Assessment value set (OID: 2.16.840.1.113762.1.4.1099.49) provides the ACS six-questions with a direct linkage to the LOINC codes in the LOINC Panel 69919-9, “Race, ethnicity, sex, primary language, disability - Health and Human Services (HHS) panel [HHS.ACA Section 4302]”. Specifically:
• 69856-3; Are you deaf, or do you have serious difficulty hearing?
• 69857-1; Are you blind, or do you have serious difficulty seeing, even when wearing glasses?
• 69858-9; Because of a physical, mental, or emotional condition, do you have serious difficulty concentrating, remembering, or making decisions?
• 69859-7; Do you have serious difficulty walking or climbing stairs?
• 69860-5; Do you have difficulty dressing or bathing?
• 69861-3; Because of a physical, mental, or emotional condition, do you have difficulty doing errands alone such as visiting a physician's office or shopping?
Current Use
(Level 2) Captured, stored, or accessed in multiple production EHRs or other HIT modules from more than one developer
Extent of exchange
(Level 2) Between more than two production EHRs or other HIT modules using available interoperability standards
Supporting Artifacts
The CMS Enhancing Oncology Model (EOM) requires collection of disability status using the ACS six-question set in production EHR environments across participating oncology practices starting in Performance Period 3 (July 2024). The list of participating health systems includes Texas Oncology with over 160 locations alone. In addition, both Massachusetts General Brigham and Kaiser Permanente use custom forms to capture this data and provide it to external entities to support a variety of needs, such as post-acute care transitions, regulatory reporting, and others via Health Information Exchanges. Cumulatively, exchange is occurring between multiple production EHR systems plus federal agencies through established reporting infrastructure. https://www.cms.gov/priorities/innovation/media/document/eom-sociodem-data-elem-guide
Potential Challenges
Restrictions on Standardization (e.g. proprietary code)
This data element is recommended to use LOINC (an open, freely available standard), specifically the ACS six-question set (LOINC Panel 69919-9). The primary standardization challenge is not proprietary codes but rather the current USCDI structure, which conflates two conceptually distinct domains—demographic self-report and clinical health assessment—under a single data element. This submission seeks to resolve that structural issue by establishing a separate demographic data element with clear terminology and purpose.
Restrictions on Use (e.g. licensing, user fees)
None known. LOINC codes are freely available under the Regenstrief Institute's open license. The ACS question set was developed by a federal interagency committee for public use in population surveys and carries no licensing or user fee restrictions.
Privacy and Security Concerns
Disability status as a self-reported demographic is protected health information (PHI) under HIPAA and subject to standard HIPAA privacy and security protections. Within those boundaries, this data can and should be shared across administrative staff (for appointment setup, coordination, and reasonable accommodation planning) and the healthcare team (to ensure accommodations are in place during clinical encounters). Notably, under ADA, Section 504, and ACA Section 1557, organizations have affirmative obligations to use this data to provide reasonable accommodations—including for caregivers with disabilities such as legal guardians and conservators. Self-reported disability status as a demographic characteristic does not invoke the heightened protections of 42 CFR Part 2 (substance use disorder records) or other specialized privacy frameworks. The data should be handled with the same privacy protections afforded to other demographic data elements such as race, ethnicity, sex, and primary language.
Estimate of Overall Burden
Implementation burden is low to moderate. The data element relies on patient self-reporting via a standardized six-question set already in widespread use across federal surveys such as the American Community Survey (Census), National Health Interview Survey (CDC), Current Population Survey (Labor Statistics). It does not require clinical calculation, specialized equipment, or external system integration. Collection can be integrated into existing patient intake and registration workflows alongside other demographic data (race, ethnicity, sex, primary language). EOM-participating practices have demonstrated that collection is feasible within standard EHR registration workflows with Epic being the largest vendor to meet this requirement. In addition, major EHR vendors (Epic, Oracle Health) already support custom form creation sufficient to capture these questions. The primary implementation effort involves configuring intake forms and ensuring the data maps to the correct LOINC codes, which is a routine EHR configuration task rather than a significant development effort.
Other Implementation Challenges
Adoption and workflow challenges include: (1) Training registration and intake staff to ensure collection of disability status occurs consistently and sensitively alongside other demographic data, as this represents a newer addition to demographic collection compared to race, ethnicity, and sex. (2) Ensuring patients understand the purpose of the questions as demographic data collection for health surveillance purposes rather than clinical assessment, which requires careful framing of the questions during intake. (3) Addressing the current structural conflation in USCDI, where demographic self-report and clinical health assessment instruments are grouped under a single data element—this may cause confusion among implementers about which instruments to use and for what purpose. Resolving this conflation through the requested data element separation would reduce, rather than increase, implementation burden by providing clear guidance on the distinct purposes and workflows for each domain.
CDC and CMS recommend moving the current Disability Status data element from the Health Status Assessments data class to the Patient Demographics data class.
Federal consideration of disability data as demographic has precedent. For example, the data collection standards established by the ACA include disability alongside many variables already included in the Patient Demographics data class, such as race, ethnicity, and sex, and by extension disability can be used when using demographic factors for stratification for equity.
Collecting and transmitting data on disability in a standardized way alongside other demographic factors is vital to recognition of disability as a key component of identity and allows analysis of outcomes and conditions in an intersectional way, incorporating race/ethnicity, age, sex, and disability together for a more comprehensive understanding of patient demographics.
CMS may additionally recommend a disability assessment data element in version 5 to qualify the disability type (e.g. functional, cognitive, physical, etc.).
Data Elements: Functional Status, Mental/Cognitive Status, Disability Status (Draft V4)
Recommendation: Remove the Disability Status data element from the Health Status data class and instead add a new data element entitled, “Disability” to the patient demographic data class.
Rationale: The PACIO (Post-Acute Care Interoperability) Project, established February 2019, is a collaborative effort between industry, government, and other stakeholders, with the goal of establishing a framework for the development of FHIR implementation guides to facilitate health information exchange. The PACIO Community supports CMS and CDC submission, which reflect their view that identifying a person with a disability does not necessarily have any bearing on how healthy a person is or the status of one’s health. However, collecting and transmitting data on disability in a standardized way alongside other demographic factors is vital to recognition of disability as a key component of identity and allows analysis of outcomes and conditions in an intersectional way, incorporating race/ethnicity, age, sex, and disability together for a more comprehensive understanding of patient demographics.
Data Elements: Functional Status, Mental/Cognitive Status, Disability Status (Draft V4)
Recommendation: Adopt the value sets developed for the “Personal Functioning and Engagement” IG as part of the USCDI V3 updates to the U.S. Core IG to incorporate Functional Status and Cognitive Status data elements.
Rationale: The PACIO (Post-Acute Care Interoperability) Project, established February 2019, is a collaborative effort between industry, government, and other stakeholders, with the goal of establishing a framework for the development of FHIR implementation guides to facilitate health information exchange. Functional and Mental/Cognitive Status are important data classes that have widespread use in all healthcare settings and sharing the content of standardized PAC assessments (some of which are federally required) with non-PAC providers (e.g., hospitals, physicians) would improve the quality of care and facilitate care coordination during transitions of care. These instruments use a consistent framework mapped to HIT standards for functional status, contain administrative and clinical patient data, can be considered as individual data elements (mobility, pressure ulcer, transportation, social isolation, etc.) or a “questionnaire” of grouped data elements together (MDS, OASIS, IRFPAI, FASI etc.) The PACIO Community wishes to update the ONC/USCDI with current efforts relating to several of the data elements under the proposed USCDI V4 data class of Health Status (Health Concerns, Functional Status, Disability Status, and Mental/Cognitive Status). The PACIO Community recognized the value of creating data models (like Gravity’s SDOH) that allow for expansion across multiple domains. As a result, PACIO created a new FHIR Implementation Guide (IG), “Personal Functioning and Engagement,” which consolidates PACIO’s prior published IGs (STU1) “Cognitive Status” and “Functional Status”. The PACIO group also is incorporating data elements of communication, swallowing, and hearing to the “Personal Functioning and Engagement” IG currently under development. Currently, the Personal Functioning and Engagement IG data structures focus on observation/ assessment data. However, the IG could include future expansion using additional resources as the work matures. The concept of “Personal Functioning and Engagement” encompasses both an individual’s abilities (positive strengths) and disabilities (impairments) across all types of functioning. The PACIO Community examined and incorporated the International Classification of Functioning, Disability and Health (ICF) as a conceptual framework that underpins this new PACIO Personal Functioning and Engagement IG. PACIO’s current work focuses on ICF “Body Functions” including mental functions, sensory functions (including hearing), voice and speech functions, and ingestion functions (swallowing). Current PACIO focus for ICF “Activities and Participation” functions include Learning and Applying Knowledge, Communication, Mobility, and Self-care.
The American Occupational Therapy Association (AOTA) agrees with CDC’s comment and echoes the sentiment that because a person has a disability, it does not mean they are not functional. If the disability status data element is intended to capture specific disability status, this should be clarified. The examples provided under disability status appear to be more in alignment with the functional data elements. Per the documentation, functional status is intended to capture an individual’s risks of development or worsening of a condition or problem. However, it is important for USCDI to recognize that disability status may not be static and often fluctuates depending on the condition and may also be progressive. If this data element is intended to capture if a patient has a disability or to identify if the patient is able to make their own medical decisions, then this may be better as a data element under patient demographics vs health status.
The PACIO Community requests ONC clarify what is meant by “Disability Status” and how it relates to the separate data element of “Functional Status.” The existing definition does not describe the current conceptualization of disability. Recent literature suggests that functioning and disability is a complex interaction between a person, their health condition, personal factors (e.g. age lifestyle), and the environment. This concept is delineated in the International Classification of Functioning, Disability and Health (ICF) (https://www.who.int/standards/classifications/international-classification-of-functioning-disability-and-health). As a classification, ICF systematically groups different domains for a person in a given health condition (e.g., what a person with a disease or disorder does do or can do). Functioning is an umbrella term encompassing all body functions, activities and participation; similarly, disability serves as an umbrella term for impairments, activity limitations or participation restrictions. ICF also lists environmental factors that interact with all these constructs. In this way, it enables the user to record useful profiles of individuals’ functioning, disability and health in various domains. The association between the person and the contextual factors, defined as personal and environmental factors in the ICF, provides a clearer understanding of a person’s functioning and disability. Disability status considers the negative aspect of the interrelationship. For example, an individual with a health condition could be considered disabled in one environment (structural barriers exist in the community restricting a person in a wheelchair from moving outside one’s home) but not in another (accessible streets and housing allow a person in a wheelchair to go to work and community-based activities). The current definition of disability status assumes that only an assessment of physical, cognitive, intellectual, and psychiatric disabilities is required. Disability could be interpreted as part of Functional Status, whereby functioning indicates capability in a given area and poor functioning could be described as disability in that area (e.g., capability to ambulate vs. inability to ambulate). Disability often manifests on a continuum and the level of disability may depend upon certain environmental variables, such as access to assistive devices or technologies. In addition, disability may be permanent or temporary (e.g., functional abilities may decline after a stroke or a surgical procedure, but then improve with time and therapeutic interventions). If for the purposes of USCDI, ONC intends for Disability Status to represent a more binary concept of permanently disabled or not disabled, as determined by qualification for federal disability benefits, for example, the PACIO Community requests more explicit guidance to this effect.
The PACIO Community recommends that disability status be defined as an assessment (self, familial or practitioner assessment) that measures the relationship between a person, their health condition, personal factors, and the environment. Assessments can be identified that fit into the disability assessment category. Alternatively, the definition can be simplified to a designation of disability benefits awarded by a governmental or regulatory agency may be included.
We recommend moving the Disability Status data element from the Health Status data class to the Patient Demographics data class; identifying as a person with a disability does not necessarily have any bearing on how healthy a person is considered to be or the status of one’s health. Disability status is important to assess on a routine basis as it can be chronic or newly-evident due to illness or injury, and up to 1 in 4 adults report functional disability. Disability status places individuals as part of a group and as members of a minority sometimes subjected to marginalization, prejudice or discrimination. The federal consideration of disability data as demographic has precedent. For example, the social security administration categorizes its research, statistics, and policy analyses by demographics, including by disability status. In addition, the data collection standards established by the ACA include disability alongside many variables already included in the Patient Demographics data class, such as race, ethnicity, and sex. Recognizing disability as a demographic variable can help public health professionals to specifically tailor health interventions with the goal of helping people with disabilities achieve health equity. Collecting and transmitting data on disability in a standardized way alongside other demographic factors is vital to recognition of disability as a key component of identity and allows analysis of outcomes and conditions in an intersectional way, incorporating race/ethnicity, age, sex, and disability together for a more comprehensive understanding of patient demographics.
The American Occupational Therapy Association (AOTA) supports more consistent collection of disability status. AOTA supports its inclusion in the Health Status class as disability status may fluctuate between and during episodes of care. Disability status is captured consistently by occupational therapy practitioners through assessment and intervention. AOTA encourages USCDI to consider how data from occupational therapy practitioners can be utilized in this data class.
We encourage USCDI to also consider how this data can be patient reported to capture the individual’s interpretation of their disability status and identify inconsistencies in reporting. Utilizing self-reported and clinician reported data will provide a more comprehensive picture of the patient's disability status.
NACHC supports the comments of CDC, Ann Phillips/IMO and Charles Mayo/University of Michigan.
NACHC is supportive of the concept of disability status; however, it is not likely to support interoperability to solely create a terminology binding to support the concept. Because the concepts in the draft version generally represent non-semantically equivalent types of disability status and observations about these conditions, we believe that creating a class for this concept will likely create larger transitions of care documents without being able to be processed by receiving systems.
This approach creates liability for providers who at best can use this data as free text in this case and contributes to data overload and burnout. We strongly recommend providing either specific category of functional status with equivalent semantics and clear terminology bindings.
Please see attached NACHC letter, documenting this comment and other feedback for v3 accepted draft data elements.
The submission for this data element cites the FHIR Implementation Guide for Electronic Case Reporting (eCR), Resource Profile: Disability Status (v2.0.0: STU 2 FHIR R4) which references a value set for Disability Status OID: 2.16.840.1.113762.1.4.1099.49.
IMO has reservations regarding the technical specification for the Level 2 data element for Disability Status in the Functioning Data Class. The submission does not meet the implementation requirements for a new Level 2 Data Element for production implementation or exchange between systems.
Of particular concern is the Disability Status value set developed by the Assistant Secretary for Planning and Evaluation (ASPE) in 2011. This value set consists of 6 LOINC codes to define disability for the Disability Status use case. This value set is quite limited in scope and does not serve to capture the range of variables for disability. IMO would encourage the ONC to coordinate with ASPE to develop a more inclusive value set that better aligns with the needs of the disability community.
The "Optional Background Text / Cover Letter" field provides space for additional context or introductory information related to your comment.
If you wish to provide context, explanation, or an introduction to your comment, enter this information in the field labeled "Optional Background Text / Cover Letter." This is entirely optional and is most useful when submitting multiple related comments or when additional background would help reviewers understand your feedback.
If you are only commenting on a single data class or element, you may leave this field blank.
2. Select the Data Class
To specify which data class your comment addresses:
In the "Data Class" drop-down menu, select the appropriate data class you want to comment on.
If you are providing a general comment that is not specific to a data element, select "General" from the options. Comments with this designation will be displayed on the USCDI landing page.
Note that the Data Class field will automatically populate based on your current location in the platform:
If you are on a data class page, the field will be set to that specific data class
If you are on a data element page, the corresponding data class will be pre-selected
3. Select the Data Element
To specify which data element your comment addresses:
In the "Data Element" drop-down menu, select the specific data element you want to comment on.
The drop-down menu will display only the elements available under the data class you selected in the previous step.
You can use the search function within the drop-down to quickly locate a specific data element.
If you are commenting on the data class itself rather than a specific element, you may leave this field blank.
Note: Comments on a specific data element will appear on the respective data element page, while comments on a data class (without a specific element selected) will appear on the landing page for that data class.
Fig 1 The "Data Class" and "Data Element" dropdown menus allow users to specify the exact content they wish to comment on.
4. Optional: Propose New Data Class or Element
If you cannot find the appropriate data class or element for your comment:
Instead of clicking the "Comment On An Existing Data Class Or Element" button, click the adjacent button labeled "Propose a New Data Class or Data Element."
This will redirect you to the ONDEC (ONC New Data Element and Class) Submission System.
In the ONDEC system, follow the provided instructions to submit your proposal for a new data class or element.
Once your proposal is submitted through ONDEC, it will be reviewed separately from the commenting process.
Fig 2 The "Propose a New Data Class or Data Element" button redirects users to the ONDEC Submission System for proposing new data elements not currently available in the system.
5. Complete the Comment Form
Fill out the required fields in the comment form:
Subject: Enter a brief, descriptive title that summarizes your comment. This helps reviewers quickly understand the nature of your feedback.
Comment: In this field, provide the full details of your comment or feedback. Be as clear and specific as possible about your suggestions, concerns, or observations. Include any relevant details that support your position.
6. Optional: Add Additional Comments
If you need to comment on multiple data classes or elements:
After completing your first comment, click the link labeled "Comment on another data element" at the bottom of the form.
A new comment section will appear, allowing you to enter details for your additional comment.
For each additional comment, you must select the appropriate data class and data element from the drop-down menus.
Complete the Subject and Comment fields for your additional comment.
Repeat this process for each additional comment you wish to submit.
Fig 3 The "Comment on another data element" link enables users to create multiple comments addressing different elements within a single submission.
7. Optional: Upload Supporting Files
The platform allows you to upload supporting documentation to enhance your comment:
Locate the "File Upload" section at the bottom of the comment form.
Click to upload any files (such as PDFs or documents) that provide additional context, evidence, or clarification for your comment.
Important: If you have already entered your comments using the form fields, there is no need to upload duplicate content in PDF format. The file upload feature is intended for supplementary materials only. Please avoid uploading files that contain the same information already provided in your comment text.
Fig 4 The "File Upload" section permits users to attach supporting documentation that supplements their written comments.
8. Optional: Save and Exit
If you need to pause your work and return to complete your comment later:
Click the "Save and Exit" button at the bottom of the form.
Your comment will be saved as a draft that you can access and complete later.
When you return to the platform, you will see a red triangle with an exclamation mark next to the “Return to saved Comment” button, indicating that you have saved comments in draft status.
Click this button to continue working on your draft.
You will be taken to a review page where you can:
Select "Submit Comment" to officially submit your feedback.
Click "Edit" to return to the comment form and make changes
Select "Discard Draft" to delete the saved draft and start fresh
Fig 5 A red triangle with exclamation mark indicator appears next to the “Return to saved Comment” button when draft comments are saved in the system.
9. Review and Submit
Once you have completed your comment:
Click the "Review and Submit" button at the bottom of the form.
This will take you to a review screen displaying your comment(s) in full.
Review all information for accuracy and completeness.
On this review screen, you have three options:
Click "Submit Comment" to officially submit your feedback
Click "Edit" to return to the comment form and make changes
Click "Discard Draft" to delete the comment and start fresh
The review screen also includes a "Print" button that allows you to create a printed copy of your comments for your records.
If you choose to submit, your comment will be recorded in the system and made available for review by the appropriate stakeholders.
Fig 6 The review screen allows users to verify comment content and make any necessary modifications before final submission.
Submitted by yale-coredQMRoadmap on
CMS-CCSQ/CDC Joint USCDIv4 Priority: Disability Status
CDC and CMS recommend moving the current Disability Status data element from the Health Status Assessments data class to the Patient Demographics data class.
Federal consideration of disability data as demographic has precedent. For example, the data collection standards established by the ACA include disability alongside many variables already included in the Patient Demographics data class, such as race, ethnicity, and sex, and by extension disability can be used when using demographic factors for stratification for equity.
Collecting and transmitting data on disability in a standardized way alongside other demographic factors is vital to recognition of disability as a key component of identity and allows analysis of outcomes and conditions in an intersectional way, incorporating race/ethnicity, age, sex, and disability together for a more comprehensive understanding of patient demographics.
CMS may additionally recommend a disability assessment data element in version 5 to qualify the disability type (e.g. functional, cognitive, physical, etc.).