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
