Printer Friendly, PDF & Email

Patient Demographics

Data Element

Information from the submission form

Deceased date
The ability to capture, track, and monitor expiration date (hospital, home, LTC, other). Cause of death can be optional


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.  

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:

USCDI_Version_2_Draft_Template for Comments_MortalityCommentsNCHSv5.docx

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.

USCDI_Version_2_Draft_Template for Comments_DHDSP_vFinal_04.14.2021_0.docx

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

Log in or register to post comments