# Should ATTESTATION.reason datatype really be DV_TEXT or rather DV_CODED_TEXT (or perhaps CODE_PHRASE)? **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2010-02-26 14:11 UTC **Views:** 1 **Replies:** 6 **URL:** https://discourse.openehr.org/t/should-attestation-reason-datatype-really-be-dv-text-or-rather-dv-coded-text-or-perhaps-code-phrase/14964 --- ## Post #1 by @system Hi\! Here comes yet another possibly stupid question\.\.\. Do we ever want the attribute ATTESTATION\.reason to be a DV\_TEXT instead of a DV\_CODED\_TEXT? Is this a possible improvement for the specification \(common IM rev 2\.1\.1 from release 1\.0\.2\) or is there an intention behind being that liberal? The spec says the value for ATTESTATION\.reason should come from the terminology group "attestation reason"\. A less important sidetrack: Is the use of the more verbose DV\_CODED\_TEXT instead of just CODE\_PHRASE for fields/methods like VERSION\.lifecycle\_state and AUDIT\_DETAILS\.change\_type there for human readability reasons or what is the purpose? Are end users really supposed to see the DV\_TEXT\.value of those? I guess aplication logic and GUIs are better off trying to use the embedded CODE\_PHRASE than relying on the possibly language dependent DV\_TEXT\.value for those fields/methods\. Best regards, Erik Sundvall erik\.sundvall@liu\.se http://www.imt.liu.se/~erisu/ Tel: \+46\-13\-286733 --- ## Post #2 by @thomas.beale > ``` > Hi! > > Here comes yet another possibly stupid question... > > Do we ever want the attribute ATTESTATION.reason to be a DV_TEXT > instead of a DV_CODED_TEXT? > Is this a possible improvement for the specification (common IM rev > 2.1.1 from release 1.0.2) or is there an intention behind being that > liberal? > > The spec says the value for ATTESTATION.reason should come from the > terminology group "attestation reason". > > ``` the current values are 'signed' and 'witnessed'. Noone has asked for more codes, which implies that the codeset should be ok, and also that we could change it to DV_CODED_TEXT, as suggested above. > ``` > A less important sidetrack: > > Is the use of the more verbose DV_CODED_TEXT instead of just > CODE_PHRASE for fields/methods like VERSION.lifecycle_state and > AUDIT_DETAILS.change_type there for human readability reasons or what > is the purpose? > ``` yes - for human readability, including being able to put something sensible on the screen. > ``` > Are end users really supposed to see the DV_TEXT.value > of those? I guess aplication logic and GUIs are better off trying to > use the embedded CODE_PHRASE than relying on the possibly language > dependent DV_TEXT.value for those fields/methods. > > ``` **a** base assumption in openEHR historically is that the data might arrive in some application space that doesn't have access to the terminology. This can easily happen for many reasons. We don't want the application to be useless (i.e. can't put stuff on the screen) just because it can't see the terminology. Now, in these structural attributes, you could expect that the openEHR terminology would be available somewhere in the application space. However, for both these situations, we historically decided that it was always better to have the original text of any coded element, in the original language. In hindsight we probably could have done what you say, but I would not like to change the specifications now given the structural differences it would make to software and data. - thomas --- ## Post #3 by @Peter_Gummer1 Thomas Beale wrote: >> Are end users really supposed to see the DV\_TEXT\.value >> of those? I guess aplication logic and GUIs are better off trying to >> use the embedded CODE\_PHRASE than relying on the possibly language >> dependent DV\_TEXT\.value for those fields/methods\. > > a base assumption in openEHR historically is that the data might > arrive in some application space that doesn't have access to the > terminology\. This can easily happen for many reasons\. We don't want > the application to be useless \(i\.e\. can't put stuff on the screen\) > just because it can't see the terminology\. Now, in these structural > attributes, you could expect that the openEHR terminology would be > available somewhere in the application space\. However, for both > these situations, we historically decided that it was always better > to have the original text of any coded element, in the original > language\. When you say "in the original language", do you mean the original language of the archetype, or do you mean the original language that the user saw on the screen when the data was committed? For example, if an archetype's original language is English, but a user is viewing the text in Swedish, then which of the two languages would the DV\_CODED\_TEXT\.value be committed in? \- Peter Gummer --- ## Post #4 by @thomas.beale it is the latter - the archetype's original language is irrelevant - we are only interested in the locale language of the committing user, which could easily be different. - thomas --- ## Post #5 by @ian.mcnicoll I would agree \- this is clinically the safest and correct action\. Ian Dr Ian McNicoll office / fax \+44\(0\)141 560 4657 mobile \+44 \(0\)775 209 7859 skype ianmcnicoll ian\.mcnicoll@oceaninformatics\.com ian@mcmi\.co\.uk Clinical Analyst Ocean Informatics openEHR Archetype Editorial Group Member BCS Primary Health Care SG Group www\.phcsg\.org / BCS Health Scotland --- ## Post #6 by @Peter_Gummer1 Thomas Beale wrote: >>>> Are end users really supposed to see the DV\_TEXT\.value >>>> of those? \.\.\. >>> >>> \.\.\. we historically decided that it was always better >>> to have the original text of any coded element, in the original >>> language\. >> >> When you say "in the original language", do you mean the original >> language of the archetype, or do you mean the original language that >> the user saw on the screen when the data was committed? > > it is the latter \- the archetype's original language is irrelevant \- > we are only interested in the locale language of the committing > user, which could easily be different\. That makes sense\. On committing the contribution, is there validation of the DV\_CODED\_TEXT\.value to ensure that it is the same text as the value defined for the committing user's language, for that code in that terminology? \- Peter Gummer --- ## Post #7 by @system The latter\.\.\.you are not forced to have every entry in the languahge of the composition\. Sam Sam Heard via Blackberry CEO Ocean Informatics \+61417838808 --- **Canonical:** https://discourse.openehr.org/t/should-attestation-reason-datatype-really-be-dv-text-or-rather-dv-coded-text-or-perhaps-code-phrase/14964 **Original content:** https://discourse.openehr.org/t/should-attestation-reason-datatype-really-be-dv-text-or-rather-dv-coded-text-or-perhaps-code-phrase/14964