I have just been contemplating the ISO requirement: STR4.6 The EHRA must support the identification of information that has been translated from the language in which it was originally recorded. Such identification must describe the faithfulness or reliability of the translation. (1.4.3)
We have previously said that a new TRANSACTION would be created for the purposes of translation. Let's imagine that it is necessary to have a portuguese translation of the current Care Plan transaction (let's say a UK traveller is in hospital in Portugal or Brazil...). What needs to happen? step 1: create a new TRANSACTION version in the same VT, which is a copy of the exiting latest one step 2: all DV_PLAIN_TEXTs (whether self-standing or in DV_PARAGARPHs) have to be edited into portuguese step 3: either we assume that all DV_TERM_TEXTs will jsut appear in portuguese via a terminology (unlikely since not many termsets have portuguese translations) or the author translates all these as well. Probably the system should convert them all to DV_PLAIN_TEXTs first. set 4: commit new version Now, what is in the new version? If it is only Portuguese language, it breaks the rule that the latest version contains the latest information in the sense that now it cannot be read by the usual owners of the record (UK doctors, hospitals, software). Also, what if the portuguese/brazilian clinicians decide to add some new information - it would only be in portuguese (actually, that's a bit unfair, doctors in both countries are much more likely to be able to choose to use English in an english language EHR than most english speakers are to do the reverse. Nevertheless...let's imagine the consultant does not know how to write english - maybe they are a local nurse or other kind of carer in rural brazil). There are two solutions I can see. 1. versions for the purpose of language translation only could be "side" branches on the version tree, meaning that both the current top english-language version and the newly translated portuguese version are both the latest (but the english language one would take precedence because it was the "trunk". If the record had been in portuguese, and we were doin an english translation of a part of it, it would be the other way round). This would slightly change the version identification scheme, and would complicate the management of versions a bit. On the other hand, branching is a very well understood idea in version control, and there are many models for how to do it. However, we would probably have to impose a rule that the translated version was just a translation - no additions etc. If additions were wanted, then yet another new version would be created on top of the new translated version. This version then would be the "latest" in the tree. 2. make the translation a new version in the trunk, but make the model so that each fragment of text which has been translated is also retained in english as well - ie.. for every single text item in the english original, there are now two items - the original and the portuguese equivalent. Viewers of the record choose whichever language, and see the appropriate view. This approach breaks the current rule that the contents of a TRANSACTION are all in one language only. We would have to move the language indicator to DV_TEXT, DV_PARAGRAPH etc to enable different fragments to each hae their own translation. If the portuguese authors decide to add more information in portuguese, where will it go? Presumably in a new transaction on top of the translation one, but the problem now is that there are item(s) which are now only in portuguese, salted through the latest TRANSACTION... Solution 1 is preferable from a clean version control perspective, since it is absolutely obvious where the latest information is, and where any information in a given language will be. But solution 2 probably corresponds more closely to the reality that complete translations might not be done - just enough fragments might be translated to enable the treating physician to do his/her work. This means that solution 1 would result in transaction versions which remained mostly in english, with bits of portuguese sprinkled through them, being saved as "portuguese" language transactions. I think the rules we should stick to are as follows: a) one primary language for the whole transaction. Transactions in which the totality of information is not available in one language are not viable for safe health care b) new versions on the trunk of the version tree should never change their primary language. This means that all trunk versions in a VERSIONED_TRANSACTION have the same primary language. A solution which would respect these rules and achieve what we want takes another approach: - define the primary language at the VERSIONED_TRANSACTION level (i.e all TRANSACTIONs in the tree have the one primary language) - any translation no matter how partial of an existing TRANSACTION, causes a side version whose reason for creation is "translation to XXX", where XXX is the target language - translation of fragments in the side version is done by allowing DV_TEXTs to have translations, which do not replace the current value, but are in addition to it. As many or as few textual fragments as are needed can be translated. - if the 2nd language author wants to write new content into an existing transaction in the 2nd language only, create a new TRANSACTION version containing the new content items on top of the side version. Now, let's imagine the UK person gets back home after their bad accident in Brazil. The Brazilian doctors have been brilliant, and fixed them up; only problem is that the patient's new care plan (and maybe a lot of other bits and pieces in the record) all appear in Portuguese only. According to the above solution, the new information must be in latest versions on side branches of existing versioned transaction trees, or else in completely new transaction trees. This makes it easy for the software to find the 2nd language additions, and for the health service to get them translated back to english, and put in as new trunk versions, now bringing the trunks up to date. What about the transaction trees newly created in Brazil - does english now become the side version here? Or do we force them to be created with portuguese as the side branches, even though they were created for the first time by portuguese-speaking authors? I favour the second approach., Thoughts? This is a tricky area, and I;m sure there are holes in my proposals so far. - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
