Data used to categorize individuals for identification, records matching, and other purposes.

Data Element
Date of Death
Description (*Please confirm or update this field for the new USCDI version*)

Known or estimated year, month, and day of the patient's death.

Submitted By: Jeff Lyall / Cigna
Data Element Information
Use Case Description(s)
Use Case Description 1. Systematic awareness and data life cycle completeness in regards to a Patient records and data maintainers (i.e. Providers and Health Plans)
2. Meaningful analytic driven guidance relating to disease tracking, patient longevity, and population trends.
3. Population studies – include or exclude members based on living status from study criteria will have more accurate outcomes and or interventions
4. Bereavement considerations impacting family members. Payers could reduce member notification to member and family or better service survivors on next steps
5. Health Plans can reduce fraud and abuse by monitoring claim activity for deceased membership.
Estimate the breadth of applicability of the use case(s) for this data element >1M+ : This would be used by multiple entities (plans , providers, health proxies) for the individuals and for population health uses.
Use Case Description Date of death is required to be captured in inpatient certified EHR systems as part of ONC's 2015 Certification
Estimate the breadth of applicability of the use case(s) for this data element All inpatient EHRs are required to capture date of death in their certified EHRs.
Link to use case project page https://www.healthit.gov/test-method/demographics
Healthcare Aims
  • Improving the health of populations
  • Reducing the cost of care
  • Improving provider experience of care
Maturity of Use and Technical Specifications for Data Element
Applicable Standard(s) Follow the DOB format
Additional Specifications HL7 USCore Implementation Guide v3.1.0 and v3.1.1 (Errata release) both allow for capturing deceased as either a Boolean (yes/no) or the date of death in the Patient profile. (Reference Link)
However, neither version of the USCore Implementation Guide state the element as a Must Support or required. USCore would need to bring the Patient profile up-to-date if the proposed Date of Death element is approved for USCDI v2.
Current Use In limited use in production environments
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 Same security measure apply to this data element.
Estimate of Overall Burden EMR capture expiration dates
ASTP Evaluation Details
Each submitted Data Element has been evaluated based on the following criteria. The overall Level classification is a composite of the maturity based on these individual criteria. This information can be used to identify areas that require additional work to raise the overall classification level and consideration for inclusion in future versions of USCDI
Criterion #1
Maturity - Current Standards		 Level 2 - Data element is represented by a terminology standard or SDO-balloted technical specification or implementation guide.
Criterion #2
Maturity - Current Use 		Level 2 - Data element is captured, stored, or accessed in multiple production EHRs or other HIT modules from more than one developer.
Criterion #3
Maturity - Current Exchange		 Level 2 - Data element is electronically exchanged between more than two production EHRs or other HIT modules of different developers using available interoperability standards.
Criterion #4
Use Case(s) - Breadth of Applicability		 Level 2 - Use cases apply to most care settings or specialties.
Evaluation Comment Significant support for adoption (15 comments total to date) across the industry, capacity to exchange (in various ways) across standards and terminologies, low implementation burden for most developers.

Comment

Submitted by RUy on

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 USCDIv3 submission page does not point to a specific concept for date of death.

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

  • It should be noted that the FHIR profile referenced in comment for DeathCertification, for example, references SNOMED-CT concepts (SCT 419099009) and not LOINC and it is expected that the USCore profile would reference the LOINC code for both patient deceased and date of death (LOINC 80816-6, 81956-5, 81954-0).
  •  

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

Submitted by mitrarocca on

Comment from FDA

  1. For the use case: adverse events reporting from EHRs, deceased death and cause of death are important outcomes of interest. 
  2. In order to conduct post-market surveillance, there is a need to capture deceased death.  (e.g. FDA Sentinel Initiative has a table to capture death: Browse Sentinel Common Data Model / sentinel_common_data_model - Sentinel Version Control System (sentinelsystem.org), PCORnet (https://pcornet.org/ ) and OMOP common data models (DEATH_DATETIME). 

 

Submitted by nedragarrett_CDC on

Unified Comment from CDC

  • Additional Use Cases: This is a standardized data item used by central cancer registries in all states. Data received through data exchange from medical facilities (e.g., laboratories, hospitals, physician EHRs, etc.) to central cancer registries for CDC and NCI’s national cancer surveillance systems, as required by law.  ( https://www.cdc.gov/cancer/npcr/)
     
  • MedMorph: https://www.cdc.gov/csels/phio/making-ehr-data-more-available.html
     
  • Death Reporting: https://www.cdc.gov/nchs/nvss/deaths.htm
     
  • Hepatitis C: https://www.cdc.gov/hepatitis/hcv/index.htm
     
  • PCORnet: https://pcornet.org/
     
  • Estimate # of Stakeholders who capture, access, use or exchange this DE:  All 50 states participate in one or more of the MedMorph public health and research use cases that exchange these death data elements.
     
  • There were approximately  1,000,000 practicing physicians (as of 2020), approximately 120,000 certified physician assistants (as of 2019) and 290,000 licensed nurse practitioners (as of 2019). Most of these licensed clinicians interact with one of these public health use cases intermittently, annually. As of 2018 AHA reported 6,146 hospitals in the US experiencing 36,353,946 admissions. Almost all of those hospitals and many of the admissions interact with one or more of the public health and or research use cases.

     
  • Electronically Exchanged: Level 2 – exchanged between 4 or more different EHR/HIT systems.  More routinely exchanged between multiple different systems can justify adding to next draft version.
     
  • Multiple public health agencies are recipients of a death certificate to include NAPHSIS, other jurisdictions, surveillance programs such as cancer and NCHS.
     
  • IHE Connectathon integration profiles for death reporting (2019) - tested between (4) electronic death registration vendors (EDRS) and NCHS.
     
  • HL7 FHIR Connectathon results (Sept 2019 and 2020): tested between (5 -7) electronic death registration vendors (EDRS) and NCHS.
     
  • NACCHO 360X Interoperability Demonstrations for Death reporting 2020 (FHIR) tested between EDRS and NCHS
     
  • This element is used by CMS Quality Reporting and is marked Required or MustSupport in the FHIR QI Core IG      
     
  • CSTE supports inclusion of this measure into USCDI v3  

Submitted by suchen on

The patient death endpoint…

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.

https://confluence.hl7.org/display/COD/CodeX+Home

Submitted by nedragarrett_CDC on

Deceased date

• 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

The current submission by…

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

Suggest changing the definition

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.

 

Log in or register to post comments