Trying to use MedplumClient to create a new Patient resource with an ID generated in another system. Getting

not found

error. There are no details on the creation part here: https://www.medplum.com/docs/sdk/classes/MedplumClient#updateresource In the HL7 FHIR R4 spec it seems that some servers are offering

Update as Create

https://www.hl7.org/fhir/http.html#update Trying to see how to make it work through the client, or need to do it by hand with direct request with options like such:

const options = {
  method: 'PUT',
  headers: {
    'Content-Type': 'application/fhir+json',
    'If-None-Match': '*'
  },
  body: JSON.stringify({
    // Patient resource goes here with ID included
  })
};

fetch(url, options)
  .then(response => {
    if (response.status === 200) {
      // Resource was updated
    } else if (response.status === 201) {
      // Resource was created
    }
  })

Hi @.olegro , that's a great question. Currently, the medplum server doesn't support Update as Create, but it's something we've definitely been thinking about. A prerequisite to this work is supporting client-assigned ids, and we have a Github discussion about it here. We'd love for you to weigh in: https://github.com/medplum/medplum/discussions/1175

Yeah, our requirement is that it matches the external system, which will greatly simplify our system. Our use case: a client signs up via our mobile app, and when they're ready to start connecting the medical records we're going to create a corresponding Patient record for them in our Medplum Server instance, which we use as a hub to link to records pulled from other sources.

Got it! So Medplum Super Admins are allowed to overwrite resource ids. So while you can't do "Update as Create" off the bat, you could do a "create resource" and set the

meta.id

property. If you're client application has super admin privileges (i.e. was created in the

Super Admin

project), it should be able to set the ids upon create. Below is a guide to our super admin documentation: https://www.medplum.com/docs/self-hosting/super-admin-guide

That's an interesting option! Thank you

UUID client-assigned IDs are possible today as long as the user is a "super admin" user, as @rahul1 mentioned. That can be a normal

Practitioner

user or a

ClientApplication

in the super admin Project. At present, client-assigned ID's require a little extra care because resource ID === database primary key ID. Therefore, it is only possible in a self-hosted environment / non-multi-tenant environment. It is absolutely technically possible with a few tweaks in

repo.ts

. Extra care would be required for the case where a user attempts to use a UUID that is already used in a different Project. The work for full client-assigned IDs is actually mostly done: 1. Github discussion: https://github.com/medplum/medplum/discussions/1175 2. PR with "part 1" of the implementation: https://github.com/medplum/medplum/pull/1350 We've been sitting on that because (1) it does have a perf hit, (2) it increases system complexity, and (3) no customer has explicitly asked for it. We'd be happy to discuss that work too if you're interested.

@cody Thank you for painting the full picture. Now I better understand the concerns of having full proper implementation of client-assigned UUIDs as a generally available feature for both hosted & self-hosted environment. Our use case is might be quite a bit different from mainstream use. Although we'd greatly benefit from having this feature available for two reasons: 1. easy and fast synchronization between Medplum server and our application backend without a need for additional ID mapping resolution 2. we would be able to import patient data form other healthcare systems (their FHIR servers) as is and store it in it's original form in "intake" project first (with IDs preserved and strict validation off), and then use Bots to process and store in a "clean" project.

Just adding to this, our scenario also requires that we use non-UUID IDs for Patients and Organizations. Following this closely. 😃

Noting that we need this in order to be able to facilitate deterministic seeding of resources for self-hosted medplum instances.