Bump for client-assigned IDs
# support
r
Apologies as this is probably the wrong place for this inquiry, but I'm wondering if there are any current plans to support [client-assigned IDs](https://github.com/medplum/medplum/discussions/1175). It seems there was some prior thinking around how this might work. This would be a massive win for our mobile app where we currently have to do a fair amount of bookkeeping to juggle references to entities prior to saving them. Thanks in advance!
r
Have you tried these? 1. Generate IDs locally and send them as
urn:uuid:
fullUrls. Within one bundle, any reference to
urn:uuid:<your-id>
resolves to the resource that entry creates, so you can build a Patient, an Encounter and three Observations on device, wire them to each other with your own IDs, and post the whole graph in one request. The server assigns the real IDs and returns them in the response bundle, so the reference juggling happens server side rather than in your app. https://www.medplum.com/docs/fhir-datastore/fhir-batch-requests#internal-references 2. For replays, put a stable business
identifier
on each resource and set
ifNoneExist
on the entry. A resubmitted bundle no-ops instead of duplicating, which is the case you hit when a phone retries on a flaky connection. https://www.medplum.com/docs/fhir-datastore/fhir-batch-requests#conditional-batch-actions 3. For links to resources that already exist on the server, you can write the reference as a search instead of an ID, for example
{"reference": "Patient?identifier=http://yoursystem|12345"}
, resolved at write time. It has to match exactly one resource. https://www.medplum.com/docs/fhir-datastore/fhir-batch-requests#external-conditional-references
4 Views