Condition, diagnosis, or reason for seeking medical attention.

Data Element
Date of Onset
Submitted By: Steven Lane / Sutter Health
Data Element Information
Use Case Description(s)
Use Case Description Documenting and exchanging the Date of Onset and Date of Diagnosis for diagnoses listed in the past medical history and active problem list would support the ability of public health and researchers to calculate incidence and prevalence statistics for reportable and other health conditions. For practicing clinicians and patients documenting this data will provide a more robust picture and understanding of both individual and related conditions and support a deeper understanding of the evolution of a patient's condition and overall health status over time. For those managing the health of populations knowing how long a patient has had a condition could help identify those at the greatest need for outreach/engagement and allowing resources to be directed to where they might provide the greatest value.
Estimate the breadth of applicability of the use case(s) for this data element Potentially all clinicians
Healthcare Aims
  • Improving patient experience of care (quality and/or satisfaction)
  • Improving the health of populations
  • Improving provider experience of care
Maturity of Use and Technical Specifications for Data Element
Applicable Standard(s) Date
Additional Specifications https://www.hl7.org/fhir/us/core/SearchParameter-us-core-condition-onset-date.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) n/a
Restrictions on Use (e.g. licensing, user fees) n/a
Privacy and Security Concerns n/a
Estimate of Overall Burden EHRs and other HIT systems likely all capture, at least in audit trail/metadata, the date that a diagnosis was entered into the active problem list and/or medical history list. This is quite different in meaning than the Date of Onset so an additional date field would need to be added, the data stored in the database, data added to interoperability payloads for send, receive, ingestion, etc..
Other Implementation Challenges There would be a need to develop and maintain a clear definition of how this field is to be populated as well as a determination of what types of actors should be allowed to populate or update this data field. Would also need to define how to capture and maintain a provenance history for this data element that could eventually travel with the data as it is transmitted between HIT systems. It would be appropriate for this field to accept fuzzy dates as the date of onset for a given condition may sometimes only be available as an estimate such as a year or month.

Comment

Submitted by mturchioe on

ANI's comment on USCDI v6: Date of onset

The Alliance for Nursing Informatics (ANI)  supports this inclusion as it is a key clinical data point for chronic disease management and outcomes analysis. Implementation guidance should clarify how estimated dates are handled and ensure consistent documentation practices across systems. Please see previously submitted ANI comments for additional recommendations.

Submitted by BLampkins_CSTE on

CSTE Comment - v6

CSTE supports inclusion of this data element in USCDI V6. Please see previously submitted CSTE comments for additional recommendations.

Submitted by nedragarrett_CDC on

CDC's comment on behalf of CSTE for USCDI v5

CSTE strongly encourages the inclusion of date of onset in USCDI v5. This is one of the most important data elements for public health. Date of onset often is the defining date for the beginning of a reportable condition and is used to classify cases and detect outbreaks and clusters. Exposures must be investigated in relation to the onset date. If the onset date is not captured as a distinct structural data point, public health staff must dig for it in notes or other parts of the medical record and it is inevitably vague and sometimes missing. Date of diagnosis is not the same as date of onset. Date of onset is defined as the first clinical symptom or sign for a particular condition. It would be highly beneficial if date of onset could be captured for each problem/diagnosis or condition noted in the medical record but if this is not possible it should at a minimum be noted for the primary diagnosis of the patient encounter.

Submitted by nedragarrett_CDC on

CDC's comment on behalf of CSTE for USCDI v4

CSTE strongly encourages the inclusion of date of onset in USCDI v4. This is one of the most important data elements for public health. Date of onset often is the defining date for the beginning of a reportable condition and is used to classify cases and detect outbreaks and clusters. Exposures must be investigated in relation to the onset date. If the onset date is not captured as a distinct structural data point, public health staff must dig for it in notes or other parts of the medical record and it is inevitably vague and sometimes missing. Date of diagnosis is not the same as date of onset. Date of onset is defined as the first clinical symptom or sign for a particular condition. It would be highly beneficial if date of onset could be captured for each problem/diagnosis or condition noted in the medical record but if this is not possible it should at a minimum be noted for the primary diagnosis of the patient encounter.

