Notifications
Clear all
Topic starter
Wondering if anyone has seen this, and might know how it happened. A provider signed a note, and the content of the note saved as one long, run-on sentence, with what appears to be control characters, line feeds, etc.... showing within it as well. See below. This is just a sample...the entire note looks like this, and we have no idea how it happened. This is the only instance that we know of.... Please share if you have seen this. thanks.
John
\par\cf3\sscharaux00\par\cf0\fs24\sscharaux21\b HPI -- Diabetes-Specific Symptoms \fs20\b0\par He does not at this time demonstrate an understanding of the dietary principles of diabetes management. The patient reports sensory loss to be present at this time. He performs regular foot examinations. The patient does not perform home glucose monitoring. He is not completely following diabetic dietary principles at this time. \b Additional Barriers: \b0 Educational\par\par\fs24\b Diabetes Management Exam \fs20\b0\par\fs24\b Foot Exam (with socks and/or shoes not present): \fs20\b0
Posted : June 17, 2015 4:47 am
We have this from time to time as well. I opened a ticket with GE but they were unable to determine what was causing this. This never occurred in versions prior to 9.8.
Luckily the data is still saved. I am unsure of the exact cause though and would be curious if anyone else has experienced this.
Dave
Posted : June 17, 2015 5:01 am
Did your provider paste this from a word processing system (ex: Word) into CPS/EMR?
Posted : June 17, 2015 5:06 am
We have this every once in awhile. In our case the "chunks" that are saved in the docdata table have DDID's that are out of order. We are on CPS 12.0.6
Posted : June 17, 2015 5:15 am
That's formatting controls. From my understanding, if the Centricity app can't parse the formatting data correctly, it simply displays it all as text. I believe Centricity generally follow RTF formatting protocols, but there could be exceptions I'm not aware of. I often see suggestions to copy formatted data, for example from a word processor like Word, to Wordpad first. Wordpad sanitizes the content to true RTF, which Centricity does much better with.
Posted : June 17, 2015 5:20 am
We've seen this a few times and as others have mentioned the best we've been able to determine is that is can happen when copy/pasting. We've seen it when copying from word as well as copying off of the internet.
Thanks
Mike
Posted : June 17, 2015 6:22 am
This just happened to us for the first time. Do you have an SR or SPR number I can use to refer to the problem? Now that I know it happens to others I want to report it.
I'm sure the text wasn't pasted in from Word or anywhere else, and the provider wouldn't have signed it with the whole note looking like that. It appears that all documents are stored with these rtf control codes, and Centricity converts when displaying each time. Some corruption caused this one to display incorrectly after signing.
I copied the text from the bad document and used Word to replace all \par with ^p (Paragraph) \tab with ^t, turned on bold at \b, etc, cleared out junk, moved the top half of the document to the bottom and got a nice-looking note. I pasted to wordpad, then into an append. I really don't want to do that on a regular basis, but we didn't have to redo the whole visit with clinical list changes.
Posted : June 17, 2015 6:31 am
Each document (a record in the DOCUMENT table) stores its text as RTF data in one or more records in the DOCDATA table. What's happened here - and we've seen it happen many times - is that the DOCDATA records have been put in the wrong order.
When putting together the data for display, Centricity concatenates all the DOCDATA.DATA values it finds for that SDID (that's the document identifier), ordered by DDID. If the DDID order doesn't correspond to the order of the various snippets, the result is what you're seeing.
All RTF documents start with something like this:
{\rtf1\ansi\ftnbj{\fonttbl{\f0 \fmodern Courier New;}}...
If it doesn't start with that \rtf1, then the document cannot be read as RTF data. Just like a web page has to start with an html tag. Without that, it will be interpreted as plain text.
For a given SDID, the DOCDATA record with the lowest DDID should start with that tag. But if the records are out of order, the resulting block of text isn't going to start with that, therefore Centricity interprets it as plain text and you get garbage on your screen.
I've been able to resolve this in the past by simply analyzing the DOCDATA records for that document. Identifying the first piece should be easy, because you know will start with that rtf tag. From there you can compare the end of each piece with the beginning of the others to determine what order they should be in. Copy those strings into Notepad, and update each DOCDATA record with the appropriate line of text. It's a pain, but it works, at least for a single document.
Posted : June 17, 2015 6:52 am
Oooohhhhhh.... This makes perfect sense!
For those of who who don't want to go into the database like that, I have a quick and simple solution that will give you a pretty note in just a couple of minutes. I just tried it with my problem document and it worked.
1. Copy all of the garbled text and paste into Notepad.
2. Find the {\rtf1 code and select all text from the { to the end of the file.
3. Cut it and paste into the top of the file.
4. Save as xxx.rtf
5. Open the file and see your note. Hopefully you won't have more than one segment to move, but it's possible you'll have to repeat steps 2-3 to move text.
6. Append the offending document and paste in the formatted text.
Posted : June 17, 2015 7:22 am
GE first told me they hadn't heard of this but when I told them about this post and asked to make sure they actually checked with and/or reported to engineering, the next response was that engineering is aware and it is listed under SPR CISDB00062408.
Posted : July 10, 2015 7:57 am
I've discovered the cause of this. Let's call it "the odometer bug." 🙂
CPS writes data to the DOCDATA table in chunks, and increments the DDID value of each successive chunk by 20. So for a given document, you should see...
DDID DATA
1721108760999920 {\rtf1\ansi\ftnbj...
1721108760999940 chunk2...
1721108760999960 chunk3...
1721108760999980 chunk4...
The problem is in what happens when CPS tries to write chunk5. See how those last six digits are about to roll over to all zeros, like an odometer? You'd think the preceding digits would increment from 60 to 61. But they don't. So you end up with...
DDID DATA 1721108760000000 chunk5...
When CPS re-assembles these chunks for display in the documents screen, it assembles them in order by DDID. Since chunk5 now has a lower DDID than the other chunks, it's added first, and the others are added after it. This screws everything up, since not only is the information out of order, but the rtf tag that is supposed to come first isn't there.
Every affected document in our database shows evidence of this problem. GE may know about this already, but I'm going to tell them about it anyway. If you're interested in finding all affected documents in your database, this script will get you there. I'll caution you, however, that it is not a fast script and may take 15-20 minutes to run, depending on the size of your database. It might be best to do in your test environment with a fresh copy of your production db.
SELECT
dd2.DDID AS preDDID,
dd.*
FROM DOCDATA dd
INNER JOIN DOCDATA dd2
ON dd.SDID = dd2.SDID
AND dd.USERID = dd2.USERID
WHERE dd.DATA LIKE '{\rtf%'
AND dd2.DATA NOT LIKE '{\rtf%'
AND dd2.DDID < dd.DDID
AND NOT EXISTS (SELECT 1 FROM DOCDATA pre
WHERE pre.SDID = dd2.SDID
AND pre.USERID = dd2.USERID
AND pre.DDID < dd2.DDID
AND pre.DATA LIKE '{\rtf%')
ORDER BY dd.SDID, preDDID
Fixing it is a whole other issue, and it's not exactly a quick thing either. So I'm going to wait and see if anyone responds to this looking for the fix before I bother typing it all in here. But I will probably write this up in detail on my Centricity blog.
Posted : July 30, 2015 2:21 am
@ronmoses, looks like GE may have fixed your "odometer" bug in SP10. Although they say it caused CPS to crash, I don't see why it would cause a crash.
Addresses an issue where DDIDs rolled over and were out of order, causing the
application to crash. SPR 63629
Posted : August 4, 2015 11:15 am
