Accepted Manuscript Vietnam Journal of Computer Science

Accepted manuscript to appear in VJCS
Accepted Manuscript
Vietnam Journal of Computer Science
Article Title: Version-Compatible HL7 Parser Based on Object-Oriented Design

by 5.188.217.244 on 09/18/19. Re-use and distribution is strictly not permitted, except for Open Access articles.
Author(s): Dinh Tuyen Hoang, In Keun Lee, Dosam Hwang
DOI: 10.1142/S2196888819500258
Received: 29 April 2019
Accepted: 26 July 2019

Vietnam J. Comp. Sci. Downloaded from www.worldscientific.com
To be cited as: Dinh Tuyen Hoang, In Keun Lee, Dosam Hwang, Version-Compatible
HL7 Parser Based on Object-Oriented Design, Vietnam Journal of Com-
puter Science, doi: 10.1142/S2196888819500258
Link to final version: https://doi.org/10.1142/S2196888819500258
This is an unedited version of the accepted manuscript scheduled for publication. It has been uploaded
in advance for the benefit of our customers. The manuscript will be copyedited, typeset and proofread
before it is released in the final form. As a result, the published copy may differ from the unedited
version. Readers should obtain the final version from the above link when it is published. The authors
are responsible for the content of this Accepted Article.
T
IP
CR
World Scientific Publishing Company
Version-Compatible HL7 Parser Based on Object-Oriented Design
US
Dinh Tuyen Hoanga,c

a
Department of Computer Engineering, Yeungnam University,
Gyeongsan-si, Gyeongsangbuk-do, Korea
c
Faculty of Engineering and Information Technology, Quang Binh University,
AN
Dong Hoi, Vietnam

hoangdinhtuyen@gmail.com
In Keun Leeb
b
Daegu Metropolitan Transit Corporation,
Daegu, Korea
inkeunlee@gmail.com
Dosam Hwanga,*
DM
a
Department of Computer Engineering, Yeungnam University,
Gyeongsan-si, Gyeongsangbuk-do, Korea
dshwang@yu.ac.kr
Received (Day Month Year)

Revised (Day Month Year)
International standards for the exchange of healthcare information, known as Health Level Seven
(HL7), were developed for the interoperability of healthcare information systems. Because of HL7’s
complex structure and syntax, HL7 messages are processed by computer software. HL7 defines that,
when the version is updated, it should be compatible with the previous version. However, most of
the HL7 interface software that is currently in development does not consider the version
TE
compatibility of HL7 messages. Instead, a separate conversion software module has been used to
handle the version compatibility of HL7 messages for the healthcare information system. However,
such a method is inefficient, because it requires several hours and incurs a huge cost. Therefore, in
this study, an HL7 parser was developed that not only supports backward compatibility with older
versions in accordance with the version compatibility definition of the HL7 V2 messages but also
guarantees forward compatibility with newer versions to enhance its utilization. The developed
parser was used to test conversion between different versions of HL7 V2 messages, which were
created to transmit information from one healthcare device to another. Through this test, the
EP
usefulness of the developed parser was verified.
Keywords:Health Level Seven; Object-Oriented Design; Version Compatibility.
∗Contact dosam hwang. email: dosamhwang@gmail.com

C
1
AC
T
IP
CR
World Scientific Publishing Company
1. Introduction
As a result of efforts to computerize healthcare information, diverse healthcare

information systems, such as Electronic Medical Record and Electronic Health Record,
have been developed to create and manage healthcare information. Additionally, to
US
exchange information between healthcare systems that have been built independently by
each healthcare institution, various transmission standards for healthcare information,

such as Health Level Seven (HL7)1,2, Digital Imaging and Communications in Medicine
(DICOM), and Clinical Document Architecture (CDA), are used.3 In particular, HL7 is
widely used for exchanging healthcare information between different systems. Because
HL7 messages have complex structures and syntax, computer software parsers are used
to process these messages.4 Conceptually, HL7 has been designed to support
AN
interoperability between diverse versions (V2.1 through V2.8). However, existing

software parsers developed to process HL7 messages, such as Symphonia, NeoBrowse
TCP, Chameleon, LINKTools, do not satisfy the version compatibility between different
versions of HL7 messages to guarantee the reusability and interoperability of HL7.1
To solve this problem, HAPI5 provides a method to convert from a newer version to
an older version of HL7 message, and recent studies6-8 have designed a structure of HL7
parser that guarantees backward compatibility according to HL7’s version compatibility
DM
definition2. Existing studies6,7 have proposed, from an object-oriented perspective, a

