-
-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/FilterSurgeries #59
Conversation
Needed to change parameter to be consistent with other files to pass merge tests, once merged with main I will create another PR to fix this.
…024-Intake into feature/filter_surgeries
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #59 +/- ##
==========================================
- Coverage 13.86% 13.08% -0.77%
==========================================
Files 55 55
Lines 2671 2845 +174
==========================================
+ Hits 370 372 +2
- Misses 2301 2473 +172
Continue to review full report in Codecov by Sentry.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FIYA
Load robust Surgery data from FHIR Resource and filter procedures using manual filters and LLM reasoning
♻️ Current situation & Problem
At first pass, the SurgeryItem had the following footprint:
To load the surgery from FHIR data into this struct, we had a shallow query that only took the display name and date from the FHIRResource datatype instead of loading the robust data from the Procedures datatype specifically. This looked something like this:
Furthermore, there was no filtering done on the procedures, meaning that the datapoints we displayed included items such as "Medication Reconciliation". Technically, these count as procedures, but we want to filter them out and only keep relevant surgeries.
⚙️ Release Notes
Now, we load data from the Procedure itself, and have access to richer information: notes, complications, status, location, and body sites, as well as more specific date information that allows for operations that span more than one day. See the Documentation section for more information about the specific changes to the SurgeryItem footprint and the new loading function.
Additionally, the function that loads in the surgeries now filters them using a manual filter and LLM reasoning. First, the manual filter excludes all procedures whose display name includes words in a manually curated stopWords list (see inline documentation). Then, the remaining display names are passed to an LLM, which removes extraneous labels such as "(procedure)" and selects which surgeries seem most relevant. This is done with few-shot prompting, and works reasonably well (see in-line documentation). More work is required to fine tune this process for better results.
📚 Documentation
The SurgeryItem now includes more robust information:
Note that there will only ever be an endDate if there is also a startDate. Both are optional.
See inline documentation for details about the loading function and filtering.
✅ Testing
This section will be thoroughly tested along with the rest of the code.
📝 Code of Conduct & Contributing Guidelines
By submitting creating this pull request, you agree to follow our Code of Conduct and Contributing Guidelines: