-
Notifications
You must be signed in to change notification settings - Fork 2
Track individual coding and import runs #92
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
base: main
Are you sure you want to change the base?
Conversation
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.
This looks nice! One thing that would be helpful is, for any given coding run, being able to tie the assigned CauseOfDeath or CauseCodingIssue to the VerbalAutopsy for that run. I could see having separate CodingBatch and ImportBatch models, and adding relations to the CodingBatch model, though there may be other ways to handle it.
I think this should be possible already unless I'm misunderstanding what you're getting at. Each BatchOperation has a list of VerbalAutopsy - and each VerbalAutopsy has a CauseOfDeath and CauseCodingIssue associated. So you could get all the CauseOfDeath instances for a specific BatchOperation if you wanted: CauseOfDeath.objects.filter(verbalautopsy__batchoperation=123) |
What about the case where 1) a coding run fails for a particular VA with some errors, 2) the VA is corrected to address the errors, and 3) the VA is coded in a subsequent coding run. In that case there will be two coding runs associated with that particular VA and I don't think it's possible to distinguish which coding run had the errors and which had the successful coding result. |
You're right. It doesn't handle that use case. Let me think over the design a bit and come up with something that addresses that. |
One thought: An ImportBatch model that has a 1-to-many relationship with the VerbalAutopsy model A CodingBatch model that has a 1-to-many relationship with both the CauseOfDeath and CauseCodingIssue models The CodingBatch model then has an implicit 1-to-many relationship with the VerbalAutopsy model through both the CauseOfDeath and CauseCodingIssue models |
Updated to split out In this test case below there were 39 VAs imported (as you can see by the import). The first time coding algorithm ran, it coded 27 VAs and 12 had errors (there were also 195 warnings). The second time coding algorithm ran, it tried to code the 12 that had errors (since they didn't have a COD) and they all failed again. So it keeps a full history of all errors/warnings/successful across all coding runs. |
Adds view_batchoperations permission, refactors navbar to contain link groups, tangentially fixes a bug preventing access to dhis page
de2a9f4
to
5c67239
Compare
For imports and coding algorithm runs, it will create a BatchOperation instance.
For each BatchOperation, it tracks associated verbal autopsies.
For an import BatchOperation, tracks all the VAs that are successfully imported.
For a coding BatchOperation, tracks all the VAs without cause that are sent to the coding algorithm (regardless of whether they are successfully coded).
Adds a page to view all past batch operations (at
/va_data_management/batch_operations
). There's no link to this page and no way to view the individual VAs in a batch yet. We'll want to think about the permissions for that.