Stream: FHIRcast
Topic: Sept FHIRcast virtual connectathon
Isaac Vetter (Sep 10 2020 at 13:46):
Let's share Hub urls here!
Isaac Vetter (Sep 10 2020 at 13:53):
Testing status
clients/Hubs | Bas | George/Catie | Endre (Siemens Healthineers) |
---|---|---|---|
Bas (Phillips Research) | X | ||
Juan (UMich)) | |||
Stanislav (Smart Reporting)) | X | X | X |
George/Catie (Nuance) | X | ||
Niklas (Sectra) |
Endre Berki (Sep 10 2020 at 14:00):
Hub url: https://siefhircasthub.azurewebsites.net/
Subscriptions:
* only websocket channel is supported
* returned websocket address is in the Content-Location header of the response (STU2)
Authentication: based on api keys
* Authorization header: APIKEY testApiKey1
George Kustas (Sep 10 2020 at 14:08):
Nuance Hub info:
Nuance Integration Guide:
https://connect2.nuancepowerscribe.com/psonesetup/PO-PowerCastIntegrationGuide.pdf
Hub endpoint:
https://powercast.dev.nuancepowerscribe.com/api/hub
- Hub will support Subscribe endpoint HTTP GET at base url. Any/all events are allowed. NOTE: Subscribe response does NOT confirm to STU2, but rather returns a json object with two fields: "websocket_endpoint" and "context".
- Hub will support Notify at baseurl/topic (HTTP Post) per specification
- We can use a topic of your choice, or we can choose one at the time of testing
- Nuance clients will use and respond to the following events: DiagnosticReport-open, DiagnosticReport-update, DiagnosticReport-close, userLogoff
- subscribe and notify require OAuth2 access token in Authorization header as "Bearer".
- current tokens to use (will expire 2020 -09-11 10:00:00 eastern time)
Seimens token:
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6Ik1qTkVRa014TkVVd1F6UXdRVFJFUVRBNU9UWTNRalUzT1RoQk16QXdPRUpCTXpNeVJqWkJRZyJ9.eyJodHRwczovL251YW5jZWhkcC5jb20vYWxpYXMiOiJBcHBsaWNhdGlvbnxTaWVtZW5zREkiLCJpc3MiOiJodHRwczovL251YW5jZWhkcC5hdXRoMC5jb20vIiwic3ViIjoiVVlwRnFkNHd6OWRVeG5aZzZYaVhIOXNJenBXamIwRVVAY2xpZW50cyIsImF1ZCI6Imh0dHBzOi8vbnVhbmNlaGRwLmNvbS9Qb3dlckNhc3QvSHViIiwiaWF0IjoxNTk5ODMyMjM3LCJleHAiOjE1OTk5MTg2MzcsImF6cCI6IlVZcEZxZDR3ejlkVXhuWmc2WGlYSDlzSXpwV2piMEVVIiwic2NvcGUiOiJBZG1pbiIsImd0eSI6ImNsaWVudC1jcmVkZW50aWFscyIsInBlcm1pc3Npb25zIjpbIkFkbWluIl19.MnjNMZCFFhoSlS_vabLSCkci9dwIpxj9tktp_IqMTLDBZgC2LguE-JtUUFL04Czqwqocy3GHKHAfof7ZivFj8JzuCqzYE76Y2XZ85tqwaJm0qPNYCumjddZIHdultcCqauI08yeufrGBKj9Sjer_U8FNFSNLRj-58hVefgSZcNcZbeQirQxtOn7DYnRu4zkjL796BGI8rMZzGLZtmzkYbL6QGWXB5_L5UKMKGndVb9GXMA9TRUdrsZwMyUBD-ENRHlKeFL0ZnE0EGjw6nFZQxJfEzfl9IIR5vrlCzWSH3WPOSYae54udLhh2Yagx7Cx1sUUWQF9di2ZJAtiJ1BKfxA
Philips Token:
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6Ik1qTkVRa014TkVVd1F6UXdRVFJFUVRBNU9UWTNRalUzT1RoQk16QXdPRUpCTXpNeVJqWkJRZyJ9.eyJodHRwczovL251YW5jZWhkcC5jb20vYWxpYXMiOiJBcHBsaWNhdGlvbnxQaGlsaXBzSW50ZWxsaXNwYWNlIiwiaXNzIjoiaHR0cHM6Ly9udWFuY2VoZHAuYXV0aDAuY29tLyIsInN1YiI6ImdFSVpTcWUxbm55MklzN0xSNTcxOUhoaDZ4T21xZENKQGNsaWVudHMiLCJhdWQiOiJodHRwczovL251YW5jZWhkcC5jb20vUG93ZXJDYXN0L0h1YiIsImlhdCI6MTU5OTgzMjI2MywiZXhwIjoxNTk5OTE4NjYzLCJhenAiOiJnRUlaU3FlMW5ueTJJczdMUjU3MTlIaGg2eE9tcWRDSiIsInNjb3BlIjoiQWRtaW4iLCJndHkiOiJjbGllbnQtY3JlZGVudGlhbHMiLCJwZXJtaXNzaW9ucyI6WyJBZG1pbiJdfQ.WvhFYwToVz7kmYihmMANLS96X2Szal0lfskpT66pj0kGB_covx8hE3OQs2o_Wak-v0W4dr1_nugctxlt802vDP63AZlTAN6E8nHSNglBOM9bUoMc6AfFyjSQcYB7stJ6410eMYIzhzR28P2lCNt356S9JMKvVV0FmUcJKy7I5K5StuO36G8xvQAM7y4soh7nbtnI64k_8gEUSKic8kYtIO1Tye17v5ppE_sBsInOcsIp9AovnVTW-ocUS8DMGiIKdJLddHr92Kyy_g_lQol5h5T-WEogeiUZu3RPU8fXytvN5Y1ZG2lEMoiOb0oOoiMdWebBi6_cBKYmpiVW4JtX3w
Epic token:
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6Ik1qTkVRa014TkVVd1F6UXdRVFJFUVRBNU9UWTNRalUzT1RoQk16QXdPRUpCTXpNeVJqWkJRZyJ9.eyJodHRwczovL251YW5jZWhkcC5jb20vYWxpYXMiOiJBcHBsaWNhdGlvbnxFcGljIiwiaXNzIjoiaHR0cHM6Ly9udWFuY2VoZHAuYXV0aDAuY29tLyIsInN1YiI6Ilo0R0hFblRGaU1yWktnNFBCYUFvZFBReUlwTW45Qk9HQGNsaWVudHMiLCJhdWQiOiJodHRwczovL251YW5jZWhkcC5jb20vUG93ZXJDYXN0L0h1YiIsImlhdCI6MTU5OTgzMjE3NiwiZXhwIjoxNTk5OTE4NTc2LCJhenAiOiJaNEdIRW5URmlNclpLZzRQQmFBb2RQUXlJcE1uOUJPRyIsInNjb3BlIjoiQWRtaW4iLCJndHkiOiJjbGllbnQtY3JlZGVudGlhbHMiLCJwZXJtaXNzaW9ucyI6WyJBZG1pbiJdfQ.shg49GtKt_htuUnXXx4Esqls4ZPzReHPQf5fEaLtE_ZCIJFhLa7Dshcm7Kbdpk8o02Vnxzzs4Z56NaO8QT6z5NIdVdj5zDSo6zCEoTAoJ5B2MPJfzEdUBjlqjGnFIDtqgceyDaIaWhzezoXQQNYDjMnI5XzXPBHNLtkGGJUhe-waDHI7mu8-wkpj7B58oyJgb7JB8pzGwRF3Tz7kKPaeakRwyKnEE4IvBTu5S9C7y-NvA1i6r2giNfcZ-MPIitv5lg60O7TaRkEaLz1rTBTHSPUvHOCUH0VydGNe8J14qThnniKifO2JleLoMlSJ6z0nVMmPBBKoiMzVL7uE_upWjQ
Bas van den Heuvel (Sep 10 2020 at 14:44):
Instructions on reaching the Philips FHIRcast server
URL: http://212.187.34.124:9410/api/sync/fhircast
Predefined topics include: Topic1, Topic2, Topic3, Topic4, Topic5
Isaac Vetter (Sep 10 2020 at 15:27):
FHIRcast jira issues: https://jira.hl7.org/browse/FHIR-25432?filter=12642
Isaac Vetter (Sep 10 2020 at 16:36):
FHIRcast touchbases:
- Thursday @ 4p Eastern / 10p CET - testing status/stand-up: how are you doing? What do you need?
- Friday @ 9p Eastern / 3p CET - testing status & content sharing overview and direction
Endre Berki (Sep 10 2020 at 17:07):
I will leave for today, but will check the messages here a few times.
If someone wants to play with the hub a little further based on the scenarios mentioned on the confluence page, it should work with every basic scenario except the SMART ones, and every DR context scenario except the DR-update (the hub uses an older format for this event).
Happy to hear any feedback :)
See you tomorrow.
Juan Arzac (Sep 10 2020 at 17:27):
@George Kustas, Thanks for the endpoint. I think I was able to subscribe to Topic1, though "contexts" in the response is empty. But I haven't received a confirmation at my callback endpoint yet.
Juan Arzac (Sep 10 2020 at 17:29):
@Bas van den Heuvel, I believe that I got a subscription to Topic1. Could you please trigger a notification to this topic to test it?
Stanislav Melnikov (Sep 10 2020 at 17:30):
@Bas van den Heuvel : I'm trying to subscribe for Topic1 events diagnostic-report-open/update/close from the Philips hub (Websocket). The server confirms subscription with code 202, but "Content-Location" header of the response is not filled. Do I miss something?
Update: Yes, I missed that this requirement appeared in the STU-2 draft. Sorry for the confusion.
Juan Arzac (Sep 10 2020 at 17:40):
@Bas van den Heuvel , I could subscribe using hub.channel.type: websocket, but not webhook. For webhook I get a 500 error.
Martin Bellehumeur (Visage Imaging) (Sep 10 2020 at 17:57):
(deleted)
Martin Bellehumeur (Visage Imaging) (Sep 10 2020 at 17:58):
Endre Berki said:
I will leave for today, but will check the messages here a few times.
If someone wants to play with the hub a little further based on the scenarios mentioned on the confluence page, it should work with every basic scenario except the SMART ones, and every DR context scenario except the DR-update (the hub uses an older format for this event).
Happy to hear any feedback :)See you tomorrow.
Hi, what is the format of your dr-update?
Stanislav Melnikov (Sep 10 2020 at 18:16):
I was able to subscribe events from Nuance hub as well. The server responded with 202. I expected to have a ws socket endpoint in the "Content-Location". As I realised now, it is a part of STU-2. STU-1 does not say anything about it. So everything looks OK.
Bas van den Heuvel (Sep 10 2020 at 19:57):
I'm back - lets see what happened.
Bas van den Heuvel (Sep 10 2020 at 19:57):
I'm back let's see how I can help you
Endre Berki (Sep 10 2020 at 21:30):
@Martin Bellehumeur (Visage Imaging)
I've attached the specification on which the hub was implemented. DiagnosticReport-Update.pdf
Basically the clinical context (which is Patient, ImagingStudy and DiagnosticReport in our scenario) serves as a base for clinical content (Observations). The main idea is that any Resource-Open and Resource-Close events are describing the current context, while the Resource-Update events are modifying the clinical content of the currently opened context.
Some ideas from this spec made it to the new spec George linked, and we are planning to adapt our hub to that spec. So this pdf is mostly obsolete, but it can be interesting nonetheless.
Endre Berki (Sep 10 2020 at 21:37):
Stanislav Melnikov said:
I was able to subscribe events from Nuance hub as well. The server responded with 202. I expected to have a ws socket endpoint in the "Content-Location". As I realised now, it is a part of STU-2. STU-1 does not say anything about it. So everything looks OK.
Hi, as George mentioned, the Nuance hub returns a json object in the response body. You can retrieve the wss address by querying the attribute with name "websocket_endpoint" in it. One pitfall I was struggling with when connecting to the nuance hub was that the topic id has to contain a '.' character, otherwise the wss connection will fail on the client side. @George Kustas feel free to correct me if I wrote something incorrect.
George Kustas (Sep 10 2020 at 21:50):
There is no requirement in our Hub for the topic to contain a ".". However, in production use we use PowerScribe to generate the topic which is retrievable during discovery using the PowerCast Connector on the desktop. See the Integration Guide for details. It generates the topic using: <powerscribe customer license key>.<username>. But technically, a client can use the Hub and subscribe using any topic it wants.
NOTE: The PowerCast Hub (our FHIRCast Hub) responds to a subscription in a non-standard format. This is because of our proposed context management change. We now return a json object as defined in the Integration Guide:
{
"websocket_endpoint" : "wss://....",
"contexts" : []
}
Niklas Svenzen (Sep 11 2020 at 10:00):
The websocket end point should really be going in the ContentLocation Header, can't you keep it there and send the contecxt in the body. This would reduce the amount of parsing and such for regular workflows.
Niklas Svenzen (Sep 11 2020 at 10:03):
Also, tested with your Hub Bas and I got some strange results. Initially I got a patient-open notification and when I responded with a "Ok, 200" I got an InternalServer Error back and the web socket was shut down. Am I not supposed to respond to a Notification?
Endre Berki (Sep 11 2020 at 14:06):
Niklas Svenzen said:
Also, tested with your Hub Bas and I got some strange results. Initially I got a patient-open notification and when I responded with a "Ok, 200" I got an InternalServer Error back and the web socket was shut down. Am I not supposed to respond to a Notification?
Hi, I think your response to the notification should contain the notification id as well, otherwise the hub would not be able to correlate the notification response to the notification itself, if there is more than one ongoing notification on the wss channel.
I was able to receive and react to notifications without disconnecting from Bas' hub using the following notification response format:
{
"id": <notification id>
"status": 200 (or 4xx/5xx)
}
Isaac Vetter (Sep 11 2020 at 14:36):
Guys - we're re-grouping at noon eastern/6CET/11a Central US for our much anticipated content conversation! @Niklas Svenzen - can you make this time?
Isaac Vetter (Sep 11 2020 at 14:38):
Testing status for Friday!
clients/Hubs | Bas | George/Catie | Endre (Siemens Healthineers) |
---|---|---|---|
Bas (Phillips Research) | X (with SMART launch) | X | |
Juan (UMich)) | X | X | X |
Stanislav (Smart Reporting)) | X | X | X |
George/Catie (Nuance) | X | ||
Niklas (Sectra) | |||
Endre | X | X | X |
Juan Arzac (Sep 11 2020 at 14:50):
@Isaac Vetter , I got the verification email from Bas' server.
Juan Arzac (Sep 11 2020 at 14:55):
@George Kustas @Catie Ladd , Now I'm getting a 401 Unauthorized when I try to subscribe.
Catie Ladd (Sep 11 2020 at 15:42):
I think @George Kustas updated the Auth0 keys earlier, you may need to update your key from yesterday. They are only good for 24 hrs.
Isaac Vetter (Sep 11 2020 at 19:53):
Hey Guys -- here's our track report-out. Great work! :trophy: :tshirt:
Martin Bellehumeur (Visage Imaging) (Sep 14 2020 at 06:46):
Endre Berki said:
Martin Bellehumeur (Visage Imaging)
I've attached the specification on which the hub was implemented. DiagnosticReport-Update.pdf
Basically the clinical context (which is Patient, ImagingStudy and DiagnosticReport in our scenario) serves as a base for clinical content (Observations). The main idea is that any Resource-Open and Resource-Close events are describing the current context, while the Resource-Update events are modifying the clinical content of the currently opened context.
Some ideas from this spec made it to the new spec George linked, and we are planning to adapt our hub to that spec. So this pdf is mostly obsolete, but it can be interesting nonetheless.
I think the examples are missing a parenthesis in here : . ..."context ” : [ "key": "Report"...
Last updated: Apr 12 2022 at 19:14 UTC