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.
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.
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?
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.
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?
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