Page tree
Skip to end of metadata
Go to start of metadata

Vital Records Death Reporting (VRDR)

Vital records death reporting is focused on adopting best practices for information exchange that lessen the burden on data providers (e.g., vital records offices, electronic health records, medical examiner and coroner offices, toxicology labs) while providing a seamlessly automated data feed to public health and public safety data requestors.  There are two use cases that will be tested. These use cases include Jurisdiction’s Electronic Death Registration System (EDRS) to National Center for Health Statistics (NCHS), and Medical Examiners’ / Coroners’ Case Management Systems (ME/C CMS) to EDRS workflows. A stretch goal scenario will also be tested. It will include that an EDRS send a FHIR Death Record to a Cancer Registry.

VRDR Tools and References:

  • VRDR current FHIR IG Publication
  • nightingale a synthetic EDRS to consume and parse the FHIR bundle from participating CMSs
  • Canary a VRDR FHIR validator

Technical Leads

  • EDRS to NCHS - Pete Krautscheid (MITRE)
  • CMS to NCHS - Myung Choi (GTRI)

Test scenarios for bidirectional workflow EDRS to NCHS:

The goals include testing of submission of FHIR mortality records from jurisdictions to NCHS and return of coding response messages from NCHS to jurisdictions. These tests will focus on the VRDR IG for the format of the record itself and the FHIR messaging proposal for supporting the business processes of submitting, resubmitting, and voiding records. For each test case the jurisdiction will initiate the test by sending a message to NCHS using STEVE 2.0's manual testing environment via the "other" message type and expect responses through STEVE 2.0. The following test scenarios will support progressive testing of FHIR message processing capabilities.

Jurisdictions are requested to test the following in order:

Test 1: submission of individual FHIR messages


The jurisdiction will send individual FHIR messages, each containing a death record, to NCHS. NCHS will reply with an acknowledgement message and a coding response message for each submission. Four individual records will be submitted:

  • Cancer Patient Mortality Test Case
  • Pregnant Mortality Test Case
  • Opioid Death at Home Mortality Test Case
  • Car Accident at Work Mortality Test Case


For each record, the following criteria will indicate success:

  • message is received by NCHS and a valid record is extracted
  • ack is returned to jurisdiction and references the original message
  • coded responses are returned to jurisdiction and contain the expected codes
  • coded response acks are returned to NCHS and reference the coded responses


Test 2a: submission of a valid FHIR update message changing medical information


The jurisdiction will send a FHIR update message to NCHS and NCHS will reply with the appropriate acknowledgement messages and the coding response messages. The record to submit an update for will be the Cancer Patient Mortality Test Case from Test 1 above. The updated record will change cause of death from

congestive heart failure

breast cancer

to

cardiopulmonary arrest

eclampsia

The following criteria will indicate success:

  • update message is received by NCHS and a valid record is extracted
  • update ack is returned to jurisdiction and references the update message
  • coded responses for update are returned to jurisdiction and contain the expected codes
  • coded response acks are returned to NCHS and reference the coded responses


Test 2b: submission of a valid FHIR update message changing race and ethnicity


The jurisdiction will send a FHIR update message to NCHS and NCHS will reply with the appropriate acknowledgement messages and the coding response messages. The record to submit an update for will be the Pregnant Mortality Test Case from Test 1 above. The updated record will change the race from “White, American Indian” to “Hispanic or Latino” and the ethnicity from “Salvadoran” to “Panamanian”. The following criteria will indicate success:


  • update message is received by NCHS and a valid record is extracted
  • update ack is returned to jurisdiction and references the update message
  • coded responses for update are returned to jurisdiction and contain the expected codes
  • coded response acks are returned to NCHS and reference the coded responses

 

Test 3: submission of a valid FHIR void message


The jurisdiction will send a FHIR void message to NCHS and NCHS will reply with the appropriate acknowledgement message. The record to submit a void message for will be the Opioid Death at Home Mortality Test Case from Test 1 above. The following criteria will indicate success:

  • void message is received by NCHS and references the original message
  • void ack is returned to jurisdiction and references the void message


Stretch Goal Scenario: Jurisdiction EDRS reports FHIR Death Record to Cancer Registry

Action: The EDRS prepares death record in the FHIR format and submits it to a cancer registry.

Precondition: EDRS maps death record in its internal database to the VRDR FHIR death report format.

Success Criteria: The EDRS successfully produces a death record in the FHIR format and the Cancer Registry successfully received via transport mechanism and successfully ingested.

Optional Tests for EDRS to NCHS


The above tests exercise the “happy path” of data exchange. Once those tests have been completed, it will be valuable to continue with the following optional test cases to ensure that the overall system is robust against edge cases and errors:

Test 4: submission of malformed message, with no death record