conceptual design of a parser that can convert from a newer version to anolder version.
However, they have failed to present specific methods to implement the parser based on
this design. In addition, one study8 has not considered the scalability of the parser for the
addition of newer versions. As a result, when a new system has been implemented using
the parser, the system has to be modified whenever the parser is updated, thus lacking
system developer convenience.
Therefore, in this study, an HL7 parser, which guarantees forward compatibility to
improve its utilization as well as backward compatibility according to the version
compatibility definition, was developed. This parser was designed based on the concept
TE
of object-oriented design. Furthermore, in implementing this parser, a method was

proposed for creating several thousand class files easily and quickly. According to the
proposed method, an HL7 parser that can process eight versions (V2.1 through V2.7) of
HL7 messages was implemented. Furthermore, the usefulness of the developed parser
was verified by conducting a test using the parser to convert between different versions of
HL7 messages, which were created to transmit information between healthcare devices.
EP
2. Design of a version-compatible HL7 parser
The composition of segments inside an HL7 V2 message and the composition of

components inside a segment are defined differently based on the message version.
Additionally, when a new version is defined for HL7, new categories are added to the
C
2
AC
T
IP
CR
structures of segments and components from the previous version. Hence, HL7
guarantees backward compatibility based on the version compatibility definition.4 (e.g., a
message based on V2.3 will be understood by an application that supports V2.6). In other
words, because the structure of a newer version (e.g., V2.6) includes the structure of
anolder version (e.g., V2.3) in HL7, it should be possible to convert a message of the
newer version to a message of the older version. However, in reality, the structures of
US
HL7 messages between different versions are partly different, so the existing parsers have
not taken the version compatibility into consideration. In addition, a separate conversion
module based on the version of the HL7 messages has been developed and is being used
to support the version compatibility. To solve such a problem, previous studies6-8 have
proposed, from an object-oriented perspective, a conceptual design of a parser that can
convert from a newer version to anolder version; however, they could not provide
specific methods to implement a parser based on their design.
AN
The structure of the studies6-8 is based on the concept of inheritance in object-

oriented design. As shown in Fig. 1, the class for the newer version of the HL7 message
inherits from the class for the older version. Additionally, in another study8, HL7
messages were processed by sequentially converting the type or value of the components
according to the version of the class instance, from the instance of the class
corresponding to the version of the original message to the instance of the class for the
version to which the message will be converted. For example, an ADTÂ01 message of
the older version (V2.4) is handled by the instance of "V24.ADT_A01" class, which is
DM
the superclass of “V25.ADT_A01” class in Fig. 1. Once the message has been converted
to the newer version (V2.5), the instance of subclass "V25.ADT_A01" performs the
creation of new messages. Therefore, message and component classes for all versions are
interrelated in the HL7 parser designed based on the concept of object-oriented design
(shortly OOD).
TE
EP
Fig. 1. OOD-based structure of HL7 V2 parser

C
3
AC
T
IP
CR
Hoang et al.
2.1. Design of a class diagram
To design the structure of a version-compatible parser, the concept of inheritance in

object-oriented design was used, which was the same as in previous research8. That is to
say, by having the instance of the class corresponding to the newer version inherit the
US
instance of the class for the older version, as shown in Fig. 1, HL7 messages of all
versions can be processed using only the instance of the lowest subclass. However, unlike
the previous research8, in this study, the lowest subclass was defined not to have a
version specified for it, as shown in Fig. 2. The parser was designed to process messages
of all versions by utilizing the lowest subclass.
AN
DM
TE
Fig. 2. Enhanced OOD-based conceptual structure of HL7 V2 parser
For example, when processing the ADTÂ01 message of HL7 V2.4, the parser first
EP
checks the actual version of the message, and the instance of the "V24.ADT_A01" class
for the corresponding version processes the message. The “V24.ADT_A01” class
contains the instance of the "MSH" class. Here, the request is made to "V25.MSH"—the
instance of the lowest subclass—to process the message, and the instance of "V24.MSH"
class processes the HL7 message according to the version of the actual message. The data
C
4
AC
T
IP
CR
of the HL7 message that have been processed through this procedure are stored in the
instance of the class associated with the corresponding version.
However, if a new system is implemented using the parser library developed
following the design of the previous study8, the developer would produce the software by
using the lowest subclass (e.g., V25.ADT_A01 class in Fig. 2) provided by the library. If
a parser library that includes the HL7 messages of a new version is provided, then the
US
system developer encounters the problem of having to modify the existing software. For
example, if the code is written using the HL7 parser library for V2.4, as shown in Fig.
3(a), but later the HL7 parser library updated with V2.5 is used, then the instance of the
lowest subclass must be redefined, as shown in Fig. 3(b).
V24.ADT_A01 adt_a01; V25.ADT_A01 adt_a01;

