Health Status Assessments

CMS-OBRHI Submission for USCDI v4

Please see the attached comments from The Centers for Medicare and Medicaid Services, Office of Burden Reduction and Health Informatics for USCDI v4. Suggestions include:

• Include function and cognition assessment results in the Health Status/Assessments data class
• Define the Health Status/Assessments Data Class and Disability Status data element more clearly
• Include data elements that pose a significant risk to patients if not exchanged during transitions of care
• CMS PAC assessment LOINCs for use as testing criteria

CMS-LTPAC USCDI v4 Submission Letter- Final_9-30-22.pdf

Functional Status, Disability Status, Personal Priorities

We support the inclusion of new data classes including functional status, disability status and mental function. Self-care, mobility, instrumental activities of daily living, living arrangements and caregiving domains are important aspects related to successful community living. In assessments such as the Functional Assessment Standardized Items (FASI) set and the IRF-PAI, MDS, and OASIS Functional Assessment and Goals, function is assessed as the assistance needed to perform everyday self-care, mobility, and other daily living tasks. This appears to align more with the proposed class of Disability status. The proposed class labeled “Functional Status” includes data elements more related underlying capacity and health status. An alternative label to “functional status” may help avoid confusion with existing terminology. We believe that locating personal priorities and goals under a data single class of "Goals" poses a risk of separating functional (i.e., disability) goals and personal priorities from the specific domains of data elements to which they relate. With regards to FASI personal priorities (listed below with relevant LOINC codes), we recommend these be located within the data class of relevant functional (i.e., disability) items.

Public comment to ONC 4-29-22.pdf

PACIO Update re: data elements in v3 Health Status data class

The PACIO Community (Post-Acute Care Interoperability) leadership wishes to update the ONC/USCDI with current efforts relating to several of the data elements under the proposed USCDI v.3 data class of Health Status (Health Concerns, Functional Status, Disability Status, and Mental Function). 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) for the general term “Functional Performance” and will test it at the May 2022 HL7 Connectathon. This IG consolidates PACIO’s prior published IGs (STU1) “Cognitive Status” and “Functional Status”. The PACIO group is also considering adding data elements of communication, swallowing, and hearing to the “Functional Performance” IG currently under development.   Currently the Functional Performance IG data structures focus on observation/assessment data. However, possibilities for future expansion could be considered as the work matures. The concept of “Functional Performance” 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 Functional Performance 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.

Health Status

In USCDI V3, Health Concerns are categorized under both Health Status and Problems, making this notion less clear for implementers.  There is a subtle relationship between Encounter Diagnoses, Problems, and Health Concerns.  When an encounter diagnosis is an issue that requires follow-up and management over a span of time, the encounter diagnosis goes onto something called a “Problem List” which practitioners use to track progress as they manage the ongoing problem which the patient was diagnosed to have. When a patient has been diagnosed with a long-term condition that includes other risks and issues to be addressed or when a patient’s social condition includes risk factors that should be addressed to ensure optimal health outcomes, these health concerns also become part of the issues addressed in a patient’s care plan.  For clarity, consider moving Health Concerns out of the Health Status category. Having it here confuses things. A health status describes the assessment of the person’s health in a certain area or dimension of wellness. Based on that health status, there may or may not be a health concern that needs to be addressed.  Not all issues that are assessed to exist need to be addressed, mitigated, or resolved.  For a variety of reasons, it may not be appropriate to make the issue a health concern that needs a plan and should be worked on to be changed.  While ICD-10 is the better single vocabulary for coding diagnoses, problems, and health concerns for which the patient will receive care services, SNOMED CT is ideally positioned to provide the clinical vocabulary for addressing clinical findings which are documented to describe a person’s health status.  In fact, many health status assessment tools use a combination of SNOMED CT and LOINC to effectively express and exchange health status assessment information.  Separating the uses of ICD-10 for diagnoses and the use of SNOMED CT for clinical findings would eliminate the requirement to translate between these two code systems. ICD-10 and SNOMED CT do not align well. Removing the need to map between when populating a single data element would offer a significant reduction in the burden to provide coded information for interoperability.    

