# CONTRIBUTION questions **Category:** [Implementers (archive)](https://discourse.openehr.org/c/implementers-archive/158) **Created:** 2007-01-30 03:44 UTC **Views:** 3 **Replies:** 5 **URL:** https://discourse.openehr.org/t/contribution-questions/15916 --- ## Post #1 by @Andrew_Patterson Hello all ehrplementers, I am looking at the semantics and mechanisms of versioning\. Whilst I understand that the CONTRIBUTION class is not fully specified \(because much of how it works is dependant on the particular implementation\) I was wondering if anyone had some clarifications for the following: a\) the AUDIT\_DETAILS of CONTRIBUTION has a     mandatory attribute 'change\_type'\. Would I be right     in thinking that for a CONTRIBUTION this must always     be 'creation' \(as contributions are never ammended\)? b\) section 6\.2\.1   > The CONTRIBUTION class also contains an   > audit attribute\. Whenever a CONTRIBUTION is committed,   > this attribute captures to the time, place and committer   > of the committal act; these three attributes   > \(creating\_system\_id, committer, time\_committed   > of AUDIT\_DETAILS\) are usually copied into the   > corresponding attributes of the commit\_audit   > of each VERSION included in the CONTRIBUTION   > \(there is nothing to stop this being overridden   > however\. This is done to enable sharing of versioned   > entities independently of which Contributions they were part of\.   I don't understand what the ramifications are if the   CONTRIBUTION audit details \_aren't\_ copied into the   VERSION audit details? Are they in fact synonomous \-   or can a contribution have VERSIONs with different   committer and time\_committed from its containing   CONTRIBUTION? What would it mean if they do? c\) CONTRIBUTION has an invariant of     audit\.description /= void but I don't know what exactly     would be placed in this 'description' \(or why it is mandatory\)\. thanks Andrew --- ## Post #2 by @thomas.beale Andrew Patterson wrote: > Hello all ehrplementers, > > I am looking at the semantics and mechanisms of > versioning\. Whilst I understand that the CONTRIBUTION > class is not fully specified \(because much of how it > works is dependant on the particular implementation\) > I was wondering if anyone had some clarifications for > the following: > > a\) the AUDIT\_DETAILS of CONTRIBUTION has a >     mandatory attribute 'change\_type'\. Would I be right >     in thinking that for a CONTRIBUTION this must always >     be 'creation' \(as contributions are never ammended\)? >   The meaning is not whether Contributions \(or Versions for that matter\) are changed, amended etc \(they never are \- all writes are logically indelible\); the meaning is whether the EHR is amended, created, changed etc\. So this value could also be other values from 2\.3\.2 in http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/terminology.pdf > b\) section 6\.2\.1 >   > The CONTRIBUTION class also contains an >   > audit attribute\. Whenever a CONTRIBUTION is committed, >   > this attribute captures to the time, place and committer >   > of the committal act; these three attributes >   > \(creating\_system\_id, committer, time\_committed >   > of AUDIT\_DETAILS\) are usually copied into the >   > corresponding attributes of the commit\_audit >   > of each VERSION included in the CONTRIBUTION >   > \(there is nothing to stop this being overridden >   > however\. This is done to enable sharing of versioned >   > entities independently of which Contributions they were part of\. > >   I don't understand what the ramifications are if the >   CONTRIBUTION audit details \_aren't\_ copied into the >   VERSION audit details? Are they in fact synonomous \- >   or can a contribution have VERSIONs with different >   committer and time\_committed from its containing >   CONTRIBUTION? What would it mean if they do? >   I agree these semantics need to be a bit tighter \- the time, creating\_system\_id & committer should be the same\. The description can vary\. > c\) CONTRIBUTION has an invariant of >     audit\.description /= void but I don't know what exactly >     would be placed in this 'description' \(or why it is mandatory\)\. >   this is like the description of a change\-set being committed to subversion or CVS \- it should be filled in by the software with something like "Encounter 2007\-06\-01 12:20:00" or whatever\. Being mandatory might be too string however; what do others think? \- thomas --- ## Post #3 by @Andrew_Patterson > > a\) the AUDIT\_DETAILS of CONTRIBUTION has a > > mandatory attribute 'change\_type'\. Would I be right > > in thinking that for a CONTRIBUTION this must always > > be 'creation' \(as contributions are never ammended\)? > > > The meaning is not whether Contributions \(or Versions for that matter\) > are changed, amended etc \(they never are \- all writes are logically > indelible\); the meaning is whether the EHR is amended, created, changed etc\. > > So this value could also be other values from 2\.3\.2 in For a VERSION, the AUDIT\_DETAILS\.change\_type affects the behaviour of the contained data with regards its corresponding VERSIONED\_OBJECT<T> i\.e\. whether we are creating a new VERSIONED\_OBJECT, ammending a VERSIONED\_OBJECT or deleting the data from a VERSIONED\_OBJECT\. However, for a Contribution, there is no corresponding meta level object \(unless you regard the whole EHR as the meta level object \- in which case every contribution 'ammends' the EHR in some way\)\. It seems to me that change\_type is superfluous for a contribution, but given that it is required in the reference model I would think it just needs to be set to a known value \(or set to an arbitray value and ignored by EHR systems\)? Andrew --- ## Post #4 by @thomas.beale Andrew Patterson wrote: > > ``` > > r values from 2.3.2 in > > > > ``` > > ``` > > For a VERSION, the AUDIT_DETAILS.change_type affects the > behaviour of the contained data with regards its corresponding > VERSIONED_OBJECT i.e. whether we are creating a > new VERSIONED_OBJECT, ammending a VERSIONED_OBJECT > or deleting the data from a VERSIONED_OBJECT. However, for > a Contribution, there is no corresponding meta level object > (unless you regard the whole EHR as the meta level object - > in which case every contribution 'ammends' the EHR in some > way). It seems to me that change_type is superfluous for a contribution, > but given that it is required in the reference model I would think > it just needs to be set to a known value (or set to an arbitray value > and ignored by EHR systems)? > > ``` the way we have seen this in the past, the change type in a Contribution corresponds to the logical operation being done to the whole EHR, which can still be correction, creation (i.e. addition of new info), deletion etc. If there are >1 item in the Contribution, and they don't all have the same type, probably the Contribution audit change type should just be 'modification'. But it will be very useful for Contributions containing just a deletion, new addition, or error correction, to have their audit change type set to the corresponding value - this means that software scanning for error corrections or deletions can find them just by inspecting the Contribution list. If the rules in a specific system that logical deletions and error corrections (say) always were single item-per-Contribution, then Version audits never have to be inspected to e.g. find all deletions that ever happened. This might not be possible. Another slight modification that could be done is to allow >1 change type value in a Contribution, so that all types of change in the version set in the Contribution are included (e.g. deletion + creation or whatever). This means that the Contribution list then really is a definitive index for such changes. This change to the model would be easy to make, and should have almost no knock-on, since there are few implementations so far of this part of the model. thoughts? - thomas --- ## Post #5 by @Andrew_Patterson > type set to the corresponding value \- this means that software scanning for > error corrections or deletions can find them just by inspecting the > Contribution list\. If the rules in a specific system that logical deletions > and error corrections \(say\) always were single item\-per\-Contribution, then > Version audits never have to be inspected to e\.g\. find all deletions that > ever happened\. I think that because the Contribution/Version mechanism is highly implementation specific, it doesn't really need the standard to try to make optimisations like that\. Sure, set a minimal functional interface for the Contribution object, but I'd leave the implementations to store indices of version\-by\-changetype\-by contribution or whatever they want to store to make the systems go fast\. Andrew --- ## Post #6 by @thomas.beale We have created a CR for one of Andrew's suggestions - see [http://coruscant.chime.ucl.ac.uk:8200/openEHR_Collector/projects/specifications/CR/235](http://coruscant.chime.ucl.ac.uk:8200/openEHR_Collector/projects/specifications/CR/235) The changes are only to the documentation in the Common IM, and the addition of a new openEHR terminology code, both of which will be uploaded very soon. - thomas Andrew Patterson wrote: --- **Canonical:** https://discourse.openehr.org/t/contribution-questions/15916 **Original content:** https://discourse.openehr.org/t/contribution-questions/15916