I am trying to enter CPT category 2, the code describe certain condition such as how high the blood pressure or what kind of medicine was reviewed during the visit (example 1159F, 1160F). There is no fee associated with the code, but it needs to be justified by the icd 9 code. I created a new category in the lists>code type, and the option appears in fee sheet and can be chosen; two issues: when the fee sheet is created the cpt 2 appears there justified but when the claim is generated on paper or x12, the codes doesn’t get print in either case. The second issue if this code was entered under HCPCS type, the fee sheet will have option to enter med name and dose, but the x12 claim did not go through. Any help is greatly appreciated.
Guessing a place to start is modifying the following code in openemr/library/Claim.class.php:
// Sort by procedure timestamp in order to get some consistency.
$sql = "SELECT * FROM billing WHERE " .
"encounter = '{$this->encounter_id}' AND pid = '{$this->pid}' AND " .
"(code_type = 'CPT4' OR code_type = 'HCPCS' OR code_type = 'COPAY' OR code_type = 'ICD9') AND " .
"activity = '1' ORDER BY date, id";
$res = sqlStatement($sql);
I started using the CPT II codes this week, 3074F, etc… I built a new code type (CPT II or #4 on the list), with justification set to ICD9. I changed the line in claim_class.php to include this type and all is ok so far.
claim_class.php change:
// Sort by procedure timestamp in order to get some consistency. $sql = "SELECT * FROM billing WHERE " . "encounter = ‘{$this->encounter_id}’ AND pid = ‘{$this->pid}’ AND " . "(code_type = ‘CPT4’ OR code_type = ‘HCPCS’ OR code_type = ‘COPAY’ OR code_type = ‘ICD9’ OR code_type = ‘CPT II’) AND " . “activity = ‘1’ ORDER BY date, id”; $res = sqlStatement($sql);
Thanks brady for the insite into this, all the HMO’s that we are dealing with are asking for the values these codes allow us to transmit with our billing.
Kim Weesner, IT
Affilliated. Doctors Orange County., Orange County, CA
Seems like it might be a good idea to remove this hard coding and add some kind of indicator field that would tell claim class what codes to include. The less editing raw code for new things the better.
Maybe just a 'include in claims Y/N" field on the code_types option list?
Should join in the code_types table (on the ct_key from code_types table and code_type from billing table) and include anything has a ct_fee or ct_diag set to 1 in code_types table. This will then open the door to allow ICD10/SNOMED codes to also be used.
To help us come to an ideal solution (for example, if we need to add a new column in code_types), can you let us know what your sql database data looks like for CPTII in the code_types table.
Also, why using CPTII rather than CPT2 (is one standard). I say this, because we can add this to the code_types table for the 4.1.1 release, but want to make sure we use the standard name.
Well the reason for CPT II is that is how the AMA and the CQC (California Quality Collaborative) along with the NCQA Volume 2 HEDIS Technical Specifications 2012. It would be good to add this to the 4.1.1 release as all the HMO’s want the data that these codes allow us to send along with the billing. The HMO’s are after MU bucks the same as we are and the only way to get the data they need has been to send people out to the doctors office’s and do chart scanning.
I would be glad to contribute this mod to the cause. I have all the codes entered in the codes list and they are working great, PalmettoGBA, OfficeAlly, Blue Cross, etc.
I will send you a SQL script that sets the code_types table and loads the codes into the codes table. I do not think we need another field in code_types as these Category II codes need to be justified by some clearing house’s (OfficeAlly for one). The only other issue is a more elegant fix in claim_class than the hard-coded hack I put in, like allow for expansion of the code_types without having to hard-code.
Let me get this bundled up and sent to you and then we can chat about the other issues.
It is based on code in master (4.1.1-dev). If want to test in 4.1.0, then need to remove the following line:
"ct.ct_active = '1' AND " .
Regarding adding the CPTII stuff. Several issues:
1. Are the codes licensed (like the CPT4 codes which I think do not allow distribution)?
2. Note we do not hard-code the ct_id, but can get to that later. Let me know if above code works well to support CPTII along with the standard ICD9/CPT4 in the claims.
That would be fine with me.
The patch for claims_class.php is:
$sql = "SELECT * FROM billing WHERE " . "encounter = ‘{$this->encounter_id}’ AND pid = ‘{$this->pid}’ AND " .
"(code_type = ‘CPT4’ OR code_type = ‘HCPCS’ OR code_type = ‘COPAY’ OR code_type = ‘ICD9’ OR code_type = ‘CPT II’)
AND " . “activity = ‘1’ ORDER BY date, id”; $res = sqlStatement($sql);
I have been using these codes all week through OfficeAlly and all my HMO’s are getting them.
Now all I need is a capitation payment routine that goes through all my HMO encounter claims and write them off and clears them out of the billing system. Got any ideas???
1. Are the codes licensed ? Not to my knowledge, everyone is distributing them, AMA, HMO’s, etc.
2. I will keep you informed.
I got mail from my forth HMO so far wanting BMI, LDL, and blood pressure data sent to them in this fashion. This feature is a hot item, great we got it.
I have also been working on the RAF scores. Risk Adjustment Factoring, it is a way the HMO’s figure out how risky or costly a member is going to be. They get aid from the government given the risk value. They have codes like our issue’s so I am adding this feature. The HMO’s are requiring the doctors to fill out long paper forms on each member with no reimbursement for there time. If we had this feature I have an HMO that said they would buy 50 modules and contract for 50 installations so that they can give OpenEMR to there doctors for free. The doctors are really mad about the forms, several have left the HMO, they better do something.
Note that the planned 4.1.1 version will have much more flexibility with which code_sets to use and doesn’t require them to be stored in the codes table (see the development demo at Administration->Lists->Code Types to get an idea of this.
Thoughts are that it makes sense to add the CPTII to code_types (with the ct_active flag turned to off by default). Then we should leverage the mechanisms currently being built to import ICD10/ICD9/SNOMED codes to also import the CPTII/CPT4 codes from the primary data files from the AMA. In the interim, individuals can also use other methods (such as yours) to get the CPTII/CPT4 codes imported. Note that the ct_id is not hard-coded. New installations will get a ct_id of 104 for CPTII, however for upgraders the assignment of this value is flexible (so if 104, is already taken it will use a ct_id that is not yet taken). In the codebase it won’t matter what the ct_id is(instead identifying the code_type with the ct_key element), but is is something to watch out if are are using the mysql method of importing these codes into the codes table.
One thing to consider regarding claims generation, is that someone may want a code type that has fees but is not to be billed to insurance. So I’d suggest either yet another attribute for that, or else revert Claim.class.php to check for specific code types (it is already very specific to its code types anyway, so that’s what I’d do).
Sounds like I should add another attribute (plan to call it ct_claim unless know of a better label), and then can actually remove the ct_fee flag from CPTII since it is not actually associated with fees/charges. Quick question, should the ICD9/10 procedure/service codes also have the ct_claim flag set also since they appear to be used as billing codes for inpatients (not the diagnosis codes, but the procedure/service code sets, which are gonna get added soon in this commit: http://github.com/bradymiller/openemr/commit/0393f824d149507c7bccc961cbccbeaeefdacbd1