HL7 is a communication protocol for medical applications that tries to conform to the OSI concepts of networking. Particularly, HL7 even attaches it's name to the OSI reference model (Health Level 7) therefore it should be expected, that HL7 will easyly comply to the concepts and methods that are suggested by OSI.
Indeed, the distinctions between abstract syntax and encoding rules, are reflected in the HL7 document: For each message, an abstract message definition is given, consisting of 3 parts, which are logically related to the elements which are considered by HL7 to constitute transactions: (1) messages, (2) segments and (3) fields, `data elements' or types. The transactions (messages) are conceptually embedded into their environment in which they occur in terms of `trigger events'. On the other hand, there are encoding rules defined in order to have an interim standard, until the OSI suite of protocols is sufficiently supported.
Finally there are several lower layer protocols (LLP) specified, which belong to the session and transport layers, and which include or use in turn resources, which are associated with again lower layers. These various protocols all meet different needs, which arise from the use of different transport media and their properties such as reliability.
However in the proceeding of this implementation attempt it turned out, that the HL7 specification doesn't make the distinctions above as strict as it claims to. This poses problems to the implementor, who tries to go with OSI. We will point out these problems in this paper at the place where they become evident (see section On the abstractness of abstract syntax in HL7)
The unique notation used in the HL7 document is another problem, that uneases the use of OSI standard methods. Probably much of the problems of HL7 could have been avoided, if a standard notation such as ASN.1 would have been taken over in time. This problem may be partialy come from kind of a misinterpretation of ASN.1: In the HL7 document it is repeatedly stated, that the scope of ASN.1 be the basic encoding rules, however ASN.1 is an abstract syntax notation, which is more appropriate for comparison with the `abstract message notation' used by HL7. The encoding rules stay completely hidden in ASN.1 (in opposite of HL7 message definition). It seems rather likely, that ASN.1 was primarily avoided because of the difficulty "to explain to application programmers, who are not schooled in recursive languages in general, or ASN.1 in particular". This is certainly an anachronism, since tools like lex and yacc are widespread and extensively used since many years. However, to be fair, we have to note here, that HL7 was first documented back in 1987 when the ASN.1 standard was just released.