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.
