-
Notifications
You must be signed in to change notification settings - Fork 7
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
Cancelled rows stay as zombies in the encounter* table #95
Labels
good first issue
Good for newcomers
Comments
BEULAHEVANJALIN
added a commit
that referenced
this issue
Apr 12, 2024
BEULAHEVANJALIN
added a commit
that referenced
this issue
Apr 12, 2024
vinayvenu
added a commit
that referenced
this issue
Apr 12, 2024
#95 | cancelDateTime updated in ETL tables
There is a corresponding migration that has not been done as part of this card. |
@vinayvenu we could have deleted the row in encounter table to keep it consistent instead of updating the cancel_date_time? Was there a reason we didn't do it that way? |
@mahalakshme some reports are expecting cancel datetime in the encounter table. We will be breaking the contract by removing the rows |
@vinayvenu oh okay got it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When an encounter or program_encounter is cancelled, then the corresponding row in the etl's encounter* table is left as a zombie and never updated.
The cancel_date_time is mentioned in the encounter* tables, but anything with a cancel_date_time is never updated. For those querying the table, it feels as if there is a planned encounter that never got done, but it is actually cancelled, but the row was never updated in the table.
A side impact of this behaviour is that if a row was cancelled before the first run of ETL, then it will show up only on the _cancel table and not on the encounter table. This makes behaviour inconsistent.
Fix
The text was updated successfully, but these errors were encountered: