Welcome to the NEW CHUG— your ultimate destination for cutting-edge insights and discussions at the intersection of healthcare and technology.

Our platform is dedicated to exploring the dynamic landscape of healthcare technology, empowering professionals, enthusiasts, and innovators alike with the knowledge and resources to navigate the rapidly evolving field.

From telemedicine revolutionizing patient care to the transformative potential of artificial intelligence in diagnostics, we delve into a myriad of topics shaping the future of healthcare delivery. Whether you’re a seasoned healthcare IT professional, an aspiring entrepreneur in the digital health space, or simply curious about the latest innovations, our curated content, expert interviews, and thought-provoking articles provide a comprehensive exploration of healthcare technology’s most pressing issues.

Join us as we navigate the forefront of innovation, driving forward the transformation of healthcare for a healthier, more connected world.

Have questions or suggestions? Please use the contact button below.

Notifications

Clear all

CPS 12 SP3 CAUTION - Data Loss (Race) during upgrade

CPS, C-EMR, PM

Last Post by Anonymous 1 second ago

10 Posts

6 Users

0 Reactions

64 Views

RSS

mdoak

(@mdoak)

Posts: 92

Estimable Member

Topic starter

This has been mentioned before as an individual message during another thread, but I think it's a big enough deal to point out in its own thread.

When upgrading to CPS 12 SP3, you will lose the recorded race for some races in your database - most importantly, this includes WHITE people which happen to be a very high percentage of our patient populations. I have confirmed this to be the case by looking at backups of our databases that I took before I did the upgrade.

So now, I am faced with the prospect of telling our staff that they need to re-record the race for everyone or I need to spend a couple days restoring copies of these seven db backups to an online state, extracting the IDs of all the white people in the "PatientRace" table and then inserting the appropriate rows into the same table on the upgraded databases.

To anyone who hasn't upgraded, you could probably save yourself some time by getting a query of all your patients/races ahead of time before you do the upgrade.

I opened a case with support for good measure, but I'm not optimistic there is any options besides the two I have proposed above. I do see the database has a "PatientRace_BAK" table now, but it's empty. Maybe it's something they thought of during planning, but never implemented?

Great quality control...

-Matt

Posted : June 23, 2014 1:30 am

jhuckaby45

(@jhuckaby45)

Posts: 65

Estimable Member

This also happened at our site when installing SP3 on CPS12.

Justin

Posted : June 23, 2014 3:14 am

tnc

(@tnc)

Posts: 517

Honorable Member

mdoak said:

This has been mentioned before as an individual message during another thread, but I think it's a big enough deal to point out in its own thread.

When upgrading to CPS 12 SP3, you will lose the recorded race for some races in your database - most importantly, this includes WHITE people which happen to be a very high percentage of our patient populations. I have confirmed this to be the case by looking at backups of our databases that I took before I did the upgrade.

So now, I am faced with the prospect of telling our staff that they need to re-record the race for everyone or I need to spend a couple days restoring copies of these seven db backups to an online state, extracting the IDs of all the white people in the "PatientRace" table and then inserting the appropriate rows into the same table on the upgraded databases.

To anyone who hasn't upgraded, you could probably save yourself some time by getting a query of all your patients/races ahead of time before you do the upgrade.

I opened a case with support for good measure, but I'm not optimistic there is any options besides the two I have proposed above. I do see the database has a "PatientRace_BAK" table now, but it's empty. Maybe it's something they thought of during planning, but never implemented?

Great quality control...

-Matt

Per this email I just checked and can confirm that it happened to us as well.

I do my upgrades by building new servers, CPS 12 included, so I do have access to my old DB still. I am a noob when it comes to SQL queries but would I be able to do what you say with the query on the old DB, then inject that information to the new DB? The problem seems to be renaming "caucasion" to "white"; this is probably a government thing for MU or something.

Mike Zavolas

Tallahassee Neurological Clinic

Posted : June 23, 2014 3:20 am

mdoak

(@mdoak)

Posts: 92

Estimable Member

Topic starter

I THINK that would be possible although i haven't gotten as far as figuring out the specifics yet. I received a call back from someone at support saying he might have a better solution, but I haven't been able to hook up with him and look at it. I would like for them to resolve it if it's possible before I take more drastic measures. I will post back with what I find.

