FHIR Chat · January 2022 testing event questions · Death on FHIR

Stream: Death on FHIR

Topic: January 2022 testing event questions

Pete Krautscheid (Jan 07 2022 at 01:59):

We've had some questions on the January testing event via email; I'm posting the conversation here as well for posterity and for anyone else who may find the conversation helpful.

1. Use of Test Steve 2.0 to test FHIR messaging will be like the previous Connectathon procedure in which a jurisdiction creates a death record in the FHIR message, manually upload the FHIR message to Steve 2.0 and then notifies NCHS which will retrieve the message run it through their program to generate ICD-10 cause of death and race codes and then manually load that FHIR message back to Test Steve 2.0. The jurisdiction will then log in to Test Steve 2.0 and manually download the returned FHIR message and then upload that message back into our Test EDRS system that would load or consume the FHIR message so that the ICD-10 cause of death and race codes can be extracted and stored in the corresponding death record in the Test EDRS

That’s correct, except that processing of the uploaded file should happen automatically without notifying NCHS. It’s still a good idea to track what’s happening, but the responses should be automatically generated.

2. Use of the test API in which a Test EDRS has the functionality to press a button in a jurisdiction Test EDRS for a death record in which the Test EDRS creates a FHIR message and automatically send the test FHIR message to the API with the proper formatting and authorized credentials in the header in which the API will accept the message and then automatically run the NCHS program to that review the cause of death literals and race information and then generates the ICD-10 cause of death and race codes and automatically creates the FHIR message to be sent back to the jurisdiction.

Yes, that’s correct. It will also include the acknowledgement messages. The list of messages is outlined in the test plan for each test.

3. In the same procedure but in the opposite direction, the NCHS FHIR API will send a message header with the proper credentials that a jurisdiction Test EDRS will recognize and then load that returned FHIR message to be "consumed" and the Test EDRS system will automatically identify that record and read the ICD-10 cause of death and race codes and then extract and store these codes in the proper death record. Ability for the Test EDRS to correctly load the returned FHIR message will be based on the 3 numeric fields in the FHIR message or the jurisdiction in the original FHIR message can use one of the customizable data fields such as using the jurisdiction EDRS unique primary key value and that primary key value will be retained and sent back in the returned FHIR message that can be used by the Test EDRS to correctly identify the corresponding death record.

Yes, that’s correct, with the additional detail that the return message will be pulled from the API by the EDRS; that way, the EDRS doesn’t have to set up a listening endpoint.

4. Would it also be accurate to say since the jurisdiction will be sending FHIR messages real time to the Test API, they will not be batched so the subsequent returned FHIR message with ICD-10 and race codes to be consumed back in the test EDRS will also be returned real time as well and not batched?

That’s correct, all testing with FHIR is not batched (including through STEVE). Keep in mind that there might be some delay in providing the coding response message because coding does not happen instantaneously.

Aihua Tong (Jan 11 2022 at 19:46):

I have received the following error when trying to get OAuth token with the provided curl command. I can login SAMS
{
"error": "invalid_request",
"error_description": "The resource owner could not be authenticated due to missing or invalid credentials"
}

I can get the token successfully after setting up System account

Saul Kravitz (Jan 13 2022 at 17:36):

@Pete Krautscheid @Sarah MacAdam

Pete Krautscheid (Jan 13 2022 at 17:40):

Hi @Aihua Tong, glad you were able to sort out connections during our calls.

For others who are testing, as Aihua notes it will be important to set up the system account within your SAMS account for testing. As we discussed during the most recent call, I've reached out to the SAMS team to try to understand why many of us aren't seeing the system account within the SAMS account and will post updates when I hear more.

Doug Wheeler (Jan 25 2022 at 20:47):

I am getting the following trying post a bundle...

https://apigw.cdc.gov/OSELS/NCHS/NVSSFHIRAPI/MN

{
"Error": "Authorization Failure",
"Reason": "User is not a memeber of a SAMS Activity"
}

Pete Krautscheid (Jan 25 2022 at 20:51):

