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
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
> 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
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<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)?
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?
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
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
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.
Andrew Patterson wrote: