Quick summary:
-Immunizations now use the CVX codes which
have been imported into the codes table.
-Also supports previous custom immunization
list in list_options.
-If a previous immunization does not have
a cvx identifier, then it will use the
previous identifier from lists_options.
-Can also force to only use the custom list
in lists_options in Administration->Globals->
Features->Use Custom Immunization List
-Can also map the previous custom immunization
list items to CVX codes in the
Administration->Lists GUI.
Primary author of this code is rammohan <rammohan@ensoftek.com>.
Significant modifications also contributed by bradymiller.
This is testing well and some other MU items are dependent on this code, so plan to commit this evening unless any issues brought to attention.
One initial comment: The numeric code type is supposed to be an invariant identifier. Assigning it as a the maximum existing ID + 1 is not going to work very well. We need a registry for these, perhaps as a text file in the distribution or maybe in the wiki.
Hi Rod,
Why does it need to be invariant? From my knowledge, the only thing that should be invariant across openemr installations is ct_key column in code_types. Note the immunization queries use this to identify correct code type. The code type id is merely used as a connector across codes and code_types tables. Forcing invariable id seems like it would be a mistake since this would essentially not allow users whom have customized their code_types to upgrade their openemr version. Am I missing something?
-brady
Hi Rod,
Why does it need to be invariant? From my knowledge, the only thing that should be invariant across openemr installations is ct_key column in code_types. Note the immunization queries use this to identify correct code type. The code type id is merely used as a connector across codes and code_types tables. Forcing invariable id seems like it would be a mistake since this would essentially not allow users whom have customized their code_types to upgrade their openemr version. Am I missing something?
-brady
It needs to be invariant for at least two reasons:
1. The text version of the code type (e.g. “ICD9”) appears on various web pages and some sites might want to change the way they read. Thus it makes sense for the numeric form (which does not appear on web pages) to serve as the invariant ID.
2. There is some existing logic that is tied to specific identifiers.
Perhaps there are better ways to design it, and even the current design is wrong in that the numeric identifier should be used in the codes table instead of the textual identifier, but those are discussions for another day.
Still not convinced.
1. The labels could be easily dealt with by running them through the translation engine.
2. Agree there is existing code that uses the id for ICD9, but this has no effect on other code_types.
If we want to make the id invariable, then there is no way for upgraders to upgrade automatically and safely to new features that need cvx codes, rxnorm codes, snomed codes, etc.
Still not convinced.
1. The labels could be easily dealt with by running them through the translation engine.
2. Agree there is existing code that uses the id for ICD9, but this has no effect on other code_types.
If we want to make the id invariable, then there is no way for upgraders to upgrade automatically and safely to new features that need cvx codes, rxnorm codes, snomed codes, etc.
Yes you could run the textual code types through the translation engine, but that seems convoluted as the underlying need might not be related to translation. Bottom line is, there needs to be an invariant ID, why should that not be the numeric ID? And if the textual ID is the invariant, then the numeric ID serves no sensible purpose at all.
I think it’s wise to follow the current design until there is a well-thought-out replacement.
Not sure I understand the part about no way to upgrade. But let’s say a site is not using ICD9 codes and so the numeric ID for it gets used for something else, logic that assigns special meaning to it will break, and also they will have a problem if they later want to use ICD9. That’s why we need a “registry” of the codes.
Regarding upgrade (this is extremely important to support several important useful features including eprescribing), here’s a simple example of what needs to be solved:
A previous user added a new ‘code_types’ which then takes up code_type id number 4 (could be SNOMED, RXNORM, ICD10, or some other specific facility code set). If this is the case, then please let me know how you are going to safely and automatically support an upgrade mechanism that brings in support for the CVX codes. If you try to hard-code at code-type 4 then two very bad things will happen to the user:
1. The upgrade sql script will break (since there is already a ct_id with 4, and they have to be unique in code_types).
2. The immunization functionality will break, since it will now thinks the codes with code_type 4 are immunizations (when they are all in fact something else).
This will not only be the case for the immunization codes, but will be the case for any code set we need to add (RXNORM, SNOMED, etc.). If you can provide a solution for this, then please do. Perhaps I missed something.
In the current OpenEMR design, bad things will happen if you change either the ct_id or ct_key of the current code_types entries. For example, the ct_key are use in diagnosis filtering, database token, etc. However, new code_types are more flexible since we have control over them. By making the ct_key invariant with standardized acronyms is acceptable if it allows us a fully flexible mechanism to support upgraders; please see my code to see how it is handled in the upgrade script and in the code itself; very straightforward. I’d argue that we are indeed still using the current design; it’s simply evolving to support code_type upgradability (ie. the ct_key is winning the invariant battle for new code types).
Quick simple counter-points to above arguments:
1. To support customized labels is a minor issue. Can either send through the translation engine or could even make a ct_label field in code_types. Both are straightforward considering the ct_key is really not displayed in many places.
2. How can we create/maintain a registry for a category of fully customizable entries? In the US, there are multiple fields using this software with their own set of codes which is then multiplied by a multitude of countries. Our goal is to support the full userbase.
Maybe I’m just being dense, but I’m not seeing a problem. If the project maintains a “master list” of the ct_id and corresponding ct_key values that are in use, then anyone who wants to make a new code type consults the list and makes a new pair that is unique and submits it to the master list. It’s sort of like creating a new table in the database, you look at the current table names and don’t create a name that is already in use.
This generally assumes that those doing this are working with the community. If necessary, a range of ct_id values could be assigned for private use, very much like IP addresses such as 10.x.x.x or 192.168.x.x are used for that purpose, and users could use them without having to interact with the project.
Oh and again, if you want ct_key to be the invariant ID then the numeric ct_id becomes useless baggage and should be eliminated by changing codes.code_type and the associated logic to use ct_key instead of ct_id. I’m not sure that is best but I wouldn’t object to it. Still though, you’d need a master list of the ct_key values that are in use.
Even if we decide to make a master list for ct_id numbers, this will essentially not allow upgrading for any previous users that have already added new code_types. Is this acceptable?
One of my primary goals to keep/build a userbase is a smooth upgrade process. If you know of another solution other than mine that will do this, I’d be happy to utilize it.
Also don’t think I should be responsible for cleaning up other code to implement this feature. I’d be happy to create a wiki page of master ct_key text values, though along with a summary of which ct_key values require specific ct_id values (ICD9,CPT4,HCPCS) to maintain compatibility. This could then be the launching point for starting to “clean up” this issue after certification.
Brady, I suggest that if you must auto-assign numeric code types, then also assign a minimum value to those such as 100 or 1000. That way there will be little danger of auto-assigning on top of existing types that are fixed but not yet in use at a given site.
Definitely don’t want to add to your work load needlessly! My point about the numeric ID being useless in your scheme is to say that it must have been intended to be an invariant ID, otherwise it would not exist.
Agree with using ct_id of 100 or greater to avoid conflicts with previous hard-coded elements by current OpenEMR users. I just added a commit that does the following ( http://github.com/bradymiller/openemr/commits/cvx_final ):
1. On new installation, ct_id of the CVX code_types are set to100
2. On upgrade, ct_id of CVX code_types are either 100 or if ct_id of 100 already exist, then 1 plus the maximum ct_id (ie. so the ct_id will be greater than or equal to 100).
Also placed a wiki page to keep track of code_types here (page also describes the invariant issues of ct_key vs ct_id and a plan of what to do after we get certification to clean things up a bit): http://www.openmedsoftware.org/wiki/Code_Types
Hi Visolve,
I passed this on to Ram (at Ensoftek) whom is working on that part of the code. I’m guessing Ram will come up with the needed mods rather quickly.
thanks,
-brady