tmccormi wrote on Wednesday, February 01, 2012:
We made these changes as a result of rejects from the clearing house. The Off and Return to work dates and the hospitalization dates need to be empty (instead of 00000000) when they are reals dates.
See: https://github.com/tmccormi/openemr/tree/claim-class-chgs
Anyone else have this issue?
-Tony
yehster wrote on Wednesday, February 01, 2012:
Tony,
I haven’t seen this problem, but I’m sure it exists. Might a suggest a cleaner approach to coding this
https://github.com/yehster/openemr/commit/f266d5544e5f6a9360ce842beb5033df8e9d2532
Refactor the code and use a function to do the same thing multiple times.
It will be more maintainable in the future. Note I haven’t tested my version.
tmccormi wrote on Wednesday, February 01, 2012:
I’ll check your code, the code submitted was written by one of my support team, he’s just starting to learn programming, pretty good for a first try. If others think this is needed we’ll do it for real.
-Tony
aethelwulffe wrote on Wednesday, February 01, 2012:
Looks good,
I’ll tinker today and test with real billing tomorrow.
Remember, unless the facility is (I think) 21 or 22, there should be no 837 segment for the hospitalization date ( the segment should not be sent AT ALL), and normally no onset date, they can never be the same date in 5010. This needs to be fixed in form_encounter. Too many times, folks put in an onset date because they have a blank spot. Some carriers don’t care, and others will trash your claims as being a HIPPA violation (not sure why they think of it that way). Magellan is one that will trash your claims…the whole batch. Medicaid (in Florida) doesn’t seem to care.
yehster wrote on Wednesday, February 01, 2012:
Remember, unless the facility is (I think) 21 or 22, there should be no 837 segment for the hospitalization date ( the segment should not be sent AT ALL), and normally no onset date, they can never be the same date in 5010. This needs to be fixed in form_encounter.
We can also fix this in x12_gen… The program knows when it’s generating the x12 what type of facility has been set. So it has all the information it needs to know to skip inappropriate segments it encounters. The more error checking we can do for the user the better as long as it doesn’t become intrusive.
tmccormi wrote on Wednesday, February 01, 2012:
Availity is saying to skip the date segments completely if the date is blank regardless of POS. Does that jive with your specs Art?
-Tony
yehster wrote on Wednesday, February 01, 2012:
Tony,
I’m looking at the code, and I don’t actually see these fields being used for X12. I see them going into HCFA, but not gen x12.
yehster@ubuntu:/var/www/openemr$ ack-grep hospitalizedFrom
library/gen_hcfa_1500.inc.php
349: $tmp = $claim->hospitalizedFrom();
library/Claim.class.php
1029: function hospitalizedFrom() {
yehster@ubuntu:/var/www/openemr$ ack-grep hospitalizedTo
library/gen_hcfa_1500.inc.php
353: $tmp = $claim->hospitalizedTo();
library/Claim.class.php
1033: function hospitalizedTo() {
yehster@ubuntu:/var/www/openemr$ ack-grep offWork
library/gen_hcfa_1500.inc.php
312: $tmp = $claim->offWorkFrom();
316: $tmp = $claim->offWorkTo();
library/Claim.class.php
1017: function offWorkFrom() {
1021: function offWorkTo() {tmccormi wrote on Thursday, February 02, 2012:
Starting around line 453 in gen_x12
if ($claim->onsetDate() && ($claim->onsetDate()!==$claim->serviceDate())) {
++$edicount;
$out .= "DTP" . // Date of Onset
"*431" .
"*D8" .
"*" . $claim->onsetDate() .
"~\n";
}
if ($claim->dateInitialTreatment()) {
++$edicount;
$out .= "DTP" . // Date of Initial Treatment
"*454" .
"*D8" .
"*" . $claim->dateInitialTreatment() .
"~\n";
}
// Segment DTP*304 (Last Seen Date) omitted.
// Segment DTP*453 (Acute Manifestation Date) omitted.
// Segment DTP*439 (Accident Date) omitted.
// Segment DTP*484 (Last Menstrual Period Date) omitted.
// Segment DTP*455 (Last X-Ray Date) omitted.
// Segment DTP*471 (Hearing and Vision Prescription Date) omitted.
// Segments DTP (Disability Dates) omitted.
// Segment DTP*297 (Last Worked Date) omitted.
// Segment DTP*296 (Authorized Return to Work Date) omitted.
if (strcmp($claim->facilityPOS(),'21') == 0) {
++$edicount;
$out .= "DTP" . // Date of Hospitalization
"*435" .
"*D8" .
"*" . $claim->onsetDate() .
"~\n";
}aethelwulffe wrote on Thursday, February 02, 2012:
Availity is saying to skip the date segments completely if the date is blank regardless of POS. Does that jive with your specs Art?
Yep.
All this is pretty well covered on the OEMR forum of 837.
Agree toe-tale-lee.
Just working off of POS 21 isn’t good enough of course. We need some sort of check against all three of the above dates. Our method of gathering data in form_encounter should be less cryptic as well. We can go over the standard for this more carefully.
yehster wrote on Friday, February 03, 2012:
Tony,
Note though that while the x12 segment it refers to is hospitalization date in your code segment, it is actually using the onset date from the encounter and not the billing option dates.
aethelwulffe wrote on Friday, February 03, 2012:
That’s what it looks like to me also. It really isn’t right.
Anything that is applicable for hcfa as well as 837 should be configured in
the encounter form (if any of it is). If I were consulted, I would also say
it should be labled to reflect that it is billing information (and even the
hcfa box), AND it should display the value that will actually be sent (such
as location code), AND you should be able to VIEW the fee sheet data for the
encounter on form_encounter without going to the fee sheet edit screen if
you are an admin type, or the fee sheet should display the POS etc… that
will be billed, AND the hcfa options should be accessible right through the
same billing sheet. We should integrate everything somehow.
tmccormi wrote on Friday, February 03, 2012:
I am aware of that, and if you look at the New Encounter page the prompt says: “Onset/Hosp Date” So it’s assume one or the other not both…
That the other thoughts are good …
-Tony
tmccormi wrote on Friday, February 03, 2012:
is assumed …. 
yehster wrote on Friday, February 03, 2012:
It seems like revising the billing options interface should be another task for the “Practice Management” wish list. Easier said than done of course…
tmccormi wrote on Monday, February 13, 2012:
This is testing well and is ready for review… https://github.com/tmccormi/openemr/commit/3b63810d1e71058c2bf9a024df351abaefad02df
-Tony
tmccormi wrote on Friday, February 17, 2012:
These change have been committed:
8cd93fa Add date format cleaner for x12 5010 - tmccormi Wrapping onset date - yehster
M library/Claim.class.php
M library/gen_x12_837.inc.php
One function cleans Zero dates making sure they are returned as empty strings, a second allows for validation of “emptyness” (sounds zen-like)
Loops that would be produced with empty onset/hospitalization dates are skipped entirely now. Only dates that were already implemented have been touched. Dates that will be implemented in the future can use the same cleaner function and logic.
-Tony
kevmccor wrote on Tuesday, February 21, 2012:
Additional change requested:
Currently, BHT03 is hard-coded as ‘0123’ in gen_x12_837.inc.php. Some of the ISA, GS, ST etc. values are changed in the billing_process.php script and I suggest that someone add something like:
if (elems == ‘BHT’) {
$bat_stcount . ‘-’ . $bat_icn // change for BHT03
}
in billing_process.php around line 82 (after the ST adjustments)
So that
BHT*0019*00*0123*CCYYMMDD*HHMM*CH~
becomes
BHT*0019*00*$bat_stcount . ‘-’ . $bat_icn *CCYYMMDD*HHMM*CH~
e.g. BHT*0019*00*0003-021162972*CCYYMMDD*HHMM*CH~
for claim 3 with batch control # 021162972 (ISA13)
from the CMS 4010 to 5010 spreadsheet: “BHT03 Originator Application Transaction ID AN 1-50 R”
So it appears there are up to 50 characters allowed.
I am learning that the 277 response files refer to BHT03 as our ID number and ‘0123’ does not help.
With my suggestion, we have a unique claim ID and I think we can find the batch file and the included claim without too much difficulty.
Thanks,
Kevin