GratefulPatientFeaturizer/EncounterTransformer: index-encounter keying vs. the PHI-free bundle contract need a design decision

オープン
  • 何か問題がありますか？
#110 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
リファクタリング
明瞭さ
明確に書かれている
活発さ
静か
技術スタック
python, scikit-learn
領域
data

調査の方向性

Read philanthropy/preprocessing/_grateful_patient.py, especially merge_key, last_discharge, and __getstate__, then review the PHI-free bundle contract in docs/explanation/compliance_considerations.md and the issue’s linked context in #78. The issue is closed by a written decision on the tradeoff; if retaining latest-discharge keying, document the recurrent-patient limitation in the compliance considerations file.

索引モデルが issue の本文から書いたものです。

説明

help wanted question roadmap
The conflict

GratefulPatientFeaturizer and EncounterTransformer key on the donor's
latest discharge (grep -n "merge_key" philanthropy/preprocessing/_grateful_patient.py,
groupby on merge_key then take last_discharge). For a donor with more than
one encounter, a gift is measured against whichever discharge happens to be
most recent at fit/transform time, not the discharge that was actually closest
in time to that specific gift. Recurrent patients (oncology, transplant) are
the people this most misrepresents.

The fix needs the raw per-gift, per-encounter rows available at transform
time so each gift can be joined to its own nearest prior discharge. That is
exactly what __getstate__ is designed to strip
(grep -n "__getstate__" -A8 philanthropy/preprocessing/_grateful_patient.py):
raw encounter_df is PHI-bearing and is replaced with None on serialisation
so a saved model bundle never carries patient rows (#78).

Per-gift keying and the PHI-free bundle contract are in direct conflict. This
is not a bug with an obvious patch; it needs a design decision on which
guarantee gives way, or a third option (e.g. storing only a de-identified
per-donor encounter-to-gift offset at fit time, if that is precise enough).

Why it matters now

This is the one item from the 2026-08-13 audit that landed as "documented
limitation" rather than "fixed" going into the JOSS submission. It affects the
grateful-patient timing story the paper's Software design section describes as
solved via as_of; per-gift keying is a separate, still-open gap in the same
story.

What would close this

A written decision (this issue, a discussion, or a design doc) on one of:

  1. Keep latest-discharge keying, document the recurrent-patient
    misattribution explicitly as an accepted limitation in
    docs/explanation/compliance_considerations.md.
  2. Store a de-identified per-donor "days since nearest prior discharge, as of
    each gift date" summary at fit time (no raw dates, no diagnosis), so
    __getstate__ still has nothing PHI-bearing to strip.
  3. Some other resolution.

This needs a person to decide the tradeoff; it cannot be closed by a PR alone.

主要言語
Python
スター
11
フォーク
23
平均マージ
1日 8時間
マージ済み PR（30日）
35

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

PhilanthroPy-Project/PhilanthroPy のほかの issue

PhilanthroPy-Project/PhilanthroPy の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。