Problems

Problems

The Problems Data Class in USCDI separates Problems as a distinct data element from SDOH Problems/Health Concerns.  This approach to organizing the data elements is problematic because it doesn’t draw a clear distinction.  Problems, as a notion is being used for the Category as well as a data element, and as a data element Problems is differentiated from SDOH Problems/Health Concerns.  The lack of semantic clarity creates an avoidable burden for implementers. Problems are the conditions a person has. Health Concerns are the risks a person is working to reduce or the issues a person is working to address. Problems are an assertion that person has a particular condition.  Health Concerns are the focus of change that is being managed toward an agreed upon outcome. Without disambiguating these notions, by definition, the overlap and confusion creates a barrier to interoperability. A Problem can be a Health Concern, but it doesn’t necessarily need to be.  A Health Concern that is a focus of care planning, may be a factor that is not, by definition, an issue that belongs on a patient’s Problem list. Historically, a patient’s “Problem list” was the worklist of medical issues clinicians were addressing with a patient. The notion of Health Concerns came on the scene as new focus was placed on expressing and exchanging Care Plans to track a patient’s progress toward goals that have been set for their care. Now that there is widescale agreement about the important of social determinants being important to address as part of achieving better health outcomes, we need to revise our understanding of what goes on a patient’s Problem List and what issues may be the focus for improvement in a patient’s plan of care. SDOH Problems should be Problems and SDOH Health Concerns should be Health Concerns. The distinction between a person’s medical and social problems is an arbitrary and outdated practice which does not advance whole-person care. Care Plans created to achieve optimal health outcomes need to address all types of concerns. Medical as well as social concerns can be the focus of interventions designed to support patients in making progress toward their health goals.  The whole point of the SDOH movement is to integrate the thinking and treatment of SDOH issues in conjunction with other medical issues, and to recognize that SDOH issues can’t be separated from medical issues when optimate health outcomes is the goal. To reinforce and accelerate the important progress being made to incorporate care for social factors of health in concert with medical factors, the Problems Data Class should be reorganized. The Problems data element should include medical as well as SDOH Problems and the Health Concerns data element should include medical as well as SDOH health concerns. This change would support clarity and consistency that would empower and enable standardization for SDOH information as an integral part of a patient’s longitudinal health record. Currently, the Problem data element has several standardized types:

• Diagnosis, Disease, Condition
• Clinical finding, Finding of functional performance and activity, Cognitive function finding
• Finding reported by subject or history provider
• Problem, Complaint, Symptom

This list of “problem types” could be expanded to include and additional problem type or types that are relevant for issues related to social determinants of health.

USCDI V3 Comment 20220429_3.pdf

Add element for Primary caregiver of disabled person

We suggest including the SDOH measure for "Caregiver of disabled person status" that is included in the standardized ontology developed by AAPM and ASTRO.  The question uses the value set in the American Community Survey as a basis for identifying if the respondent is a primary care giver for a person with Hearing difficulty  ,Vision difficulty ,Cognitive difficulty, Ambulatory difficulty, Self-care difficulty or Independent living difficulty .  This is important to understanding ability of patients to undergo treatments that take them outside of the home, compromising their ability to provide care for the person dependent upon them. It is also a co-factor for other SDOH measures such as employment and insurance status.  Charles Mayo

Renaming the Problem Data Class

Suggest renaming the problem data class to condition, which has been proposed by the CDC colleagues as well.  A patient may have condition(s) or current treatments (medications, diet, devices) that impact their response to a newly introduced medication, device or procedure. Knowledge of these variables is essential in establishing a cause and effect relationship for an adverse event and this data class (problem) can be referenced to represent the context or details of an adverse event.  Condition resource in HL7 FHIR r4:  https://www.hl7.org/fhir/condition.html

Problems Data Class

APTA re-iterates its request that ONC clarify whether this includes symptoms like pain, numbness, shortness of breath on exertion, or functional problems like unable to climb stairs, difficulty toileting, etc.?

data of diagnosis and date of resolution

The CDC Division for Heart Disease and Stroke Prevention and the Million Hearts® 2022 Hearts national initiative (co-led by and the Centers for Medicare & Medicaid Services) uses this data as it is available for monitoring and evaluation to prevent 1 million heart attacks and strokes in 5 years. Furthermore, the CDC plans to leverage this data further in the future for surveillance and epidemiology studies if advanced through policy and available from EHRs. The Multi-state EHR-based Network for Disease Surveillance (MENDS) pilot will use electronic health record (EHR) data collected in clinical settings leading to a real-time, chronic disease surveillance model to plan and evaluate short-term outcomes of policies and program interventions. This field is for general comments on this specific data class. To submit new USCDI data classes and/or data elements, please use the USCDI ONDEC system: https://healthit.gov/ONDEC

USCDI_Version_2_Draft_Template for Comments_DHDSP_MENDS_04.15.2021_0.docx

Cerner Corporation USCDI Draft V2 Comments - Problems

Provided below are Cerner's comments on the USCDI draft V2 proposals for the Problems data class. Cerner's full public comments on the USCDI draft V2 have been posted on the USCDI general comments section.   Regarding the proposed addition of the “Date of Diagnosis” element to the Problems data class, the element necessitates further specificity as to which date/time aspects are potentially relevant to the Problems data class. There are four different date/time aspects for problems to consider: Onset Date, Asserted Date, Recorded Date (original), and Record Date (local system). We’ve used the below example scenario to define each of those four.  

• A patient schedules an appointment with Dr. Jones to discuss issues they have been having with breathing difficulty since January 2021.
  • January 2021 would be the Onset Date since it is when the condition first appeared independent of an actual diagnosis or recording in the record
• After assessing the patient, Dr. Jones diagnoses them with asthma on February 15, 2021 at 11:00 am.
  • February 15, 2021 at 11:00 am would be the Asserted Date since it is when the provider determined the diagnosis
• Dr. Jones’ nurse then records the asthma entry to the patient’s problem list later that same day at 12:30 pm.
  • February 15, 2021 at 12:30 pm would be the Recorded Date (original) as it is the first time the diagnosis has been entered into the patient’s record in any EHR system (it would also represent the Recorded Date (local system) for Dr. Jones’ EHR exclusively)
• Following the visit, Dr. Jones refers the patient to a pulmonologist, Dr. Smith, and sends a summary of care record. Before the patient’s appointment, Dr. Smith reconciles the asthma problem into her EHR system on March 1, 2021 at 9:00 am.
  • March 1, 2021 at 9:00 am would be the Recorded Date (local system) for Dr. Smith’s EHR (each subsequent system that the problem is reconciled/recorded into would have its own unique Recorded Date (local system) observation).

We note that two date/time concepts were in consideration for the USCDI v2 Draft: Date of Diagnosis and Date of Onset. The suggested definitions of both concepts appear to reflect the same aspect of Onset Date as we described. The proposed USCDI data element Date of Diagnosis seems to align more closely with the Asserted Date aspect if just looking at the name, but when considering the suggested definition, it would align more with the Onset Date aspect.   If the intent was to reflect the Asserted Date, based on ONC’s stated goal with USCDI V2 to adopt elements that are “already supported by current versions of the C-CDA and FHIR US Core implementation guide” (https://www.healthit.gov/isa/sites/isa/files/2021-01/Draft-USCDI-Version-2-January-2021-Final.pdf), this element should not be adopted with USCDI V2 because it is not currently supported in the HL7 FHIR US Core IG Condition Profile, nor in the underlying standard. This Profile currently supports date/time observation concepts for onset (which would align with our Onset Date observation concept) and recordedDate (which would align most closely with our Recorded Date (local system) observation concept) in addition to the abatement attribute, which would align with the separately proposed Date of Resolution element. Furthermore, from a clinical perspective the distinction between the Asserted Date and the Recorded Date would be insignificant.   Accordingly, we recommend that ONC withdraw the Date of Diagnosis element from USCDI V2 and wait to introduce that concept until applicable standards (such as HL7 FHIR US Core and HL7 CDA C-CDA) have discretely accounted for it (if at all, given the lack of apparent clinical significance in comparison to the Recorded Date). Instead, we recommend adopting the following elements with USCDI V2 given the alignment with current supported elements in HL7 FHIR US Core and HL7 CDA C-CDA:  

• Onset Date – this should be explicitly defined as the approximate date that the condition began for the patient (independent of when it may have been diagnosed or recorded to the record) and must also be clarified as having flexibility to be a “fuzzy” date given the reality of the concept (e.g., could be a specific calendar month or year, or a date range as opposed to needing to be a hard date). This element is already supported in both HL7 FHIR US Core (via the onset attribute), and also HL7 CDA C-CDA (via the Problem Observation (V3) entry template effectiveTime low observation).
• Recorded Date – this should be explicitly defined as the date the problem is recorded in the local system, which would be a unique date/time for each system. This is distinct from the original Recorded Date, which would be the very first time it was recorded in any system (a difficult observation to effectively/accurately trace). This element is already supported in both HL7 FHIR US Core (via the recordedDate attribute), and also HL7 CDA C-CDA (via the Problem Concern Act (V3) entry template effectiveTime low observation and/or Author Participation entry template time observation).

Regarding the proposed “Date of Resolution” element, we support its inclusion in USCDI V2. Unlike the “Date of Diagnosis” element, this element is clearer and more definite as to its intent. It is also already supported by both HL7 FHIR US Core (via the abatement attribute) and HL7 CDA C-CDA (via the Problem Observation (V3) entry template effectiveTime high observation).   Additionally, there is a need for further clarity on the intended scope of the Problems data class generally. It is currently defined very broadly as “Information about a condition, diagnosis, or other event, situation, issue, or clinical concept that is documented.” Considering there is a separate “Encounter Diagnosis” data element proposed for adoption in USCDI V2 under the Encounter Information data class, the Problems data class should be focused on ongoing conditions that warrant long term management or tracking that are identified by a clinician, independent of encounters. This would distinguish the data class from Encounter Diagnoses data element, which, as we’ve recommended elsewhere in this comment letter, should be the list of coded diagnoses for a single visit and may or may not also qualify separately as Problems. It would also distinguish it from Health Concerns data class, which is broader and inclusive of concerns from the patient or family members that may not be clinical in nature or necessarily a concern of a clinician.

Suggest renaming Problems class to Conditions

MedMorph suggests that the Problems class be renamed to Condition to align with US Core.  Conditions may not always be on the Problem List, they could be included in the Medical History. Conditions may reside in various areas of EHRs and there may not be a date associated with the condition.

We request that ONC clarify…

We request that ONC clarify whether this includes symptoms, like pain, numbness, shortness of breath on exertion, or functional problems like unable to climb stairs, difficulty toileting, etc.?

Date of Diagnosis, Date of Onset and Date of Resolution

I fully support the addition to "Problems" of: Date of Diagnosis, Date of Onset and Date of Resolution.