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 > -----Original Message----- > From: openehr-technical-bounces at chime.ucl.ac.uk [mailto:openehr- > technical-bounces at chime.ucl.ac.uk] On Behalf Of Erik Sundvall > Sent: Monday, 15 February 2010 9:40 PM > To: For openEHR technical discussions > Subject: Clarified semantics of CONTRIBUTION.audit.change_type > > 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 > 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 at liu.se 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 > 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 > > 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. > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
