Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.06%. Comparing base (3ee7ec5) to head (a608798).
Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main     #229      +/-   ##
==========================================
+ Coverage   97.80%   98.06%   +0.26%     
==========================================
  Files          32       32              
  Lines        1774     1813      +39     
==========================================
+ Hits         1735     1778      +43     
+ Misses         39       35       -4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@ericbuckley @m-goggins Updated code to make all tests pass (there's still one set of three tests that involved belongingness that I'm not quite sure what to do with, but will continue noodling).

I also ran the algorithm tests using the certain hierarchy I established, and we doubled our performance! If we were getting 33% last time (two out of the six cases), we now get 4 out of the 6 cases correct. We correctly get 3 out of the 5 match cases, and correctly flag the invalid birthdate. The cases we miss are (1) the record has first and last name switched (there's nothing we can do about that, since first and last are blocking fields in one pass [they fail exact matching] and then evaluation fields in another [but they earn 0 points]); and (2) a test case where someone named Tho-mas fails to match to a cluster that contains 2 identical patients except for their first names, Thomas and ThoMas. I believe if we implemented basic string normalization on incoming names (e.g. standardize casing, remove numbers and punctuation) we would catch this case. We don't even have to do it at the persistence level so that data is still preserved as supplied; we could apply it on the fly during record evaluation, just like we proposed with skip values. This would allow us to still correctly model names that might actually have punctuation (e.g. the Arabic surname Al'Charif, also sometimes written Al-Charif) but wouldn't penalize one of those representations over the other. I believe this is a bug we should fix, but wanted to drop my findings here before I actually took off for the day.

Updating to mark all code here complete. All tests have been adjusted to match the new algorithm and everything passes. This is, from my view, "merge ready" code.

Flagging that I've edited the ticket's AC due to scoping down work and the urgency of progressing this to allow our clients to test. There won't be any logical or performance based hits as a result, merely moving work to consolidate and refactor code into a follow-up.

Follow up ticket with class consolidation: https://app.zenhub.com/workspaces/dibbs-record-linker-678acc70237f5000299a9d71/issues/gh/cdcgov/recordlinker/263

@m-goggins Super fair point, and I think it's important to show that grade adaptation is a new feature of the RMS decision mechanism. I've added tests to cover both directions (existing grade is certain so no change in pass 2, and existing grade is only possible so definite change in pass 2) so we should now have total coverage for our link.py case logic.