[Bug] Patient created with tags appears in DB not being returned by GET to patient endpoint

Question

[Bug] Patient created with tags appears in DB not being returned by GET to patient endpoint

jayallenmn opened this issue 2 years ago · 19 comments

Describe the bug
When creating a patient with tags, the patient gets created just fine but can't be found with a subsequent GET to the patient endpoint. Here's some example JSON we're using for the POST to the patient endpoint to create with the patient with tags. The patient endpoint is working because it is returning patients without tags.

{"resourceType": "Patient", "id": ".", "meta": {"tag": 
        [
         true,
         "8",
         true,
         "12345",
         "466",
         "Contact"        ]
      ,...}

To Reproduce
Steps to reproduce the behavior:
Using postman, create a patient that contains tags using JSON similar to the above.

Expected behavior
We expect a user with tags to be returned by a GET to the patient endpoint.

Screenshots
If applicable, add screenshots to help explain your problem.

Versions (please complete the following information):
Version 5.1.0 following the steps documented here https://github.com/awslabs/fhir-works-on-aws-deployment/blob/mainline/INSTALL.md

We used the CDK deploy option.

Additional context
We deployed a development FHIR server in late August using the now removed AWS solution. It works fine creating and getting a patient with tags.

Answer 1 · 2023-02-15T15:10:55.000Z

Hi @jayallenmn ,

Thanks for reaching out!

I tried to reproduce the bug you encountered, but I could get a user with tags to be returned by a GET to the patient endpoint. The steps I did are: 1. deployed FHIR 2. set up Postman for environment 3. Made a Post request where I added tags into Body in Postman 4. used the returned patient id in Post request response to do a GET request and got a response with tags.

Could you provide more details for your steps?

Thanks,
Jay

Answer 2 · 2023-02-15T17:49:35.000Z

Hey Jay,

Thanks for the fast response. We're thinking of just deleting and recreating FHIR but would like to check a couple things - could you share the json you used to create the patient, we'd like to try that as well. Also are you using FHIR 5.1.0?

Jay

Answer 3 · 2023-02-15T22:51:15.000Z

Hey @jayallenmn ,

The FHIR version I use is 5.1.0. The following json is I used in Body of Postman.

{
  "resourceType": "Patient",
  "text": {
    "status": "generated",
    "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p></p></div>"
  },
  "active": true,
  "name": [
    {
      "family": "Smith",
      "given": ["Emily"]
    }
  ],
  "gender": "female",
  "birthDate": "1995-09-24",
  "managingOrganization": {
    "reference": "Organization/2.16.840.1.113883.19.5",
    "display": "Good Health Clinic"
  },
  "meta": {
        "lastUpdated": "2023-02-14T17:46:54.163Z",
        "versionId": "1",
        "tag": [
            true,
            "8",
            true,
            "12345",
            "466",
            "Contact"
        ]
    }
}

Thanks,
Jay

Answer 4 · 2023-02-16T03:00:04.000Z

Thanks for the json. We couldn't get a patient that we created with this JSON so we went ahead and deleted our FHIR instance and are going to recreate it. We'll be following the installation instructions at https://github.com/awslabs/fhir-works-on-aws-deployment/blob/mainline/INSTALL.md . Can you confirm these are the correct main steps to install v5.1.0:

clone the main branch of the fhir works repo and switch to that directory
yarn install
yarn run release
yarn deploy --profile -c stage= -c region=<AWS_REGION>

Thanks,
Jay

Answer 5 · 2023-02-16T16:26:34.000Z

Hey @jayallenmn Jay,

According to my understanding, the main steps are correct.

Thanks,
Jay

Answer 6 · 2023-02-16T23:29:37.000Z

Hey Jay,

Well shoot, after deleting and re-installing we get exactly the same behavior again. We did notice that when we strip tags from a user (in dynamodb) that that user starts being returned. We also noticed that when we add tags to a user created without them that the user is still returned but with an empty set of tags (even though we filled it).

It's frustrating as we can't find a way to debug and see what is failing - do you have any pointers?

One idea is that maybe that we should switch to the v5.1.0 tagged branch before we do the yarn build and deploy, instead of mainline - could that be it?

Jay

Answer 7 · 2023-02-17T02:44:05.000Z

Update - here's an error we found in the logs for the ddbtoes lambda function. It occurs when we update a patient record created without a tag list to contain a tag list with a few example strings. It's not a flow we'd be doing from code but it indicates something is wrong with the parsing of the patient meta.tag field for all patient records in our FHIR install.

We assume that because the patient record with a meta.tag isn't indexed in elasticsearch it's not being returned by a call to the /patient endpoint. Could something be wrong with the mapping parser?

`2023-02-17T01:22:24.413Z eb0a6a84-e5f5-4820-92dd-ff76e04e1401 ERROR { component: 'persistence' } Failed to update ES records [{
"status": 400,
"error": {
"type": "mapper_parsing_exception",
"reason": "object mapping for [meta.tag] tried to parse field [null] as object, but found a concrete value"
},
"index": "patient",
"id": "1e375e64-b017-45ab-9ca9-1c2d3d940366_1",
"esOperation": "update"
}] Error: [{
"status": 400,
"error": {
"type": "mapper_parsing_exception",
"reason": "object mapping for [meta.tag] tried to parse field [null] as object, but found a concrete value"
},
"index": "patient",
"id": "1e375e64-b017-45ab-9ca9-1c2d3d940366_1",
"esOperation": "update"
}]
at DdbToEsHelper.executeEsCmds (/var/task/index.js:51418:19)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at async DdbToEsSync.handleDDBStreamEvent (/var/task/index.js:51506:11)
at async Runtime.exports.handler (/var/task/index.js:51747:3)

Answer 8 · 2023-02-17T16:00:42.000Z

Hey Jay @jayallenmn ,

Thanks for update.

There are more information needed before figuring out what the real problem is.
There are the steps you can use to check the problem:

Could you test if you can make GET request by using resourceId {{API_URL}}/Patient/:id in Postman?
If it works, could you check if updateSearchMappingsLambdaFunction is triggered successfully? You can check if there is log group for updateSearchMappingsLambdaFunction in CloudWatch. If there is created log group for updateSearchMappingsLambdaFunction in CloudWatch, is there any error shown in the log?

Thanks,
Jay

Answer 9 · 2023-02-17T17:54:50.000Z

Hey Jay,

I can make a GET request to {{API_URL}}/Patient/:id in Postman and get the patient if the patient was originally created without tags. If I add a meta.tag list to the patient record in dynamodb, the patient is still returned but without the tag list. If the patient was created with a tag list, it's not returned from a GET to {{API_URL}}/Patient/:id

I see logs for updateSearchMappingsLambdaFunction in Cloudwatch and the logs are clean - however, they appear to be the logs from when this FHIR instance was created. There are no logs from any POSTs or GETs after that time.

This is the only log I see for anything to do with patients:

2023-02-16T19:35:55.726Z 5c8050f0-3ff0-47c8-a7ac-32bc8b4fa69e INFO creating index for Patient

Jay

Answer 10 · 2023-02-17T18:23:42.000Z

Jay - if you have a few minutes today we could get on a screenshare and I could show it to you, let me know.

Answer 11 · 2023-02-17T19:33:48.000Z

Hi Jay @jayallenmn ,

I need to check with my manager on the policy for scheduling calls. At the meantime, could you please share the complete request and response data when you try to post a patient with the meta.tag field? In specific, is the meta field in the response data with the tag field missing? Or the entire meta field is missing?

Thanks,
Jay

Answer 12 · 2023-02-17T23:16:54.000Z

Hey Jay,

Thanks. I discovered if I create a user with a meta.tag from a POST through postman (using the JSON you supplied above) that I can GET it through /patient/:id with the meta.tag. I tested this previously by updating the record in dynamodb which isn't the right flow - note that doing that though causes the mapping parse error.

What still doesn't work is a GET to /patient without an ID - if any of the patients have a meta.tag, I can't retrieve any of the records.

Here's the response to that /patient GET without an ID. There are two records with meta.tag in the DB. Any records that don't have meta.tag will be returned.

{
    "resourceType": "Bundle",
    "id": "e7e4c2f8-fc07-4ee9-8116-a28a7e4e104b",
    "meta": {
        "lastUpdated": "2023-02-17T23:15:18.280Z"
    },
    "type": "searchset",
    "total": 0,
    "link": [
        {
            "relation": "self",
            "url": "https://kno4hh2wfa.execute-api.us-east-1.amazonaws.com/production/Patient"
        }
    ],
    "entry": []
}

Answer 13 · 2023-02-20T16:59:54.000Z

Hey, we just investigated this and found the piece we were missing: GET by id directly accesses DynamoDb, where the resource was posted successfully. However, GET via a search gets the resource from ElasticSearch, where the resource failed to populate due to the error in the ddbToEs Lambda. This error happens because there is no mapping that exists for the meta.tag field. There are two approaches I think could work for your use case here:

Update the meta mapping [here[(https://github.com/awslabs/fhir-works-on-aws-search-es/blob/mainline/scripts/elasticSearchMappingsGenerator/types.ts#L278) and redeploy.
Add a new custom mapping here and redeploy.
I think the custom mappings may conflict with the hapi validator if you are using that, but this should otherwise allow the resource to properly get populated into ElasticSearch. Let me know if this helps!

Thanks,
Sukeerth

Answer 14 · 2023-02-20T23:02:17.000Z

Hey thanks Sukeerth. Can you post exactly what needs to be updated at https://github.com/awslabs/fhir-works-on-aws-search-es/blob/mainline/scripts/elasticSearchMappingsGenerator/types.ts#L278? Because of the time and cost with deleting and redeploying we'd like to get it right the first time.

Also, is there a way just to update the search mapping without deleting and recreating our FHIR instance? We find that when we delete we have to manually clean up some things (opensearch instances for example).

Jay

Answer 15 · 2023-02-21T02:14:05.000Z

Hey Jay,
You shouldn't need to delete the FHIR instance in between redeploying, as redeploying should update the existing deployment. Also, I went and took a look at the fhir spec while trying out the suggestions above, and realized that the tag field is a CodeableConcept array. So the values within the tag must be of this form:

"meta": {
        "lastUpdated": "2023-02-14T22:46:54.163Z",
        "versionId": "1",
        "profile": [
            "http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient"
        ],
        "tag": [
            {
                "system": "hxxp://mydomain/fhir/custom_tag/SystemActionStatus",
                "code": "Updated"
            }
        ]
    }

POSTing the resource with this format worked, and we observed no errors in the ddbToEs Lambda, nor did we miss the result in the search. I would suggest trying this method first, and if this still doesn't work, we can look into the steps for updating the ES mapping.

Thanks,
Sukeerth

Answer 16 · 2023-02-21T18:00:33.000Z

Hi everyone. I am currently working with @jayallenmn on this project. Thank you for all your help and input on this issue. So far I've been able to get @ssvegaraju suggestion to work with the following tag.

 "tag": [
            {
                "system": "hxxp://mydomain/fhir/custom_tag/SystemActionStatus",
                "code": "Updated"
            }
        ]

However, in order for our app to read and map the patients accordingly we need a few more pieces of data including the OrgId, EstimateId's (multiple estimates for patients), fhirId , the patient mrn and the preferred contact method. So far I have been putting them in the tags and they have been getting searched and returned in our old project, however they are not being returned in the new one described by @jayallenmn.

We are using the following json sent by @JayLuo2022

{
  "resourceType": "Patient",
  "text": {
    "status": "generated",
    "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p></p></div>"
  },
  "active": true,
  "name": [
    {
      "family": "Smith",
      "given": ["Emily"]
    }
  ],
  "gender": "female",
  "birthDate": "1995-09-24",
  "managingOrganization": {
    "reference": "Organization/2.16.840.1.113883.19.5",
    "display": "Good Health Clinic"
  },
  "meta": {
        "lastUpdated": "2023-02-14T17:46:54.163Z",
        "versionId": "1",
        "tag": [
            true,
            "8",
            true,
            "12345",
            "466",
            "Contact"
        ]
    }
}

For some reason these tags are not getting returned even though the first example is. I understand that this could be a restriction to how FHIR actually works and to keep everything up to code. Is there a better place or a different way I should be attaching this information to the Fhir instance so our search returns the correct patient as searching by tag is no longer working the way we anticipated?

Answer 17 · 2023-02-21T23:20:50.000Z

Hey @ssvegaraju, if there isn't a way to add the information that @mikethecodegeek spoke about to the existing FHIR patient json, can you explain more about what you suggested yesterday:

Update the meta mapping [here[(https://github.com/awslabs/fhir-works-on-aws-search-es/blob/mainline/scripts/elasticSearchMappingsGenerator/types.ts#L278) and redeploy.

Can you tell us what the mapping should look like for the meta.tag field?

Jay

Answer 18 · 2023-02-21T23:37:06.000Z

Hey Jay and Mike,
The meta.tag field is actually generated from the FHIR specification, so we don't have an mapping in our code base that can be edited as it is automatically generated from these parameters. When I first saw the error you were running into, I had assumed it was tied to a previous issue where the mapping didn't allow dynamic content. However, it turns out the mapping exists, but it just expects it in a different format. So you shouldn't need to update/redeploy anything, but just update how you're defining custom tags for patients, if that makes sense. To look at the example above, we would take this meta object:

"meta": {
        "lastUpdated": "2023-02-14T17:46:54.163Z",
        "versionId": "1",
        "tag": [
            true,
            "8",
            true,
            "12345",
            "466",
            "Contact"
        ]
    }

and translate it to

"meta": {
        "lastUpdated": "2023-02-14T17:46:54.163Z",
        "versionId": "1",
        "tag": [
            {
                "system": "<SOME URL TO DEFINE WHAT THIS TAG IS>",
                "code": "<String value for Org Id>"
            },
            {
                "system": "<SOME URL TO DEFINE WHAT THIS TAG IS>",
                "code": "<String value for MRN>"
            },
            {
                "system": "<SOME URL TO DEFINE WHAT THIS TAG IS>",
                "code": "<String value for Contact>"
            },
            ... //(you'd add more objects to the array depending on additional needed tags such as Estimate ID's, etc.)
        ]
    }

The fhir spec for the objects within the tag array can be found here.

The reason the first example does not return during searches is that the mapping is expecting objects in the array, but instead finds literal values. Hence, the resource is never written to ElasticSearch, but exists within DDB from the initial POST. However, if you adjust your tags to follow the format, they should properly be mapped into ElasticSearch and return in searches.

I apologize for the earlier confusion with suggesting to update the mapping, I should have taken a closer look at the generic FHIR Resource template instead of just the Patient specification 😅.

Thanks for your time,
Sukeerth

Answer 19 · 2023-03-13T18:11:15.000Z

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.