# Setting audit_change_type value in compositions

**Category:** [Platform](https://discourse.openehr.org/c/platform-implem/7)
**Created:** 2024-08-22 11:29 UTC
**Views:** 80
**Replies:** 6
**URL:** https://discourse.openehr.org/t/setting-audit-change-type-value-in-compositions/5600

---

## Post #1 by @Dileep_V_S

When I get a versioned composition (3c355f02-c805-4a29-84bd-7fb71cbafb76::ehr.ehr.network::3) I do not see get any commit_audit details, but I am able to retrieve it using aql(v/commit_audit/change_type/value). 

However even for updated compositions, the change_type is shown as creation. So I assume that this is not managed by the server and needs to be supplied at the time of POST/PUT of the composition.

What is the format to do this in FLAT compositions?

regards

---

## Post #2 by @Dileep_V_S

@birger.haarbrandt does EHRBase support adding commit_audit/change_type in FLAT compositions? Currently we are getting "creation" for both initial and updated versions of compositions.

regards

---

## Post #3 by @sebastian.iancu

I don't know if commit_audit is part of FLAT or neither I don't know how particularly EHRbase is or should handle it, but I would just like to comment from a general perspective:

The Version (and commit) data is not "inside" composition, as it is a metadata associated with the process or creation or update of that composition. As parallel with real life: consider that if a Composition is an (paper) envelope or a package that you want to send via regular-post, you will get the the stamp or stickers "on", and not "in" your envelope/package, which has to be deliver unopen to the destination. Thus, you should not expect to have this info (commit_audit) will be at same place (and mingled)with your clinical-data. Instead these are often available or supplied as extra http headers, or need another REST endpoint. That's also the reason in AQL you need that extra `v`.

---

## Post #4 by @Dileep_V_S

Thanks @sebastian.iancu What you say make sense and I also gathered this with my experimentation. 

If commit_audit is not part of the composition, shouldn't the  REST specs include how this is managed? I do not think the current REST specs covers this.

Headers in POST/PUT Composition is a good option. But the problem would be that  we would need multiple headers - change_type.value, change_type.code, change_type.terminology, commit_audit/time_committed etc. The other option is to put the composition inside a larger container, that contains composition object, commit_audit object and probably other metadata.

Is this aspect being considered from the specifications perspective?

regards

---

## Post #5 by @ian.mcnicoll

It is explicitly covered by the /Contribution calls - this does exactly what you are describing.


https://specifications.openehr.org/releases/ITS-REST/Release-1.0.3/ehr.html#tag/CONTRIBUTION

The /composition POST actually performs a CONTRIBUTION under the hood - so it is essentially a convenience wrapper for simple single composition commit use-cases.

---

## Post #6 by @sebastian.iancu

[quote="Dileep_V_S, post:4, topic:5600"]
Is this aspect being considered from the specifications perspective?
[/quote]

There are some recommendation for such related headers on request, and in theory something similar can be used for response, but I don't know the implementation state. 

The larger-container is what Ian mentioned -> Contribution.

---

## Post #7 by @ian.mcnicoll

FLAT/ STRUCTURED Ehrscape calls do allow a little manipulation  of the VERSION wrapper but via API parameters instead of Headers, so pretty well equivalent.

EhrBase openEHR Canonical REST supports FLAT/STRUCTURED, and I understand Better are implementing this also, so we will move away from Ehrscape /composition to openEHR /composition just to minimise confusion.

---


**Canonical:** https://discourse.openehr.org/t/setting-audit-change-type-value-in-compositions/5600
**Original content:** https://discourse.openehr.org/t/setting-audit-change-type-value-in-compositions/5600