The jurisdiction will send a single FHIR message containing no death record to NCHS, NCHS will reply with the appropriate error message, and the jurisdiction will acknowledge the error. The following criteria will indicate success:

  • error is returned to jurisdiction and contains the correct error message
  • error acknowledgement is returned to NCHS and references the error message


Test 5: submission of malformed message, with an incorrectly formatted record


The jurisdiction will send a single FHIR message containing an invalid death record that cannot be processed to NCHS, NCHS will reply with the appropriate error message, and the jurisdiction will acknowledge the error. The following criteria will indicate success:

  • error is returned to jurisdiction and contains the correct error message
  • error acknowledgement is returned to NCHS and references the error message


Test 6: submission of invalid void message, missing certificate identifiers


The jurisdiction will send a single FHIR void message without the proper certificate identifiers to NCHS, NCHS will reply with the appropriate error message, and the jurisdiction will acknowledge the error. The following criteria will indicate success:

  • error is returned to jurisdiction and contains the correct error message
  • error acknowledgement is returned to NCHS and references the error message


Test 7: resending unacknowledged error messages


The jurisdiction will send a single FHIR message containing an invalid death record to NCHS, NCHS will reply with the appropriate error message, and the jurisdiction will not acknowledge the error; NCHS will resend the error message, and the jurisdiction will then acknowledge the error. The following criteria will indicate success:

  • error is returned to jurisdiction and contains the correct error message
  • after an appropriate delay, error is resent to jurisdiction
  • error acknowledgement is returned to NCHS


Test 8: submission of valid message followed by re-submission of the same valid message


The jurisdiction will send a single FHIR message containing a death record to NCHS and then resend the same message to NCHS; NCHS will reply with the appropriate acknowledgement messages and the coding response message. The following criteria will indicate success:

  • original message is received by NCHS and a valid record is extracted
  • original ack is returned to jurisdiction and references the original message
  • resubmitted message is received by NCHS and processed as a duplicate
  • resubmission ack is returned to jurisdiction and references the resubmitted message
  • a single coded response is returned to jurisdiction and contains the expected codes
  • coded response ack is returned to NCHS and references the coded response

 

Test 9:  submission of update message followed by original message (out-of-order)


The jurisdiction will generate a FHIR message and an update message, then first send the update message to NCHS followed by the original message. NCHS will reply with the appropriate acknowledgement messages and the coding response message. The following criteria will indicate success:

  • update message is received by NCHS and a valid record is extracted
  • update ack is returned to jurisdiction and references the update message
  • update coded response is returned to jurisdiction and contains the expected codes
  • coded response ack is returned to NCHS and references the coded response
  • original message is received by NCHS and processed as an obsolete message
  • original ack is returned to jurisdiction and references the original message


Test 10: submission of void message followed by original message (out-of-order)


The jurisdiction will generate a FHIR message and a void message, then first send the void message to NCHS followed by the original message. NCHS will reply with the appropriate acknowledgement messages. The following criteria will indicate success:

  • void message is received by NCHS and references the original message
  • void ack is returned to jurisdiction and references the void message
  • original message is received by NCHS and processed as an obsolete message
  • original ack is returned to jurisdiction and references the original message


Test 11: submission of void message followed by update message (un-voiding)


The jurisdiction will submit a FHIR message containing a valid death record, a void message, and then an update message; NCHS will reply with the appropriate acknowledgement messages and the coding response message. The following criteria will indicate success:


  • original message is received by NCHS and a valid record is extracted
  • original ack is returned to jurisdiction and references the original message
  • void message is received by NCHS and references the original message
  • void ack is returned to jurisdiction and references the void message
  • update message is received by NCHS and a valid record is extracted
  • update ack is returned to jurisdiction and references the update message
  • coded response is returned to jurisdiction and contains the expected codes
  • coded response ack is returned to NCHS and references the coded response


Note: Depending on timing, original coded response may or may not be sent

Test 12: submission of 10 messages


The jurisdiction will send 10 FHIR messages containing death records to NCHS and NCHS will reply with the acknowledgement messages and the coding response messages. The following criteria will indicate success:


  • 10 messages are received by NCHS and valid records are extracted
  • 10 acks are returned to jurisdiction and reference the original messages
  • 10 coded responses are returned to jurisdiction and contain the expected codes
  • 10 coded response acks are returned to NCHS and reference the coded responses


Test 13: submission of 100 messages


The jurisdiction will send 100 FHIR messages containing a death records to NCHS and NCHS will reply with the acknowledgement messages and the coding response messages. The following criteria will indicate success:

  • 100 messages are received by NCHS and valid records are extracted
  • 100 acks are returned to jurisdiction and reference the original messages
  • 100 coded responses are returned to jurisdiction and contain the expected codes
  • 100 coded response acks are returned to NCHS and reference the coded responses


Test 14: submission of 1000 messages


