Vital Records FHIR Messaging (VRFM) IG
2.0.0 - release

Vital Records FHIR Messaging (VRFM) IG - Local Development build (v2.0.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

## Home

Official URL: http://cdc.gov/nchs/nvss/fhir/vital-records-messaging/ImplementationGuide/vital-records-fhir-messaging | Version: 2.0.0
Active as of 2025-08-11 | Computable Name: VitalRecordsFHIRMessagingIG

### Background

Vital records jurisdictions submit information on deaths and births in their jurisdiction to the U.S. National Center for Health Statistics (NCHS). For each submission, NCHS codes all causes of death, races, and ethnicities and returns the information to the submitter.

The Vital Records Death Reporting (VRDR) and Birth and Fetal Death (BFDR) specify how to represent the information sent from vital records jurisdictions to NCHS using FHIR documents. They do not specify how such data is exchanged nor how the coding information is represented and returned to the submitter.

FHIR Messaging defines how to use FHIR in a message exchange scenario. This document describes the use of FHIR Messaging for:

1. Submission of vital records documents (birth, death, and fetal death) from vital records jurisdictions to NCHS, and
2. Return of coded content (e.g., causes of death, race and ethnicity, industry and occupation) information from NCHS to vital records jurisdictions.

This implementation guide is agnostic about the format of the content of the messages. The NCHS established business rules for the submission of birth, death, and fetal death records can be found in this IG.

This FHIR Implementation Guide supersedes a previous description of the Vital Records FHIR Messaging interface that can be found here. All maintenance of content since November 2021 is taking place in this document only and is managed via GitHub.

This document will evolve in response to community feedback as well as changes to the VRDR and BFDR IGs or business requirements. NCHS may decide, at its sole discretion, to transition this content into a FHIR Implementation Guide under HL7 auspices. This initial version of this IG under NCHS auspices is an initial step towards modernization of the exchange of Vital records data. The content with the highest value for secondary use has been included in VRCL, BFDR and VRDR.

### Requirements

#### Asynchrony

While the majority of submissions can be coded automatically, some will require nosologist intervention for manual coding. This will require asynchrony between submission and the return of coding information.

#### Death and Birth Report Submission

Vital records jurisdictions need a mechanism to submit VRDR Death Certificate Documents and BFDR Birth Certificate Documents to NCHS. Vital records jurisdictions should not be required to wait for a death report or birth report submission to be acknowledged or coded before submitting additional reports, as there may be many outstanding report submissions at any time.

Vital records jurisdictions need a mechanism to update VRDR Death Certificate Documents and BFDR Birth Certificate Doucments previously submitted to NCHS. This should not rely on patient matching algorithms, but instead use embedded identifiers for record correlation.

Vital records jurisdictions need a mechanism to void a single or a block of certificates. Voiding may target previously submitted documents or may be used to inform NCHS that a specific set of certificate numbers will not be used in the future.

#### Coding Response

NCHS needs a mechanism to send coded causes of death, as well as coded race and ethnicity information to vital records jurisdictions in response to receipt of a VRDR Death Certificate Document or BFDR Birth Certificate Document. NCHS also needs a mechanism to update previously-sent coding information. Causes of death codings may be sent separately from race and ethnicity codings. Updates to either may also be sent separately.

For a death record submission, the underlying cause of death along with contributing causes of death are coded along two axes: record and entity. Each [Cause Of Death Condition] resource in the submitted [VRDR Death Certificate Document] may result in multiple codes as described in the current TRANSAX format.

The race and ethnicity information in the submitted birth/death documents can result in multiple race and ethnicity codes in the coding response. The structure of the information returned is described in NCHS Procedures for Multiple-Race and Hispanic Origin Data: Collection, Coding, Editing, and Transmitting.

#### Delivery Status

Vital records jurisdictions need a mechanism to determine that submissions to NCHS, such as VRDR Death Certificate Documents, were successfully received by NCHS. NCHS needs a mechanism to determine that data returned to vital records jurisdictions, such as causes of death coding and race and ethnicity coding, were successfully received by vital records jurisdictions.

#### Reliability

NCHS and vital records jurisdictions need a mechanism to automatically recover from messages that are lost during exchange in either direction.

#### Error Reporting

NCHS needs a mechanism to report errors to vital records jurisdictions in response to receipt of VRDR Death Certificate Documents and BFDR Birth Certificate Documents that could not be processed. Vital records jurisdictions need a mechanism to report errors to NCHS in response to coded causes of death, race, and ethnicity that could not be processed.

### FHIR Messaging

As described earlier, the Vital Records Death Reporting (VRDR) and Birth and Fetal Death (BFDR) specify how to represent the information sent from vital records jurisdictions to NCHS using FHIR documents. The specific versions used in production and testing are described in the Implementation Notes page. However, it does not specify the mechanism that is used to exchange those FHIR documents, nor how the coded response is represented and returned to the submitter. This document describes the use of FHIR Messaging to accomplish this essential function. FHIR Messaging defines:

1. A standard MessageHeader resource that captures common message metadata including
   - An id that is useful for correlating requests and replies.
   - Source and sender information that is useful for addressing replies.
   - Destination information that is useful for routing. This can be used to route messages to NCHS and/or jurisdiction exchange via STEVE.
   - Event information that is useful for capturing the reason that a message was created.
   - Information about the subject or topic of the message that is useful for providing context.

2. Patterns for synchronous and asynchronous exchange of messages.

3. A standard FHIR process message operation and an alternate pattern for exchange of messages using the FHIR REST API for messaging.

4. A pattern for reliable message exchange over unreliable channels.

The remainder of this document describes how these capabilities can be applied to submission of death records and birth records to NCHS and the return of coded cause of death, race and ethnicity information to vital records jurisdictions.

### High Level Architecture of a FHIR Messaging Based NVSS

Figure 1: High level architecture

Figure 1 illustrates the high-level components of a FHIR messaging based NVSS, using death record submission as an example.

- Death Registration System: Jurisdiction systems that process death records

- FHIR Adaptor: Functionality to convert between native data formats and FHIR representations of that data

- FHIR Messaging Infrastructure: Functionality to:
  - Package payloads in FHIR messages
  - Send and receive FHIR messages
  - Extract payloads from FHIR messages
  - Acknowledge receipt of FHIR messages
  - Report errors if FHIR messages are malformed

- NVSS: NCHS systems for processing and coding death reports

- FHIR VRDR: A FHIR document formatted according to the Vital Record Death Reporting (VRDR) FHIR IG

- FHIR Coding or Error: A FHIR representation of either:
  - Causes of death coding, races and ethnicities coding, or both
  - An error that occurred when processing a FHIR message or its contents

The flow of information is illustrated using numbered steps as follows:

1. A jurisdiction death registration system generates a death report that is mapped to a FHIR VRDR document by a FHIR adaptor and submitted to the FHIR messaging infrastructure for delivery to NCHS.

2. The FHIR messaging infrastructure wraps the VRDR document in a FHIR message and sends it to the NCHS FHIR messaging infrastructure.

3. The NCHS FHIR messaging infrastructure validates the syntax of the received FHIR message and extracts the VRDR document. The NCHS FHIR messaging infrastructure does one of:
   - Acknowledges the message in the case that the VRDR document could be extracted successfully, or
   - Reports an error in the case that the VRDR document could not be extracted successfully.

4. The NCHS FHIR messaging infrastructure submits the VRDR document to NVSS for processing. The NVSS FHIR adaptor converts the VRDR document into the desired internal format for processing.

5. NVSS analyzes the death report:
   - If the death report can be processed, NVSS will generate two coding responses: one for the cause of death and one for the decedent race and ethnicity. ^[Cause of death coding occurs separate from the race and ethnicity coding. The coding responses are delivered separately.]
   - If the death report cannot be processed, NVSS generates an error report response.
   - In either case the NVSS FHIR adaptor maps the response to FHIR and submits it to the NCHS FHIR messaging infrastructure for delivery.

6. The NCHS FHIR messaging infrastructure wraps the response in a FHIR message and sends it to the jurisdiction FHIR messaging infrastructure.

7. The jurisdiction FHIR messaging infrastructure acknowledges the coded response or error report

8. The jurisdiction FHIR messaging infrastructure unwraps the content of the message and submits it to the jurisdiction death registration system whose FHIR adaptor converts it into the required internal format for processing.

The above sequence describes the general process for exchange of information between vital records jurisdictions and NCHS.

Note that the FHIR messaging infrastructure is logically separated from both NVSS and jurisdiction death registration systems and it is this system that provides reliable delivery of death/birth reports and coded responses (or errors) between jurisdictions and NVSS. The mechanics of reliable delivery (acknowledgements and retransmissions) are largely hidden from NVSS and jurisdiction death/birth registration systems.

### Changes Since the Initial (PDF) Version of This Guide

1. Coding and Coding Update messages have been split into Demographics (Race and Ethnicity) coding messages and Cause of Death messages.
2. All fields that are sent to jurisdictions as MRE or TRX messages are now sent as part of coding messages. These include some fields that are sent from EDRS to NCHS (so-called 'regurgigated fields').
3. Field names that are named and documented as part of the IJE, MRE, and/or TRX documentation have the same names and encodings in this guide. Please refer to the below-referenced documentation.

### CDC NCHS Documentation

- 2022 Mortality Data reference
- NCHS Instruction Manual part 8
- SuperMicar documentation(PDF, XLS)
- NCHS Procedures for Multiple-Race and Hispanic Origin Data: Collection, Coding, Editing, and Transmitting

#### Bulk Submissions

While the message exchange patterns included in this document focus on individual message exchanges, it would be possible to batch messages together to reduce the number of transfers. E.g. a single transfer from a vital records jurisdiction to NCHS could batch together a set of death record submissions, and acknowledgements for previously received coding response messages. On receipt, NVSS could process each individual message in the batch and create a new batch to return to the jurisdiction.

### Understanding this Guide

The Vital Records FHIR Messaging Implementation Guide was developed using the standard HL7 FHIR publishing tools. The page layouts and symbols are explained in the FHIR documentation. In viewing a profile page, note that there are multiple views. The "Differential Table" view represents the difference between the current profile and its base resource or profile. When interpreting this view, bear in mind that the immediate parent may not be a base FHIR resource, but it could be a US Core profile or another profile in this guide. The "Snapshot Table" represents the entire profile, with all elements.

In the event there are differences between the page renderings in this IG and the associated FHIR artifacts, the FHIR artifacts should be taken as the source of truth. In the unlikely event that an artifact's snapshot is inconsistent with its differential, the differential should be taken as the source of truth.

### Contributions

Nightingale is an open source project and welcomes all contributors. The source code for this IG is maintained in the Nightingale Github. Instead of just suggesting a change, consider creating a branch, making the change, and submitting a pull request. All of our profiling work is done in FHIR Shorthand and all narrative content in markdown (specifically, Kramdown). We suggest using the Visual Studio Code editor with the FHIR Shorthand plug-in. For more information on how to get started with IG development, visit the FSH School.

### Credits

This IG is based on the FHIR Messaging for NVSS authored by Marc Hadley (MITRE). The data element descriptions in that document have now been captured as a FHIR specification in this guide, which incorporates all of the content from the original guide. Both the original document and this Implementation Guide were developed by the MITRE corporation under contract to the Division of Vital Statistics, National Center for Health Statistics, of the Centers for Disease Control.

This IG was authored by the MITRE Corporation using FHIR Shorthand (FSH) and SUSHI, a free, open source toolchain from MITRE Corporation.

### Contact Information

Questions or comments about this IG can be directed to "Death on FHIR" zulip stream1 or the "Birth and Fetal Death on FHIR" zulip stream.

1. https://chat.fhir.org/#narrow/stream/179301-Death-on.20FHIR ↩