Andrew Patterson wrote:
I think there is some ambiguity around the 'change type' in a
version's audit, and the lifecycle state of the version.
To recap, change type has the following terminology entries
creation
ammendment
modification
synthesis
deleted
attestation
unknown
And lifecycle state can be
complete
incomplete
deleted
Firstly, I think the 'synthesis' and 'unknown' change types aren't
well defined so until they are it might be better if they weren't in
the list of allowable 'change types'.
Hi Andrew,
the explanation in the spec could be better for “synthesis”, I agree, but the meaning is that the data were created by automatic generation according to some algorithm. This happens when importing data that have little structuring, e.g. no sections, or missing items.
The “unknown” change type exists when none of the other terms will do - since a change type is needed in the audit object. I don’t know of any better solution to this. Putting nothing makes it look like the software might have a bug; putting “unknown” at least means that the change type was considered.
Secondly, I don't think 'change type' and 'lifecycle state' are
completely orthoganal, so we need to define which lifecycle
states are allowable with each change type.
So
a) can we 'create' a 'deleted' version
not sensibly;-)
b) can a complete version have its 'change type' be deleted?
yes - an item in ‘complete’ state, meaning no other info had to be added, can be later logically deleted (perhaps the whole thing was in error, or in the wrong EHR). The audit action needs to record the fact of deletion. The lifecycle state should also be set to ‘deleted’. So there are two things here: the content is logically ‘deleted’, and the action to achieve this was ‘deletion’ (and I notice that code 523 should be ‘deletion’ not ‘deleted’).
c) is attestation possible for an incomplete version?
yes - attestation is possible for anything - it just means that whatever is there (complete, incomplete (or deleted?)) is being attested, i..e signed off, by some user.
d) is attestation possible for a deleted version? (is this
attesting to the deletion?)
good question - I would say it is possible - e.g. if an appropriate user were to sign off on the fact that material had to be deleted from patient A’s health record because it had been put there in error. IN fact, I would imagine some kind of attestation to deletion would be preferable to having none.
e) is a lifecycle deletion ever an 'ammendment'
I don’t think this could make sense.
Also, are there any state transitions that are disallowed
i.e. is it possible to go from created/complete to
modification/incomplete?
well, the audit change types are not states in a cycle - they merely indicate what kind of change was done in going from the previous version the information to the current version. But there is certainly a (albeit simple) state machine implied in the lifecycle state, which is currently:
(initial) → incomplete → complete
(initial) → complete
incomplete → deleted
complete → deleted
I don’t think this is documented anywhere as such, but it should be. Currently the following text is in the Common IM spec:
6.3 Versioning Semantics
6.3.1 Version Lifecycle
Content in Original versions has a lifecycle state associated with it, modelled using the
ORIGINAL_VERSION.lifecycle_state attribute, which is coded from the openEHR Terminology “version
lifecycle state” group. The possible values are “complete”, “incomplete” and “deleted”. Usually
content will be committed in the “complete” state. However, in some circumstances, e.g. because the
author has run out of time or due to an emergency, it may be committed as “incomplete” meaning that
it is either incomplete or at least unreviewed. In hospitals this is a common occurrence. Unfinished
Compositions cannot be saved locally on the client machine, since this represents a security risk (a
small client-side database would be much easier to hack into than a secure server). They must therefore
be persisted on the server, either in the actual EHR, or in a ‘holding bay’ which was recognised as
not being part of the EHR proper. Either way, the author would have to explicitly retrieve the Composition(
s) and after further work or review, ‘promote’ them into the EHR as ‘active’ Compositions; alternatively,
they might decide to throw them away.
Going from “incomplete” to “complete” almost always corresponds to a change in content, and corresponds
to a new VERSION regardless. This modelling approach allows such content to exist on the
EHR system, but to be flagged as incomplete when viewed by a user.
Systems are responsible for implementing checks to find ‘old’ Versions in “incomplete” state, and
bring them to the relevant user’s notice, or automatically deleting them or progressing them to “complete”
as appropriate.
6.3.2 Logical Deletion
Within the lifecycle described above, deletion of existing top-level content items (i.e. the entire data
contents of a Version) is somewhat of a special case in openEHR and in EHRs in general. Medicolegal
and traceability requirements mean that information cannot be literally removed, since it must
always be possible to revert back to a previous state of the record in which the deleted information is
intact. Accordingly, information can only ever be logically deleted. This is achieved by the following
procedure in the Version container in question:
• create a new Version in the normal way;
• delete its data (which will by default be a copy of the data of the previous Version);
• set the lifecycle_state value to the code for “deleted”
• commit in the normal way.
Logical deletion can be used for various reasons, including patient direction to remove material, and
in the situation where information about a different patient has been incorrectly committed to a
record, and has to be removed.
This could be improved perhaps; certainly something should be said about non-sensical combinations. As you say, we need some formal description of what combinations make sense and what doesn’t - a set of rules, or maybe a matrix of allowed combinations.
thoughts?
