Even though patients may be registered at the spokes, we're talking about a single patient population that is managed at the hub.
One approach is to have a single ID scheme, and these IDs can be assigned at any node. (This requires something like what Mike describes about using the idgen module so that each node can have pools of available identifiers to give out.) In this case, if the same patient has a duplicate record registered at a second facility, the records will need to be merged later, and one of the spokes needs to be told that the primary ID number for that patient record has changed.
Another approach is that each spoke assigns local IDs (e.g. each spoke uses a unique prefix) but when the patient records is pushed to the hub it gets a global ID assigned (which is also pushed back out to the spoke). Ideally you'd have a chance to merge records at this point, but this is a nice-to-have. The benefit here is that each spoke can file paper records under its own ID, and doesn't have to refile paper charts based on patient merges that happen at the hub.
Which of these approaches is better depends on the deployment scenario, e.g. are the spokes fixed subcenters? are they mobile clinics that don't have their own paper filing system? how often do patients move between spoke nodes and can you predict this ahead of time?
+1 to this. Basically the Hub & Spoke architecture should do simple and predictable things given the IDs that are generated/entered so that there's nothing hub-and-spoke-specific about ID generation, and we support multiple approaches depending on the implementations.