Noah ES Optimistic Locking and Impact for Noah 4 API Modules
Introduction
Noah ES has some differences, from Noah 4. One of these is that Noah ES implements what is known as “Optimistic Locking”. On this page Optimistic Locking will be briefly explained along with that this might mean for your modules. You will also be introduced to an example where this has had an impact on HIMSA’s own modules.
Optimistic Locking and Noah ES
Optimistic Locking, as it relates to Noah ES, means that several concurrent users, will be able to view the same patient at the same time. The patient will no longer be locked, like it was in previous versions of Noah. This means that modules that rely on patient locking, may need to be adapted, to function correctly, with Noah ES.
Events for changes in open patients.
With optimistic locking, several users may look at the same patients at the same time. While this is happening, one of these users may choose to edit something with this patient. This will now trigger an event, which modules for Noah ES may now listen for and use to update their views.
Example
Below we describe a situation, where optimistic locking will prevent a the same user from editing the same action on two different PC’s
Test Steps:
Open up patient A, on PC 1.
Create and save data with the module under test.
Still on PC 1 update the action but do not save.
Switch to PC 2.
Log into PC 2 with the same credentials as on PC 1.
Open up patient A on pc 2.
Open up the saved action created by the module under test on pc 2.
Update the action on pc2 and save the updated action.
Switch back to PC 1.
The above test was performed by HIMSA on all certified modules, and the results of these tests were sent to the owners of the relevant modules.
In the initial tests, HIMSA’s own Audiogram Module 1.4 lost data in this edge case. Showing that some modules may be adversely affected by this change, in specific circumstances and may need to be updated. In the case of HIMSA’s Audiogram module, the correction is in Audiogram Module version 1.5.