Replacing your names with letters produces an alphabet soup that his generally harder to follow than if you used names.
What would dates have have to do with with relationships based on UUIDs?
Ah, I was hoping to make it simpler to understand.
Relationships are via UUIDs. However, I wrongly also used UUIDs as the import match fields. Of course it 2 users deal with the same Patient (Table 1a) and each have a record for this, importing from one user to the other will never find a match, because they are each unique IDs. Hence I switched to a name/hospital number method for the 1a match field. Records from tables 1b, 2a/b and 3 are each recognised by the User by their date, so I thought it best to match fields by date for each of these tables. As for tables 4/5, if they were related to a new parent record, they'd get added even using UUID as the match, and if their parent wasn't new, it's probably best they weren't added.
At least, that's my logic. But I'd appreciate comments on whether I've making mistakes before I try rolling it out !!
UUIDs are specifically designed to make this sort of thing easier not harder. Matching by dates does not seem like a workable approach.
It sounds like the problem you are dealing with is that 2 users on separate copies might create a patient record for the same patient. That will pose a problem for any type of ID that you might generate from separate applications. You need an identifier available to that patient which is unique to that patient.
I'd like a unique ID, but because they're standalone Runtime's it doesn't look possible. The best I can do (that I know of) is to ID the patient by name + fairly uinque hospital ID and the other tables in another way.
Why doesn't it look possible?