sunsetsystems wrote on Friday, December 09, 2011:
Kim, not sure what you did but what I see on the weesnerkim account on github does not show me your changes. Suggest you carefully go through the links in the “Repository” section of the developer info that I pointed you to earlier.
bradymiller wrote on Friday, December 09, 2011:
Hi,
Best way to get git up and started in OpeneMR as quick as possible is here:
http://open-emr.org/wiki/index.php/Git_for_dummies
There’s a bit of a learning curve and feel free to ask any questions here while figuring it out.
-brady
weesnerkim wrote on Friday, December 09, 2011:
I followed instructions but I am not sure if it went so I emailed the module to Rod at help@sunsetsystems.com just in case. I received another response file from PalmettoGBA medicare saying everything is ok to go to production status.
I need to do some reading on this Git issue, lol.
Kim
yehster wrote on Friday, December 09, 2011:
Kim,
Here is another thread where someone else was getting started on git that might be helpful.
http://sourceforge.net/projects/openemr/forums/forum/202506/topic/4818992
bradymiller wrote on Wednesday, December 21, 2011:
Hi,
I’m a 5010 idiot and am just wondering if OpenEMR(note patch 5 has all pertinent changes from the master branch) is now fully compliant with the 5010 mandates that start in March? Or is there more to do?
-brady
nursejeff wrote on Wednesday, December 21, 2011:
There will need to be changes in Administration->Pracitce->X-12Partners settings. Mine is Availity. I know I have to change my “Version” setting indicating I am using the 5010 format but I don’t know yet, if other changes will need to be made.
I just upgraded last night and my biller has not submitted any claims yet for me to comment on. If anyone else knows all the exact changes needed please help.
Thanks.
Jeff Guillory Jr.
NP Health Clinic
sunsetsystems wrote on Wednesday, December 21, 2011:
Brady, I’ve not heard any progress being made yet with electronic remittances in the 5010 format (though there may not be much to do, not sure). What I’ve done is the claim generation side. It appears to work for 5010 claims as well as it did for 4010. Can’t claim “full compliance” though, as some areas of functionality in the spec that nobody has cared much about yet have always been missing.
aethelwulffe wrote on Wednesday, December 21, 2011:
B.O.L.O. Alert!:
Wanted: File, ASCII ANSI X-12 5010 standard 835, last seen with the possible extension of “.era”……
Guys,
I just went through patch 5, mixed and matched my 837 5010 code and other files to try to re-integrate our clinic’s working 5010 stuff into the main line. My current issue is that due to some inherent differences in the content of the billing we typically send out (and different database fields), our billing code has some severe simplifications as well as a lot of claim scrubbing checks against authorized units blah blah blah….and I can’t send off a claim that will get back “typical” complexity 835’s that I can test with.
The upshot is that I need a 5010 835 file with more than one procedure code, and at least two diagnosis for one procedure so that I can test this crap before it gets patched *again*……
Please……if you have a file you can share, replace identifying data bits by simply altering the numbers and names, leaving the file length intact. Post it ANYWHERE or send it to me at Art@OEMR.org
-Thanks guys.
aethelwulffe wrote on Thursday, December 22, 2011:
Rod,
I am reviewing your 837 generator and comparing it to my working version. I have some views to state relevant to 5010, as well as to the billing process as a whole. I am sure to drone on, as there is a lot on my mind with this, and I will understand if this never really gets read 
First item I came up with was an item to answer a question:
// The 5010 spec says:
// “On or after the mandated implementation date for the HIPAA
// National Plan Identifier (National Plan ID), XV must be sent.
// Prior to the mandated implementation date and prior to any phase-
// in period identified by Federal regulation, PI must be sent.”
// *************** Anybody know what that date is? ***************
// August 2011 - Publish interim final rule
// October 1, 2012-March 31, 2013 - Enumeration
// April 1, 2013-September 30, 2013 - Testing
// October 1, 2013 - Implementation
Next:
// “MI” = Member Identification Number
// “II” = Standard Unique Health Identifier, “Required if the
// HIPAA Individual Patient Identifier is mandated use.”
// Here we presume that is not true yet.
It is not true. You will find this in CFR 160 if it ever becomes so. The same gang that worried about Social Security numbers (funny, why don’t they use that??? Too many fake SSN’s out there?) is yelling “Big Brother!” pretty loudly. While Health Plans had to have identifiers as early as 2007 (first for big plans, then small companies), the patient number thing has not come up with a date yet, though the first white paper was published in 1991 outlining how important this was (and very aptly too).
Use of Segment REF*6R (Line Item Control Number) would REALLY be a good start on developing a recursive claim checking interface. Personally, I think it would be really helpful if we could add some billing fields to handle this (would we need a UNIX timestamp, or will the auto-increment billing line item record ID be sufficient for use across to tables like ar_activity?). I think that may make it easier to make an interface more like what you see on other EMR’s that will highlight the item in red on a billing interface. This could be a separate pop-up interface, an expand feature on the payments screen, or something on the billing report that will allow us to see the data, change it, and alter the fee sheet, insurance info, demographics or the like without going to the normal interfaces.
Next:
form_encounter has those Date of Service and Onset/Hospitalization dates. For 5010, it is a big boo-boo to screw these up. For 4010, I had to make sure that these dates were always included to avoid input error, so we changed the output to use the date of service for both, because if we didn’t have both, claims screwed up. For 5010, If you have an onset date, it must be different (presumably before) the date of service. The code SEEMS to ask if there is a value here, but in practice, data entry by the providers was gumming up the works. For 5010, I found that the item was Situational Required, so I just commented out the whole darn thing. We need to ensure that unless the place of service is a hospital (Location 12?) that this value is not sent at all. It may not screw things up for general practitioners, but it’s been a major pain here. I am not sure how things work when you have a professional claim performed at a hospital, and the location code is a hospital and the billing code is the office, but I would feel better if we linked this to the appropriate location code and not just whether or not there is a date in the field.
if ($claim->onsetDate()) {
only checks to see if there is a date there, right?. We need to make sure that this is only used if the claim needs it. Some payers simply dump the whole claim (Magellan for one) if this is screwed up, stating “HIPPA violation”, and not giving any other remittance advice. It is a troubleshooting nightmare.
Next, I think some header adjustments are in order:
$out .= "ISA" .
"*" . $claim->x12gsisa01() .
"*" . $claim->x12gsisa02() .
"*" . $claim->x12gsisa03() .
"*" . $claim->x12gsisa04() .
"*" . $claim->x12gsisa05() .
"*" . $claim->x12gssenderid() .
"*" . $claim->x12gsisa07() .
"*" . $claim->x12gsreceiverid() .
"*030911" .
"*1630" .
"*" . ($CMS_5010 ? "^" : "U" ) .
"*" . ($CMS_5010 ? "00501" : "00401") .
"*000000001" .
"*" . $claim->x12gsisa14() .
"*" . $claim->x12gsisa15() .
"*:" .
"~\n";
We have 3 X12 partners that use configurable values here. From what I have read, soon others will be required to follow suit. I have published partner configuration code to support this, and it would really help out if this could be integrated into the code base. I am also of the opinion that the date and time fields we have hard coded could be put to use.
Finally (and this is not related to 5010 specifically), I think there are some fee sheet tweaks we need to make.
First: We can evaluate who may need the Supervising Provider field and configure that with globals. It confuses many folks and is not often used in any case, so it would be a nice thing to be able to remove.
Next, there is a lot of confusion with the providers listed on the billing line items. It would be good to explain the use of this. Generally, only one provider sees a patient, and that provider is not always the billing provider….what should really be done there? What is the purpose of that anyway, and how does it affect the billing?
Finally, I address a multi-faceted issue dealing with non-billing providers. In our system, we have changed the “rendering provider” field to say “Billed Under”, removed the “Supervising” field, and added a field to indicate who performed the service (as well as special stuff for travel, reviews etc…). This enables us to do many things. First, it allows us to do reporting on services rendered by non-billing providers. With this, we can (coupled with user data fields indicating pay rates) produce paycheck data for contracting, non-billing providers. Second, we can use that as a customized search field in the billing report, which normally only allows you to search by billing provider. This is very useful when processing billing. Next it allows us to reference authorized billing units for individual patients, and identify their actual provider and alert them to the fact that they are using up allowable units. Finally it allows us to do reporting and pay on the activity and work that the supervisors of these providers perform, evaluate clinical performance, and all that.
I thought that this stuff was really just applicable to the Mental Health field, but it apparently is almost as important to Primary Care. They too have “eat what you kill” providers, interns that need to be tracked, or simply RVU’s calculations that need to be done. When you can identify providers of all levels, it is easy enough to report how many units of what that an individual provider has performed, and then convert that to RVU’s if desired (RVU’s are a crock of shit of course, but no accounting for taste). These seem to be features that are greatly desired by the practice managers I have been in contact with.
Last item of the last item 
Fee sheet item Authorizations.
I have no idea how this is SUPPOSED to work. It certainly does not account for non-billing providers performing services and filling out fee sheets. At a MINIMUM, whatever else happens with “Encounter Authorizations” or the like, the fee sheet line items (better yet the whole fee sheet) should be set to unchecked (in function echoline: $auth = FALSE). The billers really appreciate being able to pull a billing report, seeing the unauthorized billing items, going to the fee sheet, checking the items, authorizing, and continuing until they are ready to refresh their billing report. This allows them to mark fee sheets as being reviewed and ready for billing. I am sure that more elegant multi-level flags for who is “authorized” and in what way will be needed in the future, as well as some way of flagging notes for review by supervisors like most other EMRs do (the Authorizations interface is basically useless currently, and I myself am not sure about some of the implications), but for now this would be big help to billers just getting into OpenEMR (provided there was a tutorial with a suggested workflow).
Thank you for your hard work on the 837 stuff Rod. As soon as I have finished removing some of my “features” from my ERA parsing file to better comply with the official patch as you have written it, I will post it tonight, probably here first since I don’t have access to my home dev machine from the boat, and It would kill me to try to set up Git again.
sunsetsystems wrote on Thursday, December 22, 2011:
Art, thanks for checking in here with your comments. Much appreciated, and I look forward to your code contributions.
Some practices definitely need supervising providers, so that would need to remain an option.
Regarding authorizations, many docs seem to see those as just a meaningless pain in the rear, so I guess there needs to remain an option where they don’t have to mess with them.
I might have some more comments, but have to go make dinner now.
yehster wrote on Thursday, December 22, 2011:
Use of Segment REF*6R (Line Item Control Number) would REALLY be a good start on developing a recursive claim checking interface. Personally, I think it would be really helpful if we could add some billing fields to handle this (would we need a UNIX timestamp, or will the auto-increment billing line item record ID be sufficient for use across to tables like ar_activity?)
Art,
What are the restrictions on this identifier? can it be alpha numeric or does it have to be fully numeric. If alpha num is allowable, I suggest using a uniqid.
http://php.net/manual/en/function.uniqid.php
Autoincrement fields can be convenient, but we’ve got issues already wtih autoincrement stuff breaking on xamp > 1.7.3, and there are hosts of other reasons integer id’s are less desirable that I could find you references for if you want.
The guaranteed uniqueness is also useful if you’ve got data from multiple sources, such as merging data from multiple
The only real disadvantage is a slight performance hit, but if the underlying queries are poorly designed, it’s going to suck just as bad with integer ids.
If alphanum isn’t allowed, there are still other strategies to build unique integers.
Also, regarding git, what OS are you running? All you should really need to get up and running is your private key file from off your home dev machine. http://code.google.com/p/msysgit/ Mysysgit should get you running under windows quickly, and all the linux variants have package installers.
Anyway thanks for this.
-Kevin
aethelwulffe wrote on Thursday, December 22, 2011:
Rod,
Yes, obviously we still need to have supervising providers as an option, and who is to say what options should be turned on by default? Only way out of that one is quality documentation and tutorials to explain our way out of more complex features. I feel better with that than supplying any number of useful features and no clear discussion of how to properly use them. Fee sheet and the ACL (basic) interface could use some more in-depth cause and effect documentation. The users want really simple answers to really complex situational questions…always a pain in the butt, Ja?
I also totally agree on the Auth stuff, but once again, there ARE some uses, basically when you have interns or dictation types that write the note and then the real doc has to “sign off”. It’s something that ought to be configurable, and probably work through a message system on the notes and records side, for the BILLING however, I think we can really justify doing something, as not only do those crazy billing ladies not mind pensively going through line items and manually marking them, but they seem to enjoy (or at least prefer) that. No big discussion, but it IS a viable use of the auth system, and doesn’t get in the way of the docs. For the same reason, I would prefer to keep the fee sheet style coding interface in the encounter forms for the practitioners, but also have some “god mode” for billing people that lets them use an interface that looks more like a spreadsheet or HCFA to review, alter, re-open, or approve billing items away from the “dumbed down” version the docs see.
Ultimately, dinner IS more important than this crap, and I salute your priorities.
Kevin,
REF Line Item Control Number 1 S 2110
New Segment
REF01 Reference ID Qualifier ID 2-3 R………………no idea what the qualifier values might be, just 2-3 characters
REF02 Line Item Control Number AN 1-50 R…………1-50 characters…I think we can assume alphanumeric
REF03 Description AN 1-80 N/U………………not used
REF04 Reference Identifier N/U………………not used
Situational segment in loop 2010.
I think Rod has our copy of the actual standards. Perhaps he can look it up for us and see if there is some usage info. Lacking the usage info has been my main problem in working with this stuff.
Thanks for the link to mysysgit. I have been using SmartGIT, which I like a lot when I can figure out what upload/download/rebase blahblah buttons to hit in the right order (interface is a lot like Netbeans or Winmerge for file comparison and versioning) I’ll check out mysysgit, but my key is on a lan that is now running on a dynamic IP, no ddns, and the JackWaggon from brighthouse networks did some freaky stuff with the modem, plugged the ethernet cables into the modem with the router plugged in parallel (didn’t even know you could do that) and even if I get the current IP from my wife, it thinks the modem is the gateway (which I can’t log into), and naturally any configuration of ports for RDP is either not applicable or simply wiped out with a reset…and there is no way in hell I am gonna have my wonderful wife try to find my key and pop it onto the FTP tonight….
aethelwulffe wrote on Thursday, December 22, 2011:
…Oh, I already have MysysGit. That is the engine that Smartgit interfaces with….
yehster wrote on Thursday, December 22, 2011:
Art,
The issue of rendering/billing provider etc… seems like it’s important in lots of other situations such as where you have Nurse Practitioners and Physicians Assistants. What further complicates things with some of those entities, is that an NP is allowed to operate independently and bill for himself. However, he can also be supervised by a physician which allows for billing at a higher level.
Part of the problem is that our data structures are quite rigid because the easiest thing to do is to just tack on additional fields to tables, whenever a new entry is needed, but this isn’t really good design practice down the road.
One possibility for us might be to track per encounter “everyone involved”. This would be a simple table, with columns like this
1. ID (row id, autogenerated)
2. Encounter ID (maps to an openemr encounter)
3. User (the username of anybody involved)
4. Role: this is where we note what the user “did for the patient” (rendered service, signed off on note, etc…)
Then what might happen is at “biling time” the system reviews the entries in that table.
If it finds that a user with 'billing/supervising" permissions is the one who rendered the services, then it can verify that it has the information it needs and can allow billing to continue.
If the rendered service role was provided by someone who doesn’t have appropriate privilleges, then it checks to see if someone who does signed off already, if so again allows billing to proceed. Otherwise it flags the encounter as needing review.
aethelwulffe wrote on Friday, December 23, 2011:
OK,
I re-did my analysis of my 835 file parse_era.inc.php
First, I am not sure how I am supposed to handle repeat segments. I know that segments DO repeat in a claim (designated by a maximum number of repeats allowed for a segment in the standards), but when there are new segments added with the same name (for instance, a series of REF statements in a loop, where there was only one before) and the original code is not looking for an identifier element in the segment, do we need to add ignore code? I am also unsure of how important the sequence of the code the parses the segments is. Our code seems to not be in the same order as the standard, examples of which I will address in my following review.
I can’t color code on this forum, so I will try to bold the few serious questions I would like answered before I post any code. I still have not gotten back a 5010 835 from my test batches sent with my own 5010 code (though the claims have showed up) as the remittances have come back in 4010. I have not yet tested the variant of Rod’s 5010 837 stuff from Patch 5, as I had to do alterations to it last night to get it to work with our X12 partners.
Anywho, here it goes:
835 change notes:
We need to version GS08 (version/release) if we want to continue supporting 4010 standards like we are for 837’s, but this late in the game it seems pretty close to meaningless.
BPR01 has code U and X added, but we don’t parse those anyway.
BPR02 says it has a name change, but that seems to be incorrrect in the documentation, and does not affect us, though we do parse it= Total Actual provider payment Amount S9(8)V99…someone should check the real guide on this just because the comparison docs look funny here.
This next item is the only one that I see that is a real problem other than the simple parsing questions I have:
BPR10, Payer Identifier, which we don’t parse used to equal TRN03. Now TRN03 is not used. We parse BPR and TRN like this:
else if ($segid == 'BPR') {
if ($out['loopid']) return 'Unexpected BPR segment';
$out['check_amount'] = trim($seg[2]);
$out['check_date'] = trim($seg[16]); // yyyymmdd
// TBD: BPR04 is a payment method code.
}
else if ($segid == 'TRN') {
if ($out['loopid']) return 'Unexpected TRN segment';
$out['check_number'] = trim($seg[2]);
$out['payer_tax_id'] = substr($seg[3], 1); // 9 digits
$out['payer_id'] = trim($seg[4]);
// Note: TRN04 further qualifies the paying entity within the
// organization identified by TRN03.
}
I assume we need to parse BPR10 as a replacement for TRN03 like so:
else if ($segid == 'BPR') {
if ($out['loopid']) return 'Unexpected BPR segment';
$out['check_amount'] = trim($seg[2]);
$out['payer_tax_id'] = substr($seg[10], 1); // 9 digits
$out['check_date'] = trim($seg[16]); // yyyymmdd
// TBD: BPR04 is a payment method code.
}
else if ($segid == 'TRN') {
if ($out['loopid']) return 'Unexpected TRN segment';
$out['check_number'] = trim($seg[2]);
$out['payer_id'] = trim($seg[4]);////////////////////////////!!Not used
// Note: TRN04 further qualifies the paying entity within the
// organization identified by TRN03.
}
The two values we are looking for are payer_tax_id and payer_id.
I could use some suggestions as to where we should be getting these two values, and the impact on their usage in the EMR. Furthermore, the EFT and check number can now be up to 50 digits, and we should check to see if we otherwise support that.
Next:
CUR and the first REF segment are parsed in reverse order in the original file. It reads Ref-CUR-REF, and it is really CUR-REF-REF. I don’t know if this hurts anything in a linear process. CUR should never have anything in it, and I have no idea what our treatment of the first Ref segment (Reference Identification is supposed to do for us, except throw an error if there is anything in it. All the same, for multi-site support, perhaps we should consider using the first ref segment so that we can make sure we are loading the era into the correct clinic….unless the data in Loop 1000B N1 N104 is better used.
else if ($segid == 'REF' && $seg[1] == 'EV') {
if ($out['loopid']) return 'Unexpected REF|EV segment';
}
else if ($segid == 'CUR' && ! $out['loopid']) {
if ($seg[3] && $seg[3] != 1.0) {
return("We cannot handle foreign currencies!");
}
}
else if ($segid == 'REF' && ! $out['loopid']) {
// ignore
}
Should we switch these around?
The same sort of thing happens at the end of the 1000A Loop. We now have three PER segments: Payer Business Contact, Payer Technical Contact, and Payer Website. We ignore the original PER segment like so:
else if ($segid == 'PER' && $out['loopid'] == '1000A') {
// TBD: Report payer contact information as a note.
}
Does this need a triple repeat? (I should hope not, but I don’t know much about parsing text files with php) Should we store/report or log the contact info for biller troubleshooting? In Loop 2100 PER we do have some warnings code that lists claim contact info, but I don’t know how effective that is.
At the end of loop 1000B there is a new segment RDM, Remittance Delivery Method. Unless there is a use for this, I suggest ignoring it like so:
else if ($segid == 'RDM' && $out['loopid'] == '1000B') {
// Used to report delivery method. Ignored.
}
NEXT: Loop 2000
We ignore segment TS2, but according to the documentation it comes after TS3, do we need to re-order?:
else if ($segid == 'TS2' && $out['loopid'] == '2000') {
// ignore
}
LOOP 2100:
CLP02 has some claim status codes deleted. Now only 1,2,3,4,19,20,21,22, and 23 are used. How does this affect us?
CLP07 limit increased to 50 characters. This loads to payer_claim_id. We parse this. Will this affect us anywhere?
First CAS element used to just have one adjustment reason, code, and amount. Some reason codes were deleted. Now it allows for six different adjustments per claim (up to CAS19). In my code, I have not added anything here. I could really use a wiser head here on how we should treat this. Should they be parsed, added, and then all the adjustment reasons stored and reported sequentially? How will this affect the payments module? parse_era_2100() is supposed to attend to stuff here, and I don’t think I understand enough about the underlying system.
NM1 NM103/104 patient name fields have increased to 60/35 characters, which we trim. Will this affect us?
DTM- There are now 4 DTM segments. We ignore the original. Code changes needed to ignore the new ones? I once again suppose and hope not, but since this section gives us coverage data, I think it is really foolish not to put some effort into using it if payers are providing it.
Second CAS element (Service Adjustment) pops out warning to us about contractual Obligation differences. There seems to be a lot of this going on, and perhaps we need to get some better reporting into the payments module along with the payer contact data, Ja?
There are two new REF segments:
1. Service identification REF segment that gives us a line item control number supporting the above. This relates to data we could send with the 837 regarding this, and may help with reporting for the Service Adjustment. There is no value listed for the reference ID Qualifier for this REF segment, unlike the next one (same as the 4010 Rendering Provider Information) which is identified with ‘HPI’, and the second new one identified with ‘0K’ (Zero Kilo). Currently we ignore the Ref segment, but now there are three, which brings back the question of how/if the repeated segments are handled, i.e.:
else if ($segid == 'REF' && $out['loopid'] == '2110') {
// ignore
}
Finally, Segment PLB is out of order. It is shown to be after LQ Once again, I wonder if these Provider Level Adjustments should be better reported than just in the warnings in the HTML report.
biller2 wrote on Friday, December 23, 2011:
Question on the 5010 837. I sent to Idaho Medicaid “Molina” and they seemed to like the file just fine however I need to send 35 claims in a test batch before they will approve me for production so that will either be today or first part of next week. They will not accept any 5010 batches until Jan 1, 2012 so I can’t test that in production mode. The issues I have been having have been with Blue Cross of Idaho’s clearing house and Medicare “CGS” I send to both of them directly. Blue Cross is a website I upload files to and Medicare is a dial-up. For both of these carriers I wasn’t getting any conformation of the files. The lady from Blue Cross was the most helpful was able to look at the actual file I send and didn’t see anything wrong with it and couldn’t advise me on what was wrong with the file. She mentioned that it looked like there were to line feeds or carriage returns at the top of the file. I noticed the same thing so I thought what the heck, let me edit the file and remove those two lines and resend, viola they worked. My question is which file should I edit and what lines in that file are creating the carriage returns. If I can fix that I think I’m good to go. Thanks so much for the new 5010 programming its exciting so see it all come to fruition. John
biller2 wrote on Friday, December 23, 2011:
Oops please disregard the above post. It was obviously something I did. I took the original gen_x12_837.inc.php and replaced the one I was using and it works fine. I guess I did something to muck up that file. So in the end all is good. So sorry to interrupt this thread. Thanks again for the awesome work. John
cverk wrote on Monday, December 26, 2011:
I sent a 5010 X12 test file to OfficeAlly and received the following error message that might be helpful.
H10611 2 Excess trailing delimiters. " A delimiter is a symbol that indicates additional data appears in a segment, In the ANSI files it’s a * . The end of the segment contains * indicating there is additional data … only you aren’t sending any.
I am not sure since it only came through in one segment if you do or do not have data but you do need to make sure the file isn’t sent with the character or the processing systems assumes you are sending additional data in that segment. "
I found this in the x12 file as ( NM1*QC*1*lastname*firstname*~ ) where the last * is considered the excess delimiter.
The only other error is that you should enter your facility zip code without a hyphen between the first 5 and last four digits. (xxxxxxxxx) not (xxxxx-xxxx).I guess the field has only 9 digits and doesn’t accept hyphens. They said they can edit that out from their end if needed, but it likely could trip up other clearinghouses.
Other than those two issues, they say it is ready to go. Any idea how to fix the delimiter issue?
cverk wrote on Monday, December 26, 2011:
I think this might be the problem. In the gen_x12_837.inc.php file for the patient, it appears if you don’t put in a patients middle name in demographics, which we commonly have not and carriers don’t require, the code still enters a * before the blank spot where it expects a middle name to be. This is perhaps then seen as an excess delimiter.
++$edicount;
$out .= “NM1” . // Loop 2010CA Patient
“*QC” .
“*1” .
“*” . $claim->patientLastName() .
“*” . $claim->patientFirstName() .
“*” . $claim->patientMiddleName() .
“~\n”;
I just commented out the patient middle name line and it seems to create a file without the excess delimiter. I will see if office ally is willing to test that again for me. Any thoughts?