We are in the process of switching to a new demo dental office database for our testing credentials. You will soon see smaller primary keys for some of our tables, such as appointments.
But it's always possible for patient databases to have extremely large primary keys. You need to be able to handle them, even if they are large. In C#, the type is long, and in mysql, the same type is called bigint. It can have a max of 9,223,372,036,854,775,807.
The MAX_SAFE_INTEGER in JS is 2^53-1. Considering the maximum number of possible patients to be equal to the number of persons living on earth then I would like to mention that the AptNum being 64 Bit poses a problem to me.
We settled on this about 15 years ago. It allowed different ranges of PKs for different offices all using the same database with replication, so that there was virtually no chance of collision. Also, many tables such as logs can fill up rather quickly. It's something that must be intentionally turned on by the office, and I suspect that virtually nobody is using it, but it is a possibility. It's also possible that, if an office does have large PKs, that we could somehow "repair" their database and convert them all to smaller PKs. Hopefully, it won't come to that. Also, JS does have bigint.