Notifications
Clear all
Topic starter
We have a Corrupt Chart that is causing many problems that once you access this chart and go to another patient the problems follow the user. The only temporary resolution GE has given us is to have the user log completely out after being in the affected chart and then all issues resolve. We are checking to see if anyone else has experienced this and if there is a permanent solution and/or an SPR that you have been attached to.
Thanks!
Posted : March 24, 2016 2:55 am
This may not be the same issue you are experiencing, but we have had a similar issue as a result of the FH-SH-CCC form containing too much data. The error popup never popped up and it took a while to track down the issue. Once a chart with too much data was opened all charts opened by the same user were a problem. We ended up having to go through the database looking for patients with X number of records in the FamilyHealthHistory table and inactivate entries for relatives not considered critical by our providers.
I only got the popup to come up once in our case when running an SQL trace. One of the traces showed the too much data error and I created a stored procedure that goes through and cleans up any affected records periodically. GE was no help.
Posted : March 24, 2016 3:53 am
Topic starter
Did you find any common thread between the charts like any special characters listed in the General Comments or just a large amount of structured data? The one patient in question has no family history that is in the structured data field and only listed in the General Comments box. We are just trying to put a thumb on what we think the common thread could be and try to find a resolution.
Posted : March 24, 2016 4:03 am
We had this issue also. We found it had to do with a large amount of OBS terms. We ran the Archive OBS script and it fixed the issue.
Laurie
Posted : March 24, 2016 5:36 am
In our case it was a large amount of structured data. Generally too many relatives with FH history information. In our case we set everything to inactive except for Mother, Father, Full Brother, Full Sister, Half Brother, and Half Sister. We may still have the issue if any of those have excessive history, but I haven't received any reports of this problem since.
We first tried running the archive script as Laurie suggests, but in our case the problem persisted mainly because this was recent data.
Steve
Posted : March 24, 2016 5:50 am
Have you checked the ErrorLog table on the user that gets the error? We get errors that follow our users around even after log out sometimes. In our case the error appears to be Centricity trying to insert a row with a primary key that already exists.
Posted : March 28, 2016 5:00 am
I'll have a go with my answer. We have three SQL scripts that we run against these corrupt charts that (most of the time) fixes these problems.
First one is to check if a document has an incorrect "CONFTYPE". Grab the PID from the patient you are searching for.
select top 100 * from PERSON
where LASTNAME = 'last' and FIRSTNAME = 'first'select * from document where
conftype IS NULL and
PID = '1652716788006910'Begin Tran
Update DOCUMENT set CONFTYPE = 0 where conftype IS NULL and PID = '1652716788006910'
ROLLBACK -- IF You Make A mistake
commit -- IF you're confident of your change
Second one checks for NULL flags in the chart. Make sure to grab the id from the select statement.
use CentricityPS
SELECT * from FLAG
where SUBJECT = 'last, first'Begin Tran
Update flag set status = 1 where id = '1737896938631650'
ROLLBACK -- IF You Make A mistake
commit
Third one is to fix when viewing a patient's Contacts cause Centricity to freeze up. Make sure to change the PatientId to the patient in question.
select * from PatientProfile
where PatientId = '108213'select * from PatientRelationship
where PatientProfileId = '108213'delete PatientRelationship
where PatientRelationshipId in (204757,204756, etc.)
Posted : March 28, 2016 9:26 am
