On Add/Edit AllergyIntolerance, reaction object using Snomed CT terminology does not work

[tri...@cura.tech]

I am using open sandbox to test this.

While creating/editing and AllergyIntolerance and if I select a reaction from Snomed CT,  I am getting an error: Status: 500 Internal Server Error

Instead of selecting a Snomed CT term, if I enter a free text, the save is successful. So terminology mapping may not be working.

X-Request-Id : 44261bdfdd6d62826c07716c03b8187d

[tri...@cura.tech]

The reaction JSON structure that is posted to the sandbox is given below. Do let us know whether the full JSON body is required

"reaction": [
    {
      "manifestation": [
        {
          "coding": [
            {
              "code": "4685010",
              "display": "Pharyngeal edema",
              "system": "http://snomed.info/sct"
            }
          ]
        }
      ]
    }
]

[Jenni Syed (Cerner)]

For FHIR, whenever a create or update is done, the FHIR specification requires that the full resource, with any changes applied, is sent. Any unset value is interpreted as unsetting it/nulling it out.

This is called out in our documentation here: http://fhir.cerner.com/millennium/dstu2/general-clinical/allergy-intolerance/#update

Edit: after re-reading above, I can't tell if that was intended to just be an example of what was posted or a comment on the full body. We do not need the full body example - we'll use the request id you gave.

~ Jenni

[Jenni Syed (Cerner)]

Looking at the logs, we received an unexpected response from one of the underlying services. We'll continue to investigate this issue. Thank you for reporting it!

Do you know if the new/updated allergy shows in the response when you re-read the patient allergies? Allergies does do some duplicate checking, so it may update an existing allergy if it determines it's duplicated.

~ Jenni

[tri...@cura.tech]

Hi Jenni,

Is the reason identified? Here is an sample reaction segment that is being sent while creating AllergyIntolerance:
X-Request-Id: 9b4899957e1b3ebadf55101d6734ab97

Thanks
Trinadh..

"reaction": [
    {
      "manifestation": [
        {
          "text": "Muscle spasm - tone",
          "coding": [
            {
              "code": "333934015",
              "display": "Muscle spasm - tone",
              "system": "http://snomed.info/sct"
            }
          ]
        }
      ]
    },
    {
      "manifestation": [
        {
          "text": "Pharyngeal edema",

          "coding": [
            {
              "code": "4685010",
              "display": "Pharyngeal edema",
              "system": "http://snomed.info/sct"
            }
          ]
        }
      ]
    }
  ]

[Jenni Syed (Cerner)]

Hi Trinadh,

The one issue that's the defect is being investigated.

Can you answer my previous question, this will be helpful for the investigation: When you query for the allergy that seems to have failed, do you see it in the resulting list? Again, if you try to write an allergy that already exists, it may update an existing allergy rather than adding a new one. So you may need to see if there's an allergy that's already in the list.

~ Jenni

[tri...@cura.tech]

Hi Jenni,

Here is a new x-request id that we tried debugging.

> X-Request-Id: 4633e1ebd0ef861416d7dfdd50a78e86

> X-Request-Id: 03cc8d42433e05b3ed4c837cc98ac9b0

We tried both the options:
1) Creating a new Allergy with reaction which is failing
2) Adding a new reaction(s) to an existing allergy which also fails.
New allergy doesn't get saved hence not present in the list of allergies of patient and existing doesn't get update though we can read.

Thanks
Trinadh..

[Jenni Syed (Cerner)]

It looks like the code you're using may not be mapped/exist in the environment. It should land as a freetext reaction when that happens, so we're investigating that aspect of the issue. However, I assume that's not what you would like to happen :)

Does the local Millennium system allow this SNOMED code to be chosen for the allergy reaction?

~ Jenni

[Jenni Syed (Cerner)]

To add more detail here - we'll be updating the underlying code to allow the "freetext" override when we can't find a valid SNOMED code.

However, the code being sent in this case is a description id, and not a concept id from SNOMED. FHIR only allows concept ids to be used from SNOMED: http://hl7.org/fhir/dstu2/snomedct.html

When we update the code, the update will hopefully behave more like the write (we'll need to make sure we can distinguish the difference) - return a 422 since the underlying code is actually invalid vs. just not available in the domain.

~ Jenni