We have encountered an issue with four of our providers (so far). Centricity has a dropdown that automatically fills with the previously viewed patients. This exists in the Patient Chart and the Scheudling Module, and the lists should mirror each other.
A few of our providers have empty dropdowns in the Scheduling Module. The Patient Chart dropdown works as intended. The Scheduling Module dropdown will fill in as the user views patients from there, but it clears once they log out.
We have tried uninstalling and reinstalling the CPS client, but to no avail.
Our vendor has said that this is a known issue with GE, but they don't have a fix. Has anyone seen this before and/or have a workaround/fix? This is a serious pain...
Yes, but on the screen you attached, it's populated, along with the dropdown on the patient chart. It's only empty on scheduling. The dropdown actually has a shape, it's just a big, empty box.
Unfortunately I don't know how it populates the dropdown. I tried a SQL trace because I was curious, but I did not find a query that returned the recently viewed patients.
Someone else may chime in.
-dp
I turned on debugging and looked for what happened only when a patient is selected from the dropdown. I'm putting this here in the hopes that someone may have some experience playing with CPS internal processes. I have also removed the datetime and process Id from all but the first line, as it's identical on every other line.
FROM PATIENT CHART
10/18/2017 14:26:19.107 DEBUG Process Id #2664 ML Thread [Debug] 2664,0B00 - CConnectionCache::ExecuteReadOnlyWithCursorCacheSize - CPatMRUListManager::GetPIDForEMR
$+ CMBCADOConnection::ExecuteExWithCursorCacheSize Start. select PatientProfileID, PatientID from patientprofile where PID = 1615537236643000.000000
$- CMBCADOConnection::ExecuteExWithCursorCacheSize End.
CConnectionCache::Execute - CPatMRUListManager::UpdateMRUList
$+ CMBCADOConnection::ExecuteEx Start. MRUPatientUpdate 1790670512451690.000000, 201287
$- CMBCADOConnection::ExecuteEx End.
FROM SCHEDULING MODULE
10/18/2017 15:07:21.343 DEBUG Process Id #2664 Thread Id #90 [Debug] 2664,07EC - CConnectionCache::Execute - SelectPatientNI
$+ CMBCADOConnection::ExecuteEx Start. upGetPatientId 201287
$- CMBCADOConnection::ExecuteEx End.
CConnectionCache::ExecuteReadOnlyWithCursorCacheSize - CDlgSelectEx::GetList
CMBCADOConnection::ExecuteExWithCursorCacheSize Start. select distinct top 1001 v.PatientProfileId, v.Name, v.PatientId, v.SSN, v.Birthdate, v.Expr1, v.City, v.State, v.Zip, v.Phone1,v.Phone2, v.DoctorName, v.FacilityName, v.MedicalRecord, v.LocAbbrevname, v.ExternalId, v.searchname from vSelectPatient v left join PatientInsurance pi ON v.PatientProfileId = pi.PatientProfileId WHERE ((1=1) AND v.PatientStatusMId = -900 AND v.PatientId = '201287' ) ORDER BY v.SearchName
$- CMBCADOConnection::ExecuteExWithCursorCacheSize End.
CPatMRUListManager::UpdateMRUList seems to be what's called when a new patient is accessed. It then executes MRUPatientUpdate with the PID (this is a test patient we frequently use, not a real person) from the top of the new list and pulls that chart in.
This dynamic list has to be saved in the database, right? And why would CPS use two different methods to build two lists differently?
We recently had this issue with just one user.
We run in a Citrix environment and clearing the users profile resolved the issue.
Mary Kay