# a question on ATTESTATION of ORIGINAL_VERSION **Category:** [Implementers (archive)](https://discourse.openehr.org/c/implementers-archive/158) **Created:** 2007-01-30 13:31 UTC **Views:** 7 **Replies:** 4 **URL:** https://discourse.openehr.org/t/a-question-on-attestation-of-original-version/14616 --- ## Post #1 by @Andrew_Patterson In sec 6\.2\.3, in the section on attestations is > Attestations can be > added at any time after committal of the content being attested\. I can't work out how a new version adding nothing but a new attestation would be formed \- wouldn't it require the submission of all the content of the existing version \(existing list of any attestations plus all actual composition content\) with a new attestation added? Or is there a mechanism to add an attestation without resubmitting the content? I see that the absence of a ORIGINAL\_VERSION\.data can be used to effect a logical deletion\. Can the absence of data but with a 'complete' lifecycle state be used to modify just the attestations? Andrew --- ## Post #2 by @thomas.beale Andrew Patterson wrote: > ``` > In sec 6.2.3, in the section on attestations is > > > ``` > > > ``` > > Attestations can be > > added at any time after committal of the content being attested. > > > > ``` > > ``` > > I can't work out how a new version adding nothing but a > new attestation would be formed - wouldn't it require the > submission of all the content > of the existing version (existing list of any attestations plus > all actual composition content) with a new attestation added? > Or is there a mechanism to add an attestation without > resubmitting the content? > ``` Andrew, see VERSIONED_OBJECT.commit_attestation > ``` > I see that the absence of a > ORIGINAL_VERSION.data can be used to effect a > logical deletion. Can the absence of data but with a > 'complete' lifecycle state be used to modify > just the attestations? > > ``` Not sure what you mean here.... - thomas --- ## Post #3 by @Andrew_Patterson > Attestations can be > added at any time after committal of the content being attested\. > > see VERSIONED\_OBJECT\.commit\_attestation I missed that one :\) \! However, having a function like that allows adding an ATTESTATION without any 'contribution' being made to the system \- I had a mental model where all changes to EHR state are linked to a contribution \- therefore I was trying to create an ORIGINAL\_VERSION \(that could be 'part' of a contribution\) whose purpose was to add an ATTESTATION without changing any of the data of the ORIGINAL\_VERSION\.\. If ATTESTATIONS can be made outside of a contribution, doesn't that mean that its impossible to track when ATTESTATIONs have been added \(which could be interesting medico\-legally\)? > I see that the absence of a > ORIGINAL\_VERSION\.data can be used to effect a > logical deletion\. Can the absence of data but with a > 'complete' lifecycle state be used to modify > just the attestations? > > Not sure what you mean here\.\.\.\. see above \- I had a different model in my head and was trying to shoe horn things into it\! Andrew --- ## Post #4 by @thomas.beale Andrew Patterson wrote: > > ``` > > Attestations can be > > added at any time after committal of the content being attested. > > > > see VERSIONED_OBJECT.commit_attestation > > > > ``` > > ``` > > I missed that one :) ! However, having a function like that > allows adding an ATTESTATION without any > 'contribution' being made to the system - I had a mental > model where all changes to EHR state are linked to > a contribution - therefore I was trying to create an > ORIGINAL_VERSION (that could be 'part' of a contribution) > whose purpose was to add an ATTESTATION without > changing any of the data of the ORIGINAL_VERSION.. > > If ATTESTATIONS can be made outside of a contribution, > doesn't that mean that its impossible to track when > ATTESTATIONs have been added (which could be > interesting medico-legally)? > > ``` Andrew, this is probably the one ugly bit of modelling I know of in the whole of openEHR (or at least the only bit I don't like trying to defend;-). The requirement was to be able to attest an existing Version some time after original committal of the Version, e.g. 2 hours later, a day later or whatever. This happens often in hospitals where the senior consultant is not on hand to attest when the junior doc enters the data. We decided a long time ago that such a situation should not cause a new Version - no data are being changed, all that is happening is that existing data are being sighted and possibly digitally signed. I still believe that is the correct approach. The result is that Attestations are the one kind of change that can be made to the data that causes no Version or Contribution. We haven't re-analysed this in the last couple of years, but now that you mention it, it seems to me that what we should do is to reword the spec to say that an Attestation-only addition requires a Contribution, just like anything else. We might need a flag or classifier on the Contribution object to handle this (or maybe a new Contribution subtype), but otherwise, it would not change the model, just the rules for using the model. I will bring this idea up with the rest of the modelling group. Feel free to add further input here. - thomas --- ## Post #5 by @Sam I guess attestations need to know when they were committed - it is important that we can add these as far as the clinicians are concerned - witnesses etc. Can't signatures be dated in a robust manner? This is a general problem - not an openEHR problem. Cheers, Sam Thomas Beale wrote: --- **Canonical:** https://discourse.openehr.org/t/a-question-on-attestation-of-original-version/14616 **Original content:** https://discourse.openehr.org/t/a-question-on-attestation-of-original-version/14616