Thomas Beale wrote:
>
> 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."
the only problem with literally agreeing with this is that if a
transaction has been committed in language L1, there is no way in the
architecture to go and modify it, even jsut for the purpose of
translating it to L2, without creating a new transaction - that's the
principle of indelibility, required to ensure medico-legal
investigations can occur. So any change, no matter how small must cause
a new transaction; we then need to decide among the following possibilities:
1. add a new "trunk" transaction in L2; this transaction is now the "latest"
2. add a "branch" transaction in L2; both the most recent trunk and the
new branch are candidates for being the "latest", depending on what
language you want to read in, and whether the writers of the new branch
added anything
3. create a new VERSIONED_TRANSACTION whose first TRANSACTION is the one
in L2, based on a transaction in an existing versioned transaction.
However, I agree with the spiriti of Jean-Luc's statement - one meaning
/ one transaction; however, I would apply it to the whole record: there
is just one record, of which some information might be in language L1,
some in L2, some in L3 etc. This is in contrast to a possible view which
says that there might be different langauge "views" of the record, e.g.
a portuguese view, a bulgarian view, a basque view. From the scenarios
described below, and from most people's experience, this is unrealistic.
The reality is that bits here and there are translated, some completely,
some not, some information is added in a new language, etc. And all the
while, practitioners (at least at higher levels of training) can read
all those latin/greek based words used in the european tradition of
medicine, so the difference between what is written (in various
languages) and what is understood is a grey area (but note: it would be
easy not to understand some little words in another language, which
might be things like "no evidence of", "fear of" etc - food for thought).
> 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).
I don't know if there is any need for another "reason" attribute, since
TRANSACTION already has one, but maybe for recording quality or type of
translation...
> 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.
I agree; no-one is going to do this. The only way to know if anything
has been added is to read the new material, which may require getting
someone in fluent in the other language to do it.
> 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.
Given that there is no way for software to tell the difference between
2) and 3), I think that both cases have to lead to a new transaction.
> 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).
I agree - this should be done in the display, and does not change
anything in teh EHR.
> 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.
agree.
> 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.
But due to the indelibility requirement we have to make a new
TRANSACTION anyway...
> 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.
I think I probably agree with this - it maintains the principle that
"the current view of the EHR is given by the latest TRANSACTION in every
VERSIONED_TRANSACTION". If just translating a transaction causes a new
VERSIONED_TRANSACTION, then this rule is broken - some VTs will have
out-of-date informatino as their latest version.
> 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.
I'm not sure how much I like the name, but the idea of
EQUIVALENT_TRANSACTION probably should be considered. One point to think
about though: what happens if the latest version of say a care plan is
partially translated, and this new version now goes back a new
TRANSACTION in the VT stack, but it contains only the translated bits.
What is the clinical meaning of this: that some parts were deleted
because they were not translated, or that some parts where deleted
because they are no longer clinically relevant, due to the new care
situation of the patient.... or both...?
When I think of this situation, I find I come back to branch versions,
where you can always see the latest verion in a given language, but also
know, due to committal date/times, what is the "latest" information. In
general, this leads to a real version "tree" not just a "trunk".
- thomas beale
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org
