Tom Language translations are part of the terminology service from my point of view and the text should be in the original language. I do not think that the 'translations' should be used for language - but for different coding systems.
I do not think this has any implications for openEHR at the moment. Sam > -----Original Message----- > From: owner-openehr-technical at openehr.org > [mailto:owner-openehr-technical at openehr.org]On Behalf Of Thomas Beale > Sent: Monday, 8 July 2002 5:36 PM > To: open-ehr technical > Subject: New data type issue to think about from HL7 > > > > Here is a possible new data type being suggested in HL7, which looks > real enough to me. Original post from Lloyd McKenzie (HL7 MnM list) > below. I would not agree with the exact model he has proposed (modified > CE/CD) but rather a new subtype of CV, or what we call CODED_TEXT in > openEHR (what was called TERM_TEXT). > > It seems reasonable that we use the coding aproach to represent error or > other short messages, including with the idea of parameters, since a) we > want the same language translation facility and b) it would be > convenient to use the coding approach to deal with such message strings, > rather than having to have some other mechanism. Logically the subtype > of CODED_TEXT would be called something like PARAMETERISED_MESSAGE, i.e. > a message whose whole text is coded, but contains placeholder positions > for parameters, similar to unix variables in strings. There are probably > other, less ugly names, but I can't think of one at the moment... > > thoughts? > > - thomas beale > > ---------- > (following posted by Lloyd McKenzie, 8 jul 2002) > > One of the important use-cases we have in terms of handling messages as > part of e-claims is the ability to communicate a textual message as a code > and a list of parameters. This allows the recipient to translate the > resulting message into the appropriate language for display. We have > client applications that may translate adjudication messages into 10 or 15 > different languages. The back-end claims adjudication systems are unable > to handle this many translations and deal with the situation by > sending out > a code representing the general error message, accompanied by 0..* > parameters that can be plugged into the message. > > For example, an adjudicator might have a message that says "Claim refused. > Coverage expired January 5, 2002". Rather than translating this into > English, French, Japanese, Polish, Italian, etc., the adjudicator > assigns a > code 'C1' to the message "Claim refused. Coveraged expired January &1". > They publish the code/text combination and the client system vendors > produce translations for their respective audiences. Within an actual > message, the adjudicator just sends 'C1', '20020105'. The client system > then expands this into the appropriately substituted message. I would > recommend the use of Java's approach to defining parameter substitution. > > To support this in HL7 requires one of two things: > a) Modify the CD and CE datatypes, adding an additional 'Parameters' > property of type LIST > b) Create new datatypes based on CD and CE having the new parameter. > > We need this in 3.0. We can't release our national claims > standard without > it, even if it means hacking it into the datatype specification ourselves. > (In other words: Feel free to argue about better ways to meet the > use-case, > but don't say it can wait until 3.1 :>) > > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
