Adjust abnormal flag mapping

[emyl3]

BACKEND PULL REQUEST

Related Issue

• Part 1 for FHIR Mapping: Adjust abnormal flag mapping #7897
• This should at least fix the issue CA was experiencing.

Changes Proposed

• Set the Abnormal and Normal coding only when they match a defined list of SNOMED codes that we support
• If the SNOMED code that is provided does not match, we will log it and return null instead of setting the code to Normal

Additional Information

• Will create an alert in a separate PR when we log an unsupported SNOMED code
• ⚠️ As part of Update Bulk Result File Validation: Result Code #7898 we should make sure that any results being sent to the CSV pipeline should also map to values here: https://github.com/CDCgov/prime-reportstream/blob/1ffae4ca0b04cd0aa9f169e26813ecd86df71bb5/prime-router/src/main/kotlin/metadata/Mappers.kt#L768 otherwise you get the following error from ReportStream that is not obvious to users uploading their results:
  RS CSV API Error 400 Response:

{
  "id" : null,
  "submissionId" : 4261955,
  "overallStatus" : "Error",
  "timestamp" : "2024-07-11T20:43:28.954Z",
  "plannedCompletionAt" : null,
  "actualCompletionAt" : null,
  "sender" : "",
  "reportItemCount" : null,
  "errorCount" : 1,
  "warningCount" : 0,
  "httpStatus" : 400,
  "destinations" : [ ],
  "actionName" : "receive",
  "externalName" : "",
  "reportId" : null,
  "topic" : null,
  "bodyFormat" : "",
  "errors" : [ {
    "scope" : "item",
    "indices" : [ 1 ],
    "trackingIds" : [ "42daf9c8-9deb-4636-a040-380bde2b44cd+1+20240711" ],
    "field" : "test_result (test_result)",
    "message" : "The code '' for field test_result (test_result) is invalid. Reformat to HL7 specification.",
    "errorCode" : "INVALID_MSG_PARSE_CODE"
  } ],
  "warnings" : [ ],
  "destinationCount" : 0,
  "fileName" : ""
}

Testing

• deployed to dev3
• upload a bulk result with various SNOMED combinations
• example with new SNOMEDs
  DEV3_EX.csv

[emyl3]

fixed to Encode.forJava(resultCode)) 😅

[DanielSass]

I think it also makes sense to adjust this bit to not add the interpretation that the abnormal flag coding lives inside. (otherwise it will just be an empty interpretation)

[mpbrown]

+1 agree that makes sense to omit the interpretation if it'll be empty anyway

[emyl3]

OO good catch -- thank you!

[mpbrown]

LGTM! Nice work!

[sonarqubecloud]

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

[emyl3]

@fzhao99 @DanielSass @mpbrown Ready for re-review!

[DanielSass]

⚠️ As part of #7898 we should make sure that any results being sent to the CSV pipeline should also map to values here: https://github.com/CDCgov/prime-reportstream/blob/1ffae4ca0b04cd0aa9f169e26813ecd86df71bb5/prime-router/src/main/kotlin/metadata/Mappers.kt#L768 otherwise you get the following error from ReportStream that is not obvious to users uploading their results:

about this bit - is this an issue with how we are handling the response (in other words, do we need to do work to convey info we're getting from RS back to the user)?

Definitely out of scope for this PR, just something to think about as we look at the next story for updating the bulk upload file validation

[emyl3]

This is an example of a FHIR bundle with a nonsensical SNOMED (search "111") -- no abnormal/normal flag is added
hiv_bundle_with_nonsense_snomed.json