Open david-navapbc opened 4 months ago
@GilmoreA6 SME guidance required for the requirements listed above.
Hey team! Please add your planning poker estimate with Zenhub @brick-green @david-navapbc @jack-h-wang @jalbinson @JFisk42 @mkalish @thetaurean
Please add your planning poker estimate with Zenhub @adegolier
- receiver
- name : ELR_EXAMPLE
- Topic: FULL_ELR
- FHIRTransforms: [ELR_EXAMPLE_REMOVE_OBSERVATIONS.yml, GENERIC_REMOVE_ORPHAN_DIAGNOSTIC_REPORTS.yml]
Spent time today learning about mappings and how messages are transformed. Specifically FHIR->FHIR. I still need to trace through the data flows and testing rig to better understand how things work presently.
talked with @arnejduranovic and @JFisk42 today to get some clarity on the flow involving FhirTransformSchemaElementAction.DELETE
refactored FHIRReceiverFilter.evaluateObservationConditionFilters()
to reduce redundant code and improve algorithmic efficiency. all existing tests are still passing.
going to look more closely at the FHIRBundleHelpers
methods to ensure they are doing things in a grokkable and efficient manner and shore up testing.
PR up. As per scope of ticket I left most of the things alone. I did validate the flow has a robust set of tests and I did refactor the method in FhirReceiverFilter that coordinates filtering/removal of resources. I also sanity checked the utility methods in FHIRBundleHelpers to ensure they were doing it right.
we're going a different direction with this but we wanted to save the work I did - which is here in this draft pr
Some more context: We are currently working on the design for ReceiverFilterFunction which will remove the need for conditionFilter and mappedConditionFilter and the deletion of resources (and the associated cleanup) is currently being planned to happen completely in FHIR->FHIR transforms, thus making this ticket redundant in the long term. The design is not set in stone and may change, but that is where we are at now.
User Story
As a receiver of reports from ReportStream, I want the received items to be "properly" cleaned up when resources are removed, so that my system can safely process the items and confusion can be limited.
Description/Use Case
Presently, when a resource is deleted there is complicated and poorly tested logic that runs to "clean up" the bundle. It has been decided this functionality should be:
The resource deletion strategy should be updated to adhere to the following requirements:
Risks/Impacts/Considerations
Dev Notes
Acceptance Criteria