anonymous wrote on Tuesday, January 26, 2010:
Only a small amount of work is needed for OpenEMR to meet this MU requirement.
See http://www.openmedsoftware.org/wiki/Demographics for details.
Please review and comment.
sunsetsystems wrote on Wednesday, January 27, 2010:
There are already demographics items and corresponding lists for ethnicity and language. Or perhaps what you mean is to replace the default contents of those lists?
anonymous wrote on Wednesday, January 27, 2010:
Hi Rod,
Yes, we know there is already a list for language and ethnicity, respectively. So it’s a matter of adding to the lists. The concern is when there are different wordings for the same thing. Fortunately, CAIR reads the codes and not the text.
The challenge here is that we don’t know what is required by other states. We will have to deal with each state separately.
blankev wrote on Wednesday, January 27, 2010:
If you want to keep OpenEMR with International standards, you have to keep in mind what Codes can be used in what situation.
No tonly the different States in US might have different coding systems. In the Netherlands they have a different code from the US for Demographics and Religon and Ethnicity. The WHO has e different Code and the UN has a different code. This has nothing to do with Translations but with different interpretations of Demographics and who wanted to invent the wheel again…
Is there still an option of keep an open MySQL table, to be filled with codes of different coding systems during installations? Once all interaction is in place it is hard to change just one table with a new coding system.
The consequences will be that the use of healthplans and other use of these Demographic tables used with different but local registered codes has to be developed with some kind of open International policy inmind. Or something has to be in place like the Brady translation gmail-document where you can change any translation into something more useful for any local situation
Example changing OpenEMR with translations:
Changing ICD9 and ICD into ICD10 in Brady Translation or in Administration language and change, translations gives nice results and almost no problem with other interactions. Fee and billing have to have some changes in tables and/or MySQL but for the general use of the OpenEMR program itself it can be used and works as expected. Just translate. Be sure to use the right table/codes .
Pimm
anonymous wrote on Wednesday, January 27, 2010:
Hi Pimm,
I don’t see code inclusion as a problem. CAIR (California Immunization Registries) codes can be managed in the PHP codes and will not be displayed to the users. You won’t even know if they are there. There are a lot of OpenEMR codes not used/seen by the users.
As for changing codes, I would assume that OpenEMR can handle this already (???).
Some of the Demograhpics fields can be made to be controlled in the setup configuration or in Administration. For example, if you don’t choose US and California, then you don’t see the CAIR fields.
sunsetsystems wrote on Wednesday, January 27, 2010:
This is an important point. There is a table of code types and their attributes in custom/code_types.inc.php. Logic that is specific to CPT4 or ICD9, etc. should not be hard-coded into OpenEMR. The current exception is the insurance claim generation logic which is highly US-specific.
anonymous wrote on Wednesday, January 27, 2010:
Just to clarify, I did not say “embed the CAIR codes with PHP codes”. I said “they can be managed in PHP codes” as a techie talking to an end user. So yes, the “codes” will be put in the “”“codes”"" table.
blankev wrote on Wednesday, January 27, 2010:
Thomas,
thanks for the explanation. So California has the CAIR codes, is there an option to use PIMM - codes without need to be afraid that I repeatedly get a patient for PAP smears en Breast examinations if I use the wrong coding/translations in the different tables?.
For registration I can understand that code numbers are sacred for Developers.
For medical reasons Codes are always connected to the same person and same disease…… so FLU vaccination in CAIR should also be the FLU vaccination in PIMM-Code (and that was all I wanted to have in place with your solutions. But it seems that this was a not needed discussion, since from the beginning you was aware of this coding problem.
It could be that I see gosts, but I really want to be able to “one way or another to” be able to make use of your program efforts, since this is an option I always liked, did not find it in any EMR program.
_
2010-01-27 16:14:32 VET
This is an important point. There is a table of code types and their attributes in custom/code_types.inc.php. Logic that is specific to CPT4 or ICD9, etc. should not be hard-coded into OpenEMR. The current exception is the insurance claim generation logic which is highly US-specific._
It was this that refrained me for so long to make changes to the different tables. But I changed in YOUR Code_type file ICD9, CD4 and HCPCS and filled them with a local billing code system the ICPC codes an some frequent Laboratory codes. I did not need it but I even tried an extra coding tabel for odd cash receipts and that was no problem. It seemed to work and changing the names of the codes mentioned in US-clinic was all it took. Uploaded the other codes with CSV files. In Fee sheet I had some problems but after some changes in List this was also corrected. And NO I did not have any problems with Insurance since we claim the Insurance a different way.