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.

Data Element
Disability Status
Description (*Please confirm or update this field for the new USCDI version*)

Assessments of a patient’s physical, cognitive, intellectual, or psychiatric disabilities. (e.g., vision, hearing, memory, activities of daily living)

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.72

View guidance on Applicable Vocabulary Standards and versioning.
Submitted By: Grace Cordovano / Enlightening Results
Data Element Information
Data Element Description 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 Over 61 million (roughly 1 in 4) adults in the United States live with a disability. https://www.cdc.gov/ncbddd/disabilityandhealth/infographic-disability-impacts-all.html#:~:text=61%20million%20adults%20in%20the,is%20highest%20in%20the%20South.
Healthcare Aims
  • Improving patient experience of care (quality and/or satisfaction)
  • Improving the health of populations
  • Reducing the cost of care
  • Improving provider experience of care
Maturity of Use and Technical Specifications for Data Element
Applicable Standard(s) N/A
Additional Specifications http://hl7.org/fhir/us/ecr/2021Jan/StructureDefinition-disability-status.html
Current Use 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.

Comment

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.

Submitted by bswenor on

Moving Disability Status Data Element to Patient Demographics

As co-founders of the Disability Health Equity Research Network (DHERN), we provide our strongest support for the PACIO 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

 

Submitted by Megan Morris on

Support of Moving Disability Status to Patient Demographics

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.

As part of its mission, DEC strongly endorses the PACIO Project’s proposal to move disability status to Patient Demographics. We concur with the rationale that disability status is a demographic characteristic and therefore belongs within the Patient Demographics/Information data class. This perspective is grounded in both federal standards and a robust body of research showing that people with disabilities experience profound disparities in health and healthcare outcomes. These inequities cannot be explained by functional impairment alone, but are driven by structural conditions within and beyond healthcare—paralleling the experiences of other demographic groups. Recognizing this, the National Institutes of Health (NIH) has designated people with disabilities as a health disparity population.

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.

Submitted by jpatterson@mitre.org on

PACIO recommends changing Disability Status to Disability

  • Data Class: Health Status Assessments
  • Data Element: Disability Status (Draft V6)
  • 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/Information data 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/Information data 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.

Submitted by rdillaire on

CMS-CCSQ Recommend revising the Disability Status data element

Data Element: Disability Status (USCDI v5)

  1. 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.
  2. 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.

Submitted by HCapon on

PACIO Recommendation V6 Disability Status Rename / Move

  • Data Class: Health Status Assessments  (V5)
  • Data Elements: Disability Status (V5)
  • 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. 

Submitted by nachcinformatics on

Disability Status

Health Status – Disability Status

 

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. 

Submitted by nachcinformatics on

Comments on Disability Status

Health Status – Disability Status

 

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.

Submitted by yale-coredQMRoadmap on

CMS-CCSQ/CDC Joint Support for Disability Status for USCDI v5

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.

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.).

Log in or register to post comments

FormGuide

Help

1. Optional: Background Text / Cover Letter

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:

  1. In the "Data Class" drop-down menu, select the appropriate data class you want to comment on.
  2. 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.
  3. Note that the Data Class field will automatically populate based on your current location in the platform:
    1. If you are on a data class page, the field will be set to that specific data class
    2. 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:

  1. In the "Data Element" drop-down menu, select the specific data element you want to comment on.
  2. The drop-down menu will display only the elements available under the data class you selected in the previous step.
  3. You can use the search function within the drop-down to quickly locate a specific data element.
  4. 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.
 

Data Class and Data Element

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:

  1. 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."
  2. This will redirect you to the ONDEC (ONC New Data Element and Class) Submission System.
  3. In the ONDEC system, follow the provided instructions to submit your proposal for a new data class or element.
  4. Once your proposal is submitted through ONDEC, it will be reviewed separately from the commenting process.
Propose New Data Class or Element

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:

  1. After completing your first comment, click the link labeled "Comment on another data element" at the bottom of the form.
  2. A new comment section will appear, allowing you to enter details for your additional comment.
  3. For each additional comment, you must select the appropriate data class and data element from the drop-down menus.
  4. Complete the Subject and Comment fields for your additional comment.
  5. 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.

Upload Supporting Files

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:

  1. Click the "Save and Exit" button at the bottom of the form.
  2. Your comment will be saved as a draft that you can access and complete later.
  3. 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.
  4. Click this button to continue working on your draft.
  5. You will be taken to a review page where you can:
    1. Select "Submit Comment" to officially submit your feedback.
    2. Click "Edit" to return to the comment form and make changes
    3. 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:

  1. Click the "Review and Submit" button at the bottom of the form.
  2. This will take you to a review screen displaying your comment(s) in full.
  3. Review all information for accuracy and completeness.
  4. On this review screen, you have three options: 
    1. Click "Submit Comment" to officially submit your feedback
    2. Click "Edit" to return to the comment form and make changes
    3. Click "Discard Draft" to delete the comment and start fresh
  5. The review screen also includes a "Print" button that allows you to create a printed copy of your comments for your records. 
  6. If you choose to submit, your comment will be recorded in the system and made available for review by the appropriate stakeholders.
Review and Submit

Fig 6 The review screen allows users to verify comment content and make any necessary modifications before final submission.

USCDI Comments

Close

Add a New Comment

Review comment and Submit

Edit
Comment #1
PDF, Doc, Docx
Max Size : 10 MB