Skip to content

feat: Add foreign key on ecr_rr_conditions to the condition_reference table #678

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

Draft
wants to merge 25 commits into
base: main
Choose a base branch
from

Conversation

akasper
Copy link
Collaborator

@akasper akasper commented May 1, 2025

PULL REQUEST

Now that we have a consistent identifier for conditions (via the condition_reference table), are add a foreign key reference to those conditions in our per-eCR reportability response conditions.

Summary

  • A database schema change that adds condition_id to ecr_rr_conditions, as well as a foreign key
  • The attendant TypeScript interface definition changes for ecr_rr_conditions
  • Modifications to data saving logic
  • Logic for backfilling existing data
  • Tests that document and prove the functionality

Related Issue

Ticket #513

Acceptance Criteria

  • A nullable column called condition_id should be added to the ecr_rr_conditions table (both schemas). It should be a foreign key to condition_reference
    • postgres
    • sql server
  • On saving data to ecr_rr_conditions it should be stamped with this ID if it can be determined
  • Create a migration such that the data already in the ecr_rr_conditions table gets an accurate fk reference to the condition_reference table

@codecov-commenter
Copy link

codecov-commenter commented May 1, 2025

Codecov Report

Attention: Patch coverage is 62.50000% with 9 lines in your changes missing coverage. Please review.

Project coverage is 92.24%. Comparing base (6a347ca) to head (6d5b512).
Report is 9 commits behind head on main.

Files with missing lines Patch % Lines
...ns/core/20250509000002_backfill_condition_codes.ts 53.33% 7 Missing ⚠️
...-db/migrations/core/20250509000000_condition_fk.ts 77.77% 2 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #678      +/-   ##
==========================================
+ Coverage   87.48%   92.24%   +4.75%     
==========================================
  Files         268      164     -104     
  Lines       14101     7475    -6626     
  Branches      886      873      -13     
==========================================
- Hits        12336     6895    -5441     
+ Misses       1748      574    -1174     
+ Partials       17        6      -11     
Flag Coverage Δ
ecr-viewer 92.43% <62.50%> (-0.47%) ⬇️
fhir-converter ?
ingestion ?
message-parser 96.12% <ø> (ø)
message-refiner ?
orchestration 85.45% <ø> (ø)
record-linkage ?
trigger-code-reference ?
validation ?

Flags with carried forward coverage won't be shown. Click here to find out more.

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

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@akasper akasper force-pushed the akasper/condition-ref-fk branch from aab819c to d50d5c8 Compare May 1, 2025 11:17
Comment on lines 312 to 319
const rr_code = await trx
.selectFrom("condition_reference")
.select("code")
.where("condition_name", "=", rrItem.condition)
.executeTakeFirst();

if (!rr_code) {
console.error(`Condition ${rrItem.condition} not found in condition_reference table`);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we add this to the metadata instead? Our conditions reference comes from TRS, so we should be able to just add the code to the metadata schema and get it from the fhir bundle if it exists

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ECR Viewer side of things is properly set up but getting a little lost in the weeds of orchestration. Would you mind taking a look at what I've done with the schema changes in the message parser @mcmcgrath13

@akasper akasper force-pushed the akasper/condition-ref-fk branch from c1ca43d to b4b5673 Compare May 7, 2025 15:56
Comment on lines 312 to 316
const rr_code = await trx
.selectFrom("condition_reference")
.select("code")
.where("condition_name", "=", rrItem.condition)
.executeTakeFirst();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

still needs to be sourced from the metadata data (and metadata parser updated to add it)

.where("condition_code", "is", null)
.execute();
} else if (dbDialect() === "sqlserver") {
const rows = await _db
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would this branch also work for postgres?

Comment on lines 62 to 69
"condition_code": {
"fhir_path": "iif(Observation.valueCodeableConcept.text.exists(), Observation.valueCodeableConcept.text, Observation.valueCodeableConcept.coding.display)",
"data_type": "string",
"nullable": true,
"metadata": {
"category": "RR Reportability Information"
}
},
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

move this up into the rr section and maybe just name code?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants