mcaloon wrote on Sunday, March 25, 2012:
Brady,
Never mind… found it in the ‘documentation’ …. the code… 
Mac
mcaloon wrote on Sunday, March 25, 2012:
Brady,
The file ./Library/classes/ClinicalTypes/codes.php has *a lot* of arrays with hard-coded values. Is there a reason why these aren’t stored in appropriate (new perhaps) tables in MySQL? I am beginning the code changes for ICD10 and was wondering whether there was another reason for this approach in the file… or should we take the time to clean it up?
Mac
bradymiller wrote on Sunday, March 25, 2012:
Hi,
These are for the Clinical Quality Measures (CQM) and maybe some Automated Measure Calculations (AMC) with some wiki documents on those here:
http://www.open-emr.org/wiki/index.php/CDR_Engine
These are used in the rules for those engines. Rather than remove these, in the future, may also want to add the ICD10 codes, which are documented in the extensive CQM documents: http://www.cms.gov/apps/ama/license.asp?file=/QualityMeasures/Downloads/EP_MeasureSpecifications.zip
Note there are also some diagnosis filters in the CDR engine main rules that can be configured via the Administration->Rules GUI, which are covered here: http://www.open-emr.org/wiki/index.php/CDR_User_Manual
As above, will also need to add ICD10 equivalents to these rule sets in the future.
So, in summary, wouldn’t worry about those for now. At some point, will actually need to add to them.
-brady
OpenEMR
mcaloon wrote on Sunday, March 25, 2012:
Greetings…
I see that RxNorm and Snomed files have on ongoing release schedule and that publish date is embedded in the file name and used when locating the files during the load process. Whereas in ICD the releases are much more infrequent and likewise a different file naming convention is employed by the WHO. For example, the current ICD 10 file being used was published in 2008 so the file name is icd102008enMeta.zip and there is an ICD 11 release currently under way for a release date in 2020 which will most likely be named icd112018enMeta.zip when it is released in 2018 (pure speculation). The question being posed is associated to the code in standard_tables_manage.php where the logic is wrapped around this embedded date in the RxNorm and Snomed file names. As the ICD files have a different naming convention, my instinct is to make the ICD code accommodate the new naming convention _(which means we’ll be deriving the revision_date column value, for example June 30, 2008 for the current file) _. Alternatively we would have to rename the WHO’s published file name enforcing an openEMR file naming convention on entities that will publish files we need in the future. Any thoughts on which approach is preferred? I think using published files names is the way to go…
Mac
mcaloon wrote on Monday, March 26, 2012:
Greetings …
Integrating the ICD code into library/standard_tables_capture.inc and wanted to review the referenced file Table_scripts_mysql_rxn.sql but it is not in my source tree. Where can I get a copy of that file? Still hunting around…
Mac
bradymiller wrote on Monday, March 26, 2012:
Hi Mac,
Agree using published files is the way to go. What about the newer ICD10 published in 2010, which is “icd102010enMeta.zip”? I’m thinking that grabbing the year for revision_date and then the language code (in this case en) for the revision (this will then allow users to “upgrade” to a different language of the same version). Regarding the Table_scripts_mysql_rxn.sql, that is part of the RXNORM stuff; see here how to download/import both the RXNORM/SNOMED tables:
http://www.open-emr.org/wiki/index.php/Import_RxNorm_and_SNOMED_Tables
-brady
OpenEMR
mcaloon wrote on Thursday, April 12, 2012:
Hello,
I have the latest set of ICD 10 files published in 2012 from http://www.cms.gov/Medicare/Coding/ICD10/index.html?redirect=/ICD10 that I am reviewing. Pretty sure these will be the files that will be loaded by the new data load scripts. I will be putting the DDL up for all the tables on github next followed by the load procedures. It would be helpful at some point to have some use cases of how these data will be used by openemr but maybe we can review the tables first then come up with the use cases once we see the data that is involved. I mention this because it seems as though there is a lot of data surrounding the actual diagnostic and procedure “codes”. I think we should probably load it all so that we have it to work with if we choose to do so. I’ll get another status after I spend some time looking things over.
Mac
bradymiller wrote on Thursday, April 12, 2012:
Hi,
I agree with loading it all up (a sql table for each file) and going from there. Once it’s imported, should be able to get it up and running very quickly by placing the needed queries (two of them) in the custom/code_types.inc.php placeholders (line 162 and line 223).
For the importing mechanism, would also be very useful to place the language identifier (ie. the ‘en’) from the filename into the standardized_tables_track at the revision_version column. Then this will allow users to change to different languages by importing them (for example, if a user has english 2012 codes installed but wants to “upgrade” to spanish 2012 codes; of course, the revision_date column should be the same or better for this option). Hope this makes sense.
-brady
OpenEMR
mcaloon wrote on Thursday, April 12, 2012:
Hello,
Since the 2008 files that I originally found on WHO, the names have changed. So that UI code that unzips the files will need to change to interpret the new file names and the 2012 file set has more files (e.g. General Equivalence Mapping files). I don’t think we’ll be loading old files so no need to be backward compatible on the pre-release code files. Although moving forward we must assume that the code databases and the load logic will need to be upgraded from time to time if new files appear and or they change the naming convention for any annual updates. Here is the new set of files:
./2012_Code_Tables_and_Index/icd10pcs_definitions_2012.xml
./2012_Code_Tables_and_Index/icd10pcs_index_2012.xml
./2012_Code_Tables_and_Index/icd10pcs_tabular_2012.xml
./2012_PCS_long_and_abbreviated_titles/icd10pcs_order_2012.txt
./DiagnosisGEMs_2012/2012_I10gem.txt
./DiagnosisGEMs_2012/2012_I9gem.txt
./duplicate_ICD10CM_codes/duplicate_ICD10CM_codes.txt
./ICD10CM_2012_Code_Tables_and_Index/ICD10CM_2012_Full_DIndex.xml
./ICD10CM_2012_Code_Tables_and_Index/ICD10CM_2012_Full_EIndex.xml
./ICD10CM_2012_Code_Tables_and_Index/ICD10CM_2012_Full_TableOfDrugs.xml
./ICD10CM_2012_Code_Tables_and_Index/ICD10CM_2012_Full_TableOfNeoplasms.xml
./ICD10CM_2012_Code_Tables_and_Index/ICD10CM_2012_Full_Tabular.xml
./ICD10OrderFiles_2012/icd10cm_order_2012.txt
./ProcedureGEMs_2012/gem_i9pcs.txt
./ProcedureGEMs_2012/gem_pcsi9.txt
./ReimbursementMapping_2012/reimb_map_dx_2012.txt
./ReimbursementMapping_2012/reimb_map_pr_2012.txt
I am investigating loading the XML files into mysql. I have the DDL for the gem, reimb and order files mostly done (reviewing for completeness).
Mac
mcaloon wrote on Thursday, April 12, 2012:
Brady,
I realize you were thinking of the old 2008 file names obtained from WHO that had the “en” in the name. The CMS files don’t have that same naming approach. Not sure which way to go on this one as “localization” in US is pretty much “en”. I think it makes sense to base US database loads on CMS files. I’m getting a whiff that there might be a localization component to the ICD10 needing to be investigated. I am focusing on the CMS files for now…
Mac
bradymiller wrote on Thursday, April 12, 2012:
Hi Mac,
This looks like a useful read:
http://www.cms.gov/Medicare/Coding/ICD10/Downloads/2012_ICD10_Guidelines.pdf
-brady
mcaloon wrote on Thursday, April 12, 2012:
Hey Brady,
It was definitely a useful read. After reading it though, it confirms my belief that an intuitive UI for code assignment would really set openemr apart from other systems. I imagine a graphic image of a patient all point and click for the doc. For example, when clicked on the left elbow the UI code sorts through all the possible codes and lists each (including laterality) with appropriate drill downs for the details in “the useful read” document giving the doc the background supplied for determining whether the coding is appropriate…. sounds like a good graduate student project hey? I will be setting up the ICD10 tables to facilitate the navigation model as described, where we’ll want to drill around perhaps…
Mac
Imagination is more important than knowledge… Albert Einstein
bradymiller wrote on Saturday, April 14, 2012:
Hi Mac,
Plan to read through the above doc at some point. You may want to put a pool of blood to click on next to the patient image for the hematologist Also, may be tough to visualize all the systemic conditions (sepsis, lupus, HTN, etc.).
Speaking as a physician: At work(use a commercial EMR in a large academic institution), I have the ability to search through categories of ICD9 codes, however, I generally don’t use this because it’s quicker for me to just google: “ICD9 <disease>”
-brady
OpenEMR
mcaloon wrote on Saturday, April 14, 2012:
Brady,
The file naming approach (and the associated php load code) used for the existing RxNorm and Snomed files will not work well with the ICD10 stuff. I just took a look at the release of the 2011 files and the example is the reimb and gem mapping files. The 2011 file is named 9cm to 10cm gem.txt and the 2012 file is named 2012_I9gem.txt - completely arbitrary naming convention it appears. CMS has taken no meaningful use approach to their naming convention :-o One thing to note is that the file set seems to be consistent where files are in both releases. We could take the arbitrarily named files and make them conform to our load procedure naming convention that we nail down. This way each year we could reuse the load procedures (assuming the data model doesn’t change). Each year someone would have to map the files into the openemr naming convention. This approach is not that great but it beats having to rewrite the actual load code each year. I am still pulling together all the DDL and load code so let me know what you think before i wire it all up…
Mac
bradymiller wrote on Saturday, April 14, 2012:
Hi Mac,
Like the meaningful use jab
Your plan sounds good to me.
thanks,
-Brady
OpenEMR
mcaloon wrote on Saturday, April 14, 2012:
Brady,
I am going to see if I can integrate this approach into the library code that loads the other tables, it’s underpinnings might behave differently but the goal is to have the look and feel be the same for the user….
Mac
garcianc wrote on Saturday, April 14, 2012:
Sorry Brady and Mac that I have fallen off this conversation. My dissertation chair was about to drop me if I did not make any progress.
I have been following the discussion regarding the load procedure and naming convention and was wondering about something. I am usually not comfortable implementing logic based on convention (i.e. naming convention) unless there is a strong interface agreement or rules in place. However, I expect that the data layout in the files would not change as often or arbitrarily - and data is really what we care about.
Having said that, what do you think about writing the load procedure based on checking the files’ layout to determine what data we are loading? or is that what Mac was already referring to? If so, I vote for that.
mcaloon wrote on Saturday, April 14, 2012:
Hey Nelson,
A nice adaptive load procedure would be nice where you could semantically analyze the content of the rows in the input files and determine whether you want to load them. This would be a substantial effort as you must realize that we’d have to adapt the table create DDL and the load procedures to change dynamically to a future arbitrary file format. A more traditional approach is to implement error checking in the load code where it will support _known layouts that currently are the 2012 ICD 10 files published from CMS.
So when someone attempts to load a future file that has changed in layout it will most likely encounter an error during load processing (unless the new attributes being added are at then end of the line in the text file - in which case the data will be ignored and no error will transpire). Each year we’ll probably need to revisit the published set of files to ensure nothing has been changed. At the very least we know that the file naming conventions are arbitrary so I am coming up with an approach that will allow a no-change in format / no-change in load processing approach. Make sense?
Mac_
garcianc wrote on Saturday, April 14, 2012:
What you described regarding the error-checking against known layouts is exactly what I meant and not the adaptive load.
Thanks,
Nelson
mcaloon wrote on Monday, April 16, 2012:
Hello,
As I’m working on the load code for the data side of the ICD 10 effort I decided to look for integration points in the existing tree so i ran the command:
find . -exec grep -il icd[-91\s{1}] {} \; | egrep -v "git|pdf|zip"
this will pick up any icd 9 or icd 10 references in the tree as some of the files have been modified already by brady and me
There are quite a few files to review and possible migrate to the ICD 10 implementation. Any help from the more seasoned team members would be great as I am still cutting teeth on the code base (reviewing as I go)…
Mac
./library/sl_eob.inc.php
./library/api.inc
./library/clinical_rules.php
./library/standard_tables_capture.inc
./library/freeb/Payer.class.php
./library/freeb/Procedure.class.php
./library/freeb/Diagnosis.class.php
./library/sql-ccr.inc
./library/Claim.class.php
./library/classes/ClinicalTypes/.codes.php.swo
./library/classes/ClinicalTypes/PhysicalExam.php
./library/classes/ClinicalTypes/codes.php
./library/classes/ClinicalTypes/.codes.php.swp
./library/classes/WSClaim.class.php
./library/classes/OFX.class.php
./library/classes/Installer.class.php
./custom/code_types.inc.php
./Documentation/User_Guide/index.html
./Documentation/Readme.txt
./interface/patient_file/encounter/diagnosis.php
./interface/patient_file/encounter/cash_receipt.php
./interface/patient_file/encounter/search_code.php
./interface/patient_file/encounter/diagnosis_full.php
./interface/patient_file/encounter/patient_encounter.php
./interface/patient_file/summary/add_edit_issue.php
./interface/forms/misc_billing_options/new.php
./interface/forms/CAMOS/notegen.php
./interface/forms/CAMOS/new.php
./interface/forms/CAMOS/help.html
./interface/billing/edit_payment.php
./interface/billing/sl_receipts_report.php
./interface/billing/payment_pat_sel.inc.php
./interface/reports/clinical_reports.php
./interface/reports/non_reported.php
./interface/code_systems/standard_tables_manage.php
./interface/super/edit_list.php
./interface/main/ippf_export.php
./interface/main/left_nav.php
./myportal/soap_service/server_existingpatient.php
./sql/ippf_layout.sql
./sql/ins_lang_def_nl.sql
-- don't think old upgrades will be changed (???)
./sql/4_0_0-to-4_1_0_upgrade.sql
./sql/ippf_upgrade.sql
./sql/3_2_0-to-4_0_0_upgrade.sql
./sql/2_8_2-to-2_8_3_upgrade.sql
./sql/4_1_0-to-4_1_1_upgrade.sql
./sql/database.sql
./contrib/forms/mh_therapy_progress/table.sql
./contrib/forms/mh_therapy_progress/save.php
./contrib/forms/mh_therapy_progress/new.php
./contrib/forms/mh_therapy_progress/view.php
./contrib/forms/individual_treatment_plan/table.sql
./contrib/forms/individual_treatment_plan/save.php
./contrib/forms/individual_treatment_plan/new.php
./contrib/forms/individual_treatment_plan/view.php
./contrib/util/load_icd_desc.plx
./contrib/util/express.php
./contrib/util/import_mi2xml.php
./contrib/util/language_translations/currentConstants.txt
./contrib/util/language_translations/current_spreadsheet.tsv
./contrib/util/language_translations/currentLanguage_utf8.sql
./ccr/ccd/templates/hl7oid.xml
./ccr/createCCRProblem.php