The jurisdiction will send 1000 FHIR messages containing a death records to NCHS and NCHS will reply with the acknowledgement messages and the coding response messages. The following criteria will indicate success:


  • 1000 messages are received by NCHS and valid records are extracted
  • 1000 acks are returned to jurisdiction and reference the original messages
  • 1000 coded responses are returned to jurisdiction and contain the expected codes
  • 1000 coded response acks are returned to NCHS and reference the coded responses


Test scenarios for CMS to EDRS workflow

This test plan will describe the support that Connect-a-thon developers testing interoperability of data flows between Medical Examiners’ / Coroners’ Case Management Systems (ME/C CMS) and Electronic Death Reporting Systems (EDRS).  There are 4 (one optional) planned Test Cases described below.  For each Test Case you will find:

  • The objective of the test case;
  • The protocol for that test;
  • What a successful outcome looks like in terms of validation and/or outputs; and
  • Required FHIR-enablement status in order to succeed / Notes for reference.


CMS and EDRS vendors in collaboration with ME/C offices and jurisdictions need to have testing instances available at the connect-a-thon to participate in testing data flows.  As workflows and business processes of data interoperability are still being refined in terms of both business requirements and development, testing will be limited to basic test cases but display important interactions between CMS and EDRS. Therefore, at this time, API patterns and any control messages such as response messages that are involved in the test plan should not be considered as standard.

Tools to be Utilized:  To support individual testing, the following tools will be provided:

  • FHIR Mortality Reporting (FORTE): A synthetic CMS called FORTE to send a mortality data FHIR bundle to the EDRS(s) of participating jurisdictions
  • Nightingale: a synthetic EDRS to consume and parse the FHIR bundle from participating CMSs
  • Canary: a VRDR FHIR validator
  • A demonstration of the testing interaction between FORTE and Nightingale

Test 1:  Validation of CMS created FHIR bundle in Canary


Objective:  A participating CMS generates the FHIR bundle using the provided testing case and validates that bundle with Canary

Protocol:

  • FHIR bundle is posted to the validation tool

Validation:

  • Canary will be the tool validating the FHIR data bundle
  • Validation tool shows the result


FHIR-enablement Status Required to Succeed / Notes:

This validation will focus on the FHIR grammar and data requirement of the submission.  Since the CMSs will not  provide all the necessary data elements required by VRDR IG profiles this FHIR bundle does not need to fully conform to the VRDR IG as. Until workflows and business processes are well-defined by the community’s stakeholders and MDI IG profiles are developed, missing VRDR data elements are acceptable.




Test 2:  EDRS Consuming and Parsing the FHIR bundle from FORTE


Objective:  FORTE will send a pre-validated FHIR bundle to the participating EDRSs’ APIs (the FHIR bundle will be created using the provided Test Case 1. The participating EDRS(s) should show the successfully parsed FHIR bundle. 

Protocol:

  • FORTE sends the FHIR bundle to EDRS API

Validation:

  • EDRS receives the bundle successfully and parses to the display.


FHIR-enablement Status Required to Succeed / Notes:

  • EDRS’ API specifications must be provided before the connect-a-thon! Sent by _____ to _________ (email address).
  • Also, the workflows and business processes have not yet been fully defined by the community. Until they are agreed upon and documented by the community, EDRS APIs will be vendor specific. Therefore, vendors/jurisdictions need to specify how the messages should be packaged and how the responses are structured before the event.


Test 3:  CMS Submitting the FHIR Bundle to Nightingale


Objective:  CMS(s) that passed Test Case 1 can send the bundle to Nightingale. Nightingale API pattern and response examples will be provided. The CMS uses the FHIR bundle that was used for Test Case 1.

Protocol:

  • CMS sends a FHIR bundle to Nightingale API
  • Nightingale receives the bundle successfully and parses to display on the dashboard

Validation:

  • CMS shows the successful response from Nightingale


FHIR-enablement Status Required to Succeed / Notes:

A successful validation of Test Case 1 is necessary to succeed.

  • On the CMS side, showing a 2xx response code will be sufficient for API transaction validation. Nightingale dashboard will be used for the content level validation (e.g. any missing data or misrepresentation of data).


Test 4: (Optional) CMS and EDRS Testing


Objective:  States that already have established protocols between CMS and EDRS can test their current interoperability using the same validation metrics used in Case Tests 1 through 3.

Protocol:

  • CMS validates a FHIR bundle with Canary used in test case 1.
  • CMS sends the FHIR bundle to EDRS API
  • EDRS receives the bundle successfully and parses to display on the dashboard

Validation:

  • CMS shows successful response


FHIR-enablement Status Required to Succeed / Notes:

Jurisdictions must already have established protocols between CMS and EDRS in place. The success status requirement would be same as Test Cases 1-3.

  • No labels