On FOCUS

by Ed Bishop

The ForUpdate mutex defines a mutex record only when the data is updated, thus limiting the amount of time that the record is locked. Examples of ForUpdate mutexes are OM Clinical Data entry, OM Order entry, and PCS Assessment edits. The key difference with a ForUpdate mutex is that the cached data value at import time (the time the user initiated the update) is compared with the permanent data value on the server prior to updating. If the data value on the server is newer than the value that was imported by the user prior to the edit, the user cannot update the record.

For example, user one imports a PCS Assessment record and proceeds to edit. User two imports the same PCS Assessment record and proceeds to edit and file. User one then attempts to file the edit and gets a warning that data on the server is newer than the data in the local cache, and therefore the edited values cannot be filed. In this case, the user must throw away the edit and begin again.

There are also instances when no mutex is obtained. If the application determines that the data being filed is not in jeopardy of being interrupted, then a mutex is not assigned at all. As an example, new assessment documentations do not require a mutex because the data is fresh and free from editing that would cause data integrity issues.

So besides changing the name to a more techy sounding word, MEDITECH has made some significant logic changes to their locking mechanism in the new technology. While these algorithms may lead to less frequent locks in general, who wants to be in IS when that call comes in from a user who has been documenting away and is now told she must discard her changes?

Previous post:  The Mutex

Related Posts

• March 2, 2010 -- The Mutex (1)
• April 13, 2010 -- Scripting the “Chain Gang” (0)
• November 25, 2009 -- It’s a MAD, MAD, MAD, MAD World – Part I (6)
• November 9, 2009 -- FOCUS: When/Where (1)
• October 20, 2009 -- When Wizards are King (0)