Re: Should ATTESTATION.reason datatype really be DV_TEXT or rather DV_CO
On 26/02/2010 14:11, Erik Sundvall wrote:
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 |
_______________________________________________ openEHR-technical mailing list openEHR-technical@openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical