Information about a condition, diagnosis, or other event, situation, issue, or clinical concept that is documented.

Data Element

Applicable Vocabulary Standard(s)

Problems

  • SNOMED International, Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) U.S. Edition, September 2019 Release

Data Element

Applicable Vocabulary Standard(s)

Date of Diagnosis

Date of first determination by a qualified professional of the presence of a problem or condition affecting a patient.

Date of Resolution

Date of subsiding or termination of a symptom, problem or condition.

Problems

  • SNOMED International, Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) U.S. Edition, March 2021 Release
  • International Classification of Diseases ICD-10-CM 2021
SDOH Problems/Health Concerns

An identified Social Determinants of Health-related condition (e.g., Homelessness (finding), Lack of adequate food Z59.41, Transport too expensive (finding)). SDOH data relate to conditions in which people live, learn, work, and play and their effects on health risks and outcomes.

  • ​​​​SNOMED International, Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) U.S. Edition, March 2021 Release
  • International Classification of Diseases ICD-10-CM 2021

Data Element

Date of Onset
SNODENT

Data Element

Disease Trend

Comment

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

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.

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.

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

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

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

Log in or register to post comments