I believe what we are talking about would involve extracting all PatientIDs and PIDs that were white from the old DB and then doing an insert into the PatientRace table on the new db for each one and setting the PatientRaceMID to whatever the new value for white is. In one extremely small example, we had 1800 rows in the PatientRace table and after the upgrade, it is only 400-something.

We could probably use Excel or something and fill column A with the PatientIDs, Column B with the PIDs, Column C with the new value for white (filled down) and then in column D, a "formula" that would be your actual insert statement with the right PatientID, PID, and new ID for PatientRaceMID filled in from the first three columns. Then copy/paste all the column Ds into query analyzer and execute. If I end up having to spend the time to do that, I can post the details.

-Matt

Posted : June 23, 2014 4:02 am

mdoak

(@mdoak)

Posts: 92

Estimable Member

Topic starter

It turns out that GE support was very useful on this occasion (thanks Robert!). They have a script which looks in the "PatientProfile_BAK" table which must be created during the upgrade and grabs the old race info from there and brings it into the PatientRace table. The comments at the top of the script indicate SPR 58442 so if you are working with support, give them that SPR and it will probably help them zero in on what you need. Check first to make sure your PatientProfile_BAK table has information populated in the "RaceMID" column. If it does, this script will work for you.

If anyone needs the script, please PM me your email address and I will get it to you. It took about 2-3 seconds to run on our largest database (fixed 30,000 rows). You could probably run it after hours as a precaution and back up first just to be safe.

-Matt

Posted : June 23, 2014 6:31 am

Jonathan

(@jonschultziddc)

Posts: 26

Eminent Member

Thank you for making us aware of this issue!

Quatris (for GE) just upgraded us from CPS 10 to CPS 12.0.3.

Race options in Registration post-upgrade include White (new for CPS 12) and White or Caucasian (carry over from CPS 10). Existing patients retained White or Caucasian during the upgrade. However, the upgrade added White or Caucasian as a Race Subcategory of Unspecified, which apparently won't count for Meaningful Use (see below).

I'm curious to see what the SPR 58442 script does.

From the CPS help file:

Caution. The default race category is "Unspecified." However, if you use this category, any patients with a subcategory linked to an Unspecified race are not counted in the Meaningful Use Demographics measure. If you attempt to save a subcategory with an Unspecified race category, you will receive a warning message.

Posted : June 23, 2014 2:41 pm

chaddix

(@chaddix)

Posts: 177

Estimable Member

This happened to us when we upgraded from CPS 11 to CPS 12. As indicated above, SPR 58442 works perfectly to resolve the issue. I tested against a restored backup of our CPS 11 database and found no problems with the script.

In short, it works by:

1. Identifying patients with the RaceMId of White/Native Hawaiian in the table MedLists_BAK, a backup of the old table MedLists.

2. Creating a new entry in the (new) PatientRace table with the appropriate PatientRaceMid.

Posted : June 25, 2014 5:02 am

cecild

(@cecild)

Posts: 314

Reputable Member

We just loaded CPS 12 Version 12.0.0.1369 on demo server and had our CPS 11 data populate it and my Race fields seemed to have converted fine.

Cecil

Posted : June 25, 2014 5:09 am

mdoak

(@mdoak)

Posts: 92

Estimable Member

Topic starter

This may only be affecting people who upgraded to the original version of 12 and then subsequently to another newer version. We didn't have any problems with 12 originally as it relates to the race until we applied SP3.

Posted : June 25, 2014 5:14 am

tnc

(@tnc)

Posts: 517

Honorable Member

MDOAK said:

This may only be affecting people who upgraded to the original version of 12 and then subsequently to another newer version. We didn't have any problems with 12 originally as it relates to the race until we applied SP3.

As it turns out mine was fine. I had GE look at it and it seems that the patients I checked were marked at undetermined. I verified this on the old DB after discovering this with GE. What are the chances I picked more than one patient, each with 'undetermined' as the race. I should have picked actual humans I knew who come here as a patient instead of a test patient but I am always worried about HIPAA stuff.

We did apply the 58442 patch when we did the upgrade. Anything missing would have been put back from the backup table

Mike Zavolas

Tallahassee Neurological Clinic

Posted : June 25, 2014 5:24 am

24 Forums
9,940 Topics
39.9 K Posts
0 Online
6,470 Members

Forum Icons: Forum contains no unread posts Forum contains unread posts

Topic Icons: Not Replied Replied Active Hot Sticky Unapproved Solved Private Closed