Hi @Doug Wheeler , did your initial GET request to https://apigw.cdc.gov/OSELS/NCHS/NVSSFHIRAPI/MN/Bundles succeed? Are you POSTing to the same Bundles endpoint?

Doug Wheeler (Jan 25 2022 at 20:53):

I did... It returned a 200 {"resourceType":"Bundle","type":"searchset","timestamp":"2022-01-25T15:52:34.4789931-05:00"}

Is that the expected outcome? I am guessing no...

Pete Krautscheid (Jan 25 2022 at 21:03):

Yes, that's correct! That's essentially saying "Here's a bundle of all your responses"; because you don't have any responses yet it's an empty list.

Doug Wheeler (Jan 25 2022 at 21:10):

Interesting.... GET https://apigw.cdc.gov/OSELS/NCHS/NVSSFHIRAPI/ID/Bundles returns...

{
"Error":"Authorization Failure",
"Reason":"User is not a memeber of a SAMS Activity"
}

Vs GET https://apigw.cdc.gov/OSELS/NCHS/NVSSFHIRAPI/MN/Bundles returns...

{
"resourceType": "Bundle",
"type": "searchset",
"timestamp": "2022-01-25T16:09:11.8698786-05:00"
}

You must be checking my jurisdiction in the token against the jurisdiction requested.

Pete Krautscheid (Jan 25 2022 at 21:17):

Absolutely!

Doug Wheeler (Jan 26 2022 at 11:21):

I am getting the following trying post a bundle...

https://apigw.cdc.gov/OSELS/NCHS/NVSSFHIRAPI/MN

{
"Error": "Authorization Failure",
"Reason": "User is not a memeber of a SAMS Activity"
}

Pete Krautscheid (Jan 26 2022 at 12:16):

Hi @Doug Wheeler , instead of POSTing to https://apigw.cdc.gov/OSELS/NCHS/NVSSFHIRAPI/MN
you should be POSTing to https://apigw.cdc.gov/OSELS/NCHS/NVSSFHIRAPI/MN/Bundles (the same entry point as the GET request you’ve tested)

Doug Wheeler (Jan 26 2022 at 12:24):

There is a typo in the error message "User is not a memeber of a SAMS Activity".

Now that I am posting to the right endpoint I am getting a 400 Bad Request. So I will take the payload I am trying to submit and validate it via Canary.

The ball is in my court!

Thank you!

Doug Wheeler (Jan 26 2022 at 12:40):

The other thing I could have done to trouble shoot the AuthZ issues would have been to sign into my SAMS account and confirmed my account was part of the NVSS_VHIR_API MN group. Correct?

Doug Wheeler (Jan 26 2022 at 12:46):

Should I just be getting a 400 or I am I really running 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

Doug Wheeler (Jan 26 2022 at 13:59):

Our primary focus for the interoperability project has been the CMS to EDRS. We did participate in previous NCHS Connectathon(s) but the focus of these Connectathons were EDRS to NCHS via STEVE2, not via RESTful API. All three also use FHIR and leverage the VRDRJavaLib, Canary and other tools so there is a lot of synergy between the interfaces.

The new RESTful NCHS API being developed and test in this event is different but very similar to the API we developed for MR&C for the CMS to EDRS API. Both require onboarding clients and granting API access via OAuth2, both APIs are JSON encoded FHIR, etc. So, there are a lot of similarities.

But there are differences the biggest one being MR&C is not a native MOM infrastructure. The MR&C EDRS is a web application. And we did not want to have to build or buy a MOM solution to achieve interoperability.

One difference between the two APIs is the async vs. synch response to Sending of messages i.e. POST FHIR payload and the ability to get / poll for status updates on a submission. The CMS to EDRS has a similar use case, but we post a bundle containing a VRDR-Death-Certificate-Document and respond synchronously with a 200 with a FHIR message containing an Operational Outcome indicate Success, Warnings, etc. Not saying it has to be one or the other is better it just what we came up with. We audit API access but we do not persist the messages.

POST: /mrc/api/FHIR/R4/vrdr-death-certification-document

