Handling of IDC-10 Translation

davidbruchmann wrote on Wednesday, December 17, 2014:

Hi Fsgl,

thanks for the hints, in the moment I can’t completely follow your descriptions.
But I’ll verify it tomorrow and get you back for any questions.

Best Regards,
David

blankev wrote on Wednesday, December 17, 2014:

David,

your idea is also a clear one, don’t forget to give it also a follow-up. Having the ICD9 or ICD10 in a separate “translation”-table could give the standard International-translations in every language an easy option to include.

ICD9 or ICD10 have codes numbers and/or Characters.

There is an official translation available in many languages. Just a matter of copy <=> paste in a spreadsheet environment and include the preferred languages in the OpenEMR production site.

Your observation of having non-translated codes in the translated language, alike in OpenEMR translations, is very important but might be of non-existence.

fsgl wrote on Wednesday, December 17, 2014:

After re-reading the .csv file creation tutorial, it is not the most efficient way to import the translated ICD-10 codes. Even though 3 columns of the codes table are the main focus, the other 9 columns require zeros. That is a lot of zeros.

It would be easier to concatenate, but I’m sure it will be tedious to drag the lower right corner for all 9K/12K codes.

A more efficient way would be a modification of David Hantke’s post. His instructions are for the pharmacies table, which has 4 columns; but they can be adapted for the codes table with a good understanding of that table’s structure.

If we run into trouble, we can always ask David for help.

fsgl wrote on Wednesday, December 17, 2014:

Yet another thought.

If translated codes are identical to that downloaded from WHO in structure, then it may be possible to deploy the External Database Import Utility. If feasible, this method requires the least amount of work for everyone involved.

  1. zip Excel .txt file.
  2. move zip file into var/www/openemr/contrib/icd10.
  3. see attachment.

Sharing the data set would involve giving colleagues the zip file for them to import with the same utility, thus bypassing .sql export step.