Stream: Death on FHIR
Topic: CMS to EDRS
Myung Choi (Sep 09 2020 at 18:00):
This is a topic for interoperability between CMS and EDRS.
Michael Riley (Sep 09 2020 at 18:22):
Putting my name in here for everyone to know. We're currently working with axiell, vitalcheck, and new hampshire as acting as our consuming EDRS systems. If you are a vendor, or another EDRS who wants to participate, contact either me or myung and we'll work with you!
Myung Choi (Sep 09 2020 at 18:23):
https://docs.google.com/document/d/1m6ea84tEmKTcZrs2NwnfZEjzzwSXhrjBzKLZpFJSSgY/edit?usp=sharing
Myung Choi (Sep 09 2020 at 18:24):
The link to the cheat sheet for FORTE.
Catherine Cheney (Sep 09 2020 at 18:25):
Thank you Myung.
Myung Choi (Sep 09 2020 at 19:06):
Myung Choi said:
https://docs.google.com/document/d/1m6ea84tEmKTcZrs2NwnfZEjzzwSXhrjBzKLZpFJSSgY/edit?usp=sharing
Just to show you. You can also reply to any post to create a thread. If you mouse over on any post, you can see three vertical dots (right next to pencil). There, you can click on "Quote and reply". Then, you post will be shown like this.
Myung Choi (Sep 09 2020 at 19:11):
This is in the cheat sheet. But, here is the Canary web instance.
http://nightingale.hdap.gatech.edu:8081
Jeff Greenland (Sep 09 2020 at 22:35):
Myung or Michael, thanks for the feedback and conversation on the R3 vs. R4 stuff on the call today. Although I do not have permission to update and support R4 at this time, I do have a question. Is there a clear way to determine which format a FHIR bundle is using?
I have looked at some existing R3 bundles and compared to the R4 that Michael sent and I don't see an obvious way to decide which standard they use.
Myung Choi (Sep 10 2020 at 13:22):
Jeff Greenland said:
Myung or Michael, thanks for the feedback and conversation on the R3 vs. R4 stuff on the call today. Although I do not have permission to update and support R4 at this time, I do have a question. Is there a clear way to determine which format a FHIR bundle is using?
I have looked at some existing R3 bundles and compared to the R4 that Michael sent and I don't see an obvious way to decide which standard they use.
I in most cases use the FHIR endpoint and get capability statement (conformance statement in STU3, I think). They should have same URL <base_fhir_endpoint>/metadata. There, "fhirVersion" is required field, which has a version of FHIR. Other than that, unless walking through the resource bundles (or resource itself), there seems to be no field that we can put the version.
In fact, client is supposed to get the capability statement to find out the capability of server before proceeding to operations. Thus, the content would not have the version info. In our case (exchanging it via Email), we are basically telling what FHIR version of server generated the FHIR data.
Myung Choi (Sep 10 2020 at 13:52):
How-Tos for CMS to EDRS test cases:
Contact:
Test Case 1: Validation of CMS created FHIR bundle in Canary
- Get your FHIR bundle ready
- Goto http://nightingale.hdap.gatech.edu:8081/tool-fhir-validator
- Paste your FHIR bundle or upload it
- Submit
- See the result if you have any issues - contact us to get a help on FHIR Bundle Format.
Test Case 2: EDRS Consuming and Parsing the FHIR bundle from FORTE
- Post or reply to this message and arrange a session to set up for FHIR submission to EDRS
- If APIs were provided before the connectathon, we may have the FORTE-export to send the data. If not, we would be using Postman to send FORTE's VRDR data to the EDRS API
- EDRS can test their API internally.
- We will send VRDR FHIR bundle via Email (as we are also updating and fixing the VRDR document, we may send updated version.)
- FORTE-FHIR-server has an API that you can retrieve updated and latest version of VRDR documents.
- Please do the following steps in postman (or any browser).
- If asked to enter username and password, use username=client, password=secret
- https://apps.hdap.gatech.edu/forte-fhir-server/fhir/Composition/
- Chain search also can be used as: https://apps.hdap.gatech.edu/forte-fhir-server/fhir/Composition/?patient.identifier=122221 (use the coroner case number at row #45 of test cases)
- From the output, choose any Composition and copy Composition ID.
-
https://apps.hdap.gatech.edu/forte-fhir-server/fhir/Composition/[Composition ID]/$document
(ex: https://apps.hdap.gatech.edu/forte-fhir-server/fhir/Composition/85d802b2-0ef3-4023-8fea-aecd5ac24aa1/$document) -
This should display the VRDR document
- Default is JSON. If you want in XML, include "?_format=xml" (without quotes) at the end of $document
Test Case 3: CMS Submitting the FHIR Bundle to Nightingale
- Use the Nightingale API to send your VRDR Bundle that is validated.
- Nightingale API:
- POST http://nightingale.hdap.gatech.edu:8081/endpoints/record/<number>
- The last number needs to be between 1 and 10.
- Goto Nightingale to check if you message arrived:
- http://nightingale.hdap.gatech.edu/
- User: admin@example.com, Pw: 123456
Please use cheat sheet document for detail information:
https://docs.google.com/document/d/1m6ea84tEmKTcZrs2NwnfZEjzzwSXhrjBzKLZpFJSSgY/edit?usp=sharing
Cindy Bush (Sep 10 2020 at 14:30):
This is the Whova room for CMS to EDRS workflow for death reporting: https://whova.com/portal/webapp/hlfhi_202009/Agenda/1212529
AbdulMalik Shakir (Sep 10 2020 at 14:57):
Death reporting agenda has been updated on Confluence page. It now includes the Whova room links: https://confluence.hl7.org/pages/viewpage.action?pageId=86974178
Eric Trinh (Genesis) (Sep 10 2020 at 16:58):
hey @Myung Choi , can you send me your bundles via email? My email is etrinh@genesisinfo.com
Eric Trinh (Genesis) (Sep 10 2020 at 19:17):
@Myung Choi and @Michael Riley : couple issues i've found so far:
The meta profile for the list is http://hl7.org/fhir/us/vrdr/StructureDefinition/VRDR-Cause-of-Death-Pathway
The code for pronounced date of death should be 80616-6 instead of 81616-6
The county is set to the country element. For example: "country": "Anne Arundel" , "country": "Fulton"
Some addresses are missing county so we can’t link city to our database.
Alaina Gregory (Sep 10 2020 at 19:36):
@Pete Krautscheid Catherine (NH) sent the following: We are getting Connection failed and this for a message:
HTTP/1.1 415 Unsupported Media Type
Content-Length: 190
Content-Type: application/fhir+json; charset=utf-8
Server: Microsoft-IIS/10.0
Request-Context: appId=cid-v1:716a11cf-2eaa-4190-8c0c-4febae5b8b09
X-Request-Id: 5d7caa0c-4a7e-4682-9ff9-b7c32c709bdb
X-Content-Type-Options: nosniff
X-Powered-By: ASP.NET
Date: Thu, 10 Sep 2020 18:59:27 GMT
I am sending both the VRDR:
https://ecodnationaldev.sos.nh.gov/Public/FHIRService/FHIRService.svc/GetEDRSByID?Identifier=2019000003
and the Message:
Alaina Gregory (Sep 10 2020 at 20:00):
@Catherine Cheney - @Howard Kong from MITRE believes your problem above is due to an incorrect jurisdiction id. You are using GA and you need to use your own state abbreviation (NH).
Eric Trinh (Genesis) (Sep 10 2020 at 21:17):
@Michael Riley looks like the only issue remains is the pathway profile. It's still http://hl7.org/fhir/us/vrdr/VRDR-Cause-of-Death-Pathway
Michael Riley (Sep 10 2020 at 21:18):
Hmmph, sorry. This is controlled by the java library. I'll try creating the record again. We might have to flush the db...
Eric Trinh (Genesis) (Sep 10 2020 at 21:19):
Jeff Greenland said:
Myung or Michael, thanks for the feedback and conversation on the R3 vs. R4 stuff on the call today. Although I do not have permission to update and support R4 at this time, I do have a question. Is there a clear way to determine which format a FHIR bundle is using?
I have looked at some existing R3 bundles and compared to the R4 that Michael sent and I don't see an obvious way to decide which standard they use.
I would just use FHIR parser of each FHIR version to try to serialize it to an object. From my experience, if the bundle is not the same of version of the parser, it would throw out an exception.
Michael Riley (Sep 10 2020 at 21:27):
@Eric Trinh (Genesis) I found the issue and pushed the new test cases up into the server. Can you shoot again?
Eric Trinh (Genesis) (Sep 10 2020 at 21:28):
Michael Riley said:
Eric Trinh (Genesis) I found the issue and pushed the new test cases up into the server. Can you shoot again?
which record is this? i try https://apps.hdap.gatech.edu/forte-fhir-server/fhir/Composition/85d802b2-0ef3-4023-8fea-aecd5ac24aa1/$document but it's still same
Michael Riley (Sep 10 2020 at 21:48):
@Eric Trinh (Genesis) Ah ok i only PREVIEWED the update, didnt commit it. Can you try again?
Myung Choi (Sep 11 2020 at 02:33):
FORTE database is cleared and repopulated. Please use the following URLs to generate VRDR documents from FORTE-CMS
Coroner Case Number: 122221
https://apps.hdap.gatech.edu/forte-fhir-server/fhir/Composition/122df423-837e-41c4-8b2e-c6b0c7e9510a/$document
Coroner Case Number: 133331
https://apps.hdap.gatech.edu/forte-fhir-server/fhir/Composition/3161a89d-7665-45b3-89dd-33b23c566ebe/$document
Coroner Case Number: 144441
https://apps.hdap.gatech.edu/forte-fhir-server/fhir/Composition/2fdade99-6f4b-4a39-bc6c-62be319a596d/$document
Coroner Case Number: 155551
https://apps.hdap.gatech.edu/forte-fhir-server/fhir/Composition/b65856b2-a5a7-445d-b026-767577f554fe/$document
Eric Trinh (Genesis) (Sep 11 2020 at 12:49):
@Myung Choi @Michael Riley : new updates are much better but for case 133331, the ethnicity should be 2182-4 for Cuban, instead of 2135-2 which is Hispanic or Latino
Eric Trinh (Genesis) (Sep 11 2020 at 13:11):
the pathway profile is back to http://hl7.org/fhir/us/vrdr/VRDR-Cause-of-Death-Pathway
Michael Riley (Sep 11 2020 at 14:17):
@Eric Trinh (Genesis) I've fixed the retrograde with the CoD Pathway URL. As far as the ethnicity coding is concerned: you're talking about the "detailed" section of the ethnicity extension. We can really only generally support the ombCategory types of ethnicity: "hispanic or latino" or "not hispanic or latino" atm, we can't support all the detailed ethnicities. But for test case 133331 I went ahead and added the detailed section with code "2182-4" and ombCategory "2135-2", so that should match with your system's expectation.
Eric Trinh (Genesis) (Sep 11 2020 at 15:14):
@Michael Riley in case 133331, the race code is correct the the system is not. According to http://hl7.org/fhir/us/core/STU3.1/ValueSet-omb-race-category.html, it's supposed to be 2.16.840.1.113883.6.238, but you have 2.16.840.1.114222.4.11.876
Eric Trinh (Genesis) (Sep 11 2020 at 15:34):
@Michael Riley @Myung Choi the usual work profile is not correct
please update http://hl7.org/fhir/us/StructureDefinition/VRDR-Decedent-Usual-Work -->
http://hl7.org/fhir/us/vrdr/StructureDefinition/VRDR-Decedent-Usual-Work
Myung Choi (Sep 11 2020 at 16:04):
At 3pm, we will be talking about MDI data elements in Death Reporting 2 room. You are all welcomed to join. And, we will also be talking about API endpoints. I encourage EDRS people to join.
@Kellie Broxton and @Jeff Greenland @John Mattis @Catherine Cheney if you can join, it will be great.
Catherine Cheney (Sep 11 2020 at 16:27):
Thank you Myung.
Myung Choi (Sep 21 2020 at 14:23):
Please continue to use https://docs.google.com/document/d/1m6ea84tEmKTcZrs2NwnfZEjzzwSXhrjBzKLZpFJSSgY/edit?usp=sharing for implementers' workgroup meeting tech group.
Myung Choi (Sep 21 2020 at 14:25):
And, we will be regeneration the VRDR generation links during the demo.
Eric Trinh (Genesis) (Sep 21 2020 at 15:41):
Hey @Michael Riley @Myung Choi i'm unable to connect to your Canary web instance. Did you guys shut it down?
Myung Choi (Sep 21 2020 at 16:01):
Eric Trinh (Genesis) said:
Hey Michael Riley Myung Choi i'm unable to connect to your Canary web instance. Did you guys shut it down?
It should work. http://nightingale.hdap.gatech.edu:8081/
Eric Trinh (Genesis) (Sep 01 2021 at 19:16):
@Myung Choi @Michael Riley could you please share the URL of the latest Canary instance?
Michael Riley (Sep 07 2021 at 15:07):
@Eric Trinh (Genesis) Hey eric sorry for the late response. We moved the instance to http://canary.hdap.gatech.edu/.
Eric Trinh (Genesis) (Sep 10 2021 at 14:32):
@Michael Riley seems like the instance is a bit slow today
Michael Riley (Sep 10 2021 at 14:59):
@Eric Trinh (Genesis) Slow in processing or connecting?
Eric Trinh (Genesis) (Sep 10 2021 at 15:23):
it's slow when calculating. Sometime it doens't even respond
Eric Trinh (Genesis) (Sep 13 2021 at 14:03):
@Michael Riley @Myung Choi have you guys updated Canary instance with latest fixes from MITRE?
Michael Riley (Sep 13 2021 at 14:06):
@Eric Trinh (Genesis) Updated to v3.1.0-Preview1
Pete Krautscheid (Sep 13 2021 at 14:22):
We expect to release a new version of Canary today with the most recent bugfixes
Veronique (Sep 14 2021 at 13:51):
@Pete Krautscheid Pete, could you pin NAPHSIS. It looks like they made a last minute change to STEVE2.0 consequently the binary message sent to NCHS are missing the first correct character which for example for JSON is {.
Pete Krautscheid (Sep 14 2021 at 15:34):
Hi @Veronique, I see the email exchange and will monitor
Last updated: Apr 12 2022 at 19:14 UTC
