Patient Demographics/Information

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

CDC's comment on behalf of CSTE

CSTE is supportive of inclusion in final version 3.

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

 

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  

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:

• In the core FHIR specification, represented by the Patient.deceased data element.
• Exchange of vital records data is covered by the Vital Records Death Reporting v0.1.0 - STU Ballot #1 IG * http://hl7.org/fhir/us/vrdr/2019May/DeathCertification.html

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

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

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

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.