# Sending UID in a new composition
**URL:** https://discourse.openehr.org/t/sending-uid-in-a-new-composition/2312
**Category:** ITS
**Created:** [1 February 2022 10:58 UTC](https://discourse.openehr.org/t/sending-uid-in-a-new-composition/2312 "2022-02-01T10:58:48Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@joseph.kane](https://discourse.openehr.org/u/joseph.kane)
#### Post date: [1 February 2022 10:58 UTC](https://discourse.openehr.org/t/sending-uid-in-a-new-composition/2312/1 "2022-02-01T10:58:48Z")
In the API specs for creating a new composition via POST, the [example](https://specifications.openehr.org/releases/ITS-REST/latest/ehr.html#composition-composition-post) shows an included uid. This seems strange to me, since it should be the responsibility of the receiving system to create the uid. Because the root needs to be unique within a system, allowing an externally-created uid root places a heavy burden on the receiver to guarantee uniqueness.
Is this intended or just an oversight? If it is intended, what is the reasoning?
---
### Author:  [@pablo](https://discourse.openehr.org/u/pablo)
#### Post date: [1 February 2022 16:40 UTC](https://discourse.openehr.org/t/sending-uid-in-a-new-composition/2312/2 "2022-02-01T16:40:29Z")
In general the server overwrites that value.
But in some implementations of the API, the server could allow the client to specify the uid for the new composition.
Current spec is not wrong, IMHO just allows different ways of implementing that service.
---
### Author:  [@borut.jures](https://discourse.openehr.org/u/borut.jures)
#### Post date: [1 February 2022 17:09 UTC](https://discourse.openehr.org/t/sending-uid-in-a-new-composition/2312/3 "2022-02-01T17:09:04Z")
The “client” can be another truster server. In such a scenario the “client server” is allowed to specify the uid.
---
### Author:  [@pablo](https://discourse.openehr.org/u/pablo)
#### Post date: [1 February 2022 17:32 UTC](https://discourse.openehr.org/t/sending-uid-in-a-new-composition/2312/4 "2022-02-01T17:32:01Z")
Client can be anything that consumes the API provided by the “server”, so it can be another server, a middleware, an app, etc.
The issue is not the definition of the client, it is if the “server” trusts the “client” in setting the uids for the compositions. A server can choose to not trust anything coming from an external system.
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [1 February 2022 18:47 UTC](https://discourse.openehr.org/t/sending-uid-in-a-new-composition/2312/5 "2022-02-01T18:47:48Z")
> [@joseph.kane](#):
>
> Because the root needs to be unique within a system, allowing an externally-created uid root places a heavy burden on the receiver to guarantee uniqueness
The question of uniqueness within a given server is easy to check; whether a supplied Guid has already been used elsewhere is a question though. I’m not convinced there is any good argument not to overwrite the Guid at the server…
---
### Author:  [@pablo](https://discourse.openehr.org/u/pablo)
#### Post date: [2 February 2022 05:26 UTC](https://discourse.openehr.org/t/sending-uid-in-a-new-composition/2312/6 "2022-02-02T05:26:12Z")
> [@thomas.beale](#):
>
> I’m not convinced there is any good argument not to overwrite the Guid at the server…
I would say most implementations rewrite the UID if provided in the payload, though the spec allows it and AFAIK doesn’t require the server to overwrite it. On the other hand, that could be the desired behavior in some environments like integrated systems that allow unique global identification of LOCATABLEs.
The real question is at which point in the spec we allow those extra improbable use cases or reinforce some behavior based on common use. This is important for conformance verification, since a conformance test case might check this behavior and we need a criteria to say which one is accepted.