"resourceType": "Bundle",
"id": "d70f4572-5f87-4caa-9d81-f3b0d79321bd",
"meta": {
    "profile": [
        "http://hl7.org/fhir/us/vrdr/StructureDefinition/VRDR-Death-Certificate-Document"
    ]
},

I could go on and on, but I really got a lot of insight and ideas for how to improve our API moving forward and better document our API, test our API, and improve our API! Surprisingly there are more similarities than difference and I can see how the two interfaces could become more and more "standard".

The COP and NCHS has done an excellent job organizing and documenting everything!

Kudos!!!

Doug Wheeler (Jan 26 2022 at 14:25):

I got this image from one of the slides. It is not obvious to me if this is a postback or not. I don't see anything in any of the test cases suggesting a postback. It looks like 2.GET FHIR response is from NVSS > API Endpoint is a postback from NVSS to the API Endpoint I think maybe it is a GET from the API Adapter to NVSS.

image.png

Pete Krautscheid (Jan 26 2022 at 14:27):

Hi @Doug Wheeler , thanks for noting the typo in the SAMS message, I've let the SAMS team know.

For the AuthZ issues, the fact that you were able to use a token to successfully send a GET request to the https://apigw.cdc.gov/OSELS/NCHS/NVSSFHIRAPI/MN/Bundles endpoint means that your authorization step succeeded (even though you saw an empty Bundle); POSTing to that same endpoint works the same way.

A simple malformed FHIR message should not give you a 400, you should get a 204 and then a FHIR message will be returned to you shortly on the return endpoint with some details about the issue. That said, in the spirit of https://www.hl7.org/fhir/http.html#Status-Codes I think we should look into returning an OperationOutcome for 400 errors with some more information. A 400 means some other type of error is happening before FHIR processing even begins. Can you share what you're POSTing as part of your submission? Are you using curl or postman to test it out?

Thanks for describing your approach! There are definitely similarities and will look forward to hearing about lessons you've learned so we can be sure to apply them to the NVSS API as well.

Pete Krautscheid (Jan 26 2022 at 14:32):

At this time we're not using any type of POSTback, messages flow back to jurisdictions via jurisdictions initiating GETs to the Bundles endpoint. The analogy I like to use is that we have two pipes, one for Jurisdiction -> NCHS and the other for NCHS -> Jurisdiction. In both cases the interaction is initiated by the jurisdiction (e.g., the jurisdiction turns the valve on and off). The Jurisdiction -> NCHS pipe is via the jurisdiction initiating POSTs to the /Bundles endpoint and the NCHS -> Jurisdiction pipe is via the jurisdiction initiating GETs to the /Bundles endpoint (which I think is what you're saying at the end of your last message).

Doug Wheeler (Jan 26 2022 at 18:21):

In the context of the NCHS Adapter would that use the same SAMS token regardless of user or does the SAMS token also have username/profile data embedded in it?

Pete Krautscheid (Jan 26 2022 at 18:50):

The SAMS token is specifically issued for a particular user (and expires after 3600 seconds aka 1 hour)

Pete Krautscheid (Jan 26 2022 at 18:55):

Unfortunately we can't easily pull the jurisdiction info from the token because of limits in the information that the SAMS Gateway forwards to the API, though we'll do a little more investigation.

Pete Krautscheid (Jan 26 2022 at 19:11):

Hey @Doug Wheeler, related to your comments earlier today, there's a trick for using Canary to generate records that you can use for testing with the API, if your goal is just to learn more about interacting with the API:

1. Under "Message Testing" select "Connectathon FHIR VRDR Messages (Producing)"
2. Pick one of the records
3. Pick a certificate number and select your jurisdiction
4. The text box in step 2 will contain a FHIR death record for your jurisdiction!

You can also use Canary to wrap that record in a submission record:

1. Copy that record to your clipboard (the little buttons to the top right of the box should help)
2. Navigate in Canary to "Message Tools" and "Creating FHIR VRDR Messages"
3. Select "Submission" message
4. Paste the record from above into the box in step 2
5. Click Submit
6. Click Generate on the bottom of the page
7. The resulting box will contain a message containing a connectathon testing record for your jurisdiction!

Last updated: Apr 12 2022 at 19:14 UTC