This portal provides an open platform for user feedback and product change requests. Anyone can add an idea and remain as a Guest, but please consider signing up so that others can see who has created the ideas!
Note: this is a public facing web portal, any text here can be viewed by anyone over the internet, so please consider carefully the content you wish to share and please do not post anything of a sensitive nature.
As described in detail in https://yhcrservice.atlassian.net/browse/ICR-2781, the PATIENT.AUTO.REGISTRATION process by default runs on the hour then 15, 30 and 45 mins past the hour every hour. Because the process executes at the same time on each instance in a cluster we have experienced race conditions that cause conflicts in the PIX registration of newly created Patient resources.
The suggestion currently is to disable the PATIENT.AUTO.REGISTRATION process on the clustered Connect instances and host a separate Connect instance purely to run the PATIENT.AUTO.REGISTRATION process.
While that is a pragmatic solution, a solution architected to work in a cluster - perhaps utilising a locking mechanism - would be optimal. This idea is to promote the development of such a solution.
I've been thinking further about this issue and i was reminded that a change was made to patient PIX registrations from synchronous processing to asynchronous batch processing due to problems when creating thousands of Patient resources while performing an initial backload of a Connect instance.
This made me wonder whether the best fix would be to allow Connect to be configured via the .env file for either synchronous or asynchronous mode: asynchronous mode can be selected on one member of the Connect cluster for the initial backload and then synchronous mode (the default) for normal operation where only a handful of Patient resources would typically be created per hour. In synchronous mode the Connect instance that processes the http request to create the Patient resource will perform the PIX registration thus preventing any contention between instances in the cluster.