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
@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
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.
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
It is explicitly covered by the /Contribution calls - this does exactly what you are describing.
The /composition POST actually performs a CONTRIBUTION under the hood - so it is essentially a convenience wrapper for simple single composition commit use-cases.
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.
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.