Submitted by aphillips@imoh… on

Level 2 Data Element: Date of Onset

IMO does not support the Date of Onset as a proposed Level 2 Data Element in USCDI V3. While it is specified as a search parameter in the FHIR US Core Implementation Guide (4.0.0 STU4 Release), it is not universally recorded in all ONC Certified HIT, and there is no standard for exchange in ONC requirements for HIT Certification

 

Submitted by nedragarrett_CDC on

CDC's Consolidated Comment

CSTE Comment:

  • CSTE strongly encourages the inclusion of date of onset in USCDI v3. This is one of the most important data elements for public health. Date of onset often is the defining date for the beginning of a reportable condition and is used to classify cases and detect outbreaks and clusters. Exposures must be investigated in relation to the onset date. If the onset date is not captured as a distinct structural data point, public health staff must dig for it in notes or other parts of the medical record and it is inevitably vague and sometimes missing. Date of diagnosis is not the same as date of onset. Date of onset is defined as the first clinical symptom or sign for a particular condition. It would be highly beneficial if date of onset could be captured for each problem/diagnosis or condition noted in the medical record but if this is not possible it should at a minimum be noted for the primary diagnosis of the patient encounter.

Submitted by nedragarrett_CDC on

Unified Comment from CDC

  • General Comment: Date of Onset currently does not  have a definition.
     
  • Proposed Definition: The estimated date, actual date or date-time the condition began.
     
  • Additional Use Cases:The Making EHR Data More Available for Research and Public Health (MedMorph) project's goal is to create a reliable, scalable, and interoperable method to get electronic health record data for multiple public health and research scenarios (use cases). MedMorph has identified Central Cancer Registry Reporting, Healthcare Surveys,  Hepatitis C Reporting, electronic Initial Case Reporting (eICR), Multiple Chronic Conditions (MCC) eCare Plan, Message Mapping Guide (MMG) for COVID 19, PCORnet, Birth and Birth Defect Reporting use cases that support the adoption of this data elements.
     
  • Applicable Standard: http://hl7.org/fhir/condition-definitions.html#Condition.onset_x
     
  • Technical Specifications using this data element:
     
  1. HL7 CDA ® Release 2 Implementation Guide: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, Release 1, DSTU Release 1.1 – US Realm: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=398
     
  2. HL7 CDA® R2 Implementation Guide: National Health Care Surveys (NHCS), R1 STU Release 3 - US Realm: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=385
     
  3. C-CDA (HL7 CDA® R2 Implementation Guide: Consolidated CDA Templates for Clinical Notes - US Realm): http://www.hl7.org/implement/standards/product_brief.cfm?product_id=492
     
  4. HL7 FHIR® Implementation Guide: Electronic Case Reporting (eCR) - US Realm: http://hl7.org/fhir/us/ecr/STU1/
     
  5. HL7 CDA® R2 Implementation Guide: Public Health Case Report, Release 2 - US Realm - the Electronic Initial Case Report (eICR): https://www.hl7.org/implement/standards/product_brief.cfm?product_id=436
     
  6. HL7 CDA® R2 Implementation Guide: Ambulatory and Hospital Healthcare Provider Reporting to Birth Defect Registries Release 1 ,
     
  7.  STU 2 -US Realm: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=428
     
  8. HL7 FHIR® Implementation Guide: Birth Defect Reporting Implementation Guide 0.1.0: https://build.fhir.org/ig/HL7/fhir-birthdefectsreporting-ig/index.html
     
  9. HL7 FHIR® Implementation Guide: Common Data Models Harmonization FHIR Implementation Guide (Release 0.1.0): http://hl7.org/fhir/us/cdmh/2019May/
     
  10. Vital Records Birth and Fetal Death Reporting - https://build.fhir.org/ig/HL7/fhir-bfdr/index.html
     
  11. HL7 Version 2.6 Implementation Guide: Vital Records Birth and Fetal Death Reporting, Release 1 STU Release 2 - US Realm https://www.hl7.org/implement/standards/product_brief.cfm?product_id=320
  • This element is used by CMS Quality Reporting and is marked Required or MustSupport in the FHIR QI Core IG

Log in or register to post comments