The following posted on behalf of Dr Jean-Luc Mommaerts
I would take as general principle the following:
"One meaning - one transaction (or 'equivalent' transaction, cf. infra);
difference in meaning - different transactions."
This goes more or less against what has been previously said, but still I
think it to be a logical solution. A doctor primarily wants to convey
meaning in his writings, independent of the format. Whether it's there on
paper, in bits and bytes, in codes or in another human language doesn't
matter for that.
Some notes:
1) I am well aware that a translation never provides 100% the same meaning.
But we talk about intentions now. If you (as reader of the EHR) know that
the intention of the writer was to convey the same meaning, you know that
you only have to look at one version, namely that of which you know the
language best.
2) In many cases, a doctor will understand some of the meaning, even if the
text is in another language. Medicine has many terms that etymologically
come from the same roots. So, partial translations will be common. But
almost always a partial translation will be supplemented with additional
information.
3) Not only can one go to Brazil on holiday. One can move to that country.
Then after a year or two (or twenty?), one moves again. And again. Anything
is possible.
This is only to depict reality. The solution that I propose transcends these
difficulties.
Let's take a look at some use cases now:
1) A translator translates one or more transactions and wants to indicate
that he translated them 'as good as possible', i.e. without intention to
change anything of the meaning. In that case, I would not make a new 'direct
' instance of <TRANSACTION>. The translator needs to be able, though, to
indicate his intention of conveying the same meaning in another language. In
any case, at this point one just has two 'forms' of the same thing, i.e. the
same transaction. Maybe make it an instance of <EQUIVALENT TRANSACTION>.
<EQUIVALENT TRANSACTION> can be a conceptual child of <TRANSACTION>, with an
additional attribute indicating its reason for existence, in this case:
language translation. Additional attributes can be where and by whom the
translation is done and with what degree of reliability (according to ISO).
2) A translator translates a transaction only partially, with no additional
information. Same result. It is the same ('equivalent') transaction. There
is a fuzzy border now between the 'primary languages'. But the migration is
from language A to language B. Let the translator be able to indicate this.
You can not ask from a doctor who translates parts of a transaction, that he
always indicates for each part whether his translation is 'pure' or with
additions.
3) There is a (complete or partial) translation + at the same time
additional information. In this case, it's a different transaction. Treat it
as any other new transaction, but with an indication of the language
migration.
4) There is an automatic translation of (some of the) terms. Here, one can
look at what happens, completely from the level of concepts instead of
terms. The same thing is there inside the computer. The only difference is
how the user looks at it. So: same transaction. In fact, wherever possible,
a user should always be able to take a look at terms in different languages.
Terms explicitly related to concepts shouldn't be present in the computer as
unrelated terms, but always as concepts (concept-ID's).
5) The doctor doesn't know anything of the language and no translation is
done at all. Then a new transaction is made with indication of language.
We come back to the general principle: "One meaning - one transaction", but
WITH an indication that it concerns a translation (whether partial or
complete). In all other cases, make a new transaction. As for 'primary
language', I think it's best to always have it indicated on the level of
transaction, instead of versioned transaction. This avoids possible errors
when a person moves and moves and moves.
This solution is simple and IMO encompassing enough. But: I don't know the
arguments why it was previously said to make a translated transaction always
a different transaction. In a sense, an 'equivalent transaction' IS also
different. Thus as an alternative, you can put it in the same list
(versioned transaction). The version identification scheme doesn't have to
be changed. The most recent transaction is then always the latest
transaction in the list, but if it's an instance of <EQUIVALENT
TRANSACTION>, then the one before is also the latest one, which, by meaning,
is true.
Kind regards
Jean-Luc Mommaerts
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org
