Create SRD for FHIR Translation Feature

[arnejduranovic]

User Story

As the Universal Pipeline, My steps should follow the single-responsibility principle (in other words, the steps should be cohesive), so that I can reduce the complexity of the system, make it easier to configure and maintain, and make it easier to keep the implementation DRY.

Description/Use Case

Presently, the Route step (ReceiverFilterFunction) has filters that also modify bundles. This is bad design as it makes the possibility of defects higher and makes the system harder to use and understand. Instead, routing filter's sole responsibility shall be to determine if a bundle contains the necessary information a particular receiver is asking for. ReportStream presently has the ability to modify bundles via FHIR-FHIR transforms, and this should be the only place bundles are modified.

The high-level proposal that should be documented as an SRD is:

• Add a new step between DestinationFilterFunction and ReceiverFilterFunction that shall apply one or more FHIR transforms to a bundle
  • This will require adding new functionality to FHIR-FHIR transforms, like the ability to remove one or more resources
• Remove MappedConditionFilter
• Redesign Receiver Routing Filters: squish all the receiver filters into a single FHIR expression Filter that can be instantiated as many times as the user would like. This can exist in parallel with the existing system as to not force engagement to perform a migration.

Risks/Impacts/Considerations

Dev Notes

Acceptance Criteria

• [ ] SRD Created
• [ ] Approval from Engagement team (Chris and Victor)

[Andrey-Glazkv]

Hey team! Please add your planning poker estimate with Zenhub @adegolier @arnejduranovic @brick-green @david-navapbc @jack-h-wang @jalbinson @JFisk42 @mkalish @thetaurean

[Andrey-Glazkv]

Hey team! Please add your planning poker estimate with Zenhub @adegolier @brick-green

[arnejduranovic]

Before we do this, we'd like more info on what features are missing or needed for engagement to migrate to relying on FHIR->FHIR transforms for data-related enrichments. @chris-kuryak. It does not make much sense to proceed with this work until we have that AND a commitment to migrate data enrichments to FHIR->FHIR transforms. @chris-kuryak @Andrey-Glazkv @brandonnava