... ...
AN
V24.MSH msh = adt_a01.getMSH(); V25.MSH msh = adt_a01.getMSH();
(a) part of code using previous library (b) part of code using updated library
Fig. 3. Examples of code based on different versions of library
However, in this study, conceptual classes, such as "common.MSH" in Fig. 2, which

are not dependent on a version, are defined. Because the system developer only uses the
lowest subclass, the existing code can be used without modification, as shown in Fig. 4,
DM
even if the library is modified by the addition of future versions.
common.ADT_A01 adt_a01;
...
common.MSH msh = adt_a01.getMSH();
Fig. 4. Example of code using the library based on the proposed structure
2.2. Decoding and encoding procedure

TE
The HL7 parser has been designed to parse messages in a bottom-up manner to support
backward compatibility. To be specific, the following method is used to process an HL7
message: (1) the version of the original HL7 message is checked, (2) the superclass
method is called by the overridden decode() method until the instance of the class
associated with the version of the original message is reached, and (3) the message is
processed by the instance of the class corresponding to the version of the original
message. For example, if the ADTÂ01 message of HL7 V2.4 is processed as in Fig. 5
EP
and Fig. 6, the type and version of the message are first checked. Then, the instance of
"common.ADT_A01" class, which is the lowest subclass, is created regardless of the
version, and parsing is performed. In the parser, the message is processed by the instance
of the "V24.ADT_A01" class that corresponds to the actual version of the message. The
“V24.ADT_A01” class contains the instance of the "MSH" class. Here also, the request is
made to the instance of the lowest subclass, "common.MSH," and the HL7 message is
C
5
AC
T
IP
CR
Hoang et al.
forwarded to the instance of the "V24.MSH" class to be processed according to the

version of the original message. Data processed through this procedure are stored in the
instance of the class corresponding to the version of the original message.
US
AN
Fig. 5. Decoding procedure of an HL7 message

DM
TE
Fig. 6. Method diagram for decoding of an HL7 message
If attempting to create an HL7 message of a new version in a bottom-up manner, the

following procedure should be used: (1) the new version of the HL7 message is set, (2)
the overridden encode() method calls the superclass method until the instance of the class
associated with the set version of the message is reached, and (3) the message is created
by the instance of the class corresponding to the set version of the message.
EP
For example, to create a message of a new version by converting the original message
of the newer version (V2.4) to the message of the older version (V2.3), as shown in Fig. 7
and Fig. 8, the following procedure is used: (1) after setting the version (V2.3), the
instance of the lowest subclass "common.ADT_A01" calls the encode() method, (2) the
encode() method of the “V23.ADT_A01” class, which is the superclass of the
“V24.ADT_A01” class, is called according to the set version, and (3) the encode()
C
6
AC
T
IP
CR
methods of "V23.MSH" and "V23.CE" classes are called using the same method to create
the HL7 message of the set version. The method overriding of object-oriented design is
utilized to support backward compatibility.
US
AN
Fig. 7. Encoding procedure of an HL7 message for backward compatibility

DM
TE
Fig. 8. Method diagram for encoding of an HL7 message for backward compatibility
However, a structure that can process HL7 messages in a bottom-up manner, as well
as a method that can process HL7 messages in a top-down fashion, is needed to design an
effective parser. In other words, implementing a parser that guarantees forward
EP
compatibility by using the structure of the parser designed to support backward

compatibility facilitates conversions between all versions of the HL7 messages.
To create an HL7 message of a new version in a top-down manner, the following
procedure is used: (1) the new version of the HL7 message is set, (2) casting is performed
until the class instance associated with the set version of the message is reached, and (3)
C
7
AC
T
IP
CR
Hoang et al.
the class associated with the set version of the message creates the message by calling the
encode() method.
For example, as shown in Fig. 9 and Fig. 10, the process to convert the message of
the older version (V2.4) to the message of the newer version (V2.5) is as follows: (1) the
instance of the lowest subclass "common.ADT_A01" calls the encode() method, (2) the
US
encode() method of the "V24.ADT_A01" class is called, which processed the original
HL7 V2.4 message, (3) the data stored in the "V24.ADT_A01" class instance are
converted to data defined in the "V25.ADT_A01" class, and the converted data are stored
in the "V25.ADT_A01" class instance according to the set version (V2.5) for message
conversion, and (4) the message of the set version is output by calling the encode()
method of the "V25.ADT_A01” class again. This method uses casting in object-oriented
programming to support forward compatibility. In other words, a superclass instance
AN
cannot call the instance of a subclass directly. Therefore, data stored in the superclass
instance are converted to the data type of the subclass instance by forcing the encode()
method of the subclass to be called through casting the superclass instance into the
subclass instance.
DM
Fig. 9. Encoding procedure of an HL7 message for forward compatibility

TE
EP
C
8
AC
T
IP
CR
US
AN
Fig. 10. Method diagram for encoding of an HL7 message for forward compatibility
As a result of integrating the above procedures, the process of converting an HL7

message to either a newer or older version in object-oriented design is illustrated as a
flow chart in Fig. 11.
DM
TE
EP
Fig. 11. Flow chart for converting HL7 message as given version
C
9
AC
T
IP
CR
Hoang et al.
3. Development tool for HL7 parser
As shown in Table 1, the number of HL7 message types and components has steadily
increased by version. The parser developed in this study processes HL7 messages of all
versions. Therefore, the number of classes that need to be created for messages,
US
segments, and components for all versions of HL7 messages amounts to approximately
6000. In addition, because the developed parser supports conversion of HL7 messages
from one version to another, the classes that comprise the parser are related to each other.
Table 1. Class amounts to compose the proposed HL7 parser
Version 2.1
AN
2.2 2.3 2.3.1 2.4 2.5 2.5.1 2.6 2.7 Total
Message 39 74 237 173 178 202 201 216 192 1,512

Segment 37 62 110 110 138 150 150 170 170 1,097
Component 7 11 38 77 79 77 77 77 72 515
Table 128 189 292 306 408 477 477 538 535 3,350
Total 211 336 677 666 803 906 905 1,001 969 6,474
DM
In the process of developing the HL7 parser based on object-oriented design, the
number of classes that need to be implemented according to the proposed design amounts
to several thousand, as shown in Table 1. Therefore, implementing the parser according
to the proposed design requires many staff resources and much time. In addition, to
modify the code of a class related to a specific version of HL7 messages, the structure
and code of all related classes have to be modified as well. In other words, if a small
modification is needed for the superclass, its subclasses and many other related class files
must also be modified.
In this study, "Class File Maker" was implemented to create Java class files
automatically according to the predefined rules, as shown in Fig. 12(a), to implement
TE
effectively the HL7 parser comprising several thousand classes. The relationship between
the HL7 message structures of different versions was set up as a database of tables, as
shown in Fig. 12(b), and codes for classes related to HL7 messages and their components
were composed as a template shown in Fig. 12(c). The Java class files were generated
automatically by combining these tables and templates.
EP
C
10
AC
T
IP
CR
US
(a) Diagram of Class File Maker
AN
(b) HL7 Database (c) Class Code Template

