Feature/remits poc phase1

[keironstoddart]

Hi @shalini1017,

Thank you for your interest in this project! I will review your pull request this weekend.

Best, Keiron

[christopherpickering]

@shalini1017 I'm testing this out and commented on a few things that I think need to be updated.

For me, I find this working when there are multiple claims per id. Any chance you can give a short description of what you are doing? I'm pretty new to this :)

[gizquier2]

@shalini1017 I'm testing this out and commented on a few things that I think need to be updated.

For me, I find this working when there are multiple claims per id. Any chance you can give a short description of what you are doing? I'm pretty new to this :)

I guess you need to be more clear on multiple claims per ID comment. A claim can have multiple lines not really clear what do you mean by id, are you referring to multiple claims per member (policy number)?

[gizquier2]

@shalini1017 I'm testing this out and commented on a few things that I think need to be updated.

For me, I find this working when there are multiple claims per id. Any chance you can give a short description of what you are doing? I'm pretty new to this :)

This merge code I believe is trying to parse the United healthcare 835•s. Delimiters are used to specify the start and end between segments or loops. The normal one is ~ but some payers may use different ones.

i would suggest read some details on the cms 835 documentation to get some standard. I will try to link it somewhere else, let’s try not to deviate from the subject if possible.

[christopherpickering]

Well, when I'm parsing Medicare claims w/ this code, there are many duplicate rows. I think the are coming in with the for loop in the transaction set serialize, but I'm digging into that still.

Yeah, I picked up on the delimiter pretty quickly ;)

[christopherpickering]

Here's a few guides I found -

• Medicare
• UHC AARP
• UHC
• UHC Community
• UHC Vision

[christopherpickering]

I think the lines appears as duplicates because the service details were removed from the dataframe. Adding these back give more details. Any reason why they should be removed?

from transaction_set.py, the datum list.

'service_code': service.service.code,
'service_modifier': service.service.modifier,
'service_qualifier': service.service.qualifier,
'service_allowed_units': service.service.allowed_units,
'service_billed_units': service.service.billed_units,
'service_charge_amount': service.service.charge_amount,
'service_paid_amount': service.service.paid_amount,
'service_start_date': start_date,
'service_end_date': end_date

[lrpauley]

@shalini1017 @keironstoddart is there a plan to get some of these changes merged? i'm working on an EDI 835 project right now, and there's some work in here that would be great to have in the main branch. i'd be willing to break some things out into smaller pieces if there's interest

[keironstoddart]

@lrpauley, thank you for your interest. What changes are you referring to in particular?

[lrpauley]

@keironstoddart I'm most interested in the logic for parsing additional details from the file. Specifically the Provider and Claim-level adjustment handling as well as the additional claim segment parsing are top of mind.

[christopherpickering]

I'd be happy to split this pr up into several pr's if it helps. I'm also on a modified version now that uses most of these changes.

[lrpauley]

same, right now i'm working off of @shalini1017's fork, but since there's some active dev happening in this fork as well, it'd be great to have things centralized. @keironstoddart lmk if you're open to PRs for the changes i mentioned. maybe @christopherpickering and i could split things up and make a few PRs.

[keironstoddart]

Yeah, this all sounds great to me. I'm definitely open to merging PRs as long as any given PR is branched from a recent main commit and encapsulates a single unit of functionality. Otherwise, it's hard for me to keep everything straight and unit test each piece of new functionality effectively before merging into the main branch for release.

[lrpauley]

great. i can start with the added parsing in segments/claim.py and go from there

[christopherpickering]

I haven't been on the project recently, but should be in the next few months. I can send split up prs then as well.

[rposborne]

@christopherpickering just wanted to give you a shout-out for an excellent review / suggestions here. Working through building on this and each time we hit a fail, you have suggested a fix.

[rposborne]

Also, throwing my hat in here to help move this work along, main is unable to parse our files but this branch is. Happy to other any support.