This wiki has undergone a migration to Confluence found Here

Datatypes R2 Issue 3

From HL7Wiki
Jump to navigation Jump to search

Data Types Issue 3: Add ED.translation

Introduction

Add support for conveying multiple language or format translations of equivalent content within the ED type. There are situations in several international affiliates where they need to be able to convey the same information in multiple languages. Repeating the entire message content for each translation represents an unnecessary and unreasonable burden.

Is backward compatible.

HL7 Canada

Discussion

Table 5: Property Summary of Encapsulated Data Name Type Description translation SET<ED> Identifies the type of the encapsulated data and identifies a method to interpret or render the data.

Definition 40: type EncapsulatedData alias ED specializes BIN {

 CS   mediaType;
 CS   charset;
 CS   language;
 CS   compression;
 TEL  reference;
 BIN  integrityCheck;
 CS   integrityCheckAlgorithm;
 ED   thumbnail;
 SET<ED> translation;
 BL   equal(ANY x);

};

Properties of Encapsulated Data (ED) Translation (translation : SET<ED>)

Definition: Identifies alternate renditions of the same content translated into a different language. The translation property is a set of encapsulated data that each translate the first rendition into different language. Each element of the translation set was translated from the first encapsulated data. Each translation may, however, also contain translations. Thus, when a document or string is translated multiple times the information about which rendition served as the input to which translation will be preserved. Note: This property should not be used to communicate different transformations or renderings of a set of content. For example, a CDA document would not be a translation of a free-text report. <We could add an invariant requiring that the language in a translation be different than the original, but I’m not sure it’s necessary. There may even be use-cases where translations to the same language is useful. E.g. simplifying terminology.>

<x

 nullFlavor = {nullFlavor}                    
 representation = "B64"|"TXT"       
 language = {language}
 charset = {charset}
 mediaType = {mediaType}
 compression = {compression}
 integrityCheck = {IntegrityCheck}
 integrityCheckAlgorithm = {IntegrityCheckAlgorithm}
 >
 -->
   translation : SET<ED>

</x>

Schema Fragment 12:

<xsd:complexTypename="ED" mixed="true">

   <xsd:complexContent>
       <xsd:extensionbase="BIN">
           <xsd:sequence>
               <xsd:elementname="reference" type="TEL" ... />
               <xsd:elementname="thumbnail" ... />
               <xsd:elementname="translation" ... />
           </xsd:sequence>
           <xsd:attributename="mediaType" type="cs" ... />
           <xsd:attributename="language" type="cs" ... />
           <xsd:attributename="compression" type="cs_CompressionAlgorithm" ... />
           <xsd:attributename="integrityCheck" type="bin" ... />
           <xsd:attributename="integrityCheckAlgorithm" type="cs_IntegrityCheckAlgorithm" ... />
       </xsd:extension>
   </xsd:complexContent>

</xsd:complexType>

<xsd:elementname="translation" minOccurs="0" maxOccurs="unbounded">

   <gsd:templatename="SET" as="type">
       <gsd:withParamname="T" type="ED" />
   </gsd:template>

</xsd:element>


Paul Biron: Is there a constraint that translation only be used when the mime-type is text/plain (or other textual types)? That is, what if the original ED.mediaType was image/jpeg...does it make sense to include a translation in that case? Just wondering...

Lloyd: In theory you could have a movie dubbed in French or Japanese . . . I expect it would mostly be used for text, but semantically it would make sense any place language does (and language isn't restricted to text only).

Paul: OK, I guess I see your point...and I also guess that it's not necessary to put a contraint that the mime type of the orig and the xlation need to be same, e.g., if the orig is a movie in french the translation could be text in english. Is that your intention?

Lloyd: OK, I guess I see your point...and I also guess that it's not necessary to put a contraint that the mime type of the orig and the xlation need to be same, e.g., if the orig is a movie in french the translation could be text in english. Is that your intention?


Disposition

INM, 2 May 2007:

There is another way to solve this problem: make the attribute type SET<ED> instead of ED. This allows committees to more precisely specify how the translations are done, but does require more committee work.

Straw vote on 3 options:

  1. accept as proposed 1
  2. Change RIM ED type attributes to SET<ED> 1
  3. Nothing is required - attach multiple documents (maybe necessary to check that model allows for this?) 4
  4. abstain 4

Further discussion with Lloyd to follow

Status

Proposed

Links

Back to Data Types R2 issues