# Clarified semantics of CONTRIBUTION.audit.change\_type

**URL:** <https://discourse.openehr.org/t/clarified-semantics-of-contribution-audit-change-type/16232>\
**Category:** Technical (archive)\
**Created:** [15 February 2010 12:10 UTC](https://discourse.openehr.org/t/clarified-semantics-of-contribution-audit-change-type/16232 "2010-02-15T12:10:16Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [15 February 2010 12:10 UTC](https://discourse.openehr.org/t/clarified-semantics-of-contribution-audit-change-type/16232/1 "2010-02-15T12:10:16Z")

</div>

Hi!

I just want to share a (to me) clarifying implementation discussion to  
the list so that it does not get lost in cyberspace 🙂

I wondered if e.g. the contribution 1 in fig 25 on  
[http://www.openehr.org/releases/1.0.2/html/architecture/overview/Output/versioning.html#1126708](http://www.openehr.org/releases/1.0.2/html/architecture/overview/Output/versioning.html#1126708)  
really was possible to record as single contribution or if it needed  
two contributions (with identical timestamps) but different  
AUDIT\_DETAILS.change\_type (one for creation and one for modification).  
I had a chat (attached below) with Tom Beale regarding this.

I had somehow gotten the impression that all AUDIT\_DETAILs of  
versioned objects belonging to a single contribution should be  
identical. This is not the case, instead e.g. the  
VERSION\<T\>.commit\_audit.change\_type can be different for the different  
objects within the same contribution.

The remaining question is then what type to select for  
CONTRIBUTION.audit.change\_type when the related  
VERSION\<T\>.commit\_audit.change\_type attributes are mixed in a  
situation like in fig 25. It seems that the semantics of  
CONTRIBUTION.audit.change\_type is not crystal clear and needs to be  
clarified in the specs. In the mean time our implementation will set  
CONTRIBUTION.audit.change\_type to "unknown" for mixed stuff and set it  
to "deleted" only if all changes of the commit are deletions (and  
creation if all are creations etc). Any comments regarding this  
solution?

Best regards,  
Erik Sundvall  
erik.sundvall@liu.se [http://www.imt.liu.se/~erisu/](http://www.imt.liu.se/~erisu/) Tel: +46-13-286733  
(Mail & tel. recently changed, so please update your contact lists.)

- - -

Shortened and somewhat spelling-corrected chat between Erik Sundvall  
and Thomas Beale 15:th of February 2010:

ES: Are the contributions 1 & 3 in fig 25 on  
[http://www.openehr.org/releases/1.0.2/html/architecture/overview/Output/versioning.html#1126708](http://www.openehr.org/releases/1.0.2/html/architecture/overview/Output/versioning.html#1126708)  
really possible to record as a single contribution or do they need two  
contributions (with identical timestamps) but different  
AUDIT\_DETAILS.change\_type (one for creation and one for modification)?

TB: the implication in that diagram is that CIx and CIy happened at  
difrerent times, for example CIx is due to a test result being added  
to the EHR and CIy is the next patient encounter where the physician  
modifies the plan (CId), the medications (CIb) and also there is the  
encounter note itself (CIy)  
sorry - just realised you said 1 & 3  
but the principle is the same

ES: I mean within contrib 1: CIw and CIa' are in the same contrib  
...but are of different types.

TB: yes  
CIw is an encounter note COMPOSITION  
CIa' is something like a problem list COMPOSITION

ES: Yes I understand that part already 🙂  
AUDIT\_DETAILS.change\_type perhaps instead should be VERSION\<T\>.change\_type

TB: well VERSION and AUDIT\_DETAILS is 1:1  
(apart from additional attestations which might occur)

ES: Do you mean that the AUDIT\_DETAILS can be different for different  
VERSIONs in the same contrib?

TB: sure  
every VERSION has its own AUDIT\_DETAILS  
AUDIT\_DETAILS is not any kind of shared object  
[http://www.openehr.org/uml/release-1.0.1/Browsable/\_9\_0\_76d0249\_1109326589721\_134411\_997Report.html](http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109326589721_134411_997Report.html)

ES: I thought it was supposed to have exactly equal content for all  
versions changed in a contribution.  
So what is the change\_type on CONTRIBUTION.audit for a "mixed" contrib?

TB: just something like 'change'  
or 'update'

ES: (I meant CONTRIBUTION.audit.change\_type)

TB: yes

ES: so if we do both creation and modification in the contrib we'll  
arbitrary pick one of them?

TB: there is not 100% clean way to map say 3 individual different  
types of change (say and addition, a modification and an error  
correction) to anything more specific on the CONTRIBUTION  
well the meaning should be taken to be: what was the change to the  
EHR as a whole?  
it is usually either a creation (only new content), modification  
(mixed changes) or could be a deletion  
this attribute on the CONTRIBUTION audit trail is not that important  
it is just like in SVN or any other VC system  
in a way, all change sets are just 'modifications'  
but it could be useful is a lot of new content were being added in

ES: Well you don't have change\_type in svn on the commit level its on  
the file level is it not? The comment is the shared thing.

TB: well, SVN's model of change sets is not that strong  
to get a proper model, you have to go to better products like ClearCase etc  
was just using it as an example

ES: Do they enforce any change\_type?

TB: but it is still possible to have major categories of different  
thing happening to a repository (here, repository = 1 EHR for us, in  
this analogy)  
e.g. major accession of new files == addition of new health data  
normal changes due to 'work' == modifications  
deletions (e.g. due to EHR demerge) == deletion  
the idea in openEHR is to synthesise change\_type for CONTRIBUTIONs  
rather than setting it manually  
as I say, I don't see it as a particularly important attribute  
for CONTRIBUTION  
but it can allow to distinguish between major different modes of change to EHR

ES: Anyway I need to figure out what to do implementation-wise, could  
you clarify once more: Should I mix types so that they are different  
in the AUDIT\_DETAILS of the versions or do they need to be the same?

TB: you can have any number of VERSIONs in a given CONTRIBUTION, each  
with different change\_type  
is that what you mean?  
that is the normal situation

ES: OK, thanks.

[...]

ES: The change type on the VERSIONS is the clinically interesting (and  
easy to detect/synthesise) then and the ad-hoc-synthesised  
CONTRIBUTION.audit.change\_type can't really be trusted to contain  
useful information.

TB: that is more or less correct

ES: CONTRIBUTION.audit.change\_type could be set to unknown if it is mixed?

TB: it can be trusted but only to mean something more coarse-grained  
so I agree it is not that useful

ES: I think I'll set it to unknown for mixed stuff then and "deleted"  
only if all changes are deletions (and creation if all are creations).

TB: sounds reasonable

ES: It would be cleaner to have the change\_type on VERSION instead  
unless there is a clear implementation guidance or algorithm to  
determine type on CONTRIBUTION. CR perhaps?

TB: well it already is - as I said, VERSION.commit\_audit is of type  
AUDIT\_DETAILS, so every VERSION has its own audit  
the only question is what guidance should exist for setting  
CONTRIBUTION.audit.change\_type  
which probably should be clearer  
don't forget, each VERSION needs everything in AUDIT\_DETAILS, not  
just change\_type  
that's why AUDIT\_DETAILS exists as a class

ES: Yes. My thought was that if change\_type was moved from  
AUDIT\_DETAILS to VERSION\<T\> then there would be no change\_type in  
CONTRIBUTION but still be there on all VERSION\<T\>-objects.  
But implementation guidance will also work to get around it.

TB: well the problem with that is that you are splitting up one  
attribute from AUDIT-DETAILS from the others in that class, which it  
logically belongs with  
we could have maybe made a simplified AUDIT\_DETAILS just for  
CONTRIBUTION, but that is more classes, for little gain it seems to me

ES: I guess it is a matter of taste if change type belongs best to  
version metadata directly within the class or in an associated class,  
but since AUDIT\_DETAILS is reused in things like AUTHORED\_RESOURCE  
which is not a VERSION\<T\>  
...I think it may just as well stay.

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [15 February 2010 21:57 UTC](https://discourse.openehr.org/t/clarified-semantics-of-contribution-audit-change-type/16232/2 "2010-02-15T21:57:52Z")

</div>

Hi

The issue is that AUDIT\_DETAILS is used for commit and for individual items.  
The vocabulary is designed for revision of COMPOSITIONS and not really for  
ATTESTATION (when there is no change) or CONTRIBUTION which may have  
multiple COMPOSITIONS.

You approach seems fine but it does show that multiple composition changes  
in a single contribution has not been a feature of systems to this point.

Cheers, Sam