person cluster patient assignment endpoints

[ericbuckley]

Description

Two new person API endpoints for assigning patients to different person clusters.

Related Issues

closes #158

Additional Notes

• Deprecating existing create_person and update_person routes in the patient router
• Created create_person and update_person in the person router to replace ones in patient router
• Updated two mpi_service functions to accept a list of patients rather than just 1
• regrouping all patient, person and seeding api endpoints into "mpi" tag in api docs

<--------------------- REMOVE THE LINES BELOW BEFORE MERGING --------------------->

Checklist

Please review and complete the following checklist before submitting your pull request:

• I have ensured that the pull request is of a manageable size, allowing it to be reviewed within a single session.
• I have reviewed my changes to ensure they are clear, concise, and well-documented.
• I have updated the documentation, if applicable.
• I have added or updated test cases to cover my changes, if applicable.
• I have minimized the number of reviewers to include only those essential for the review.

Checklist for Reviewers

Please review and complete the following checklist during the review process:

• The code follows best practices and conventions.
• The changes implement the desired functionality or fix the reported issue.
• The tests cover the new changes and pass successfully.
• Any potential edge cases or error scenarios have been considered.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.62%. Comparing base (9bd3778) to head (6946c33).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #172      +/-   ##
==========================================
+ Coverage   97.56%   97.62%   +0.05%     
==========================================
  Files          31       32       +1     
  Lines        1521     1556      +35     
==========================================
+ Hits         1484     1519      +35     
  Misses         37       37              

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

[bamader]

The code changes themselves all look fine to me. I'm wondering what the rationale is for making the functions that previously operated on a single patient or person now perform bulk retrievals / updates. That seems to actually be a fairly dangerous process (see my example above about how that could corrupt linkage results and degrade future cluster quality) if we're performing this on any kind of updates to person clusters in between processing new in coming records. This seems like a case where I'm missing some context though, such as maybe this is only used for seeding.

[bamader]

Nothing wrong in the code here, just curiosity: what's the impetus for changing this from a singular patient operating function to a plural patients? Just thinking about it pedagogically in the abstract, a single patient makes sense to me because we'll be operating on single incoming records, but I think this is an area where missing context is probably in play.

[bamader]

Same question here as above, when would we be bulk updating a person cluster than adding one patient at a time? This is particularly true because that could actually change performance; e.g., adding one patient, then one patient, then one patient leaves room for the linking algorithm to actually return different match results for each subsequent addition, vs bulk adding three new patients all in one cluster update runs the risk of not properly using those second and third patients to get the most accurate linkage results. It's possible one or more might be found to be non-matches for the newly updated cluster, after adding the first patient in.

[bamader]

If we're just pulling one patient out of the returned bunch, that would seem to support having a function that does a single patient operation as the correct signature, right?

[bamader]

ditto