We have endTB 1.5.1 deployed and auto-generating EMR IDs using ID Gen module (identifier source and identifier type). Here is the identifier source config:
It is supposed to generate IDs in sequence starting with ZAF-001-00001. First two ids are generated in sequence but the next ID generated was ZAF-001-00010. I am not sure why it skipped IDs from 03 to 09.
If it is of any help person ids are also NOT being generated in sequence. After person id 97, the next one is assigned 105.
When I see the log entries for idgen, it shows all the ids generated in sequence from 01 to 10 (then why 10 is assigned to next patient and not 03).
Can any one please help me figure out why the ids are not being generated in sequence? Please note that we are NOT manually assigning Ids.
In the above example, I can not tell whats wrong. If i check with the timestamps and the person_id, they seem to be fine.
Technically, If multiple people are creating patients, there might be race conditions - the Identifier source is free to generate and provide Identifier to the requesters, and there is no guarantee that the subsequent database writes are complete (in case of some error - say network failure), and there might be skips as well.
@wasim - from what I can tell from your posting, the ids are generated in sequence, as demonstrated by the idgen log table. It appears to me that the idgen functionality is working correctly.
I believe any issue will be in how these are being requested, and if this is coming from a Bahmni implementation, then I would look at the idgen webservices module that Bahmni ships with and how this is generating new identifiers. Perhaps the user tries to submit the form, this generates a new identifier behind the scenes, and some validation error in Bahmni prevents the submission (missing birthdate, for example). Then the user tries again and maybe hits other validation errors. Or perhaps network errors lead to similar issues as @angshuonline indicates. Perhaps @angshuonline can indicate whether this is plausible, or whether the design is such that id generation does not happen until after the rest of the validation is successful?
Thank you both @angshuonline and @mseaton. We have a work around so that it does not affect our operations. However, having identifiers in sequence has its own advantages (programme-wise). Besides, I am curious as to why this is happening.
On one of our test servers, I have introduced errors while registering patients (not entering birth date and not giving rights to enroll in treatment for e.g.) to see if identifier gets generated irrespective of error. However, this is not the case. In missing birth-date case (and other similar cases) system prompts an error without submitting. It is therefore likely either client side validation or ajax-based validation. Identifier is only generated when validation is successful.
In case where I have not given rights to user to enroll in treatment, when treatment registration is clicked (without saving patient first), patient is saved and identifier is generated and assigned in sequence (at the same time, it shows error for lack of privileges for treatment enrollment).
This leaves possibility of race condition or network errors perhaps causing the behavior of not assigning ids in sequence.
An interesting observation to note though is person ids in person table are not in sequence either. As I pointed out in original post, after person id 97, the next generated one is 105. So 7 numbers in between are skipped, which is exactly the number skipped for patient identifiers as well (though log shows those 7 patient identifiers did generate in sequence). There is no such log (at least I am not aware of) for person ids to see if they were actually generated but somehow not assigned to a person.
We have been able to figure out the cause. Thanks once again @mseaton. When I entered the value in address field with more than allowed length, the system shows an error ‘statement cannot be executed’. It did, however, generate an id despite validation error as Mike pointed out. Did not create person or patient but generated an id. On successful submit, the next id in sequence was assigned. So depending on how many times the error occurred before a successful submit, those many ids are skipped.
@mseaton, I was just talking about theoretical possibilities. When making any network calls (a database save is a network call), there is no guarantee that the call will be successful. We have seen in multiple registration desks case (4 in parallel), that the IDs can be missed. (although rare).
IDs generated by a library that primary works in memory can never really guarantee sequences. Imagine, if OpenMRS was to work in a multi node environment? - a whole lotta things can go bad out there. (but thats hypothetical, OpenMRS doesn’t support a multi node cluster setup, as of now)
