[BUG] Fix bulk upload user-provided test result SNOMEDs mapping to invalid result description

[mpbrown]

Description

The bulk results uploader will list an Invalid result description if the user provides a test result SNOMED that we don't have an explicit mapping for.

Steps to reproduce

A bulk upload result row with test result of 260373001 will map the description to Detected

A bulk upload result row with test result of 10828004 will fail to map and default to a description of Invalid result (this particular code should map to Positive)

ConvertToObservationProps.resultDescription is converted into display field below

Mismatched SNOMED codes and descriptions in the ValueCodeableConcept Element of the observation

"valueCodeableConcept": {
    "coding": [
        {
            "system": "http://snomed.info/sct",
            "code": "10828004",
            "display": "Invalid result"
        }
    ]
}

Expected behavior

• SNOMED 10828004 maps to Positive and 260385009 maps to Negative
• Expect that any SNOMED that doesn't map to our predefined list should have the description omitted

Additional context

This is the method that will need to be updated, where we convert the SNOMED code to a description that is then used in the bulk uploader here and the FHIR converter here

See this Slack thread for more context on the related support request

[DanielSass]

Should it map to something like "User provided SNOMED"?

I think the convertConceptCodeToConceptName should be updated to default to an empty value rather than a specific description.

We're giving the freedom to our bulk upload users to pick any valid SNOMED and I don't think it's reasonable to support mapping every possible valid snomed to a description. And (obviously?) it's not reasonable to assume that if a SNOMED isn't in our list that it is invalid.

And the description we're passing is expected to match the snomed and describe it, which "User provided SNOMED" or something similar would not do.

I'll reach out to James Gilmore just to confirm this assumption.

[mpbrown]

Yeah was wondering if for those cases whether we should just omit description entirely (or leave it blank like you mentioned) or if that would make it seem like there is missing data

[DanielSass]

to clarify: I meant returning and empty string from the function you mentioned. We already have logic in place that only adds a description if we have a value for it, so that would result in omitting the description from the fhir (not having an empty string value).