Refactor connector: Add adjustment logic and better enrollment dates

[sarah-tuva]

Describe your changes

Please include a summary of any changes.

• Update package version range to Tuva v0.12.x
• Update project config defaults
• Add adjustment logic for DME claims
• Add adjustment logic for institutional claims
• Add adjustment logic for physician claims
• Add part D mapping and adjustment logic for pharmacy claims
• Add dbt tests for final models
• Add new enrollment file logic to populate eligibility dates with custom source
  • Background: The CCLF specification does not have a field that can be mapped directly to enrollment_start_date and enrollment_end_date, and the Part A and Part B entitlement dates (BENE_PART_A_ENRLMT_BGN_DT, BENE_PART_B_ENRLMT_BGN_DT) are often incorrect or not useful for claims analytics.
  • Enhancement: We have included an additional source called Enrollment that can be populated with enrollment dates relevant to your data. These enrollment dates may come from an attribution file, beneficiary alignment report (BAR), or any source you may have.

How has this been tested?

Please describe the tests you ran to verify your changes. Provide instructions or code to reproduce output.

Ran dbt build with original connector and refactored connector. Validated and compared output results.

Reviewer focus

Please summarize the specific items you’d like the reviewer(s) to look into.

Checklist before requesting a review

• (Optional) I have recorded a Loom performing a self-review of my code
• My code follows style guidelines
• I have commented my code as necessary
• (New models only) I have implemented generic dbt tests to validate primary keys/uniqueness in my model
• I have added at least one Github label to this PR

(Optional) Gif of how this PR makes you feel

Loom link

https://www.loom.com/share/7537bfa98fba4a6f95c86796fbe4bca0?sid=18ce83eb-cf84-4b6e-96dc-d349c374aec5

[sarah-tuva]

CI/CD has not be setup for Fabric yet. Locally testing passed.

fabric_ci_results.txt

[chase-jones]

Raising a couple of concerns @sarah-tuva . Would like to have more time to go through if possible. Concern that some claims would be getting thrown out incorrectly with logic as it stands.

[chase-jones]

Not a fan of this sort being between different models for row_num.

[sarah-tuva]

@chase-jones Can you elaborate? I'm not following your concern here.

[chase-jones]

Concern in that logic of

row_number() over (
            partition by
                  clm_blg_prvdr_oscar_num
                , clm_from_dt
                , clm_thru_dt
                , current_bene_mbi_id
            order by
                  clm_efctv_dt desc
                , cur_clm_uniq_id desc
        )

in models/intermediate/int_institutional_claim_adr.sql
might be non deterministic where here is a 0 and 1 in the same instance for adj reason codes. If this picks the 1, then the entire claim get's thrown out? But if it picks 0 then you get the latest claim?

[sarah-tuva]

Based on my exploration of real data, CMS does not always send the proper adjustment type codes for adjusted claims. They were often sending a '0' instead of a '2' for an adjusted claim, so it was unreliable in the sorting logic. This is why we are using the latest claim effective date and claim ID to try to ensure the adjusted claims get selected rather than the canceled claims. Again, this is all based on my own testing with real data (from multiple claim years), but everyone's dataset may be different.

Do you have a suggestion for better sorting logic based on your experience?

[sarah-tuva]

@bradmontierth @chase-jones I have a few people waiting to use this connector. Can I get approval on this PR? I would like to merge it as is. We've tested it on a few real data sets, and the ADR logic seems to be working okay. We can push a patch later if someone comes up with better logic for ADR.