Can no longer create `Patient` resources with `lin...
# support
y
Hi there, For our migration script, we were creating patients with
link: []
so that in subsequent batch entries, we could use JSON patch to add links without having to have any logic for checking whether a link was already set. It looks like something changed, and now any patient created with
link
set to an empty array results in
link
being unset. As an example, I tried creating the following patient:
Copy code
{
  "resourceType": "Patient",
  "name": [
    {
      "given": [
        "YaleTestLink"
      ],
      "family": "YaleTestLink"
    }
  ],
  "link": []
}
And the resulting patient JSON:
Copy code
{
  "resourceType": "Patient",
  "name": [
    {
      "given": [
        "YaleTestLink"
      ],
      "family": "YaleTestLink"
    }
  ],
  "id": "7ed75a99-a4d1-40d5-bc2c-578340da9755",
  "meta": {
    [omitted]
  }
}
Is this expected behavior? If so, how would you recommend we implement adding patient `link`s in a bundle using JSON patch?
r
Hi @yaaaaale ! That's actually expected behavior. The FHIR spec treats empty lists the same as
undefined
, so our server peforms that cleanup on your behalf
However, if the list is populated, it should not be removed. Are you able to confirm that is the case?
y
Interesting. In the past, these empty array values persisted, which is behavior we were relying on.
Let me see if I can find a way to conform to this behavior
r
I'm surprised to hear that, as this has not been default behavior for a while. The main reasons I can think that you were seeing this behavior before (lmk if these were not the case): - You were writing to the SuperAdmin project (e.g. on your localhost). This bypassess some of this filtering - Your project had "Strict Mode" set to false. Turning this off is really only recommended for Medplum legacy users
Please let me know if something else is going on, or if you suspect this might be a bug
y
Hmm, interesting. I don't believe we were writing to the superadmin project. I'm also pretty sure we were using a non-admin API client when creating these resources...
r
yeah, given your use case I definitely believe that. Are you able to DM a link to an example Patient resource that did have this persisted?
y
Let me look
r
I'm also checking with the team about any potential changes that could hav caused this. IF we could try to find a before/after resource, that would help me pinpoint the potential change
y
Odd! I wasn't able to find an existing record with an empty link.
This may be a false alarm. We're going to re-run our migration from scratch to rule out any other causes.
We re-ran the migration and did not run into the same error, so I think this is a false alarm!