Stream: subscriptions
Topic: Cerner test server
David deRoode (Sep 10 2020 at 14:32):
@Avery Allen What's the base address for this server?
Avery Allen (Sep 10 2020 at 14:42):
For R4: https://fhir-open.stagingcerner.com/beta/r4/dacc6494-e336-45ad-8729-b789ff8663c6/
For R5: https://fhir-open.stagingcerner.com/beta/dacc6494-e336-45ad-8729-b789ff8663c6/
David deRoode (Sep 10 2020 at 14:43):
Thanks
Avery Allen (Sep 10 2020 at 14:46):
You can see the supported topics by making a GET to
(R5) https://fhir-open.stagingcerner.com/beta/dacc6494-e336-45ad-8729-b789ff8663c6/SubscriptionTopic
(R4) https://fhir-open.stagingcerner.com/beta/r4/dacc6494-e336-45ad-8729-b789ff8663c6/Subscription/$topic-list
David deRoode (Sep 10 2020 at 15:18):
Getting a 403 Forbidden when GETting both from r4 and r5. Anything beyond Accept application/fhir+json?
Avery Allen (Sep 10 2020 at 15:24):
I don't think there should be. Can you provide the X-Request-Id from the response headers? I can take a look in the logs to see what's going on.
David deRoode (Sep 10 2020 at 15:25):
CovbadAFkf41B_0jNYpnKDpnLwQYByRmZ0TMy9zUhGrrrttcQoYEPQ==
Avery Allen (Sep 10 2020 at 15:35):
If you've got it handy, can you post the request URL?
David deRoode (Sep 10 2020 at 15:36):
I think it was this one: https://fhir-open.stagingcerner.com/beta/dacc6494-e336-45ad-8729-b789ff8663c6/Subscription/d6340e59-1ec9-4b12-8979-eaba2def73da
David deRoode (Sep 10 2020 at 15:40):
I've tried quite a few GETs and POSTs (using Postman) over the hour, following what I thought was exemplified in Git, but no luck...always this error
Avery Allen (Sep 10 2020 at 15:44):
So the subscription id above points to an R4 subscription. I'm able to get back a subscription with:
curl --location --request GET 'https://fhir-open.stagingcerner.com/beta/r4/dacc6494-e336-45ad-8729-b789ff8663c6/Subscription/d6340e59-1ec9-4b12-8979-eaba2def73da' \
--header 'Accept: application/json'
Avery Allen (Sep 10 2020 at 15:45):
Right now the R4/R5 Subscriptions are separated so if you create a subscription via R4 then it must be retrieved through R4.
Avery Allen (Sep 10 2020 at 15:48):
Looks like there have been a couple of R5 Subscriptions created. You can see all the R5 Subscriptions via search:
curl --location --request GET 'https://fhir-open.stagingcerner.com/beta/dacc6494-e336-45ad-8729-b789ff8663c6/Subscription' \
--header 'Accept: application/json'
Search support is currently R5 only.
David deRoode (Sep 10 2020 at 15:52):
Ahh ok, that clarifies it. Thanks. For R5 though, should't GET from "https://fhir-open.stagingcerner.com/beta/dacc6494-e336-45ad-8729-b789ff8663c6/SubscriptionTopic" return a list of all SubscriptionTopics that I am allowed to subscribe to?
David deRoode (Sep 10 2020 at 15:52):
Request ID: W9bvC8SoBjQeRPihA_wTbEIpwuqik2jWTNGK0kLbXpZ7ct2Nr-b25Q==
Avery Allen (Sep 10 2020 at 15:56):
Yeah, it should. Is that where you're seeing the 403? For me,
curl --location --request GET 'https://fhir-open.stagingcerner.com/beta/dacc6494-e336-45ad-8729-b789ff8663c6/SubscriptionTopic' \
--header 'Accept: application/json'
Returns the response:
{
"resourceType": "Bundle",
"id": "d4ba92f4-f736-4e76-8374-9b6a36af7346",
"type": "searchset",
"total": 2,
"link": [
{
"relation": "self",
"url": "https://fhir-open.stagingcerner.com/beta/dacc6494-e336-45ad-8729-b789ff8663c6/SubscriptionTopic?"
}
],
"entry": [
{
"fullUrl": "https://fhir-open.stagingcerner.com/beta/dacc6494-e336-45ad-8729-b789ff8663c6/SubscriptionTopic/admission",
"resource": {
"resourceType": "SubscriptionTopic",
"id": "admission",
"meta": {
"versionId": "1",
"lastUpdated": "2020-02-02T00:00:00.000Z"
},
"url": "http://argonautproject.org/subscription-ig/SubscriptionTopic/admission",
"version": "0.4",
"title": "admission",
"status": "draft",
"experimental": true,
"date": "2019-09-05",
"description": "Admission Topic for testing framework and behavior",
"resourceTrigger": {
"description": "Beginning of a clinical encounter",
"resourceType": [
"Encounter"
],
"queryCriteria": {
"previous": "status:not=in-progress",
"current": "status:in-progress",
"requireBoth": true
}
},
"canFilterBy": [
{
"searchParamName": "patient",
"searchModifier": [
"=",
"in"
],
"documentation": "Exact match to a patient resource (reference)"
}
]
}
},
{
"fullUrl": "https://fhir-open.stagingcerner.com/beta/dacc6494-e336-45ad-8729-b789ff8663c6/SubscriptionTopic/labs",
"resource": {
"resourceType": "SubscriptionTopic",
"id": "labs",
"meta": {
"versionId": "1",
"lastUpdated": "2020-02-02T00:00:00.000Z"
},
"url": "http://fhir.cerner.com/SubscriptionTopic/labs",
"version": "0.4",
"title": "admission",
"status": "draft",
"experimental": true,
"date": "2019-09-05",
"description": "Laboratory Observations topic for testing",
"resourceTrigger": {
"description": "New and updated patient laboratory observations",
"resourceType": [
"Observation"
],
"methodCriteria": [
"create",
"update"
],
"queryCriteria": {
"previous": "category:laboratory",
"current": "category:laboratory",
"requireBoth": false
}
},
"canFilterBy": [
{
"searchParamName": "patient",
"searchModifier": [
"=",
"in"
],
"documentation": "Exact match to a patient resource (reference)"
}
]
}
}
]
}
David deRoode (Sep 10 2020 at 15:59):
Yes (this feels like a permissions thing); for me, image.png
Avery Allen (Sep 10 2020 at 16:01):
Yeah, agreed. Looking into this. Is the issue specific to SubscriptionTopic or are you seeing the same thing for Subscription as well?
David deRoode (Sep 10 2020 at 16:02):
Same for Subscription as well
Avery Allen (Sep 10 2020 at 16:06):
Are you sending a body with the GET request? I think that may be the issue. I'm able to recreate something similar to your postman screenshot if I provide a body.
David deRoode (Sep 10 2020 at 16:10):
Bingo. I assumed GET bodies were ignored, but returning a bundle now. Thanks for your help
Avery Allen (Sep 10 2020 at 16:12):
No prob. Sorry for the extremely unhelpful error page :grinning_face_with_smiling_eyes:
Spencer LaGesse (Sep 10 2020 at 17:33):
@Avery Allen Trying to post a subscription to https://fhir-open.stagingcerner.com/beta/r4/dacc6494-e336-45ad-8729-b789ff8663c6/Subscription and getting the following error back: "Expected to include: http://hl7.org/fhir/us/subscriptions-backport/StructureDefinition/backport-topic-canonical"
I think it should be looking for "http://hl7.org/fhir/**uv**/subscriptions-backport/StructureDefinition/backport-topic-canonical"
Avery Allen (Sep 10 2020 at 17:39):
Yep, I believe you're correct:
I'll get together a fix and push it out.
Avery Allen (Sep 10 2020 at 17:41):
@Gino Canessa , I think the argo test client needs an update too. It's sending the extension in the POST body as:
"extension": [
{
"url": "http://hl7.org/fhir/us/subscriptions-backport/StructureDefinition/backport-topic-canonical",
"valueCanonical": "http://argonautproject.org/subscription-ig/SubscriptionTopic/admission"
}
]
Avery Allen (Sep 10 2020 at 17:46):
Actually, I see /us/ being used throughout the POST body:
{
"resourceType": "Subscription",
"end": "2020-09-10T18:36:23.391Z",
"reason": "Client Testing",
"channel": {
"endpoint": "https://client.subscriptions.argo.run/Endpoints/0860ace4-a750-45d5-a615-91f37c9f94f9",
"payload": "application/fhir+json",
"_payload": {
"extension": [
{
"url": "http://hl7.org/fhir/us/subscriptions-backport/StructureDefinition/backport-payload-content",
"valueCode": "id-only"
}
]
},
"type": "rest-hook",
"extension": [
{
"url": "http://hl7.org/fhir/us/subscriptions-backport/StructureDefinition/backport-heartbeat-period",
"valueUnsignedInt": 60
}
]
},
"status": "requested",
"criteria": "Encounter?patient=1316024",
"extension": [
{
"url": "http://hl7.org/fhir/us/subscriptions-backport/StructureDefinition/backport-topic-canonical",
"valueCanonical": "http://argonautproject.org/subscription-ig/SubscriptionTopic/admission"
}
]
}
Based on the IG I think these all need to be updated
Jenni Syed (Sep 10 2020 at 17:49):
The canonicals don't have to resolve, and I think this was a publishing error
Jenni Syed (Sep 10 2020 at 17:49):
the "source of truth" for what they are should be in the IG
Gino Canessa (Sep 10 2020 at 17:50):
Yep, thanks for the catch - forgot to update the implementation when it changed. I've pushed the client and realized I need to update the server too, so it make act funny until that gets updated too.
Jenni Syed (Sep 10 2020 at 17:50):
So, what is UV?
Jenni Syed (Sep 10 2020 at 17:50):
(b/c Jira also hates this)
David deRoode (Sep 10 2020 at 17:52):
Universal realm?
Gino Canessa (Sep 10 2020 at 17:54):
UV is universal realm. Originally had US (argonaut habit) but realized this isn't US-limited.
David deRoode (Sep 10 2020 at 17:54):
@Avery Allen The backport-payload-content profile should support all three payload content types, but I'm getting an error from the r4 cerner server when trying to create a new subscription with a valueCode=full-resource on this extension: ""Expected value to be one of: empty, id-only""
Gino Canessa (Sep 10 2020 at 17:55):
The backport defines all the content types, it does not mandate that they are all supported.
Avery Allen (Sep 10 2020 at 17:55):
Yeah, our test implementation only supports empty and id-only
David deRoode (Sep 10 2020 at 17:57):
Got it- I'm guessing a similar rationale for the error on criteria (ie Cerner test implmentation only supports criteria within a patient-specific Encounter context)?
Jenni Syed (Sep 10 2020 at 17:58):
sending full alerts actually has some security considerations
Jenni Syed (Sep 10 2020 at 17:59):
(in a real world server)
Avery Allen (Sep 10 2020 at 18:01):
Yeah, there's a pretty limited subset of the overall functionality we have working.
Also as an aside, the error response you're getting back is probably a 400. If we had true support for Subscription, these would likely be 422s instead since what you're asking the server to do is supported by the spec, just not by us.
Avery Allen (Sep 10 2020 at 18:02):
The patient specific Encounter context limitation ties in with the messages used to trigger notifications.
David deRoode (Sep 10 2020 at 18:03):
Read my mind. Thanks for confirming
Gino Canessa (Sep 10 2020 at 18:10):
Alright, client and server should both be updated to use UV realm now - please let me know if you run into anything else!
Ted Peck (Sep 10 2020 at 18:15):
I'll be trying to submit an R5 subscription in a little while, I assume these uv updates apply for the R5 server also?
Avery Allen (Sep 10 2020 at 18:18):
The extensions are just used as part of the R4 Backport, so you shouldn't need to worry about them with R5
Spencer LaGesse (Sep 10 2020 at 18:20):
@Gino Canessa I'm getting "Invalid subscription" when trying to post an R4 backport subscription to https://server.subscriptions.argo.run/Subscription. Can you help identify what is wrong there?
Gino Canessa (Sep 10 2020 at 18:23):
Hi @Spencer LaGesse , someone pointed out the server had been using the old 'us' realm instead of the current 'uv' realm. The server right now is showing R4 Subscription requires Extension: http://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition/backport-topic-canonical, so I'm guessing that the client is posting with US realm.
If you are using the reference client, it was updated a little while ago so probably needs a refresh (control-refresh is advised to make sure it doesn't reload from cache).
Ted Peck (Sep 10 2020 at 18:26):
OK now I see that since the R5 server doesn't need an extension, probably uv does not apply. I don't find any /us/ in the sample payload.
Spencer LaGesse (Sep 10 2020 at 18:27):
I'm using my own client, which is posting to the 'uv' realm.
Ted Peck (Sep 10 2020 at 18:30):
Is there a way I can insert Basic Auth credentials in the Authorization field of my Subscription request?
Avery Allen (Sep 10 2020 at 18:33):
You should be able to use the "header" field
Avery Allen (Sep 10 2020 at 18:34):
https://build.fhir.org/subscription-definitions.html#Subscription.header
Gino Canessa (Sep 10 2020 at 18:35):
Spencer: the R4 subscription requires several extensions. The test client shows all of them in-context:
{
"resourceType": "Subscription",
"end": "2020-09-10T19:33:31.651Z",
"reason": "Client Testing",
"channel": {
"endpoint": "https://client.subscriptions.argo.run/Endpoints/5f849307-5fd9-4e3e-a8fa-ebbc859e78a5",
"payload": "application/fhir+json",
"_payload": {
"extension": [
{
"url": "http://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition/backport-payload-content",
"valueCode": "id-only"
}
]
},
"type": "rest-hook",
"extension": [
{
"url": "http://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition/backport-heartbeat-period",
"valueUnsignedInt": 60
}
]
},
"status": "requested",
"criteria": "Encounter?patient=Patient/39917",
"extension": [
{
"url": "http://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition/backport-topic-canonical",
"valueCanonical": "http://argonautproject.org/encounters-ig/SubscriptionTopic/encounter-start"
}
]
}
Do you have an example that is being rejected?
Avery Allen (Sep 10 2020 at 18:37):
@Ted Peck
The expected syntax for headers w/ the Cerner test server is ""<header-name>: <header-value>"
You can check out this section for an example: https://github.com/averyallen/wgm_notes/blob/sept_2020/subscriptions/r5.md#create
David deRoode (Sep 10 2020 at 18:41):
Is https://fhir-open.stagingcerner.com/beta/dacc6494-e336-45ad-8729-b789ff8663c6/Subscription up? I'm getting a 504 TimeOut
Avery Allen (Sep 10 2020 at 18:45):
Still having issues @David deRoode ? I think that was temporary downtime while a new build was being deployed
David deRoode (Sep 10 2020 at 18:46):
Now getting a 502 Bad Gateway
Spencer LaGesse (Sep 10 2020 at 18:48):
{
"resourceType": "Subscription",
"extension": [
{
"url": "http://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition/backport-topic-canonical",
"valueUri": "http://argonautproject.org/subscription-ig/SubscriptionTopic/admission"
}
],
"status": "requested",
"reason": "Test subscription",
"criteria": "Encounter?patient=Patient/1316024",
"channel": {
"type": "rest-hook",
"endpoint": "https://connectathon.epic.com/Interconnect-Fhir-Unsecure/api/FHIR/R4/NotificationReceiver",
"payload": "application/fhir+json",
"_payload": {
"extension": [
{
"url": "http://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition/backport-payload-content",
"valueCode": "id-only"
}
]
},
"header": [
"Epic-Client-ID: 151ba7cb-ad9e-4361-92a0-21669aee0c65"
]
}
}
I think all of the parts in yours but not mine are optional?
Avery Allen (Sep 10 2020 at 18:52):
David deRoode said:
Now getting a 502 Bad Gateway
Looking into this now. Looks like some deployment pipeline changes were pulled in with the latest build that's causing issues for other tracks as well.
Gino Canessa (Sep 10 2020 at 18:54):
I see the issue - you have valueUri instead of valueCanonical that the server is expecting - the IG currently lists valueUri (so you are correct), but I believe (from earlier discussions) that it should be canonical now.. I'll need to change the server or the spec: @Jenni Syed @Grahame Grieve - thoughts?
Spencer LaGesse (Sep 10 2020 at 18:58):
Ah, okay. I was about to ask about that because Cerner's server is also giving me an error for that.
Ted Peck (Sep 10 2020 at 19:30):
Trying to POST an R5 subscription I got a 504:
CloudFront attempted to establish a connection with the origin, but either the attempt failed or the origin closed the connection.
https://fhir-open.stagingcerner.com/beta/dacc6494-e336-45ad-8729-b789ff8663c6/Subscription
Also got 504 from GET at the same address which worked for me earlier, so I guess the server is down now somehow?
Avery Allen (Sep 10 2020 at 19:34):
@Ted Peck
Yeah, there were changes pushed out that aren't related to subscription, but are causing the downtime. I'll update when the fix is pushed out; we are getting pretty close.
Grahame Grieve (Sep 10 2020 at 19:37):
but I believe (from earlier discussions) that it should be canonical now
well, the IG says uri so I was going to stick to uri for the duration of the connecatathon
Gino Canessa (Sep 10 2020 at 19:38):
Yeah - I'll update the reference implementation (sorry in advance to everyone for the breaking change)
Avery Allen (Sep 10 2020 at 19:39):
I'll also update what the our server expects as well.
Gino Canessa (Sep 10 2020 at 19:47):
As a note, the backport $topic-list operation uses canonical - so it's most likely that I simply missed the one extension and updated everything else (so make sure to leave the old code there too =).
Cary (Sep 10 2020 at 19:48):
Sorry, so is it canonical or is it uri?
Cary (Sep 10 2020 at 19:49):
like if I make a request right now
Cary (Sep 10 2020 at 19:49):
to the R4 backport endpoint
Gino Canessa (Sep 10 2020 at 19:53):
It's pushing the change to URI right now. It will take a couple of minutes to build and deploy.
Ted Peck (Sep 10 2020 at 19:58):
OK so I was wrong, GET is working but POST is getting a 504. I'm not sure if GET was also getting 504 before because I didn't actually do it even though I thought I did.
Ted Peck (Sep 10 2020 at 20:22):
Based on the GET results, it appears my three subscription POSTs were recorded even though I got 504 responses. But they all still have status "requested" not "active" and they are otherwise identical except for the IDs and timestamps.
Avery Allen (Sep 10 2020 at 20:25):
I believe it's still the same issue that was mentioned above. There's a fix that's in the process of being deployed.
Ted Peck (Sep 10 2020 at 20:27):
OK but also I think I put in "end" timestamps that have already passed
Ted Peck (Sep 10 2020 at 20:28):
I'll wait until I hear that the deployment is done and then I'll try deleting two and updating one.
Avery Allen (Sep 10 2020 at 20:36):
Okay, changes are live. Things that were added:
- 504s should hopefully be fixed
- Updated all extensions urls to "uv" instead of "us"
- Updated backport-topic-canonical extension to use valueUri instead of valueCanonical
Avery Allen (Sep 10 2020 at 20:37):
@Ted Peck , I don't think that we are currently honoring the end timestamps. That's something I could look into getting added if it's a workflow that you'd like to test out.
Avery Allen (Sep 10 2020 at 20:38):
@Gino Canessa , Did you also update the topic-list operation to valueUri? I left that as valueCanonical since that's how it was defined in the IG.
Gino Canessa (Sep 10 2020 at 20:42):
I left it as valueCanonical as well - that's how I realized that I just missed the one field during updating.
Avery Allen (Sep 10 2020 at 20:44):
I figured it out. I accidentally specified the server url with http instead of https which was causing the issue.
Spencer LaGesse (Sep 10 2020 at 21:04):
@Gino Canessa So, I'm still getting "Invalid subscription" for the above request. Any idea why?
Spencer LaGesse (Sep 10 2020 at 21:46):
@Avery Allen Posting subscriptions is now working for me. I'm trying to trigger a notification, but I'm finding that I get a 404 when posting to https://fhir-open.stagingcerner.com/beta/dacc6494-e336-45ad-8729-b789ff8663c6/Subscription/notify. Is that still the right endpoint to trigger notifications?
Ted Peck (Sep 10 2020 at 21:47):
I got a subscription POSTed and "active". Now I'm trying to trigger a notification, but I get a 400 Bad Request when I POST the raw V2
EVN|A04|1
PID|123|1316024|1221233
to the endpoint https://fhir-open.stagingcerner.com/beta/dacc6494-e336-45ad-8729-b789ff8663c6/Subscription/notify
Avery Allen (Sep 10 2020 at 21:53):
Hmm, I was able to get a request through with that body. Is there any error message that comes back with the 400?
Ted Peck (Sep 10 2020 at 21:55):
Maybe it's because of the content-type? When I changed it from "application/json" to "text/plain" I then get a 404 Not Found.
Ted Peck (Sep 10 2020 at 21:56):
With the 400 I got a JSON body showing the error code and text, but with the 404 I get no body
Ted Peck (Sep 10 2020 at 21:57):
But based on your successful submit I have not seen a call to my endpoint yet. Maybe that's a different problem.
Ted Peck (Sep 10 2020 at 21:58):
I take that back, I got 3 of them! They just didn't get far on my end.
Avery Allen (Sep 10 2020 at 21:59):
Okay, yeah. I can recreate the 400 by setting the Content-Type to application/json.
text/plain is working for me, though
curl --location --request POST 'https://fhir-open.stagingcerner.com/beta/dacc6494-e336-45ad-8729-b789ff8663c6/Subscription/notify' \
--header 'Content-Type: text/plain' \
--data-raw 'EVN|A04|1
PID|123|1316024|1111'
Avery Allen (Sep 10 2020 at 21:59):
Oh, cool! Glad to hear they are showing up
Gino Canessa (Sep 10 2020 at 22:13):
@Spencer LaGesse you have the wrong url for the topic, it should be: http://argonautproject.org/encounters-ig/SubscriptionTopic/encounter-start
Gino Canessa (Sep 10 2020 at 22:14):
In the context of the backport, you can run https://server.subscriptions.argo.run/Subscription/$topic-list to see the list of topics:
{
"resourceType": "Parameters",
"parameter": [
{
"name": "subscription-topic-canonical",
"valueCanonical": "http://argonautproject.org/encounters-ig/SubscriptionTopic/encounter-start"
}
]
}
Spencer LaGesse (Sep 10 2020 at 22:17):
Hm, I'm getting a 501 at that endpoint.
Avery Allen (Sep 10 2020 at 22:26):
Is there a list of the topic igs? I'm pretty sure the link that @Spencer LaGesse is providing is from the Cerner server. It's what we've been using for the last few connectathons. Maybe that used to be url and it changed?
Spencer LaGesse (Sep 10 2020 at 22:29):
I got the link originally from the R4 Backport examples, but I do see that https://microsoft-healthcare-madison.github.io/argonaut-subscription-info/ calls out that the one Gino mentioned is supported by that server. I guess I just assumed everyone was supporting "http://argonautproject.org/subscription-ig/SubscriptionTopic/admission" for testing.
Gino Canessa (Sep 10 2020 at 22:31):
The name for the Argonaut one changed a while back (can go through git) - but that was the old name. As long as the server is reporting its OWN list properly, it shouldn't matter.
In this case, the argo.run use 'encounter-start', so trying to create a subscription with the 'admission' topic fails.
Spencer LaGesse (Sep 10 2020 at 22:31):
Also @Avery Allen I am still seeing 404 at https://fhir-open.stagingcerner.com/beta/dacc6494-e336-45ad-8729-b789ff8663c6/Subscription/notify even if I set the Content-type to text/plain. The response has an "X-Cache" header that says "Error from cloudfront", so I'm not sure if that is relevant.
Gino Canessa (Sep 10 2020 at 22:33):
For reference, the current (final save for updates based on changes to R5) Argonaut encounter IG is living on GitHub, here
Avery Allen (Sep 10 2020 at 22:44):
@Spencer LaGesse , I'm going to have to dig into this one a bit more. I'm not able to recreate it on my end. If you get a chance can you provide the X-Request-Id response header?
Also the request body would be helpful
Spencer LaGesse (Sep 10 2020 at 22:45):
EVN|A04|1
PID|123|1316024|1221233
X-Request-Id: 2d0d1efe-70df-4310-ab4d-ca2b43d50db6
Ted Peck (Sep 11 2020 at 03:14):
@Avery Allen that curl is working for me, although on RedHat I had to change --data-raw to --data-ascii. I don't know why I'm getting 404 from Postman but I'll just go with curl for now.
Ted Peck (Sep 11 2020 at 03:15):
When you get a chance can you clean out all the subscriptions I POSTed? They all have endpoint edsconnect25.intersystems.com and heartbeatPeriod 600.
Ted Peck (Sep 11 2020 at 03:17):
Also I requested a second header, like below, but I don't think it's coming through:
"header": [
"Authorization: Basic X3N5c3RlbTpTWVM=",
"x-ISC-EDSName: Avery"
]
Is that plausible?
Avery Allen (Sep 11 2020 at 12:46):
@Spencer LaGesse , I tracked down the logs for the request above.
No trigger filter found for: 'EVN|A04|1
PID|123|1316024|1221233'
My suspicion is that there is either missing or extra whitespace somewhere. Here's how I have my postman request set up:
Screen-Shot-2020-09-11-at-7.45.48-AM.png
Avery Allen (Sep 11 2020 at 12:55):
@Ted Peck ,
You should be able to update the status of your existing Subscriptions to "off" to prevent them from triggering notifications. You can easily see all the Subscriptions you've created so far with:
curl --location --request GET 'https://fhir-open.stagingcerner.com/beta/dacc6494-e336-45ad-8729-b789ff8663c6/Subscription?endpoint=edsconnect25.intersystems.com' \
--header 'Accept: application/fhir+json'
Avery Allen (Sep 11 2020 at 12:56):
The server should sending multiple headers. Looking into that now.
Spencer LaGesse (Sep 11 2020 at 13:19):
@Avery Allen Okay, I think I might have it figured out. I'm on Windows, and if I send a request from Postman that looks exactly like yours, I get a 404. However, if I paste the body in Notepad++, convert the line endings to Unix (so LF instead of CRLF) and send that as a binary payload from Postman, I get 200. So I suspect this is a Windows vs Unix line endings issue.
Avery Allen (Sep 11 2020 at 13:29):
I'll look into stripping the line endings to hopefully prevent that
Spencer LaGesse (Sep 11 2020 at 13:31):
Thanks. It is easy to work around once the issue is understood, so don't worry about it too much for my benefit.
Vassil Peytchev (Sep 11 2020 at 13:55):
Since these are HL7 V2 segments, shouldn't they simply have a CR at the end (and no other line breaks)? At least that is what HL7 over HTTP expects...
Jenni Syed (Sep 11 2020 at 13:57):
This is "hacked HL7 over HTTP" not so much the real deal :D
Ted Peck (Sep 11 2020 at 14:39):
@Avery Allen I have increased my confidence that my x-EDS header is not coming through. I succeeded in updating my extra subscriptions to "off", so the only active one now is e09c0d84-692f-4149-8899-30b6c01150f2 and it has
"header": [
"Authorization: Basic X3N5c3RlbTpTWVM=",
"x-ISC-EDSName: Avery"
]
Do I have the syntax right on that second one? I do see the "authorization" header coming through.
Avery Allen (Sep 11 2020 at 14:40):
The syntax looks correct. We are currently looking into the issue. Hope to have a fix for you soon.
Avery Allen (Sep 11 2020 at 15:00):
@Ted Peck , can you give it another go? Just pushed out a change.
Ted Peck (Sep 11 2020 at 15:05):
Thanks! I seem to have gotten a bunch of new x- headers but not the one I requested.
Ted Peck (Sep 11 2020 at 15:06):
Sorry, it seems I did get it - let me check more throughly
Ted Peck (Sep 11 2020 at 15:08):
Yes, I missed it the first try because I searched case-sensitive.
So, thanks!
Ted Peck (Sep 11 2020 at 15:13):
FYI these are all the new headers I got:
"x-isc-edsname")="Avery"
"accept-encoding")="gzip;q=1.0, deflate;q=0.6, identity;q=0.3"
"newrelic")="eyJ2IjpbMCwxXSwiZCI6eyJ0eSI6IkFwcCIsImFjIjoiMTc5NTE0MSIsImFwIjoiMjEyMjkxODAzIiwidHgiOiIzMWFhMWU2NjZkNDZlNzhhIiwidHIiOiIzMWFhMWU2NjZkNDZlNzhhIiwic2EiOnRydWUsInByIjoxLjExMDI3NSwidGkiOjE1OTk4MzY1NDU3NzgsImlkIjoiNjUyNWZmOWRmZTdkY2RjNiIsInRrIjoiMTczMDc1OSJ9fQ=="
"user-agent")="Ruby"
"x-forwarded-for")="159.140.6.33"
"x-forwarded-port")=80
"x-forwarded-proto")="http"
"x-relay-domain")="edsconnect25.intersystems.com"
"x-relay-path")="csp/healthshare/edsdemo/hseds/api/trigger/fhirsub/admit-IMP"
"x-relay-proto")="https"
Ted Peck (Sep 11 2020 at 15:18):
Next question...
I tried updating to content: "full-resource" and got back an error: "text": "Expected value to be one of: id-only, empty".
I assume that's not supported for now. However the notification bundle I'm getting with "id-only" contains an entry after the SubscriptionStatus resource that is not any kind of FHIR Resource:
{
"request": {
"method": "PUT",
"url": "https://fhir-open.stagingcerner.com/beta/dacc6494-e336-45ad-8729-b789ff8663c6/Encounter/1111"
},
"response": {
"status": "200"
}
}
Is this the expected content? I see it contains the expected id but I'm not sure what to make of the rest of it. I couldn't find any documentation specifying what to expect but based on my R4 experience I was expecting the full Encounter resource.
Ted Peck (Sep 11 2020 at 15:18):
The R5 doc does give me the impression that I should expect any number of resources that match the Topic, am I right about that?
Ted Peck (Sep 11 2020 at 15:22):
I just tried a GET on the returned URL for Encounter/1111 but got a 404. Is that expected?
Spencer LaGesse (Sep 11 2020 at 15:27):
It seems the Cerner test server is not returning a fullUrl for each Bundle entry. Is that expected?
Avery Allen (Sep 11 2020 at 15:37):
@Ted Peck
Yeah, full resource isn't supported.
For the response, the first bundle entry contains the subscription status resource. The second entry only contains a request and response field that relay information about the request that triggered the subscription notification. Note that since the notification triggers are the hacked together hl7 v2 messages, that there wasn't really a post/put request like the bundle suggests, but that's how the response would be if the workflow were fully supported.
Here's an example from the spec: https://build.fhir.org/notification-id-only.json.html
Also, as for the Encounter not resolving, that's expected. In the notification body
EVN|A04|1
PID|123|1316024|1111
The last integer is used as the Encounter id. Encounter read/search is supported by the server so if you wanted a real encounter, you could look one up and use that as part of the notification. An example can be found here:
curl --location --request GET 'https://fhir-open.stagingcerner.com/beta/dacc6494-e336-45ad-8729-b789ff8663c6/Encounter/97733541' \
--header 'Accept: application/fhir+json'
Avery Allen (Sep 11 2020 at 15:41):
@Spencer LaGesse , We don't support reading the subscription status outside the context of a notification bundle, so I don't think it makes sense to add a full url there (I also don't think it's required by the spec).
I do see where it could be helpful for the second bundle entry. I'll update the server to populate the entry the same was as the example in the spec
{
"fullUrl": "https://example.org/FHIR/R5/Encounter/2",
"request": {
"method": "PUT",
"url": "Encounter/2"
},
"response": {
"status": "201"
}
}
Spencer LaGesse (Sep 11 2020 at 15:43):
I think it is required based on: http://hl7.org/fhir/R4/bundle.html#bundle-unique
Except for transactions and batches, each entry in a Bundle must have a fullUrl which is the identity of the resource in the entry. Note that this is not a versioned reference to the resource, but its identity. Where a resource is not assigned a persistent identity that can be used in the Bundle, a UUID should be used (urn:uuid:...).
Or am I misinterpreting something?
Avery Allen (Sep 11 2020 at 15:48):
Yeah, you're right. I can get that added. Also, I believe we are returning absolute urls in the request.url field, but based on the spec it should be relative:
Definition
The URL for this entry, relative to the root (the address to which the request is posted).
Avery Allen (Sep 11 2020 at 16:30):
@Spencer LaGesse
Alright! I've got a new commit building that updates the request notifications to always include Bundle.entry.fullUrl and that updates Bundle.entry.request.url to be relative as the spec requires. Example:
{
"resourceType": "Bundle",
"id": "notification-id-only",
"meta": {
"profile": [
"http://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition/backport-subscription-notification"
]
},
"type": "history",
"timestamp": "2020-09-11T11:25:20-05:00",
"entry": [
{
"fullUrl": "urn:uuid:aca62ce2-7bff-496e-b4d1-ec0591dd5152",
"resource": {
"resourceType": "Parameters",
"meta": {
"profile": [
"http://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition/backport-subscription-status"
]
},
"parameter": [
{
"name": "subscription-url",
"valueUri": "http://localhost:3000/beta/r4/2c400054-42d8-4e74-87b7-80b5bd5fde9f/Subscription/2ac4db66-4790-4cc7-b38d-d18f16fbef26"
},
{
"name": "status",
"valueCode": "active"
},
{
"name": "type",
"valueCode": "event-notification"
},
{
"name": "subscription-event-count",
"valueUnsignedInt": 2
},
{
"name": "bundle-event-count",
"valueUnsignedInt": 1
},
{
"name": "subscription-topic-url",
"valueUri": "http://argonautproject.org/subscription-ig/SubscriptionTopic/admission"
}
]
},
"request": {
"method": "GET",
"url": "Subscription/2ac4db66-4790-4cc7-b38d-d18f16fbef26/$status"
},
"response": {
"status": "200"
}
},
{
"fullUrl": "http://localhost:3000/beta/r4/2c400054-42d8-4e74-87b7-80b5bd5fde9f/Encounter/1111",
"request": {
"method": "PUT",
"url": "Encounter/1111"
},
"response": {
"status": "200"
}
}
]
}
Avery Allen (Sep 11 2020 at 16:30):
It should be available in about ~30 minutes or so.
Avery Allen (Sep 11 2020 at 16:31):
I'm going to step away for a bit to eat, but afterwards I'll be around to tweak anything else that needs updates.
Spencer LaGesse (Sep 11 2020 at 16:55):
If I try to post a subscription with criteria like Encounter?patient=Patient/1316024, I get back the following response:
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "invalid",
"details": {
"text": "Expected to match pattern: Encounter\\?patient=\\d+"
},
"expression": [
"Subscription.criteria"
]
}
]
}
But if I submit it like Encounter?patient=1316024 it works.
Shouldn't the criteria be Encounter?patient=Patient.1316024 since the value is a reference type?
Avery Allen (Sep 11 2020 at 17:14):
Both are allowed by the spec for reference searches:
https://www.hl7.org/fhir/search.html#reference
We limit to patient=<id> for simplicity in the server implementation.
Spencer LaGesse (Sep 11 2020 at 17:37):
@Avery Allen Has the fullUrl update finished deploying yet? I am still not seeing the fullUrl in the notification bundles.
Avery Allen (Sep 11 2020 at 17:38):
Let me check real quick
Avery Allen (Sep 11 2020 at 17:39):
Gah, networking issue failed the build. Lemme rerun it.
Avery Allen (Sep 11 2020 at 17:39):
Sorry about that.
Avery Allen (Sep 11 2020 at 18:50):
@Spencer LaGesse, the changes should be deployed now
Spencer LaGesse (Sep 11 2020 at 18:54):
Thanks! It seems to be working now.
Last updated: Apr 12 2022 at 19:14 UTC
