We have begun loading ICD-10 codes into production on our CPS 12.0.8 system. Prior to doing this, we loaded codes 4 times in development. Here are our results and known issues with loading ICD-10 codes.
In development:
Our servers in development are both virtual, so we know the DB isn't going to run as fast as our physical production DB server. with that being said we ran into several issues loading codes. We also did all of our testing on systems that only maybe 2-4 people max are logged into, so it would simulate off production hours.
Result 1. After selecting a range to load, for example all of the N codes for all specialties (as per GE best practices) sometimes it would load okay with no errors, other times it would pop out two windows stating "system has encountered an error".
Error 1 syntax:
Error occurred in class , method CLoadCodesView::OnLoad
Error 2 syntax:
Error occurred in class CConnection::SendCmd, method CLoadCodesView::LoadItems
SQL Query=Microsoft SQL Server Native Client 10.0(CConnection::Open) in file DBAccess\MBCADOConnection.cpp on line 551 with connection CConnection::Open
File=DBAccess\Connect.cpp
Line=468
Number=2601 State=23000 Source=Microsoft SQL Server Native Client 10.0
Description=Cannot insert duplicate key row in object 'dbo.Diagnosis' with unique index 'Diagnosis_Code_CodeType_IX'. The duplicate key value is (V80.01, 1).
Number=3621 State=01000 Source=Microsoft SQL Server Native Client 10.0
Description=The statement has been terminated.
However, quality checks prove there is no real problem.
1. Find the diagnosis code in the range you just loaded. e.g. I loaded the Z range of codes. When I go to Administration >Charge maintenance (in the top nav bar) > Diagnosis and search for a code in the range I just selected, I find that it shows up with all the specialties checked and the appropriate ICD-9 code displayed.
2. Add the problem to a test patient list - Yep, can do it
3. We even sent out a claim with the same code we had checked in the previous 2 steps, it's all good.
GE will tell you that there is a fix for these errors, and there sure is, but let me tell you that you don't want to do it. The script that they run will fix that error code, but it WILL wipe out the specialties on all the ICD-10 codes you have already loaded.
Look at it this way. If you get the errors, your codes loaded properly........ Seems to be right in line with GE logic.
Result 2: The windows wheel of business will just spin and spin. Usually, a code set of about 800 codes takes about 2-5 minutes before getting result 1. However, from time to time, it will just spin for hours. It is then time to use the old trusty reset CPS process and restart your client. You will see that your codes load. We usually wait about 30 minutes just to make sure no issues will occur before we reset cps process. If we experience this, we complete our search of diagnosis codes by either doing a search for problems, or going to the administration, charge maintenance path and do a search as outlined above.
Result 3: (EXTREMELY RARE) after electing to load your codes, the spinning wheel will go for a few minutes, disappear, and the list of codes in the load codes window you were just working with disappears. I have to assume this is how it is supposed to work. However out of the 30 times I have loaded codes between development and production, this only happened 2 times. I did my checks to make sure the codes were loaded and they were.
In production: we have only loaded the N,O,R,Z, D, B, E so far.
1. Initially, we only loaded about 10 N codes to make sure nothing blew up. I had administration, billing, and clinical on notice of what we had done and check all of their operations. No one had any issues. We actually got Result 3 when we loaded about 10 - 30 codes at a time.
2. We then loaded another 30 ish N codes with result 3.
3. Then we finished the N range of codes with result 2. We let it spin for about 3 hours since this was production. We had to make sure we didn't cut the process off and screw up the database. When restarting the client we did our quality checks.
4. We have then loaded the O, R, Z, D, B, E ranges with result 1. Quality checks indicate the codes had loaded.
****** Always make sure that before you load codes, your specialties don't magically uncheck themselves before clicking that go button. This happened twice in development. Slow is smooth, smooth is what we want. if this happens, you get to manually add specialties to those hundreds of codes one by one.
Had many of the same issues that you did and all my codes are loaded for all specialties as well. Typical GE logic!!!!!!!! You a right
I loaded ICD-10 diag codes in development as well and saw the same results. Codes all loaded 'successfully', but intermittently saw the same errors as mentioned. Quality assurance checks seem okay so far, but a bit worried about the 'monster in the closet' that may rear its ugly head down the road? I will post my results once I load the codes into production... AFTER i return from vacation. 🙂
Hi All,
I contacted GE and here is their response:
Result # 1
Reported problem probably happened because V80.01 is a related ICD-9 code to an ICD-10 code in the range they are attempting to load, and V80.01 does not exist as an ICD-9 code in the database. This is the issue is reported in SPR 63748.
Result # 2
We have not seen this nor have record of it being reported.
Result # 3
Yes, this is the correct behavior.
Terri
Are you talking about the Special Knowledgebase update just release or is this something else? CPS only maybe?
Update:
We have loaded all codes successfully, with most results ending with Result #1. Ironically, loading the V code range ended with result #3. Either way, everything loaded properly.
DavidShower, Not the KB update, just loading ICD-10 codes in administration in CPS 12.0.8
We loading them all but it took something like 30 to 45 minutes. How powerful is your test DB server? Cores and ram?