Which I have to assume is rare, right?
UUIDv4 removes all three of those vectors. UUIDv7 still removes two of three. It doesn't leak record count or the rate at which you create them, only creation time. And you still can't guess adjacent keys. It's a pretty narrow information leakage for something you routinely reveal on purpose.
With UUIDv7 the creation time is always leaked without any sampling. A casual attacker could quite easily lookup the time and become motivated in probing and linking the account further
When sequential integer ID's are externalized, an attacker does not need creation times to perform predictive attacks. All they need to do is apply deltas to known identifiers.
I can see it being bad for tracking IDs, but not order IDs, unless you are allowed to view any orders that do not belong to your account, which is just fundamentally bad security and using UUIDv4 or a random string would simply be obscuring security.
In most cases this forms a compliance matter rather than an open attack vector, but it nevertheless remains that one has to answer any question along the lines "did you minimise the privacy surface?" in the negative, or at least, with a caveat.
Whether creation date is PHI…I could see the argument being yes, since it correlates to medical information (when someone sought treatment, which could be when symptoms present.)
The only thing that seems to be protected is ‘reason for appointment’, and not all systems do that.
Everyone signs paperwork to authorize this when they first engage with the medical providers!
You wouldn't be publishing patient visits publically, the only folks that'd legitimatly see that record would be those which access to that visit, and they'd most likely need to know the time of said visit. This access should be controlled via AuthN, AuthZ and audited.
You'd also generally do a lot of time-based lookups on this data; what visits do I have today, this week, and so on. You might also want an additional DateTime field for timezones and offsets, but the v7 is probably better than v4 for this usecase.
Dates are specifically cited as potential vectors for de-anonymization. For example, you can't disclose that "Bob H presented to the clinic on October 10th" because that's a lot of information that can be used to find out who Bob H is.
Here's a practical example of what I'm talking about. Suppose you have an app for physicians that allows them to message each other to discuss a case. They can share relevant information for diagnostic purposes, e.g., "34y/o male from the southern Louisianna presented with a rash." They share de-identified photos and chat about ddx, treatment protocol, etc. All of that is cool. However, if the record of that visit is identified with a UUIDv7, and that ID is used as part of the URL you've exposed the time of the visit, and that would be a problem.
Always thought that was elegant (the attach not using the time as the seed).
Of course, it's always possible for something to do something stupid, like weak rng.