Fig. 12. Class File Maker for HL7 message parser
DM
The method for automatically implementing the parser can be explained using the
following example: (1) HL7-related data provided by a previous report1 are converted
into a table format, and the HL7 DB is set up using these tables, (2) class code templates
in Fig. 12(c) are created to implement automatically class files (e.g., ADT_A01.java)
related to HL7 messages (e.g., ADT_A01), class files (e.g., MSH.java, PID.java) related
to segments (e.g., MSH, PID) composing the HL7 messages, and class files (e.g.,
CX.java, HD.java) related to components (e.g., CX, HD) composing the segments, and (3)
class files that constitute the HL7 parser are created automatically by the "Class File
Maker" in Fig. 12(a) by referring to the HL7 DB in Fig. 12(b) based on the characteristics
TE
of the HL7 messages, segments, and components for each version in Table 1.
This method is useful for the development and modification of the HL7 parser,
because codes for several thousand class files are modified in a batch when the HL7
parser is modified, and a minimum of 1 min is needed to verify the test results for the
modified parser.
EP
4. Version compatibility test
To evaluate the version compatibility function of the developed parser, the ORU^R01
messages of various versions (V2.1, V2.2, V2.3, V2.3.1, V2.4, V2.5, V2.5.1, V2.6, V2.7)
were used to conduct the compatibility experiment. The ORU^R01 message is an
automatic observation message (unsolicited transmission of an observation message) and
C
11
AC
T
IP
CR
Hoang et al.
is used for transmitting vital signs, such as blood pressure, blood glucose level, and body
composition, measured using the personal health devices. This message is composed of
segments such as MSH (Message Header), PID (Patient Identification), OBR
(Observation Request), and OBX (Observation Result). The compatibility experiment
was conducted using 200 HL7 V2.5 messages (ORU^R01)9, which were created when
US
the blood glucose level, blood pressure, and body composition measured using the U-
Healthcare system for 11 inpatients at the endocrine internal medicine department of K-
university hospital in 2012 were transmitted to the Medical Information System. Table 2
shows the part of the ORU^R01 message used in the experiment. To verify the backward
compatibility of the developed parser, the HL7 V2.5 message was converted to V2.1,
V2.2, V2.3, V2.3.1, and V2.4. Furthermore, a test was performed to convert the HL7
V2.5 message to V2.5.1, V2.6, and V2.7 to verify the forward compatibility. Through the
AN
test, whether an error occurred during the conversion of the HL7 message between
versions and the reliability of the converted messages were verified. Table 3 shows the
results of the experiment for converting the HL7 messages between versions by using the
developed parser. The experimental results verified that the message was successfully
converted to each version without an error.
DM
Table 2. HL7 ORU-R01 messages for transmission of bio-information
MSH|^~\&|Gateway|BIT|SeniCare|MIPTH|20120209181657||ORU^R01ÔRU_R01|2
0120209181657-0|P|2.5
PID|||61:A2:02:07:00:01:04:E0||USER
OBR||1|1|29247-8^VITAL SIGNS^LN||20120209181657|20120209181657
OBX|1|NM|8462-4ÎNTRAVASCULAR DIASTOLIC:PRES^LN||83|mm(hg)|60-
90||||F
Transmission
OBX|2|NM|8479-8ÎNTRAVASCULAR SYSTOLIC:PRES^LN||117|mm(hg)|100-
blood 160||||F
pressure OBX|3|NM|8867-4^HEART BEAT RATE^LN||97|/min|60-100||||F
OBX|4|ST|8357-6^BLOOD PRESSURE METHOD^LN||MANUAL BY UA-
TE
767PBT||||||F
OBX|5|ST|8886-4^HEART RATE METHOD^LN||MANUAL BY UA-767PBT||||||F
MSH|^~\&|SeniCare|MIPTH|Gateway|BIT|20120209181700||ORU^R01ÔRU_R01|2
ACK 0120209181657-0-R|P|2.5
MSA|AA|20120209181657-0
0120209181400-0|P|2.5
Transmission PID|||61:A2:02:07:00:01:04:E0||USER
EP
blood OBR||1|1|29274-8^VITAL SIGNS^LN||20120209181400|20120209181400

glucose OBX|1|NM|14743-9^GLUCOSE^LN||85|mg/dL|80-110||||F
ACK 0120209181400-0-R|P|2.5
MSA|AA|20120209181400-0
C
12
AC
T
IP
CR
0120206121848-0|P|2.5
PID|||61:A2:02:07:00:01:04:E0||USER
Transmission OBR||1|1|10210-3^PHYSICAL FINDINGS^LN||20120206121848|20120206121848
body OBX|1|NM|18833-4^BODY WEIGHT:MASS^LN||64.5|kg|0-120||||F
composi- OBX|2|NM|39156-5^BODY MASS INDEX:RATIO^LN||22.2|kg/m2|18.5-25.0||||F
tion OBX|3|NM|41982-0^BODY FAT PERCENTAGE:MFR^LN||20.0|%|10.0-20.0||||F
US
ACK 0120206121848-0-R|P|2.5
MSA|AA|20120206121848-0
Table 3. Test result of version compatibility of HL7 message
AN
Version 2.1 2.2 2.3 2.3.1 2.4 2.5 2.5.1 2.6 2.7
Trans. Message 200 200 200 200 200 - 200 200 200
Error 0 0 0 0 0 - 0 0 0
Error Ratio 0% 0% 0% 0% 0% - 0% 0% 0%
Table 4 shows an example of converting an ORU^R01 message from version V2.5 to

