Stream: subscriptions
Topic: id-only and resources with 1.. fields
Nick Hatt (Sep 22 2021 at 21:13):
Is there a best practice around including a resource in subscription notification bundle using the id-only method when that resource contains required fields? For example, if I have an admission notification and I'd like to include id-only resources for both Patient and Encounter - I'm not going to be able to do that without also including Encounter.status and Encounter.class. Or is this just generally expected to be the way that id-only payloads work?
I'm trying to create some examples using FSH and finding this limitation - namely FSH won't let me generate a bundle with encounter with only identifier present.
I can share my FSH if it helps.
Gino Canessa (Sep 22 2021 at 21:23):
Hi Nick, if you are using id-only, then the id is populated via Bundle.entry.fullUrl, and the resource element is not present. An example from the spec can be seen here, while the FSH file that defines all those examples is here.
Hope this helps!
Nick Hatt (Sep 23 2021 at 13:31):
That makes perfect sense thanks @Gino Canessa ! I never thought about bundle.entry without .resource, but yeah that's totally allowed. http://build.fhir.org/subscription.html#payloads-id-only <- would it make sense to you to call out that the resource element should not be present for id-only?
Nick Hatt (Sep 23 2021 at 14:01):
It also seems like there's a developer experience problem here - it's not guaranteed that I can infer what the resourceType is from the fullUrl, or request.url. So as a developer, if I want to know what all was in the notification I have to go and fetch each resource and then figure out which resource is which. Otherwise, I'm stuck doing fullUrl.indexOf('Patient') to try and guess that a particular entry is the patient entry.
I realize there's nothing stopping me from using full-resource and just constraining things down to minimize data exposure, and use the data-absent-reason extension to work around Encounter and such, but that feels like it defeats the purpose.
Gino Canessa (Sep 23 2021 at 21:11):
I am hesitant about about inserting full-resource entries that are essentially blank just to get the resource type. We could add guidance to encourage implementers to fill out the Reference.type, in SubscriptionStatus.notificationEvent.focus and SubscriptionStatus.notificationEvent.additionalContext, especially when using id-only. (Those elements aren't in the R5 CI build yet, since I've been focused make sure the R4B version is ready to go - I'll be updating R5 once R4B is 'final'.) I'm happy to file the ticket for that change, but will note that we need to review in case including the resource types leaks PHI. We could also propose an extension for that same information, but need to worry about the same issue.
Good catch on calling that out that Bundle.entry.resource should be excluded! Would you mind filing a ticket for the change request?
Also, just a note that FHIR URLs should follow the [base]/[type]/[id]?[parameters] pattern (http page). So if/when they need to be parsed, it's at least not as bad as repeatedly searching the URL for string matches.
Nick Hatt (Sep 24 2021 at 13:29):
You got it @Gino Canessa - it's good motivation to get my Jira account set up.
Point taken about fullUrl, butBundle.fullUrl is a uri type though - so it could be uuid, or use something like [base]/DiagnosticReport?identifier=1045813 (http://build.fhir.org/resource.html#identifiers). If the publisher is sending uuids they are probably just being rude, but the "business identifier" reference use case seems more valid, especially as groups like Carequality are looking at subscriptions as a way to build out event notifications for otherwise unaffiliated groups - with potentially multiple hops in between.
Last updated: Apr 12 2022 at 19:14 UTC
