ICD10 again

I agree, there is not much for an interface analyst to do with the move to ICD-10.

For some transitionary period it is possible messages could contain both the ICD-9 and ICD-10 codes and so I would think some accomodations in the Xlates or Tcl code that transform the messages would be necessary.

It is also possible the vendor will not send the ICD-10 code in the same location as the ICD-9 code and so the same thing – some accomodation inside Cloverleaf may be necessary.

Like wise receiving systems may have differences regarding co-existance of multiple coding sets and their locations.

As far as teting I suspect Integration Engineers will perform the same duties as with any Integration – that is validating messages received, transformed, and delivered properly.

Those are my thoughts.

I also believe that the hype and accompanying expense are not equal to the difficulty of this project. I think it is overblown and consultants are making a lot of money. Certainly our HIS has to be modified and extensively tested, and our coding and billing systems have to be upgraded and tested.

We expect that field sizes will change and some ICD10 values may be present where none were before, but basically it is yet another ‘medium to large’ project that has to be managed effectively. Unfortunately, it is easy to sell consultant services when ~the revenue stream is threatened~ (ominous music here).

If your organization has a good project management culture then this should not be a problem.

Besides what you outlined as responsibilities, there are two things we’ve identified here that you need to be aware of:

1.  ICD-10 codes and descriptions are much longer then their ICD-9 counterparts, so you may need to tweak variants so that there is no truncation of data due to Xlates and field lenghts.

2.  Already brought up, but consider that some systems will send you both ICD-9 and ICD-10 codes in the same field (for us that’s 3M), so you may need to filter which one oges to a particular destination.

Good luck,