I’m trying to add the date of Same or Similar Illness field Box 15 to satisfy initial treatment date. I’m using OEMR V 3.2 on the virtual appliance. Any thoughts how I can add this either to the HCFA or X12?
I did look at the Misc HCFA and I see other boxes, but not 15.
Thanks in advance, John
Hi again, The ANSI v5010 requires the “Initial Treatment Data” as data related not to box 15 but to box 14 (loop 2300 or 2400, DTP/454, element 3. Box 15 is not used by Medicare. Google “dtp 1500 codes” to locate the Palmetto document explaining version 5010, “ANSI 837 v5010 to CMS-1500 Crosswalk.”
Rod - has the box 15 issue been taken care of yet?
2010-11-12 15:12:05 PST
This is to let folks know that I’ve been commissioned to take care of this. There will be a fix for 3.2 as well as current code. Rod
I don’t see it in the current code set for 4.1 (I’ve got a customer asking for this now too…)
Hi Tony, the client got bogged down in testing and so testing was never completed and the push to SF was never done. Would you like to test the 3.2 changes? They are here:
Looks like a nice feature to have. Here’s a spot code review though:
(0) builds a URL using PHP string substitution, probably should be an htmlspecialchars() there.
(1) directly writes out the result of xl(), there should be an htmlspecialchars() call there.
(2) If Rod (or anyone else) adds anything copyright-able this year, the copyright dates need to be updated.
None of this should prevent testing in an isolated installation. Tony (or anyone else), could you please test and report back so Rod and I know if this is worth the back- and forward-porting effort? Forward-porting to dev tip will take a little bit because a lot of the code needs to change to use the convenience functions added during 4.0 and later development.
FYI, the first commit that shows a conflict is 8d4acf253c4ed56f1bcc30254a6dd381fb96c0f1, about 500 commits before the 4.0 branch point, so there’s a lot of forward-porting to do if this patch is “worth it”.
I am not sure what you mean by “manual”. If you mean that git will be unable to automatically resolve all the conflicts, that’s absolutely true. If you mean that we are better off creating a new branch off of master, re-writing the code, but losing the history/dependency information, I disagree.
I say this having previously forward-ported some significant patches against 3.2 to master earlier this year. (They were proprietary patches, so they didn’t land in master.)
Rod,
I don’t have anyone running 3.2 anymore so the timing to test may be long. The solution you implemented looks like a good one ie: just what I was thinking . I think you should go ahead and bring the changes forward in to v41 and let’s test it there.
-Tony
Stephen,
Since Rod’s changes never made it into a release or release patch for 3.2 I see no reason not to just put these changes in as new to 4.1. There is no history that is relevant, in my opinion.
-Tony