Submitted by nedragarrett_CDC on 2022-04-28
CDC's comment on behalf of CSTE
CSTE is supportive of inclusion in final version 3.
Data used to categorize individuals for identification, records matching, and other purposes.
Data Element |
||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Date of Death
Description
Known or estimated year, month, and day of the patient's death. | ||||||||||||||||||||||||||||||||||||||||||||||||||
|
Submitted by nedragarrett_CDC on 2022-04-28
CSTE is supportive of inclusion in final version 3.
Submitted by mitrarocca on 2021-09-30
Submitted by nedragarrett_CDC on 2021-09-28
Submitted by suchen on 2021-09-03
The patient death endpoint is a critical data point in healthcare and is valuable for not only the use cases noted in prior USCDI, but for appropriate care coordination as well. It is valuable for bidirectional transmission of the deceased date in and out of EHRs.
Use Case Example:
When death occurs at one facility, but the patient’s medical home is at another health system. A second example is when a patient expires outside of a health setting, such as at home. In such instances, local police or even Social Security may have more authoritative information on a patient’s demise. Flowing this information back into the EHR would allow the health system to offer appropriate services to family, redirect population health management efforts, etc.
Relevant technical specifications:
The standard format for death consisting of a true/false value and/or a date of death is generally universal for collection and representation of death.
Implementation of standard FHIR IGs to exchange death information for the exchange of vital records is limited.
Implementation of death as part of the core FHIR represented by the Patient.deceasedBoolean and Patient.deceasedDataTime is more widespread in production use in several different EHR/HIT systems, however death data has several external sources and historically is not reliably recorded in the EHR.
https://www.cdc.gov/nchs/nvss/modernization/partners.htm
https://www.cdc.gov/surveillance/initiatives/tracking-deaths.html
https://fhir.epic.com/Specifications?api=931
https://fhir.cerner.com/millennium/dstu2/individuals/patient/
............
This submission is made on behalf of CodeX (Common Oncology Data Elements eXtensions), a member-driven HL7 FHIR Accelerator community of professional medical societies, health systems, industry and others seeking to achieve interoperability via the mCODE (minimal Common Oncology Data Elements) standard in order to drive step-change improvements in cancer patient care and research.
Submitted by nedragarrett_CDC on 2021-04-15
• We would need to consider capturing this variable in order to support the following domain related to Paul Coverdell National Acute Stroke Program/American Hospital Association’s (AHA) Get With The Guidelines (GTWG). The goal is to reduce gaps in stroke care across the continuum of care in states with high burden populations.
• The information captured from stroke patients and those who encounter mobility related issues and are at risk of multiple hospitalizations due to post-discharge complications can help in reducing the gaps in care and to plan quality improvement efforts.
# Domain # of Variables Variable Details Required or Optional
1 Death 1 1. if patient died, date of death Required
Use-Case Justification: The most challenging part is capturing the information post-hospital discharge for acute stroke patients. A lot of the pre-hospital care is captured through National Emergency Medical Services Information System (NEMSIS), a national database that stores EMS data from the U.S. States and Territories). The follow-up elements proposed above have been developed as a part of the Paul Coverdell National Acute Stroke Program (link provided below) and captured within EHR for submission into American Heart Association’s (AHA) Get With The Guidelines (GTWG) module. The ability to extract the follow-up encounter related dates would help with the identification of gaps in post-hospital discharge date for stroke patients and plan strategies for Quality Improvement efforts.
https://www.cdc.gov/dhdsp/programs/stroke_registry.htm
USCDI_Version_2_Draft_Template for Comments_DHDSP_vFinal_04.14.2021_0.docx
Submitted by nedragarrett_CDC on 2021-04-15
The current submission by Cigna contains a definition that does not explicitly state whether this is the date pronounced dead or the date of death, and it also mentions that cause of death may be optional along with the date. Related to national guidelines for reporting deaths, the Division of Vital Statistics would recommend that this item only focus on the deceased date, with a suggested definition of “the date an individual died” or “the date a patient died”. Death is a health outcome. We want to make sure that the information collected by ‘deceased date’ is not actually the pronounced date, which may or may not be the date of death.
The cause of death information would be located within a different data class, such as a death note or clinical note. It should not be included as an option entry in patient demographics, as it has nothing to do with demographics.
An additional use case description that would be inclusive to public health should include “Public health death reporting and death certification help track characteristics of those who have died, monitor and make decisions about public health, determine life expectancy and compare death trends with other countries.”
This field is for general comments on this specific data element. 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_MortalityCommentsNCHSv5.docx
Submitted by maria.michaels… on 2021-04-06
The current USCDI definition is broad and seems to include the location and cause of death along with the date. If this is meant to include this information, then we suggest to rename the element to Death Information. However, that would not be the most granular level of data exchange and violate the USCDI definition of an USCDI Data Element. Therefore, MedMorph suggests a change in the definition to more closely relate to existing standards (FHIR and LOINC) that refers to the deceased date. It is important that the information collected for the ‘deceased date’ is not interpreted as the date pronounced dead, which may or may not be the same as the actual or presumed date of death. The date pronounced dead should be identified separately when the individual was legally pronounced dead by the medical certifier or pronouncer.
Suggested definition: The date the individual died.
Submitted by RUy on 2022-04-29
Codes, value sets and other feedback
NACHC is supportive of a standards-based concept of date and time of death; however, we feel more guidance and support would be useful to accompany this concept.
The applicable standard specified in the draft USCDIv3 submission does not identify a terminology standard but specifies a data format.
We recommend modifications in this field to specify adherence to a clinical terminology standard such as LOINC and SNOMET-CT to represent the concept of Date of Death.
NACHC suggests the use of the LOINC code 80616-6 as the appropriate term due to its use in federal programs for death reporting and certification.
NACHC is sensitive to the fact that in some use cases a date of death may be available but not a time, and so suggests that the implementation guidance in this case addresses the situation in which date but not time are available by defaulting to a null time or by linking this code to the clinical date of death code 81954-0 which specifies a date and not a date/time and could be mapped to an 80616-6 code with a null time.
Please see attached NACHC letter, documenting this comment and other feedback for v3 accepted draft data elements.
2022-04-30 NACHC USCDIv3 Letter of Support_9.pdf