Notifications
Clear all
Topic starter
We've been having users calling with their updates being blocked by unsigned clinical list changes in documents that have been signed. GE updates the masterlock for the person to 0 and we continue on. Have one instance where the medications added and prescribed still show as unsigned in the clinical list changes of the signed document. Didn't send electronically. Database shows CHANGe = 6 and no PUBUSER or PUBTIME. Anyone else seen this?
Thanks,
Posted : January 20, 2016 12:58 pm
Problem for us. Anxious for solution.
Posted : January 20, 2016 1:38 pm
We are having the same problem with the dreaded "6" in the database during updates. Call GE and ask them to add you to SPR65495. They were able to reproduce the issue in our database.
Posted : January 21, 2016 3:09 am
We have seen this 5 or 6 times.
GE Support gave us this script to fix ourselves when it does happen:
-- Error message in CPS when user tried to update anything in chart - Pop up Error "Unsigned Clinical List changes..." but all documents in chart were signed already.
-- Normally the MasterLock field should have value of Null or Zero. If value in it and no one truly has an open update in progress then run second script below to Null the MasterLock value.
-- Update PatientID with value for problem patient
SELECT PID,PatientProfileId,masterlock, *
FROM PatientProfile
WHERE PatientID = '6246 '
-- First highlight all but the commit line and execute. If only 1 row modified then execute the commit statement.
Begin Tran
Update patientprofile
set masterlock = Null
Where PatientProfileId=6246
commit
Posted : January 21, 2016 4:25 am
Sorry to be of no help but that is concerning. Are you on SP 10 or 11 (or another)?
Posted : January 21, 2016 4:52 am
We are having the same problem with this and other locks in the database. GE told me they pushed back SP12 to address locking and performance issues before making the SP available. No time line on availability though.
Posted : January 21, 2016 4:54 am
Topic starter
Service Pack 11 issue - or at least made worse with SP 11
Posted : January 21, 2016 5:19 am
Thank you Dave - one more check in the "don't do SP11" column for us, unfortunately. If only SP 10 didn't have broken interaction overrides (override pop ups present to everyone) we'd just ride out SP10 until they get one right...
Posted : January 21, 2016 5:21 am
We are having the very same issue since SP11. Causing alot of problems & frustration.
I don't know if we are having this issue: Database shows CHANGe = 6 and no PUBUSER or PUBTIME. but will ask the GE rep when they call to clear the next masterlock ticket I have open now.
I unfortunately don't know how to run the script but would be interested in learning so I didn't have to wait on GE to call back. The last ticket took them 2 weeks to call back!
Thanks
Posted : January 21, 2016 6:20 am
Topic starter
Just ran queries to find all the problems, meds, allergies, observations, and orders affected by this. Ugh. When this first happened we didn't realize that these elements were not being put in the chart. Just ran a proof of concept against observations and I was able to set CHANGE to 2 instead of 6 and the observations showed up in the flowsheet.
Posted : January 21, 2016 11:08 am
We have the same problem since SP11 but are able to fix this using the Centricity Admin Toolbox (available for CPS at least) to unlock the document.
Posted : January 21, 2016 11:09 am
Topic starter
Unfortunately, just unlocking the document doesn't actually sign the clinical list changes. If you look at the clinical list changes from a document you unlock and that has been signed, you will see items like Medications that were added during the visit but they aren't showing in the patient's Medication list. Same with the other categories like obs, orders, allergies, and problems.
Posted : January 21, 2016 12:45 pm
I believe GE's working on this for a patch...here's the scripts I created for use on Oracle, table by table. If you set it as a stored procedure or scheduled task it could update automatically. Normally we only have a few Charts a day. Users are encouraged to sign clinical lists within the update.
As-is; change dates as are appropriate:
--run this just to get an idea of whether there are documents or not (this is optional).
select *
from ml.obs
where change = 6
and sdid in (select sdid from ml.document where db_create_date >= '18-JAN-16'
and status = 'S');
---------STEP 1
create global temporary table jimedoccontb
on commit preserve rows
as
select distinct CONTBID,sdid,USRID
FROM ML.DOCCONTB
where contb_action = 7 and db_create_date >= '18-JAN-16'
AND SDID IN (SELECT SDID FROM ML.DOCUMENT WHERE DB_CREATE_DATE >= '18-JAN-16' AND STATUS = 'S');
---------STEP 2
update ml.obs
set change = 2,
pubuser = (SELECT USRID FROM jimedoccontb WHERE obs.sdid=jimedoccontb.sdid),
pubtime = (SELECT contbid FROM jimedoccontb WHERE obs.sdid=jimedoccontb.sdid)
where change = 6
and sdid = (SELECT SDID FROM jimedoccontb where obs.sdid=jimedoccontb.sdid)
and db_create_date >= '18-JAN-16';
---------STEP 3
update ml.medicate
set change = 2,
pubuser = (SELECT USRID FROM jimedoccontb WHERE medicate.sdid=jimedoccontb.sdid),
pubtime = (SELECT contbid FROM jimedoccontb WHERE medicate.sdid=jimedoccontb.sdid)
where change = 6
and sdid = (SELECT SDID FROM jimedoccontb where medicate.sdid=jimedoccontb.sdid);
---------STEP 4
update ml.prescrib
set change = 2,
pubuser = (SELECT USRID FROM jimedoccontb WHERE prescrib.sdid=jimedoccontb.sdid),
pubtime = (SELECT contbid FROM jimedoccontb WHERE prescrib.sdid=jimedoccontb.sdid)
where change = 6
and sdid = (SELECT SDID FROM jimedoccontb where prescrib.sdid=jimedoccontb.sdid);
---------STEP 5
update ml.allergy
set change = 2,
pubuser = (SELECT USRID FROM jimedoccontb WHERE allergy.sdid=jimedoccontb.sdid),
pubtime = (SELECT contbid FROM jimedoccontb WHERE allergy.sdid=jimedoccontb.sdid)
where change = 6
and sdid = (SELECT SDID FROM jimedoccontb where allergy.sdid=jimedoccontb.sdid);
---------STEP 6
update ml.directiv
set change = 2,
pubuser = (SELECT USRID FROM jimedoccontb WHERE directiv.sdid=jimedoccontb.sdid),
pubtime = (SELECT contbid FROM jimedoccontb WHERE directiv.sdid=jimedoccontb.sdid)
where change = 6
and sdid = (SELECT SDID FROM jimedoccontb where directiv.sdid=jimedoccontb.sdid);
---------STEP 7
update ml.orders
set change = 2,
pubuser = (SELECT USRID FROM jimedoccontb WHERE orders.sdid=jimedoccontb.sdid),
pubtime = (SELECT contbid FROM jimedoccontb WHERE orders.sdid=jimedoccontb.sdid)
where change = 6
and sdid = (SELECT SDID FROM jimedoccontb where orders.sdid=jimedoccontb.sdid);
---------STEP 8
--services
update ml.orders
set change = 0,
pubuser = (SELECT USRID FROM jimedoccontb WHERE orders.sdid=jimedoccontb.sdid),
pubtime = (SELECT contbid FROM jimedoccontb WHERE orders.sdid=jimedoccontb.sdid),
status = 'C',
newrowonchange = 'Y'
where change = 2
and sdid = (SELECT SDID FROM jimedoccontb where orders.sdid=jimedoccontb.sdid)
and ordertype = 'S'
and status = 'U';
---------STEP 9
--referrals
update ml.orders
set --change = 0,
pubuser = (SELECT USRID FROM jimedoccontb WHERE orders.sdid=jimedoccontb.sdid),
pubtime = (SELECT contbid FROM jimedoccontb WHERE orders.sdid=jimedoccontb.sdid),
status = 'S',
newrowonchange = 'Y'
where change = 2
and sdid = (SELECT SDID FROM jimedoccontb where orders.sdid=jimedoccontb.sdid)
and ordertype = 'R'
and status = 'U';
---------STEP 10
update ml.assess
set change = 2,
pubuser = (SELECT USRID FROM jimedoccontb WHERE assess.sdid=jimedoccontb.sdid),
pubtime = (SELECT contbid FROM jimedoccontb WHERE assess.sdid=jimedoccontb.sdid)
where change = 6
and sdid = (SELECT SDID FROM jimedoccontb where assess.sdid=jimedoccontb.sdid);
---------STEP 11
update ml.problem
set change = 2,
pubuser = (SELECT USRID FROM jimedoccontb WHERE problem.sdid=jimedoccontb.sdid),
pubtime = (SELECT contbid FROM jimedoccontb WHERE problem.sdid=jimedoccontb.sdid)
where change = 6
and sdid = (SELECT SDID FROM jimedoccontb where problem.sdid=jimedoccontb.sdid);
---------STEP 12
commit;
---------STEP 13
truncate table jimedoccontb;
---------STEP 14
drop table jimedoccontb;
Posted : January 22, 2016 5:56 am
Topic starter
Jim, I was working on the same thing but I think I like your method better. Also, I missed the assess and directiv tables. One question, why do you have a db_create_date in your update statement for the obs update and not on any of the other tables? Is there a reason for this?
Thanks!
Posted : January 22, 2016 7:09 am
David, since the OBS table is so big, it felt better to have another select criteria in order to limit the scope. I didn't run any performance cost checks so it may or may not be of any help.
It was written originally during our Christmas luncheon and I may also have been distracted by desert.
Posted : January 22, 2016 9:34 am
Page 1 / 2
Next
