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
ASTP 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.
Communication Access in Health Care (CAHC) is a program of Hearing Loss Association of America (HLAA), the largest consumer organization for people with hearing loss, numbered at approximately 50 million, in the U.S. Members of the CAHC strategic team interact with a diverse group of stakeholders invested in the delivery of health care: providers, ADA coordinators, public health researchers and patients. The advocacy work of CAHC addresses the goal of facilitating effective communication for people with hearing loss.
CAHC offers strong support for moving Disability Status to Patient Demographics. This reclassification achieves the following:
--Supports efforts to ensure access and compliance with US law (Rehabilitation Act, ADA, ACA Section 1557), which require accommodations and nondiscrimination.
--Potentially reduces misclassification or undercounting of people with disabilities who aren’t captured via diagnosis codes, which change over time and may not capture the functional status of the patient.
--Facilitates comparison of outcomes by disability status, supporting research and the development of policy.
As co-founders of the Disability Health Equity Research Network (DHERN), we provide our strongest support for thePACIO Project’s proposal to move disability status to Patient Demographics.
The Disability Health Equity Research Network (DHERN) is a collaborative of over 1,000 researchers, policymakers, advocates, and communities working to advance the health equity of people with disabilities. Improving disability data collection is a core part of our work.
Collecting disability data as a demographic element is essential to identifying and addressing the barriers to healthcare that people with disabilities face.
We are in full agreement that disability status should be collected and viewed as a demographic characteristic. Disability data should be moved from the Health Assessment data class to the Patient Demographics/Information data class.
Collecting disability data as part of the Patient Demographics/Information data class aligns with federal standards outlined by the U.S. Department of Health and Human Services (HHS), is necessary to identify and address the known healthcare disparities that people with disabilities face, aligns with the National Institutes of Health (NIH) designation of people with disabilities as a health disparity population, and is an approach endorsed by the disability community.
DHERN strongly urges the adoption of PACIO’s proposal, as this change is long overdue and necessary for developing evidence-based strategies that improve healthcare access and outcomes for people with disabilities.
Bonnielin Swenor, PhD, MPH, Co-Founder, Disability Health Research Network, Professor and Director, Johns Hopkins Disability Health Research Center
Scott Landes, PhD, Co-Founder, Disability Health Research Network, Professor, Sociology Department, Syracuse University
The Disability Equity Collaborative (DEC) is a national community committed to advancing inclusion and accessibility for people with disabilities across the healthcare system. DEC brings together healthcare leaders, clinicians, researchers, professional societies, policymakers, and disability advocates to foster collaboration and drive systemic change. One of its cornerstone initiatives is the Leaders Learning Community, the largest network of healthcare disability coordinators in the United States. This group serves as the nation’s most comprehensive source of current knowledge, sharing best practices and the latest developments in disability-accessible care within U.S. healthcare systems.
By continuing to classify disability with the Health Assessment data class, we risk reinforcing the outdated view that disability is merely a medical condition requiring intervention. This framing undermines efforts to address the systemic barriers and inequities that people with disabilities face. It also perpetuates disparities by excluding disability status from the demographic framework used to measure, monitor, and address disparities across populations.
Including disability status within the Patient Demographics/Information data class aligns with best practices, which we have observed with our 50+ healthcare systems involved in the DEC Leaders Learning Community. It is also consistent with current development efforts by major EHR vendors, including Epic.
Finally, positioning disability as a Health Assessment data element rather than a Patient Demographic runs counter to the perspectives of the disability community itself. Disability is not just a matter of individual health—it is also a social and demographic identity that must be acknowledged in data, policy, and practice. People with disabilities must be fully included in these conversations and decisions. For these reasons, DEC strongly urges the adoption of PACIO’s proposal, which represents an essential step toward building a healthcare system that is equitable, accessible, and responsive to the needs and rights of people with disabilities.
Recommendation: Remove the Disability Status data element from the Health Status Assessments data class and instead add a new data element entitled Disability to the Patient Demographics/Informationdata class.
Rationale: The PACIO Project Community* recommends removing the Disability Status data element from the Health Status Assessments data class and instead add a new data element entitled, Disability to the Patient Demographics/Informationdata class. This recommendation is endorsed by both CMS and CDC as described in previous USCDI comments and the PACIO Project Community supports their view that “identifying a person with a disability does not necessarily have a bearing on how healthy a person is” or the status of one’s health. As an example, given in a CMS comment for this data class, “a person’s need to use a mobility aid, like a wheelchair, does not convey any information about why they need that aid or provide any information about their health, only that they use a mobility aid and that they may need mobility accommodations. Information surrounding a disability could be captured under other existing data elements such as Functional Status or Mental/Cognitive Status. Collecting and transmitting data on disability, such as presence or need for additional support, in a standardized way is vital to recognition of disability as a key component” and a “more comprehensive understanding of patient demographics.
Routinely collecting information under the notion of a disability as a status through a Health Status Assessment also opens the way for unintentional use of the data, namely in determining or altering a patient’s disability benefits. Using the data element in this way is at odds with routine clinical assessment of a disability, which is notionally captured as an absence of function or change in function under Functional Status or Cognitive Status. Because of the highly structured rules regarding disability, assessments of disability, and determination of disability, the routine collection of a disability assessment as described in Disability Status data element under Health Status Assessment data class may result in incorrect classification of the patient.
This recommendation aligns with how data are currently collected in PAC settings and aligns with CMS recommendations. By being able to collect information about a person’s disability as a demographic, we will be able to better delineate and prevent conflating of disability, functional status, and cognitive status, ultimately supporting better clinical decision-making and patient care.
* 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.
Recommendation:Remove the Disability Status data element from the Health Status Assessment data class and instead add a new data element entitled, “Disability” to the Patient Demographic data class.
Rationale: CMS believes that identifying a person with a disability does not necessarily hold bearing on the status of one’s health or how healthy an individual is. For example, a person’s need to use a mobility aid, such as a wheelchair, does not convey any information about why they need that aid or provide any information about their health—only that they use a mobility aid and that they may need mobility accommodations. Information surrounding a disability could be captured under other existing data elements such as Functional Status or Mental/Cognitive Status. Collecting and transmitting data on Disability Status, such as presence or need for accommodation, in a standardized way 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.
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 previous CMS and CDC submissions which reflect their view that identifying a person with a disability does not necessarily have a bearing on how healthy a person is or the status of one’s health. For example, a person’s need to use a mobility aid, like a wheelchair, does not convey any information about why they need that aid or provide any information about their health, only that they use a mobility aid and that they may need mobility accommodations. Information surrounding a disability could be captured under other existing data elements such as Functional Status or Mental/Cognitive Status.
Collecting and transmitting data on disability, such as presence or need for accommodation, in a standardized way 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.
Routinely collecting information under the notion of Disability Status as a Health Status Assessment also opens the way for unintentional use of the data, namely in determining or altering a patient’s disability benefits. Using the data element in this way is at odds with routine clinical assessment of a disability, which is notionally captured as an absence of function or change in function under Functional Status or Cognitive Status. Because of the highly structured rules regarding disability, assessments of disability, and determination of disability, the routine collection of a disability assessment as described in Disability Status under Health Status Assessment may result in incorrect classification of the patient.
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. NACHC encourages ONC to support work on a list of preferred instruments and mappings that will assist organizations in normalizing these types of data and work with other agencies that could extending disability documentations into coded standards and workflows.
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. NACHC encourages ONC to support work on a list of preferred instruments and mappings that will assist organizations in normalizing these types of data.
CMS, along with the PACIO Project and CDC, also repeats the recommendation to move the Disability Status data element from the Health Status Assessments data class to the Patient Demographics/Information data class. The rationale being 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.
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.).
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 pellertsen@aol.com on
Support of Moving Disability Status to Patient Demographics
Communication Access in Health Care (CAHC) is a program of Hearing Loss Association of America (HLAA), the largest consumer organization for people with hearing loss, numbered at approximately 50 million, in the U.S. Members of the CAHC strategic team interact with a diverse group of stakeholders invested in the delivery of health care: providers, ADA coordinators, public health researchers and patients. The advocacy work of CAHC addresses the goal of facilitating effective communication for people with hearing loss.
CAHC offers strong support for moving Disability Status to Patient Demographics. This reclassification achieves the following:
--Supports efforts to ensure access and compliance with US law (Rehabilitation Act, ADA, ACA Section 1557), which require accommodations and nondiscrimination.
--Potentially reduces misclassification or undercounting of people with disabilities who aren’t captured via diagnosis codes, which change over time and may not capture the functional status of the patient.
--Facilitates comparison of outcomes by disability status, supporting research and the development of policy.