Refactor transformation helpers

[basiliskus]

Refactor transformation helpers

• Refactored to create more generic helper functions:
  • addMetaTag instead of addEtorTagToBundle
  • setMessageTypeCoding instead of convertToOmlOrder
• Consolidated hapi helper methods in HapiHelper (removed HapiMessageConverterHelper and HapiOrderConverterHelper)
• Moved logic from helper to transformation methods when unique to the transformation

Issue

#1024

Checklist

• I have added tests to cover my changes
• I have added logging where useful (with appropriate log level)
• I have added JavaDocs where required
• I have updated the documentation accordingly

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[jorg3lopez]

I like that the logic is in transformation object. At lease we don't have to go looking else where for it. The only thing that I realize now is that this tightly couples the fhir library to each transformation object. I'm ok leaving it like this or adding the logic to the fhir humble object.

[basiliskus]

I like that the logic is in transformation object. At lease we don't have to go looking else where for it. The only thing that I realize now is that this tightly couples the fhir library to each transformation object. I'm ok leaving it like this or adding the logic to the fhir humble object.

Right. I think it may be ok as the transformations deal with the inners of the bundle and it may be cumbersome to abstract them from the hapi library, but I'm sure we can make improvements in that direction. This could be a good topic for eng. block. I'll add it

[jorg3lopez]

I like that the logic is in transformation object. At lease we don't have to go looking else where for it. The only thing that I realize now is that this tightly couples the fhir library to each transformation object. I'm ok leaving it like this or adding the logic to the fhir humble object.

Right. I think it may be ok as the transformations deal with the inners of the bundle and it may be cumbersome to abstract them from the hapi library, but I'm sure we can make improvements in that direction. This could be a good topic for eng. block. I'll add it

Yes. I also realize that the FHIR bundle dependency will be a part of the transformation object regardless of where we put the logic. The bundle will have to get passed to the helper function or we will iterate through it if we keep the logic in the transformation objects.

[jcrichlake]

Small note to please move the magic strings to enums/ constants in the next PR, approving with that note