In COMPOSITION Class is a note:
It is strongly recommended that the inherited attribute uid be populated in Compositions, using the UID copied from the object_id() of the uid field of the enclosing VERSION object.For example, the ORIGINAL_VERSION.uid 87284370-2D4B-4e3d-A3F3-F303D2F4F34B::uk.nhs.ehr1::2 would be copied to the uid field of the Composition.
The note says that only OBJECT_VERSION_ID.object_id() part of the VERSION.uid is copied to COMPOSITION.uid. The provided example in the node shows the full OBJECT_VERSION_ID.
Based on the similar text found in 9.2.2. Levels of Identification, it seems the note should state that the full VERSION.uid should be copied to COMPOSITION.uid.
The copying is done only if COMPOSITION.uid is not provided in the payload. There was a discussion about what happens when COMPOSITION.uid is specified by the caller. No conclusion was reached and the thread is 4 years old.
Specification uses “is strongly recommended,” which allows UIDs provided by the user. REST API also allows user provided UID.
We should either explicitly reject COMPOSITION.uid in the payload or allow it. If a CDR accepts a payload with a UID as valid, it shouldn’t silently overwrite it. This might surprise users and data could be lost if they expected their UID to be used and persisted.
I don’t have real world experience regarding whether users can provide their own UIDs. The specifications should be clearer about this.
I’ll put allowing/rejecting COMPOSITION.uid in payload under a configuration flag for now.
How did others implement this? Are you using OBJECT_VERSION_ID for COMPOSITION.uid? Do you always overwrite it if it is received in the payload?