Remove la obr except 54089 8

[somesylvie]

Add a PR title

Describe what changed in this PR at a high level.

Issue

#1355

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

Note: You may remove items that are not applicable

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 1355 - Partially compliant Fully compliant requirements: The OBR for "54089-8" remains unchanged All other OBR are removed from the outgoing HL7 ORU message All OBXs appear under the sole remaining OBR Not compliant requirements: Numeric OBX IDs are sequential and unique Write a RS E2E test that covers this transformation similar to Implementation: Automated TI <> RS tests #1255.

⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Test Completeness The PR lacks tests to verify that OBX IDs are sequential and unique, which is a requirement of the ticket.

[github-actions]

Consider adding assertions to verify that OBX IDs are sequential and unique after the transformation. This is crucial to meet the ticket requirements and ensure data integrity. [important]

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Score
Possible bug	Define the variable obr4_1 before using it to prevent undefined variable errors Ensure that the variable obr4_1 is defined before it is used in the expect block to avoid runtime errors. etor/src/test/groovy/gov/hhs/cdc/trustedintermediary/etor/ruleengine/transformation/custom/RemoveObservationRequestsTest.groovy [57] +def obr4_1 = '54089-8' obr4_1 in obr4_1Values Suggestion importance[1-10]: 10 Why: The suggestion correctly identifies a critical bug where the variable obr4_1 is used before being defined, which would cause a runtime error. Defining it before use as suggested will prevent this error.	10
	Ensure transformClass and args are initialized to prevent null pointer exceptions Verify that the transformClass and args are properly defined and initialized before their use in the when block to ensure the transformation logic is executed correctly. etor/src/test/groovy/gov/hhs/cdc/trustedintermediary/etor/ruleengine/transformation/custom/RemoveObservationRequestsTest.groovy [60] +assert transformClass != null && args != null transformClass.transform(fhirResource, args) Suggestion importance[1-10]: 6 Why: This suggestion is valid as it promotes the initialization check of transformClass and args before their use, which enhances the robustness of the code by preventing potential null pointer exceptions.	6
Best practice	Use safer type checks and conditional casting to avoid runtime exceptions Replace the direct casting of DiagnosticReport and ServiceRequest with safer type checks and conditional casting to prevent ClassCastException. etor/src/test/groovy/gov/hhs/cdc/trustedintermediary/etor/ruleengine/transformation/custom/RemoveObservationRequestsTest.groovy [63-64] -def dr = diagnosticReports.first() as DiagnosticReport -def sr = HapiHelper.getServiceRequest(dr) +def dr = diagnosticReports.first() +if (dr instanceof DiagnosticReport) { + def sr = HapiHelper.getServiceRequest(dr) +} Suggestion importance[1-10]: 7 Why: The suggestion to replace direct casting with safer type checks and conditional casting is a good practice to avoid ClassCastException. This change improves the code's safety and robustness.	7
Enhancement	Provide a descriptive message for the transformation definition to enhance clarity and maintainability Add a meaningful message in the "message" field of the transformation definition to provide clarity on the operation being performed. etor/src/main/resources/transformation_definitions.json [173] -"message": "", +"message": "This transformation removes all OBRs except for the specified OBR-4.1 value in LA Ochsner ORU messages." Suggestion importance[1-10]: 5 Why: Adding a descriptive message to the transformation definition is a useful enhancement for clarity and maintainability. However, it's not critical for functionality, hence the moderate score.	5

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud