Stream: Death on FHIR
Topic: User questions on the new API for EDRS to NCHS
Brian P (Nov 30 2021 at 16:38):
(11/30/2021)
As the API is near final development it would be helpful in the documentation to everyone to summarize all available fields either sent or received by the user to help with properly loading ICD-10 cause of death and race codes back into the original EDRS record. These fields could be defined as user defined or bookkeeping fields that are sent in the original FHIR file sent to NCHS and the returned NCHS file will return these user defined fields unchanged.
Example:
I asked about sending a single primary key value in the death record to NCHS and the returned NCHS FHIR file will include this primary key from the original sent record: We will use this primary key and not reformulate the separate State, Year and ID fields from the returned death record to create that primary key. Greatly reduces potential for error when we send our primary key to NCHS and that original primary key is returned back in the NCHS file. Pete K. informed me that there already is such a field and referred me to the following:
FHIR Messaging for vital records is documented here: http://build.fhir.org/ig/nightingaleproject/vital_records_fhir_messaging_ig/branches/main/index.html
The specification for the coding response message in particular is here: http://build.fhir.org/ig/nightingaleproject/vital_records_fhir_messaging_ig/branches/main/StructureDefinition-VRDR-CodingMessage.html#tab-diff
Due to delays of either the funeral home or medical certifier completing their respective sections in EDRS, to address timeliness we often will send an incomplete EDRS death record to NCHS to meet the number of deaths reported within a certain time frame from when the death occurred and then resend the completed EDRS death record to NCHS when it later becomes available.
To address this, it would help to provide a summary of available flag or "bookkeeping" fields in FHIR, divide into 2 categories:
1) User defined flag fields sent in the original FHIR file to NCHS and returned unchanged in the return NCHS FHIR file
2) Flag fields set by NCHS and returned in the FHIR file that our API can read and provide either a report on the status of the record or take action based on the results of that status flag.
Note:
When we purposely send an incomplete death record to NCHS to address timeliness requirements, there is a certificate ID with that record. The downside of trying addressing timeliness are duplicate records are often created in EDRS and when that death record is completed and resent to NCHS, the certificate ID (Year and ID fields) might change. However name, DOB, Date of Death, sex and SSN does not change. We also need some book keeping flag to address if the death record sent to NCHS for a particular decedent was the original record or the update.
Saul Kravitz (Nov 30 2021 at 17:06):
Hi @Brian P ,
As per the current messaging IG, a record is identified by four fields:
1) jurisdiction_ID
2) cert_no
3) death_year
4) state_auxiliary_id
My reading of the IG is that these are submitted by EDRS->NCHS as parameters on the initial submission and subsequent update, void, and alias messages. They are also included in all acknowledgements, and NCHS->EDRS coding messages and updates. So you could include your local primary key for the decedent in the state_auxiliary_id field.
If the cert_no and death_year change, it might be best to void the initial message and resubmit. There is no provision for updating these fields in the interface. Updates pertain to the content of the associated death certificate document (as defined by the VRDR IG).
Currently there is nothing in the interface that indicates whether the most recent death record for a decedent is an original or updated submission other than the trail of messages (and their associated IDs), and paired acknowledgements (which reference the submitted message id). So, you'd need to track that state on your end.
Hope this helps,
Saul
@Pete Krautscheid
Michael Riley (Nov 30 2021 at 18:03):
I believe what's being talked about here as "bookkeeping flags" are the parameters used for VRDR-messaging. For example, here's the parameter set sent when submitted VRDR. http://build.fhir.org/ig/nightingaleproject/vital_records_fhir_messaging_ig/branches/main/StructureDefinition-VRDR-DeathMessageParameters.html
The issue is that you have to submit partial records to be in keeping with your reporting requirements right? There's nothing in the Messaging specification about the quality of the DeathCertificate submitted, but you could keep track locally, and when you can create the full record, send the "completed" record. If we need to track partial records on the federal side as well, then that should be a request for the spec to change. I think you can handle the policy of resubmission locally in Hawaii though.
And what Saul is saying is right as well, if you change identification in your state system, it's (probably) best to void the original messages. That means you also need to keep up with the ids generated from the messaging protocol, and correlate them to your local case system, which will help you send finalized records as updates as well.
Pete Krautscheid (Nov 30 2021 at 19:20):
@Michael Riley One thing that @Brian P asked about during office hours that he didn't ask here is how to use the Java libraries to set the state auxiliary identifier in the VRDR record. I believe it's the identifier field in this resource: http://build.fhir.org/ig/HL7/vrdr/StructureDefinition-VRDR-Death-Certificate-Reference.html. Thanks!
I'll add that, as Saul noted, there is also a field for the jurisdiction identifier as a message parameter as well (i.e., on the envelope); I don't believe the Java library currently offers support directly for the FHIR messaging layer.
Michael Riley (Nov 30 2021 at 20:33):
Correct, we need to craft the message headers semi-manually through hapi-fhir (If you've used DCD creation in VRDR_javalib it's a similar process). @Brian P
Lalit Gawad (Feb 20 2022 at 02:32):
@Pete Krautscheid @Sarah MacAdam Trying record submission API for NYC jurisdiction through Postman using provide authentication credentials token but getting 404 response instead of expected 204 response. Is there any additional authorization is required or missing api for NYC. Please see attached requests. RecordSubmission-404-Error.png record-submission-using-jsonfile.txt record-submission-using-jsoninbody.txt
Sarah MacAdam (Feb 21 2022 at 14:33):
Hi @Lalit Gawad, it looks like there is an error in the url you provided. The url for a sending a FHIR message to the NVSS FHIR API server is https://apigw.cdc.gov/OSELS/NCHS/NVSSFHIRAPI/YC/Bundles (no /record/submission at the end, you may have been thinking of the client API /record/submission endpoint) here is an example of POSTing a FHIR message to the NVSS FHIR API server in the API documentation for reference https://github.com/nightingaleproject/Reference-NCHS-API#sending-messages
Lalit Gawad (Feb 22 2022 at 01:37):
Thanks Sarah for correcting.
Last updated: Apr 12 2022 at 19:14 UTC
