Previous Page TOC Index Next Page

2.8.14 ED - encapsulated data

Components: <source application (HD) > ^ <main type of data (ID)> ^ <data subtype (ID))> ^ <encoding (ID)> ^ <data (ST)>

This data type transmits encapsulated data from a source system to a destination system. It contains the identity of the source system, the type of data, the encoding method of the data, and the data itself. This data type is similar to the RP (reference pointer) data type of Section 2.8.34, "RP - reference pointer," except that instead of pointing to the data on another system, it contains the data which is to be sent to that system.

2.8.14.1 Source application (HD)

A unique name that identifies the system which was the source of the data. Identical format and restrictions as in reference pointer (see Section 2.8.34.2, "Application ID (HD)").

Subcomponents: <namespace ID (IS)> & < Universal ID (ST)> & <Universal ID type (ID)>

2.8.14.2 Main type of data

Identical to "type of data" component in the reference pointer (RP) data type. (See Section 2.8.34.3, "Type of data (CM)").

Refer to HL7 table 0191 - Main type of referenced data for valid values.

2.8.14.3 Subtype

Refer to HL7 table 0291 - Subtype of referenced data for valid values.

2.8.14.4 Encoding (ID)

The type of encoding, if present, used to represent successive octets of binary data as displayable ASCII characters. Refer to HL7 table 0299 - Encoding for valid values.

Table 0299 - Encoding

Value

Description

A

no encoding - data are displayable ASCII characters.

Hex

hexadecimal encoding - consecutive pairs of hexadecimal digits represent consecutive single octets.

Base64

encoding as defined by MIME (Multipurpose Internet Mail Extensions) standard RFC 1521. Four consecutive ASCII characters represent three consecutive octets of binary data. Base64 utilizes a 65-character subset of US-ASCII, consisting of both the upper and lower case alphabetic characters, digits "0" through "9," "+," "/," and "=.".

Base64 is defined as follows (adapted from MIME internet standard RFC 1521, which has precedence over this description). Proceeding from left to right across a 24-bit input group (three octets), each 6-bit group is used as an index into an array of 64 printable characters. The character referenced by the index is placed in the encoded string. These characters are shown in HL7 table 0290 - MIME base64 encoding characters, and are selected so as to be universally representable.

Special processing is performed if fewer than 24 bits are available in an input group at the end of data. A full encoding quantum is always completed at the end of data. When fewer than 24 input bits are available in an input group, zero bits are added (on the right) to form an integral number of 6-bit groups.

Output character positions which are not required to represent actual input data are set to the character "=". Since all canonically encoded output is an integral number of octets, only the following cases can arise: (1) the final quantum of input is an integral multiple of 24 bits; here, the final unit of encoded output will be an integral multiple of 4 characters with no "=" padding, (2) the final quantum of input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two "="padding characters, or (3) the final quantum of input is exactly 16 bits; here, the final unit of encoded output will be three characters followed by one "=" padding character.

Table 0290 - MIME base64 encoding characters

Value/Code

Value/Code

Value/Code

Value/Code

0 A

17 R

34 I

51 z

1 B

18 S

35 j

52 0

2 C

19 T

36 k

53 1

3 D

20 U

37 l

54 2

4 E

21 V

38 m

55 3

5 F

22 W

39 n

56 4

6 G

23 X

40 o

57 5

7 H

24 Y

41 p

58 6

8 I

25 Z

42 q

59 7

9 J

26 a

43 r

60 8

10 K

27 b

44 s

61 9

11 L

28 c

45 t

62 +

12 M

29 d

46 u

63 /

13 N

30 e

47 v


14 O

31 f

48 w

(pad) =

15 P

32 g

49 x


16 Q

33 h

50 y


The interpretation of the encoded octets by any of the encoding methods, beyond what is either implicit or specified in the represented data type (such as their ordering within 16-bit or 32-bit binary words on the destination application), is determined by the destination application and is beyond the scope of this Standard.

2.8.14.5 Data (ST)

Displayable ASCII characters which constitute the data to be sent from source application to destination application. The characters are limited to the legal characters of the ST data type, as defined in Section 2.8.38, "ST - string data" and, if encoded binary, are encoded according to the method of Section 2.8.14.2, "Main type of data."

If the encoding component (see Section 2.8.14.4, "Encoding (ID)") = ‘A’ (none), then the data component must be scanned before transmission for HL7 delimiter characters, and any found must be escaped by using the HL7 escape sequences defined in Section 2.9, "Use of escape sequences in text fields " On the receiving application, the data field must be de-escaped after being parsed.

If the encoding component (see Section 2.8.14.4, "Encoding (ID)") does not equal ‘A", then, after encoding, the (encoded) data must be scanned for HL7 delimiter characters, and any found must be escaped by using the HL7 escape sequences. Only then can the component be added to the HL7 segment/message. On the receiving application, the data field must be de-escaped after being parsed out of the message before being decoded. This can be expressed as ‘encode’, ‘escape’, parse, ‘de-escape’, ‘decode’.

Previous Page TOC Index Next Page