anolder version (V2.3.1) and a newer version (V2.7) by using the developed HL7
message parser. Based on the results of converting the ORU^R01 (V2.5) message to V2.7
DM
and V2.3.1, it was confirmed that a new message is created by applying the component
rule for each version. However, in the case of PID, RFID-tag ID, which is expressed in 8
bytes in the original message, was written in 22 characters, because the RFID-tag ID was
expressed along with ":". During the process of converting the original message to V2.3.1
and V2.7, “61:A2:02:07:00:01:04:E0” was modified to “61:A2:02:07:00:01:04” based on
the limitation of the PID-4 component length because the maximum length of the PID-4
(Alternate Patient ID) is limited to “≤20”. Therefore, it was verified that the PID-4 data
of the original message had to be modified to less than or equal to 20 characters based on
the limitation of the PID-4 component length.
TE
Table 4. Example of ORU^R01 message translated from V2.5 to V2.3.1 and V2.7
Version ORU^R01 message

81400-0|P|2.5
PID|||61:A2:02:07:00:01:04:E0||USER
2.5
OBR||1|1|10210-3^PHYSICAL FINDINGS^LN||20120206121848|20120206121848
(original)
EP
OBX|1|NM|18833-4^BODY WEIGHT:MASS^LN||64.5|kg|0-120||||F
OBX|2|NM|39156-5^BODY MASS INDEX:RATIO^LN||22.2|kg/m2|18.5-25.0||||F
OBX|3|NM|41982-0^BODY FAT PERCENTAGE:MFR^LN||20.0|%|10.0-20.0||||F
81400-0|P|2.3.1
2.3.1 PID|||61:A2:02:07:00:01:04||USER
OBR||1|1|10210-3^PHYSICAL FINDINGS^LN||20120206121848|20120206121848
C
13
AC
T
IP
CR
Hoang et al.

MSH|^~\&|Gateway|BIT|SeniCare|MIPTH|20120209181400||ORU^R01ORU_R01|2012020918
1400-0|P|2.7
PID|||61:A2:02:07:00:01:04||USER
2.7 OBR||1|1|10210-3^PHYSICAL FINDINGS^LN||20120206121848|20120206121848
US
5. Conclusion
In this study, an HL7 message parser that supports version compatibility was designed
AN
based on the object-oriented design. Based on the design, several thousand class files
need to be created. By creating these files automatically, a method of quickly
implementing the HL7 message parser was proposed. By using the proposed method, a
parser was implemented that can convert HL7 messages between eight different versions.
Additionally, the usefulness of the developed HL7 parser was verified through an HL7
version compatibility experiment by using data exchanged between healthcare devices. It
needs to be conducted to test on parsing all kinds of HL7 messages and converting
between all versions of the messages in order to verity the usefulness of the developed
DM
HL7 parser completely. However, we remain it for next study because it takes long time
to finish the test perfectly.
To apply the developed HL7 parser to healthcare information systems, further study
is needed on the implementation of a method to enable the system developer to input and
output effectively data stored in the objects by using the library. Additionally, a study is
needed to develop a method for implementing an HL7 parser that can incorporate the
characteristics of messages or components (e.g., outputting the set version of the message
from the MSH segment) that are difficult to implement in a batch by using the template
according to the segment or component.
TE
Acknowledgments
This research was supported by Basic Science Research Program through the National
Research Foundation of Korea (NRF) funded by the Ministry of Science, ICT & Future
Planning (2017R1A2B4009410).
EP
References
1. HL7, Health Level Seven (2019), http://www.hl7.org.