USCDI V3 Comment 20220429_2.pdf

Data Class: Health Status

Data Class: Health Status Data Element: Health Concerns (reclassified?) Level 2 Data Element: Functional Status (see Functioning Data Class) Level 2 Data Element: Disability Status (see Functioning Data Class) Level 2 Data Element: Mental Function (see Functioning Data Class) Level 2 Data Element: Pregnancy Status (see Pregnancy Information Data Class) Data Element: Smoking Status (reclassified?) IMO would like clarification from the ONC if the Data Class for Health Status, introduced in the January 2022 Draft USCDI V3, will be eliminated in the final USCDI V3 publication in July of 2022 if the proposed Level 2 Data Class, Functioning is finalized?

Health Status

The Regenstrief Institute believes that Health Status is a critical data class to support patient care and health information exchange. We recommend including LOINC® as a terminology standard to capture all data elements associated with Health Status. The Clinical section of LOINC includes an extensive set of concepts related to health status and we also have a mechanism to include additional concepts as needed.  We are pleased that USCDI has chosen LOINC codes to represent almost all status and assessment variables.  In general, LOINC concepts related to Health Status will represent the question. For example, LOINC would be used to encode a data field “Pregnancy status” (What is the patient’s pregnancy status?)  using 82810-3, whereas other terminologies (such as SNOMED CT) could be used to encode the response (“Pregnant”, “Not pregnant”). Regenstrief also recommends re-naming smoking status to Tobacco Use Status to more effectively reflect other types of tobacco use (e.g. smokeless tobacco, e-cigarette use) that is routinely captured in patient assessments and exchanged in health IT systems.  We also recommend adding LOINC as a terminology standard to capture tobacco use status which would include smoking status.  As noted previously, the LOINC terminology is ideally suited to encode a data field that asks for a patient’s Tobacco use status, the question (for example, with a code such as 72166-2 “Tobacco smoking status” or 88031-0 “Smokeless tobacco status”).  Other terminologies such as SNOMED CT would be best suited to encode the response. In addition to this, we recommend the addition of a broader data element such as Substance Use status which capture a wider variety of substance use that is routinely captured in patient assessments and exchanged in health IT systems.

Terminal Illness

Recommended to have element for Terminal Illness Staus in this Data Class. This is a matter of interest to Next of Kin, Care Team and can help with Transition and Coordination of Care.

AAPM&R USCDI_v3 Comments

On behalf of the more than 9,000 physiatrists of the American Academy of Physical Medicine and Rehabilitation (AAPM&R), we appreciate the opportunity to provide feedback on the new data classes and elements in the Draft United States Core Data for Interoperability (USCDI) Version 3.   AAPM&R is the national medical specialty organization representing physicians who are specialists in physical medicine and rehabilitation (PM&R). PM&R physicians, also known as physiatrists, treat a wide variety of medical conditions affecting the brain, spinal cord, nerves, bones, joints, ligaments, muscles, and tendons. PM&R physicians evaluate and treat injuries, illnesses, and disability and are experts in designing comprehensive, patient-centered treatment plans. Physiatrists utilize cutting‐edge, as well as time‐tested treatments to maximize function and quality of life.   We are thrilled to see that Functional Status, Disability Status and Mental Function have been added to the Health Status data class as new data elements. These elements are vital to understanding patients and their goals in rehabilitation. Our main concern is the excruciating slow pace of interoperability within healthcare systems and practices. Mapping out data classes and elements for interoperability is hugely important, however if electronic medical record (EMR) vendors are not making this easy for healthcare systems to adopt, we fear this work will be outdated before it gets put into practice. We believe a firm emphasis on educating stakeholders on the importance and need for interoperability is needed in this space.