Add DrugRecommendationOMOP task

[lehendo]

• drug_recommendation_omop_fn never excluded the current visit's own drugs from drugs_all, unlike every sibling drug-recommendation function/class, so the last history entry was identical to the prediction target. Fixed to match the established pattern (this is not necessary in retrospect, but the fix is fine)
• Add DrugRecommendationOMOP, a current-API, leak-free class-based replacement, since drug_recommendation_omop_fn (and its mimic3/mimic4 siblings) cannot actually run through set_task() under the current Patient/Visit API
• Document the legacy function family's set_task() incompatibility and flag the same issue in the one live example that hits it

Also addresses the comments made by @AxelNoun.

[AxelNoun]

I made a mistake because I had the commands ready, and I ended up pushing to your fork. I'm closing the PR. Sorry again for the mix-up!

[AxelNoun]

Hi. I spent some time reviewing this against the current codebase and running it locally.

The gap is real: MortalityPredictionOMOP, LengthOfStayPredictionOMOP and ReadmissionPredictionOMOP all exist, and drug recommendation is the one missing. Your diagnosis checks out too. I verified that Visit is a deprecated stub with no get_code_list, that Patient has neither __len__ nor __getitem__, and that set_task() reads task.task_name / input_schema / output_schema, so the legacy *_fn genuinely cannot run.

A few things I'd raise before this lands.

The test never exercises set_task(). It calls DrugRecommendationOMOP()(patient) directly, so the nested_sequence and multilabel processors are never run, which is the central claim of the PR. tests/core/test_omop_readmission_prediction.py is a good precedent.

The fixture can't detect the regression it targets. In test-resources/omop, only person_id = "1" has ≥2 visits with condition + procedure + drug together, and all four of its visits carry concept_id = "1" across all three tables. The drugs_hist[j] == ["1"] assertions would pass with a shifted, misattributed or reordered history. The only real assertion is that slot i is empty.

No cache_dir, so the test writes to the default platformdirs cache and can pick up a stale build between runs.

Smaller points:

• __call__'s docstring says "one sample per visit (after first visit)", but a sample is emitted for every qualifying visit including the first (drugs_hist == [[]]). Inherited from the eICU copy.
• The code filter is is not None, but CSV loading is all-string via pyarrow with strings_can_be_null=False, so a blank cell arrives as "" and becomes a code. Concept id 0 ("no matching concept") also becomes a label, while _is_missing_ndc in the same file already treats "0" as missing.
• samples[i]["drugs_hist"][j] is the same list object as samples[j]["drugs"]. Nothing mutates it today, but it's a sharp edge worth a defensive copy.
• Three get_events per visit is O(V·N). One pass grouped by visit_occurrence_id is equivalent and much cheaper on OMOP, where patients tend to have many more visits than in eICU.
• The example change documents the breakage rather than fixing it (DrugRecommendationMIMIC4() is a two-line fix), and nothing currently demonstrates the new task.

I've put a branch addressing all of the above on my fork, AxelNoun/PyHealth, branch drugleak-fixups. It builds on your commit, so comparing it against drugleak shows only the two commits I added. It has 17 tests written before the fixes (red on the aliasing and the 0 handling beforehand), a throwaway fixture built in a TemporaryDirectory so test-resources/omop stays untouched, and set_task() covered. Happy to open it against your branch, or paste the diff here, whichever you prefer.

[lehendo]

Hey @AxelNoun, I appreciate the comments and pointing out the issues. I have gone ahead and added your branch commits to this PR. Feel free to review this PR again, and let me know if it good to merge to master.

[fbonc]

looks good.

[AxelNoun]

Hey @AxelNoun, I appreciate the comments and pointing out the issues. I have gone ahead and added your branch commits to this PR. Feel free to review this PR again, and let me know if it good to merge to master.

Sounds good to me, thank you for taking my recommendations into account!

[jhnwu3]

lgtm