Has anyone found this or even tried it? In CPS 12.0.11 we are able to have two or more people join the same update and independently make changes to the document. When the document refreshes the changes are visible to all users. If someone is on SP12 can you try it to see if it has been fixed? I have a ticket open with GE 1-948165761 and am waiting for a call.
To replicate, start an update from user 1, modify the document, while leaving the document open have user 2 join the update. They should be able to add meds, problems, change data on forms, enter text in text mode, etc. Change forms or give the system a few seconds and both users should see the same data. The document can be signed without any problems as long a the other person puts it on hold first.
Is this a new feature?
You can definitely still do this in CPS 12.0.11. The only difference I have seen is that now it seems more likely to cause the document or even the patients entire chart to lock up if two or more users are actively in open documents in the same chart at the same time.
The issue described has been present for a while. As others have reported, most of the time the document becomes locked and requires a DB scrub to be performed overnight before it will unlock. We have reported the issue multiple times. The ability to open a document and have two users make changes at the same time goes against SQL logic which worries us greatly. We hope to see this remedied soon in the upcoming versions, especially before we get into EPCS.
FYI: Another caveat to this, which has been reported by our end users, is the securities between a staff member and a physician become jumbled concerning document functionality. Something to keep an eye on.
We continue to have physicians and scribes work in updates at the same time and lose information. The scribe will type the HPI while provider examines and talks to patient, however the provider will no in and start clicking around, adding notes while the scribe is in there. When they put the note on hold, all information is lost in the HPI, they lock the chart up for the entire clinic, and most of the time it takes over night to release it. We still preach to NOT join updates while others are working in the update already.
How would a user know another user has the update open?
This type of serious and potentially health-threatening software bug is par for the course for GE.
For those of you that state that they are seeing locked documents and have to wait overnight to unlock, have any of you tried to use the Centricity Admin Tool to unlock the documents? Our HelpDesk uses this often to unlock documents. On the rare occasion that they use it and it still does not unlock then they reach out to me and the first thing I do is run the following SQL script from GE. If it still does not work, I usually start hunting for an issue in the LogLocks Table.
--==============================================
--== REMOVE LOCK for Patient ==
--==============================================
DECLARE @Pid Numeric,@PPid Numeric, @Id VarChar(15)
--==============================
set @Id ='XXXXXX'--ENTER PatientID
--==============================
SELECT @Pid= PID,@PPid=PatientProfileId
FROM PatientProfile WHERE PatientID= @Id
IF (@Id ='')
BEGIN
RAISERROR(' PatientID NEEDED -- Please enter PatientID',16,1)
End
ELSE
BEGIN
DELETEFROM Applocks
WHERE ObjectID= @PPid
UPDATE PatientProfile
SET MasterLock =NULL
WHERE PatientProfileID=@PPid
UPDATE LogLocks
SET PROBLOCK=Null,MEDLOCK=Null,ALLERGYLOCK=Null,FLOWLOCK=Null,ORDERLOCK=Null,DIRECTLOCK=Null,SETUPLOCK=Null,
DEMOGLOCK=Null,ENDLOCK=Null,L3QLOCK=Null,OTHER1LOCK=Null,OTHER2LOCK=Null,CONFCHLOCK=Null,DOCPROPCHLOCK=Null,
APPTLOCK=Null,BUSLOCK=Null,NOTETEXTLOCK=Null,IMGEDITLOCK=Null
WHERE (PROBLOCK=@Pid)or(MEDLOCK=@Pid)or(ALLERGYLOCK=@Pid)or(FLOWLOCK=@Pid)or(ORDERLOCK=@Pid)or
(DIRECTLOCK=@Pid)or(SETUPLOCK=@Pid)or(DEMOGLOCK=@Pid)or(ENDLOCK=@Pid)or(L3QLOCK=@Pid)or
(OTHER1LOCK=@Pid)or(OTHER2LOCK=@Pid)or(CONFCHLOCK=@Pid)or(DOCPROPCHLOCK=@Pid)or(APPTLOCK=@Pid)or
(BUSLOCK=@Pid)or(NOTETEXTLOCK=@Pid)or(FAXDELETELOCK=@Pid)or(IMGEDITLOCK=@Pid)
END
----------------------------------------------
Update mikpatientvisit set lockuser =null, lockdate =nullwhere lockuser isnotnull
select lockid,ap.appsessionid, ap.loginname,ap.description,al.objectid,
CaseWHEN al.locktype=1 THEN'DEMO Lock'ELSE'ADMIN Lock'ENDAS LockTYPE
FROM Applocks as al
LeftJOIN AppSession as Ap on ap.AppSessionID = al.AppSessionID
We are currently on 12.0.11 and still have this issue more often than not. We will be upgrading to 12.3 sometime this year. Any word on if it has been improved for 12.2 and 12.3. Thanks!