| Submitted By: Adam Bazer, MPD / Integrating the Healthcare Enterprise USA (IHE USA) | |
|---|---|
| Data Element Information | |
| Use Case Description(s) | |
| Use Case Description | Cause of death information is needed for US Standard Death Certificate which is required by the health authority in the state to be completed and certified for every person who dies in the US. When a person dies in a medical facility the death is typically certified by the attending physician. Information on death certificates, including cause of death, are important for the patient's family as well as a source of public health statistical and surveillance data. The information from death certificates when viewed collectively is used by public health authorities to monitor population health, uncover health disparities, inform policy and funding decisions, and improve outbreak detection and disaster response efforts. These data are also relied on by researchers, epidemiologists, clinicians, policymakers, and many others working to identify threats to health, find solutions, and save lives. Cause of death information is a critical component of the death certificate. Cause of death information is necessary in order to actively monitoring diseases, making decisions about public health threats, identifying trends in healthcare services utilization and other public health matters depend on accessible and accurate data. Electronic Health Records (EHRs) are a data source that can provide timely and relevant data beyond its use by health care providers. EHR data, if made more available for public health professionals and researchers, can lead to more rapid disease detection, tracking, and treatment and innovation in healthcare delivery. Cause of Death Information : For deaths that occur in a hospital cause of death information can be found within various sections of a patient's electronic health record. There are current USCDI data classes and elements that capture items that would help inform cause of death for a patient. However, it is important to capture the whole picture of information when determining cause of death. Sections or modules from an EHR will help inform the certifying physician when interoperability is gainfully supported between an EHR and a state's electronic death registration system (EDRS). The details on a US Standard death certificate are important sources of public health surveillance data and when viewed collectively can help uncover health disparities, inform policy and funding decisions, and improve outbreak and disaster response efforts. These data are relied on by researchers, epidemiologists, clinicians, policymakers, and many others working to identify problems and improve public health outcomes. MedMorph 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 Vital Records Death Reporting, Hepatitis C, Patient-Centered Clinical Research Network (PCORnet) and Cancer use cases that support the adoption of cause of death information data element. These specific use cases are described in more depth on their respective web pages. Pregnancy History: The medical examiner or physician certifying the cause and manner of death must have access to timely and comprehensive clinical information about the decedent including pregnancy status if the decedent is female. Information from an EHR can help in this process by providing timely and accurate information while potentially improving the overall efficiency of the physician’s workflow. More specifically, related to the data element on pregnancy status, suppose a female patient dies in the hospital/health setting and the attending physician has answered several questions related to the pregnancy status at the time of death. The physician now must log into the EDRS to fill out the death certificate and answer a set of similar itemized questions about the decedent's pregnancy status. This is a time-consuming process and may result in data entry errors from having to refer to multiple sources of information and systems when completing the death certificate. Having the pregnancy status-related information from the EHR available in the EDRS for reference would help expedite the data entry process. Depending on how comprehensive the information is from the EHR, it can improve the data quality and the overall user experience by not having to log into two different systems. There may or may not be a 1:1 relationship between the information in the EHR and the EDRS and the certifier may have to depend on descriptive information from the EHR to help inform the selections in the EDRS. Was Autopsy Performed: Monitoring disease and making decisions about public health threats depends on accessible and accurate data. EHRs are a data source with the potential to provide timely and relevant data beyond its use by health care providers. EHR data, if made more available for public health professionals and researchers, can lead to innovations and more rapid disease detection. The medical examiner or physician certifying the cause and manner of death must have access to timely and comprehensive clinical information about the decedent including autopsy information. Information from an EHR clarifying if an autopsy was performed can help prompt the certifier to refer to the autopsy report if one is available. If the autopsy report is saved in an EMR and can be made available in the EDRS though FHIR based interoperability, it can potentially improve the overall efficiency of the physician’s workflow. Accurate determination of the cause and manner of death on the death certificate is eventually translated into ICD-10 codes and used to generate mortality statistics for use by the social security administration, Centers for Medicare and Medicaid, and public health surveillance among others. |
| Estimated number of stakeholders capturing, accessing using or exchanging | There are 2.8 million deaths each year and a death certificate is completed for every death with about two-thirds occurring in a medical facility (e.g. inpatient, emergency department) or receiving health care (e.g. hospice, nursing home). The attending physician or other health official completes and certifies for every person who dies in the US in a medical facility or by a Medical Examiner/Coroner who relies on this information when the death occurs outside a health care setting. Cause of death is key information on the death certificate. |
| Link to use case project page | https://www.cdc.gov/csels/phio/making-ehr-data-more-available.html https://www.cdc.gov/nchs/nvss/deaths.htm https://www.cdc.gov/hepatitis/hcv/index.htm https://pcornet.org/ https://www.cdc.gov/cancer/npcr/ |
| Healthcare Aims |
|
| Maturity of Use and Technical Specifications for Data Element | |
| Applicable Standard(s) | LOINC: Summary of death note: 47046-8 Physician Summary of death note: 83796-3 Nurse Summary of death note: 84273-2 US Standard Certificate of Death Hepatitis C Case Report Form https://loinc.org/47046-8/ https://loinc.org/83796-3/ https://loinc.org/84273-2/ https://www.cdc.gov/nchs/data/dvs/DEATH11-03final-ACC.pdf https://www.cdc.gov/hepatitis/pdfs/HepatitisCaseRprtForm.pdf |
| Additional Specifications | Vital Records Death Reporting FHIR Implementation Guide 1.0: http://build.fhir.org/ig/HL7/vrdr/ Vital Records Death Reporting HL7 Version 2.6 Implementation Guide: Vital Records Death Reporting, Release 1 STU 2 - US Realm https://www.hl7.org/implement/standards/product_brief.cfm?product_id=209 Vital Records Death Reporting "" IHE Quality, Research and Public Health Technical Framework Supplement – Vital Records Death Reporting (VRDR) Revision 4.1"" https://www.ihe.net/uploadedFiles/Documents/QRPH/IHE_QRPH_Suppl_VRDR.pdf HL7 FHIR Common Data Models Harmonization FHIR Implementation Guide http://hl7.org/fhir/us/cdmh/2019May/" |
| Current Use | In limited use in test environments only |
| Supporting Artifacts |
Comment Level – in limited test environment or pilot IHE Connectathon integration profiles for death reporting (2019) - tested between electronic death registration vendors (EDRS) and NCHS. HL7 FHIR Connectathon results (Sept 2019 and 2020): Death reporting - tested between EDRS to EDRS (2019) and EDRS to NCHS (2019, 2020). ForeCare EHR Vendor found within their integration profile https://connectathon-results.ihe.net/view_result.php?rows=company&columns=actor&title=integration_profile https://confluence.hl7.org/display/FHIR/2020-09+Public+Health+Track https://product-registry.ihe.net/PR/pr/search.seam?integrationProfile=399&domain |
| Number of organizations/individuals with which this data element has been electronically exchanged | 4 |
| Supporting Artifacts |
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. The vital statistics office and the state health department as well as multiple public health agencies and organization are recipients of a death certificate information including NAPHSIS, surveillance programs and registries such as cancer registries. 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 https://connectathon-results.ihe.net/view_result.php?rows=company&columns=actor&title=integration_profile https://confluence.hl7.org/display/FHIR/2020-09+Public+Health+Track https://trifolia-fhir.lantanagroup.com/igs/lantana_hapi_r4/vrdr/death_reporting_d |
| Potential Challenges | |
| Restrictions on Standardization (e.g. proprietary code) | None |
| Restrictions on Use (e.g. licensing, user fees) | None |
| Privacy and Security Concerns | None |
| Estimate of Overall Burden | If this data is already in the EHR, then the burden to implement should be minimal because it does not require the creation of a new data element or modifying an existing one. |
| Other Implementation Challenges | Costs associated with hosting a SMART on FHIR application and associated messaging costs may not be sustainable by public health and may require a public health costing model. |
Narrative patient data relevant to the context identified by note types.
Data Element |
Information from the submission form |
|---|---|
| Pregnancy History |
Description
Whether the patient was pregnant within the past year
|
Submitted by RUy on 2022-09-30
Description of data element is disparate from use case
The description of this data element is Pregnancy History - "Whether the patient was pregnant within the past year". The use case and other information supplied in this submission does not describe the above. Instead, it focuses on maternal mortality / cause of death / death records. Pregnancy Status was previously proposed and submitted by NACHC in coordination with ACOG for consideration in USCDIv1, USCDIv2 and USCDIv3. We fully support the previous comments from ACOG, CDC, CSTE and IMO here (https://www.healthit.gov/isa/taxonomy/term/1651/uscdi-v3). In the link provided, while NACHC agrees that there is a critical need for the pregnancy status data element, the currently submitted concept profile should not ideally be referenced from IHE IPS as the submission is not harmonized with electronic case reporting (eCR) LOINC code for pregnancy status (LOINC 82810-3) with SNOMED-CT terminology bindings. The pregnancy status LOINC code that should be referenced is missing or not immediately transparent from the current USCDIv3 status. We appreciate the use case for reported pregnancy status in a patient-facing survey; however, for use in electronic health record systems (EHRs), we believe the intended concept should preferentially be the presence of a confirmed pregnancy status referenced by LOINC 82810-3, with its terminology bound answer codes (LOINC LL4129-4). This code is referenced in the federally supported Family Planning Annual Report (FPAR) program and data system from HHS, which we believe should be included as a reference in version 3. NACHC is supportive of ACOG’s position supporting HL7’s CCDA “Pregnancy Status” and related women’s health data elements as its own data class listed in Appendix C in the attached document.2022-09-30 NACHC USCDIv3 Letter of Support_4.pdf