2. Health Level Seven Inc.,HL7 Messaging Standard V2.5: An Application Protocol for
Electronic Data Exchange in Healthcare Environments, (2003).
C
14
AC
T
IP
CR
3. H.S. Kim, H. Cho, and I.K. Lee, The Development of a Graphical User Interface Engine for the
Convenient Use of the HL7 Version 2.x Interface Engine, Healthcare informatics research,
17(4) (2011) 214–223.
4. S.M. Lee, J.T. Song, I.K. Kim, H. Cho, and Y.S. Kwak, The Design of the HL7 V2.4 Message
Interface Engine, inProceedings KISC 2003 Autumn Annual Conference, 2003, pp. 781-783,
2003.
5. The Open Source HL7 API for Java –HAPI (2019), https://hapifhir.github.io/hapi-hl7v2.
US
6. H.S. Park, H.S. Kim, and H. Cho, Development of Compatible Health Level 7 Parser,
Journalof the Korea Academia-Industrial cooperation Society, 15(7) (2014) 4290-4300.
7. I.K. Lee, and D. Hwang, Design of a Version-Compatible HL7 Parser, in Proceedings of the
29th Annual Conference on Human and Cognitive Language Technology, 2017, pp. 201-202.
8. I.K. Lee, and D. Hwang, Development of a Version-Compatible HL7 Parser, in Proceedings of
the 30th Annual Conference on Human and Cognitive Language Technology, 2018.
9. I.K. Lee, H.S. Kim, and H. Cho, Development of an Ubiquitous Healthcare System based on
Health Information Exchange Standards, Journal of Korean Institute of Intelligent Systems,
AN
22(3)(2012) 273-280.
DM
TE
EP
C
15
AC

Accepted Manuscript Vietnam Journal of Computer Science

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Accepted Manuscript Vietnam Journal of Computer Science

Uploaded by

Copyright:

Available Formats

Accepted manuscript to appear in VJCS

Article Title: Version-Compatible HL7 Parser Based on Object-Oriented Design

Author(s): Dinh Tuyen Hoang, In Keun Lee, Dosam Hwang

Received: 29 April 2019

Accepted: 26 July 2019

Link to final version: https://doi.org/10.1142/S2196888819500258

Version-Compatible HL7 Parser Based on Object-Oriented Design

Dinh Tuyen Hoanga,c

Dong Hoi, Vietnam

Received (Day Month Year)

usefulness of the developed parser was verified.

Keywords:Health Level Seven; Object-Oriented Design; Version Compatibility.

∗Contact dosam hwang. email: dosamhwang@gmail.com

As a result of efforts to computerize healthcare information, diverse healthcare

each healthcare institution, various transmission standards for healthcare information,

interoperability between diverse versions (V2.1 through V2.8). However, existing

definition2. Existing studies6,7 have proposed, from an object-oriented perspective, a

of object-oriented design. Furthermore, in implementing this parser, a method was

2. Design of a version-compatible HL7 parser

The composition of segments inside an HL7 V2 message and the composition of

The structure of the studies6-8 is based on the concept of inheritance in object-

Fig. 1. OOD-based structure of HL7 V2 parser

2.1. Design of a class diagram

To design the structure of a version-compatible parser, the concept of inheritance in

Fig. 2. Enhanced OOD-based conceptual structure of HL7 V2 parser

V24.ADT_A01 adt_a01; V25.ADT_A01 adt_a01;

V24.MSH msh = adt_a01.getMSH(); V25.MSH msh = adt_a01.getMSH();

Fig. 3. Examples of code based on different versions of library

However, in this study, conceptual classes, such as "common.MSH" in Fig. 2, which

even if the library is modified by the addition of future versions.

2.2. Decoding and encoding procedure

forwarded to the instance of the "V24.MSH" class to be processed according to the

Fig. 5. Decoding procedure of an HL7 message

Fig. 6. Method diagram for decoding of an HL7 message

If attempting to create an HL7 message of a new version in a bottom-up manner, the

Fig. 7. Encoding procedure of an HL7 message for backward compatibility

compatibility by using the structure of the parser designed to support backward

Fig. 9. Encoding procedure of an HL7 message for forward compatibility

As a result of integrating the above procedures, the process of converting an HL7

3. Development tool for HL7 parser

Table 1. Class amounts to compose the proposed HL7 parser

Message 39 74 237 173 178 202 201 216 192 1,512

(a) Diagram of Class File Maker

(b) HL7 Database (c) Class Code Template

4. Version compatibility test

Table 2. HL7 ORU-R01 messages for transmission of bio-information

blood OBR||1|1|29274-8^VITAL SIGNS^LN||20120209181400|20120209181400

Table 3. Test result of version compatibility of HL7 message

Table 4 shows an example of converting an ORU^R01 message from version V2.5 to

Version ORU^R01 message

OBX|2|NM|39156-5^BODY MASS INDEX:RATIO^LN||22.2|kg/m2|18.5-25.0||||F

OBX|3|NM|41982-0^BODY FAT PERCENTAGE:MFR^LN||20.0|%|10.0-20.0||||F

1. HL7, Health Level Seven (2019), http://www.hl7.org.

You might also like