Stream: subscriptions
Topic: int64 data type
Keith Boone (Feb 01 2020 at 20:54):
I'm thinking that the argument for the 64-bit integer type is not really sufficient to support the creation of a new data type.
- This is a pretty significant change.
- I cannot see a situation where we have to count that high in the real world. Yes, I understand that there are thousands or even hundreds of thousands of patients (or more) that an organization might have to deal with, and there could also be hundreds or thousands or more resources associated with a subscription ... but, realistically, the number of events can reasonably be capped at 2 billion.
- Given that you've missed an event, you cannot use the number as an identifier to retrieve that event. The only purpose this number serves is to tell you that you've missed something. It doesn't give you a way to recover the events you've missed. And since many FHIR servers don't support versioning (implementations over top of existing data stores), it's also unlikely that the receiver will even have a way to figure out what it might have missed.
Here's my argument:
A subscription could last at most a month (though it could be extended for another month ad infinitum). For the number to roll over within a month's time period, there'd have to be more than 829 subscription related events on any given subscription every second continuously for the entire month.
So, if there's a rollover coming up, and the subscriber doesn't want to have to deal with it, it can just create a new subscription. A 32 bit integer is sufficient for a receiver to determine that it's missed something, even with rollover, unless it's down for say, a month. In which case, they've got bigger problems.
So, technically, it may seem to solve a problem, it's really dealing with a VERY edge case, beyond the 80% of use for most implementers of subscription, has a pretty significant impact on core data types, and doesn't really seem to provide the value essential for making that sort of fundamental change.
Gino Canessa (Feb 01 2020 at 22:44):
Hi Keith. First, I'd ping over to the discussion on implementers when the type was added, since there was a lot of discussion. I'll note that it was presented to FHIR-I and passed already, so NOT adding the type would require a new Jira issue asking that it be removed.
More generally, I would argue that the datatype is required anyway, since there are things like Attachment which point to arbitrary media files. A single DICOM tomosynthesis study will overflow the byte count today, ignoring future growth.
As for forcing Subscriptions to expire every month, that's an interesting concept - but at first blush it feels like we are defining implementation details to me. I'm up for more discussion, but don't know that I prefer it over using a datatype that's wide enough so that we don't have to.
Keith Boone (Feb 02 2020 at 00:22):
Ok, since we need it anyway, I’ll be ok with using it. I wasn’t aware that there were other uses for it. If this were the only use, I’d definitely push back harder, but your DICOM example is a better justification.
Sent from my iPhone
Last updated: Apr 12 2022 at 19:14 UTC
