Embed Size (px)
Citation preview
HEALTH LEVEL SEVEN COMPLIANCE AND
CLINICAL DECISION SUPPORT SYSTEM FOR AN
INTENSIVE CARE UNIT
DISSERTATION
SUBMITTED IN PARTIAL FULLFILMENT OF THE REQUIREMENTS
FOR THE DEGREE OF
MASTER OF TECHNOLOGY IN INFORMATION
TECHNOLOGY
(SPECIALIZATION IN SOFTWARE ENGINNERING)
Under the Supervision of Dr. Sudip Sanyal Associate Professor
IIIT-Allahabad
Submitted by Mohd. Imran Khan
MS200510 M.Tech. IT (Software Engineering)
IIIT-Allahabad
INDIAN INSTITUTE OF INFORMATION TECHNOLOGY – ALLAHABAD
(DEEMED UNIVERSITY)
DEOGHAT, JHALWA
ALLAHABAD- 211011, (U.P.)
INDIA
INDIAN INSTITUTE OF INFORMATION TECHNOLOGY ALLAHABAD
(Deemed University)
(A centre of excellence in IT, established by Ministry of HRD, Govt. of India)
Date:
We do hereby recommend that the thesis work prepared under
my/our supervision by Mohd. Imran Khan entitled “Health
Level Seven Compliance and Clinical Decision Support
System for an Intensive Care Unit” be accepted in partial
fulfilment of the requirements of the degree of Master of
Technology in Information Technology (Software
Engineering) for examination.
COUNTERSIGNED
Dr. Sudip Sanyal ______________________________ THESIS ADVISER
Dr. U. S. Tiwary DEAN (ACADEMICS)
INDIAN INSTITUTE OF INFORMATION TECHNOLOGY ALLAHABAD
(Deemed University)
(A centre of excellence in IT, established by Ministry of HRD, Govt. of India)
CERTIFICATE OF APPROVAL*
The foregoing thesis is hereby approved as a creditable
study in the area of Information Technology carried out
and presented in a manner satisfactory to warrant its
acceptance as a pre-requisite to the degree for which it has
been submitted. It is understood that by this approval the
undersigned do not necessarily endorse or approve any
statement made, opinion expressed or conclusion drawn
therein but approve the thesis only for the purpose for
which it is submitted.
COMMITTEE ON
FINAL EXAMINATION
FOR EVALUATION
OF THE THESIS
*Only in case the recommendation is concurred in
i
Acknowledgements
I start this dissertation in the name of God, Who is most gracious and most
merciful.
This thesis enriches me in various facets- my qualification, technical exposure,
knowledge of healthcare domain and personal experience. There are so many kind
souls responsible for its completion and I am grateful to all of them.
“Guru Govind dou khade, kaake lagoon paye
Balihari guru aapki, Govind diyo milaye.”
The verses said by Kabir, represents my true feelings for my thesis guide Dr.
Sudip Sanyal. He has proved an oracle for me over a period of more than this thesis
discourse. My meetings with him were aimed most of the times in getting the deep
insight and novel solutions from his plethoric knowledge. But some of the times they
had a purpose of even reviving my enthusiasm. I am grateful to him for giving me his
precious time and invaluable guidance.
I owe indebted to my senior Mr. R. Amirdha Gopal for his ever helping nature,
without which I would not have been able to extend his thesis. He not only introduced
me to the system but went ahead to explain each and every nut-bolt of his project. His
work has always been an aspiration for me. I always wonder-“how can a single
person draft such a huge application in so small time in such a managed and
beautiful way???”
I am thankful to Dr. Prithwis Bhattacharya, the ICU Director of Sir Sunderlal
Hospital, Banaras Hindu University, Varanasi, who gave me an opportunity to work
for a live project of his organization. He explained the whole workflow of his hospital
and showed us the major drawbacks of the previous system, which ultimately became
the basis of my thesis. Despite his busy schedule, he has always promptly answered to
my problems.
ii
This thesis work has always been a source of happiness and enjoyment to me and
has never proved as a burden or conundrum. There are two reasons behind this-
availability of resources and freedom of work. I am obliged to the honorable Director
of IIIT-Allahabad, Prof. M. D. Tiwari for providing resources especially the Internet
and library in such abundance. My heartfelt thanks to the Dean (Academics), Dr. U.S.
Tiwary and other IIIT-A administration, for inculcating a culture where you can work
any time.
I would like to express my gratitude towards few organizations whose help is
indispensable for this thesis. I am thankful to the Health Level Seven Organization
for making its specification version 2.3.1 freely available for use. I am equally
grateful to the Free and Open Source communities especially Java, MySQL,
JFreeChart, JDOM and JSci for making it possible to provide cost effective solution
for this project.
The thesis is actually the real world implementation of the concepts we learnt in
the M.Tech first year curriculum. I sincerely feel grateful to all my teachers who
taught me these concepts. My special thanks to Dr. Ratna Sanyal who not only
taught me, but also helped me in various difficult situations and that too beyond the
scope of a teacher.
I appreciate the love and care rendered by my friends which proved to be a source
of enthusiasm for the completion of this project. I’ve found my friend Mr. Anand
Arun Atre beside me during all the tough times. His support and presence is always
precious to me.
My respected parents have always inspired me, encouraged me and I feel obliged
to them for providing me with everything.
In all, I am thankful to all IIIT-A family who helped me from time to time for
something or the other.
Mohd. Imran Khan
25 June, 2007
iii
DECLARATION
This is to certify that this thesis work entitled “Health Level Seven Compliance
and Clinical Decision Support System for an Intensive Care Unit”’ which is
submitted by me in partial fulfillment of the requirement for the completion of
M.Tech in Information Technology specialization in Software Engineering to Indian
Institute Of Information Technology, Allahabad comprises only my original work and
due acknowledgements has been made in the text to all other materials used.
Name : Mohd. Imram Khan
M.Tech.-IT: Software Engineering
Enrolment No: MS200510
iv
MISSION
To organize the medical Information and to mine knowledge from it,
to assist the doctors to save lives.
OBJECTIVES
To comply an Information System for Intensive Care Unit with Health Level Seven
Standard and developing architecture for the same, which is robust enough to
accommodate frequent changes and improvements in the HL7 Standard.
AND
To develop a Clinical Decision Support System for the ICU.
v
Abstract
The position of healthcare industry in India is poor in terms of – adoption of IT
infrastructure, and capability to harness its benefits. Both these factors entangle to
form a catch-22 situation. The fundamental problem lies with either getting
insufficient advantages or arousal of new loop holes in the IT solutions.
An important point to be realized is that automation does not mean simply the
translation of manual process. Rather, automation should provide efficient processing,
removing previous bottlenecks and safeguarding against prospective limitations and
constraints. But most of the times, automation simply mimics the manual process.
Another important fact, though said in different context, but well applied to IT is the
saying-“The art of communication is the language of leadership”. A stand-alone
information system is of no use. They should be interactive. But exchanging
information among health care information systems is a challenge. The reasons being
Health care systems are multidisciplinary in nature. The information systems
developed are too different amongst each other for obvious reasons. This problem had
been realized by some revolutionist back in 1987. They came up with a standard
known as Health Level Seven.
There is one more drawback of information systems. Though they provide a
mechanism to store and retrieve data efficiently, seldom do they provide the facility to
analyze, mine and assess the data. So their attribute of huge data storage go all waste.
Ideally, there should be mechanisms which may enable the managers to take better
decisions.
The above two factors are the basis of this thesis. In essence, they can be
summarized as- development of ‘communicative and interactive information
systems’; and ‘decision support facility’ of information systems.
This project is exclusively developed for Sir Sunderlal Hospital, Banaras Hindu
University, Varanasi. A previously developed Information System, "SANJEEVANI"
is now evolved to a communicative system renamed as "HL7 Compliant
vi
SANJEEVANI" by complying it with the HL7 standard. A clinical decision support
system, "ANAVESHAK" is also developed. It is an application to retrieve desired
information from the ICU database and to perform statistical and graphical analysis so
as to provide better care to the patients.
Keywords: Intensive Care Unit, Health Level Seven, Information System, Clinical
Decision Support System, Healthcare Environments.
vii
Table of Contents
ACKNOWLEDGEMENTS ........................................................................................ I
DECLARATION....................................................................................................... III
MISSION ................................................................................................................... IV
OBJECTIVES ........................................................................................................... IV
ABSTRACT.................................................................................................................V
TABLE OF CONTENTS ........................................................................................VII
LIST OF TABLES ......................................................................................................X
LIST OF FIGURES .................................................................................................. XI
INTRODUCTION ..................................................................................................1
1.1 Background ......................................................................................................3
1.2 Current Scenario..............................................................................................3
1.3 Drawbacks in the Current Scenario...............................................................6
1.4 The Proposed Solution Overview ...................................................................7
1.5 Benefits of the Proposed System.....................................................................8
1.6 System Development Phases .........................................................................10
1.7 System Development Schedule......................................................................11
1.8 Development Environment ...........................................................................11
1.9 List of Functionalities ....................................................................................14
1.10 Non-Functional Requirements......................................................................15
1.11 Chapter Summary .........................................................................................15
viii
LITERATURE SURVEY ..................................................................................16
2.1 Search for the Mechanism.............................................................................17
2.2 The Importance of HL7.................................................................................17
2.3 Study of HL7 ..................................................................................................20
2.4 Study of Decision Support Systems..............................................................26
2.5 Chapter Summary .........................................................................................30
SYSTEM DESIGN ...............................................................................................32
3.1 Architecture of the Proposed Solution.........................................................32
3.2 Architecture of ‘Phase I- Solution to the Communicative Information System’............................................................................................................33
3.3 Architecture of ‘Phase 2- Solution to the Decision Support System’........38
3.4 Process Flow Diagrams of ‘Phase I- Solution to the Communicative Information System’ ......................................................................................40
3.5 Process Flow Diagrams of ‘Phase II- Solution to the Decision Support System’............................................................................................................44
3.6 Chapter Summary .........................................................................................47
NOVEL FEATURES OF THE PROPOSED SOLUTION....................48
4.1 HL7 Specification stored in database (Maintainability) ............................49
4.2 Compressed Syntax Generation (Efficiency)...............................................55
4.3 Use of Configuration Files and Plug-n-Play Architecture (Flexibility and Reusability).....................................................................................................59
4.4 Chapter Summary .........................................................................................64
RESULTS AND OUTPUTS..............................................................................66
5.1 Results of the Application of Novel Techniques..........................................66
5.2 Some Outputs of the Major Functionalities ................................................70
CONCLUSION AND FUTURE ENHANCEMENTS .............................80
6.1 Conclusion ......................................................................................................80
ix
6.2 Future Enhancements....................................................................................82
APPENDIX-A: INSTALLATION GUIDE.........................................................86
APPENDIX-B: VIEWS USED BY ANAVESHAK............................................90
APPENDIX-C: LIST OF HL7 MESSAGE COMPONENTS USED BY HL7 COMPLIANT SANJEEVANI ......................................................................94
REFERENCES.....................................................................................................106
x
List of Tables
Table 1.1. Project Development Schedule................................................................12
Table 2.1. Consolidated Health Informatics Domains and standards. .................18
Table 2.2. Some of the Countries having HL7 Branch Offices..............................19
Table 2.3 HL7 and Market Relevance .....................................................................19
Table 2.4. HL7 Evolution ..........................................................................................20
Table 2.5. Examples of HL7 Events. ........................................................................22
Table 2.6. Examples of Message Types. ...................................................................23
Table 2.7. Examples of Segments..............................................................................23
Table 2.8. Examples of fields.....................................................................................24
Table 2.9. Classification of HL7 data types along with few examples. ................24
Table 2.10. An instance of HL7 Message for the event A02 – “Patient Transfer”
..............................................................................................................................25
Table 2.11. The number of events under each classification of HL7 event. .........27
Table 2.12. Number of various components in HL7 v2.3.1. ...................................27
Table 4.1. Marital Status ...........................................................................................52
Table 4.2. Format of datatype- Extended Person Name (XPN) ............................54
Table 4.3. Number of queries required to generate syntax of a typical HL7
Message ...............................................................................................................56
Table 5.1. Number of queries required to modify, add or delete an HL7 Message
Component..........................................................................................................67
Table 5.2. Average response time for the successive processing of HL7 messages.
..............................................................................................................................70
Table B.1. Details of ICU Views used by ANAVESHAK.......................................90
Table C.1. HL7 Messages (along with their segments) used by SANJEEVANI ..94
Table C.2. HL7 Segments along with their fields....................................................96
Table C.3. Classification and components of HL7 Datatypes..............................102
xi
List of Figures Figure 1.1. Healthcare departments, related external systems, and the structure
of information exchange. .....................................................................................5
Figure 1.2. System Overview.......................................................................................9
Figure 1.3. Project Development Schedule in Gantt chart.....................................13
Figure 2.1. The usage of different HL7 versions currently running in the
healthcare industry [NeoTool]. .........................................................................21
Figure 2.2. The composition of HL7 Message into segments, fields, and
components. ........................................................................................................23
Figure 2.3. Classification of Health care Information Systems. ............................28
Figure 2.4. General Architecture of a Case Based Reasoning Systems ................30
Figure 3.1. System Overview.....................................................................................33
Figure 3.2. Phase I- Modular Architecture as a Layered Model...........................34
Figure 3.3. Phase I- Modular Architecture as Package Dependency Diagram....38
Figure 3.4. Phase II- Modular Architecture as Package Dependency Diagram ..39
Figure 3.5. HL7 Compliant ICU Information System as a Sender. ......................41
Figure 3.6. Process Flow Diagram for the HL7 Compliant ICU- Information
System as a Receiver of Messages.....................................................................42
Figure 3.7. Process Flow Diagram for the Clinical Decision Support System .....45
Figure 3.8. Sequence Diagram for the Query Composition Process .....................46
Figure 4.1. The Entity-Relationship-Diagram for the HL7 Specification ............51
Figure 4.2. HL7 Database Schema Design...............................................................52
Figure 4.3. The details of tables ‘EventDescription’, ‘SegmentDescription’ and
‘EventSegment’ and their relationships...........................................................53
Figure 4.4. The application of Composite Pattern to the problem of....................55
‘Convoluted datatype structure’ ..............................................................................55
Figure 4.5. Application of Flyweight Pattern to produce compressed syntax......58
Figure 4.6. Concept of Flyweight Pattern................................................................58
xii
Figure 4.7. Table Design for mapping HL7 fields to the operational database. ..60
Figure 4.8. System Architecture as Plug-n-Play Model..........................................61
Figure 4.9. Excerpts from configurations files. .......................................................62
Figure 4.10. The integration of decision support application with two
departmental databases to produce corresponding DSS. ..............................63
Figure 4.11. An excerpt from XML property file. ..................................................64
Figure 5.1a. Sample Message for Event ‘A02- Patient Transfer’ taken from HL7
specification v2.3.1. ............................................................................................69
Figure 5.1b. Compressed Syntax for the event ‘A02- Patient Transfer’ ..............69
Figure 5.2a. Message Sending Capability of the ICU Information System..........72
Figure 5.2b. Message Receiving Capability of the ICU Information System.......72
Figure 5.2c. Full screen view of the received message. ...........................................73
Figure 5.3a. Querying Capability of SANJEEVANI – Query Sending Interface.
..............................................................................................................................74
Figure 5.3b. Querying Capability of SANJEEVANI – Query Response Interface.
..............................................................................................................................74
Figure 5.4. Receiving Applications Management Capability- Administrator’s
Managing Interface............................................................................................75
Figure 5.5a. ‘Query Browser’- An interface providing drag-n-drop option for
composing queries. .............................................................................................76
Figure 5.5b. ‘Filter Dialog Box’- an interface to specify filter attribute...............77
Figure 5.5c. Query Result Interface. ........................................................................77
Figure 5.6a. Special Interface to quickly view observations. .................................78
Figure 5.6b. Analysis of observations ‘BP Systolic’ vs ‘BP Diastolic’ using XY-
Graphs.................................................................................................................79
Chapter 1
Introduction
The healthcare Industry is growing significantly as the surveys show for the
developing countries and it consumes 10 percent of gross domestic product [Kaiser-
06]. Information is a vital part of any industry, but it becomes an indispensable need
for the healthcare industry as it is directly related to human lives. An effective
management of this information is one of the key objectives satisfying the mission of
any healthcare industry. When the issue is of ‘information management’ then
Information Technology (IT) is the only benefactor. Though healthcare enterprises
have started reaping benefits of this technology, yet a lot is left to adopt and adept
related to this science.
IT has become a ubiquitous fruit found on all the branches of the growing tree of
science. It can facilitate any industry through myriad directions. Some of the ways in
which it can help a healthcare environment are: Information Management,
Information Dispersal and Decision Support. This thesis, as a partial requirement
for the fulfillment of M. Tech in Software Engineering, is an endeavour to facilitate
an Intensive Care Unit (ICU) in its information dispersal and decision support. The
information management has already been accomplished by an earlier thesis.
This chapter introduces the purpose of the whole dissertation. It starts by making
obvious the reason behind how the project was initiated and why the ICU needed the
information system at the first place. The information system came up to its
expectations but some newer problems arose. Hence the chapter brings out the current
scenario and the reformations still required. Major problems are identified next
Introduction
2
followed by an overview of the proposed solution. How the solution will solve the
current problems is covered next. The system development phases and schedule is
presented next with the help of a table and Gantt chart. Development environment
gives a detail of the system requirements. At last, a precise list of functional and non-
functional requirements is given.
Chapter 2 explores the work done in the concerned field. Various Medicare
standards are listed with a comparative study of them. Health Level Seven proved to
be the most apt standard. The standard’s importance is shown because of which it was
chosen to provide the solution. The standard is introduced first and then dealt in
detail. Chapter 2 also gives an overview of various types of decision support systems.
Chapter 3 presents the various architectural views of the proposed system.
Package dependency view, Layered view, process flow diagrams and sequence
diagrams explains the various perspectives of the system.
Apart from functional requirements, the product provides various non-functional
requirements. Techniques applied to equip the product with non-functional
requirements like maintainability, efficiency, flexibility and reusability are covered in
Chapter 4. The chapter brings out the rationale for using each technique.
Chapter 5 verifies the design and novel techniques by showing the system
outputs. Results show the effort required to modify the standard’s specification and
the system running time. Major functionalities are also shown through screenshots of
the system.
Chapter 6 concludes the dissertation and brings out the achievements and worth
of the solution. It also discusses about the road ahead and future enhancements.
Appendices provide the Installation Guide, views used by the decision support
system and list of the HL7 components used by the information system. These
appendices would be helpful to those who want to configure and maintain the system.
At last, a list of all references is attached in an alphabetical order.
Introduction
3
1.1 Background
The ICU is the specialized unit of a hospital for patients who require special
medical care. During the patient stay at ICU, his health condition and other vital
details are continuously monitored. Outputs, ventilation details, target status,
investigation reports, culture sensitivity reports, doctor and nurse summary, adverse
events, risk assessment and scoring are tracked carefully.
Earlier, these readings were recorded in the charts. For each patient, a new chart
was filled everyday. But the information management in that system was quite messy.
The charts, despite of being large in size, used to become a limitation in storing
enough information. While on the other hand, it was difficult to manage such large
sized charts. Of course the modification and retrieval of information from those charts
was cumbersome.
The obvious solution to the problem was an ‘Information System’. The
information system was developed in an earlier thesis- “Information System for
Assessment of Functioning of Intensive Care Unit and Rule Extraction with ID3
Algorithm” [Gopal-06].
1.2 Current Scenario
The adage “Necessity is the mother of invention” holds true here as well. The
Information System named ‘SANJEEVANI’ was successful in eliminating the
targeted problems and proved a boon for the ICU. But with the deployment of the
system, some newer problems were recognized in a larger sphere of scope than the
newly developed system. The problems, which became the basis for this thesis, can be
broadly stated as below.
i. There was a need for the developed system to be able to interact with other
information systems of the hospital. ii. There was a need for a decision support system.
Introduction
4
A typical modern hospital is much like an enterprise. It comprises of a number of
information systems varying with the size of the healthcare environment. One of the
most important features of any enterprise is its ability to raise, customize or cease one
or more departments (or in the context of IT- an information system). Another
consequential characteristic of such an enterprise is its ability to communicate among
all information systems. The IT driven world today is heading towards these two
goals with leaps and bounds to invent technologies fulfilling these requirements;
Workflow Architectures and Service Oriented Architectures being the prominent
ones.
Figure 1.1 depicts few of the departments of a healthcare environment, its related
external systems and the need of information exchange among them. The real
information exchange takes place according to the business logics of a particular
system, but at the most, all the departments may require information from any other
department.
For the case of our ICU, the information system developed was a standalone
system. Hence to transfer information to this system from other information systems
was interleaved by manual processes, which proved to be a bottleneck in the entire
workflow. To make that situation more obvious, some examples are presented below.
Example 1.1. The patient arrives at the ICU either directly after registration (in case
of critical situations) or from another department (when the case deteriorates). In both
the cases, the patient’s information is required at the ICU. This information was
carried by the patient himself through reports, forms and receipts despite of being
present at the other departments’ information system. This workflow had two major
drawbacks. Firstly the patient’s information was typed again by an operator into the
ICU information system. This process itself was error prone and time consuming.
Secondly, the ICU had to haste all the arrangements on the arrival of the patient.
Although the patient was referred to the ICU much before, yet there was no way to
send an alert to the ICU.
Introduction
5
Figure 1.1. Healthcare departments, related external systems, and the structure
of information exchange.
Example 1.2. Apart from the patient’s information, the ICU staff may require other
information from different departments. A doctor might need to inquire the Pharmacy
for a certain drug before prescribing it to a patient. Or a consultant sitting in ICU
might want to know the investigation reports of one or more patients from the
Pathology. The new system was not developed to fulfill such requirements.
The above examples were just very few of the umpteen scenarios which heavily
demand information systems to communicate among themselves.
An important direction through which industries are deriving strategic advantages
by adopting IT infrastructure is the IT based decision support. The data is the actual
‘experience’ of an organization. Planning and decisions, if based on this experience
are more likely to produce good ‘judgments’.
Exchange of Information
Labs
Insurance Companies
Clinics
Hospitals
Medical Devices
Other Systems Pathology
Radiology
Electronic Medical Records
Pharmacy
External Health Care
Internal Health Care
Introduction
6
For our ICU, a decision support system was the need of the hour. Like any other
department, the ICU also performs analysis, plans and predicts; like managerial
decisions, diagnostic predictions, and case study analysis. Here again, few examples
will make the picture more clear.
Example 1.3. The ICU management might want to assess the performance of a nurse.
So they require all the adverse event entries registered against that nurse, or perhaps
the number of patients who expired during her duty hours.
Example 1.4. The residents and doctors taking care for the ICU patients might get
interested in knowing about past cases similar to some present case in the ICU. The
diagnostic procedures and their outcomes may prove really helpful to them.
Example 1.5. Medical students and junior doctors may want to extract some specific
case studies or just few attribute values in order to compare, collate and draw some
new trends.
It should be noted again that these examples are just few instances of a much
larger set which proves a genuine need for a decision support by the ICU. The
problems can be precisely summarized as below.
1.3 Drawbacks in the Current Scenario
1. There was no means by which the ICU comes to know that a patient has been
referred to the ICU. It was only when the patient or some kin reported there. In
such cases, the arrangements had to be made in haste. The situation used to get
worse when some critical case arrived.
2. Consequent to this problem was another bottleneck. For admission in ICU, the
general patient’s information was needed to be fed in the information system
which had already been fed at either registration counter or some other
department. The patients needed to carry all the prior documents and receipts.
Introduction
7
3. Some times a patient needs to be admitted in ICU directly. In such cases, it may
be required to inform other departments. Again a manual process was required
for this information flow.
4. Similar problems persisted when the patient was discharged. Other systems like
Billing Department were ignorant of this event.
5. Another important need was to access the information of other departments and
let other departments access the ICU information.
6. The ICU information system produces only few reports centered on the
patients. The database in spite of having data in bulk was useless from analysis
and prediction point of view.
7. There was no way to extract and analyze the data from the database based on
the user’s choice.
In essence, all the problems were basically due to the lack of e-communication
between various departments. The requirement of decision support is a very genuine
and intrinsic need of any management.
1.4 The Proposed Solution Overview
The solution to the problem was indeed obvious but challenging. For the problem
of ‘communicative information systems’, the solution was to upgrade the existing
system by adding a communicative module to it. But the underlying challenges
involved can be realized from the following points.
1. The number of information systems in the hospital was not fixed. The hospital
may raise, modify or cease one or more information systems.
2. The information systems in the hospital were quite disparate. To develop a
module which can communicate with some information systems in such a way
that messages sent and received are understandable by both the sender and
receiver would be infeasible and extremely tightly coupled. Moreover to
analyze all the systems is beyond the scope of even a small team of developers.
Introduction
8
In essence, the communicative module should be independent of any other
system. Thus, the need of a standard was realized. It was found that a standard named
Health Level Seven (HL7) exists which serve the required purpose [HL7-99]. The
details of HL7 are provided in chapter 2- Literature Survey. For the introductory
purpose, HL7 can be understood as a standard which defines standard messages
pertinent to each and every event that is likely to happen in a healthcare environment.
In other words, two HL7 compliant information systems can easily exchange
information among themselves by sending and receiving one or more messages of the
standard. Hence the final solution was to comply the ICU information system with
HL7 standard.
The solution to the second part of the problem – “Provision of Decision Support”
was more of a decisive problem itself. Decision support systems have a number of
classifications based on different parameters, which is discussed in details in chapter
2- Literature Survey. On one scale, there may be active, passive or cooperative
decision support systems, while on the other they may vary from elementary data
extractive tools to Case Based Reasoning Systems (CBRS) to Expert System. Each
type has its own degree of analysis and predictive potential which is directly
proportional to the cost (time, money and other resources) of such systems. After
feasibility analysis, it was decided to provide the ICU with the decision support in an
incremental fashion. As for inception, an elementary clinical decision support system
was decided which could provide an easy data extraction, statistical and graphical
analysis facilities.
The whole system along with its peer systems can be viewed as in the Figure 1.2.
1.5 Benefits of the Proposed System
The compliance of ICU information system to the HL7 standard caters following
benefits to the system.
1. The ICU is now connected to the whole hospital.
Introduction
9
2. It can now receive alerts of patient arrival to the ICU before hand so that the
arrangements can be managed properly.
3. It can notify other departments about the direct admission of patients to the ICU
as well as about the patient discharge.
Figure 1.2. System Overview. (Red arrows show data flow.)
4. The ICU staff can now query other information systems of the hospital and
receive appropriate information.
5. Conversely, the ICU information is accessible to other systems.
6. Departments or otherwise information systems can be easily managed by the
administrator of the information system. New departments can be added while
obsolete ones can be modified or deleted.
7. The mapping of messages and their corresponding receivers is subjected to an
easy addition and modification.
ICU Information System ICU Database HL7 Database
Clinical Decision Support System
HL7 Messaging Server
Other HL7 Compliant Information Systems
Introduction
10
Benefits from the decision support system are as follows.
8. The whole database schema is open to the ICU management.
9. As a result, one can query the contents of the various aspects (technically
database views) of the entire ICU.
10. The information view has broadened. The information no longer remains
patient centric as was with the reports generated from the information system. It
can be pivoted on any attribute of the schema. Moreover, the information can
be viewed in a collectively manner for all the patients.
11. Even complex queries comprising of joins of various tables can be composed
and executed.
12. Statistical and graphical analysis of the retrieved information can be done.
1.6 System Development Phases
To fulfill the two aforementioned objectives, the system was developed in two
phases, Phase I and Phase II.
Phase I
As the major phase of the development, the objective was the compliance of HL7
standard. Hence the activities performed started with designing a schema for HL7
standard, implementing it in MySQL database management system and then
populating it with sufficient amount of standard’s specification. Then the application
program was designed. During application design, the important module was ‘HL7
Syntax Composer’ which abstracted the convoluted structure of HL7 standard. Other
modules were designed for message management, validation and network messaging
service. Care was taken to provide error and accept acknowledgements to the sending
applications.
Phase 2
The phase started with creating patient-centric views in order to render complete
and meaningful information. The next step was to display all the views to the user and
allow him to query in the desired fashion. Nifty user interfaces were designed which
Introduction
11
guide a user to compose a query. Statistical and graphical analysis capabilities were
provided next.
1.7 System Development Schedule
The project-cum-thesis was a one year work starting from 15 July, 2006 to 30
May, 2007. The project was divided into probable tasks and a schedule was planned.
As the only certainty in this world is uncertainty, so the actual tasks couldn’t adhere to
the schedule completely. The duration of planned and actual tasks are shown in Table
1.1 as well as in Figure 1.3.
1.8 Development Environment
Softwares Required
The softwares required for the proposed system are
1. Java 5
2. MySQL 5
3. MySQL JDBC Connector 3.1.12 and
4. JFreeChart 1.0.0
5. jsci-mathmlimpl Library
6. JDOM 1.1
All softwares are open source and freely downloaded from the appropriate web
sites (see Appendix-A Installation Guide).
Hardware Required
1. The minimum hardware required is
2. Intel or AMD Mother Board
3. Pentium III Processsor
4. 256 MB RAM
5. 20 GB HDD
6. Lan Card or Modem
Introduction
12
The preferred screen resolution is 1024 X 768.
Table 1.1. Project Development Schedule
SNo. TASK NAME PLANNED DURATION ACTUAL DURATION/S
PHASE-I
1 Study of the current
system Jul 15, 06 - Aug 15, 06 Jul 25, 06 – Aug 30, 06
2 Literature Survey and
Study of HL7 Standard Aug 15, 06 – Sep 30, 06 Aug 25, 06 – Nov 05, 06
3 Design of HL7
Specification Database Oct 1, 06 – Oct 15, 06 Oct 3, 06 – Oct 20, 06
4
Design of Rule Engine,
Sending and Receiving
Module
Oct 15, 06 – Oct 31, 06 Oct 20, 06 – Nov 30, 06
5 Identification Of Messages
Pertinent to ICU Nov 01, 06 - Nov 15, 06 Nov 01, 06 - Nov 10, 06
6
Implementation Of Rule
Engine, Sending and
Receiving Module
Nov 15, 06 – Dec 15, 06 Nov 01, 06 – Nov 30, 06
7
Design and
Implementation of User
Interfaces
Dec 15, 06 – Dec 31, 06 Dec 20, 06 – Jan 10, 07
8 Integration and Testing of
all Modules Jan 01, 07 – Jan 31, 07 Jan 10, 07 Onwards
PHASE-II
9 Requirement Gathering for
Decision Support System Feb 01, 07 – Feb 28, 07 Feb 10, 07- Feb 20, 07
10 Design Of Decision
Support System Mar 01,07 – Mar 25, 07 Feb 21, 07 – Mar 25, 07
11 Implementation Of
Decision Support System Mar 25, 07 – Apr 25, 07 Mar 25, 07 – Apr 30, 07
12 Testing Of Decision
Support System Apr 25, 07 – May 15, 07 Apr 30, 07 – May 25, 07
Introduction
13
MILESTONES JUL,2006
AUG,2006
SEP,2006
OCT,2006
NOV,2006
DEC,2006
JAN, 2007
FEB,2007
MAR,2007
APR, 2007
MAY,2007
Study of thesystem(ICU IS)
Literature Survey
Design of HL7
Spec. DB
Design of RuleEngine, Sending
and ReceivingModules
Identification ofMessages
Types pertinentto ICU
Implementationof Rule Engine,
Sending andReceiving Modules
Design andImplementation
of UserInterfaces
Integration andTesting
of all Modules
RequirementGathering For
DecisionSupport System(DSS)Design Of DSS
ImplementationOf
DSS
Testing Of DSS
Shows Planned Activity
Shows Actual Activity
Figure 1.3. Project Development Schedule in Gantt chart
Introduction
14
1.9 List of Functionalities
I. HL7 Compliant SANJEEVANI
The ICU Information System- SANJEEVANI 1.01 is now upgraded to HL7
Compliant SANJEEVANI 2.0 with added functionalities as listed below.
For all users
i. Capability to receive alerts, reports and patients’ information in the form of
HL7 messages.
ii. Capability to automatically send patients’ information in the form of HL7
messages for following ICU events: Patient Admit, Patient Transfer, and
Patient Discharge.
For privileged users
Capability to query other information systems (which may be any HL7 Compliant
System). For Administrator
i. Capability to add, delete or modify nodes of Information systems.
ii. Capability to add, delete or modify allowable queries against each system.
iii. Capability to set any number of receivers against each automatically
triggered event (Multicast).
II. ANAVESHAK
The clinical decision support system is baptized to ‘ANAVESHAK’ –the
explorer. It provide following functionalities.
i. Capability to compose and execute a query by selecting any number of
attributes from the schema, specify filters by selecting attributes and
defining ranges or values. The system returns the required response in a
presentable way.
ii. Capability to save frequently occurring important and long queries so that
one can get execute a similar query quickly.
iii. Capability to apply various statistical analyses on the resultant query
response.
iv. Capability to graphically represent the results of the query.
Introduction
15
1.10 Non-Functional Requirements
One of the goals of Software Engineering is to encourage in providing non-
functional requirements to the projects. Several measures and techniques were applied
to provide following non-functional requirements. Incorporating these features
actually makes this thesis different from other projects. Chapter 4 ‘Novel Features of
the Proposed Solution’ elaborate on the non-functional requirements.
1. Efficiency. By generating a ‘Compressed Syntax’ via using Fly Weight
Pattern.
2. Maintainability. The storage of HL7 Specification in database makes the
system highly maintainable as the frequent changes to the standard can easily
be incorporated in the database.
3. Flexibility and Reusability. Use of Configuration Files and Plug-n-Play
Architecture.
1.11 Chapter Summary
In general, the healthcare environments are suffering from problems of lack of
‘information flow’ and decision support. The ICU at Sir Sunderlal Hospital, Banaras
Hindu University, Varanasi was one such department which faced this problem even
after the development of an information system for easy storage and retrieval of
patients record. It was its inherent need to be able to give and take information with
other system. The solution proposes to comply the information system with the HL7
standard which is a standard for interactions amongst disparate healthcare information
systems. On the other hand, a decision support system is planned to be developed to
help the ICU in decision making process.
Next chapter shows the selection procedure of the HL7 standard. The standard’s
messages and their composition are described. It gives a brief of the concept of
decision support system. The essence of past and contemporary work is provided in
the chapter.
Chapter 2
Literature Survey
The solution to the problems of ICU was a ‘communicative information system’
and a ‘decision support system’. Before going for the implementation of the solution,
Literature Survey was carried over. Reviewing the past and contemporary work of the
same area is an utmost important task for a project.
The Literature Survey for this project started from analyzing the objectives of a
healthcare environment so as to better align our objectives with them. Key healthcare
organization’s objectives include (but not restricted to these only):
1. Better quality of care
2. Improved patient outcomes
3. Increased productivity and workflow efficiency
4. Better information at the point of care
5. Improved and integrated communications
6. Privacy and protection of patient information
The points in bold font actually come under the responsibility of the IT department.
Our solution of “Decision support system” is a step towards better productivity and
efficiency (that is point 3). The solution to “Communicative information systems”
caters to the point 5, while the information system was developed on the first hand to
fulfill the objective stated as point 6.
To meet these objectives, the goals of Literature Survey can be stated as below.
1. To search for a mechanism, which makes communicative information
systems.
2. To probe the importance and worth of that mechanism in the current scenario.
Literature Survey
17
3. To learn and understand the mechanism thoroughly so as to make use of it.
4. To study the architectures, designs and algorithms used of a decision support
system.
These explorations are summarized under following heads.
2.1 Search for the Mechanism
The first objective of the project was to make the ICU information system
communicative. As stated earlier, this was even more challenging because there was
no information available about other information systems. The only solution left was
to adopt some standard. Open Electronic Healthcare Record (EHR), European
Standard EN 13606 EHRcom, Health Level Seven (HL7), Digital Imaging and
Communications in Medicine (DICOM), Integrating the Healthcare Enterprise (IHE)
are some of the standards that structure clinical contents for the purpose of
information exchange [Aden-05]. United States Department of Health and Human
Services instigated an initiative named as Consolidated Health Informatics (CHI)
which has recognized the most relevant standard for various sub-domains of
healthcare industry. Table 2.1 shows some domains and the pertinent standards. As
the table shows, HL7 seemed to be the most pertinent and complete solution for our
information exchange problem.
2.2 The Importance of HL7
It may be argued that for many standards, which no sooner they conceive than they
die their own deaths. Many research papers, scientific magazines, news papers,
market surveys are in favor of HL7. The facts in favor of HL7 are listed below.
1. HL7 is an ANSI accredited standard.
2. HL7 is endorsed by Health Insurance Portability and Accountability Act of
United States (HIPAA) as one of the important healthcare standard.
3. The standard is widely used in many countries and consists of branch offices
in countries some of which are shown in Table 2.2.
Literature Survey
18
Table 2.1. Consolidated Health Informatics Domains and standards.
DOMAIN ADOPTED STANDARD
Laboratory Results Names Logical Observation Identifiers Names and
Codes (LOINC)
Messaging Standards: General Health Level Seven (HL7)
Messaging Standards: Retail Pharmacy National Council for Prescription Drug
Programs (NCPDP) SCRIPT Transactions
Messaging Standards: Connectivity IEEE 1073
Messaging Standards: Image information to
workstations
Digital Imaging and Communications In
Medicine (DICOM)
Medications Federal Drug Standards
Interventions/Procedures: Lab Test Order
Names LOINC
Interventions/Procedures: Non-Laboratory Systematized Nomenclature of Medicine,
Clinical Terms (SNOMED CT)
Demographics HL7
Immunizations HL7
Lab Results Contents SNOMED CT
Units HL7
Anatomy SNOMED CT for Anatomy
Diagnosis/Problem Lists SNOMED CT
Nursing SNOMED CT
Financial/Payment
Health Insurance Portability and
Accountability Act of United States (HIPAA)
Approved Code Sets and Transactions
Clinical Encounters HL7
Text-Based Reports HL7
4. A survey of various EHR standards shows a significant market relevancy of
the HL7 standard [Aden-05]. Table 2.3 shows the market relevancy of the
HL7 standard with respect to countable aspects of market relevancy.
5. Not only IT firms hire HL7 experts, but also there are commercial
organizations like NeoTool [NeoTool] and AMICAS [Amicas] with whole-
soul expertise in HL7 standard only.
Literature Survey
19
Table 2.2. Some of the Countries having HL7 Branch Offices.
COUNTRY WEBSITE
Argentina http://www.hl7argentina.org.ar
U.K. http://www.hl7.org.uk
Japan http://www.hl7.jp
Ireland http://www.hl7.ie
Germany http://www.hl7.de
Finland http://www.hl7.fi
China http://www.hl7.cn/
Canada http://hl7canada.cihi.ca/
Australia http://www.hl7.org.au
Table 2.3 HL7 and Market Relevance
Aspect of Market Relevance HL7 Standard
Final specification available Yes
Implemented Yes
Comercial products available Yes
Intended for international market Yes
Focusssed on medical imaging sector No
But nothing is absolutely black or white in this world. Critics regard HL7 as too
complex for modeling and adding security. They have proved that it as designed for
implementation and not for conceptual modeling against the claim of the designers of
HL7. They consider that the HL7 documentation is very difficult to understand
[Fernandez-05]. In the paper “An analysis of modeling flaws in HL7 and JAHIS”
[Fernandez-05] they quote as follows: “Instead of using the Unified Modeling
Language (UML), the standard notation for object-oriented software development,
these two organizations have developed specialized object-oriented models. This has
resulted in languages which are incompatible with the current use of UML. What is
worse, it will be difficult to add security specifications in their models, a critical
aspect in the electronic interchange of medical records.”
Since the pros overweighed the cons, we decided to go ahead with HL7.
Literature Survey
20
2.3 Study of HL7
In the past decade, HL7 has evolved through many versions as depicted in the
table below [Neotool].
Table 2.4. HL7 Evolution
DATE EVENT
Mar, 1987 Conception of HL7 standard
Oct, 1987 HL7 Version 1
1988 HL7 Version 2
1990 HL7 Version 2.1
1994 HL7 Version 2.2
1997 HL7 Version 2.3
1999 HL7 Version 2.3.1
2005 HL7 Version 3
Still new versions are underdevelopment. Versions 3 onwards were not freely
available. Version 2.3 was found to be most reliable and heavily used version of the
standard as can be seen from the Figure 2.1. It is also freely available. The standard
was found to be very complex and comprehensive [Fernandez-05]. Conventionally,
HL7 organization advocates for a training programme and thus conducts various
training programmes, conferences, meetings and seminars round the year for its
members.
The standard was studied with the help of following sources.
1. Version 2.3.1.
2. There is a corroborative standard to HL7 named Reference Information
Model [RIM-04]. RIM provides a static and complete view elaborated in UML
for the design and requirements of HL7.
3. White papers from companies providing HL7 solutions [Neotool, Amicas].
Literature Survey
21
Version 2.1Version 2.2Version 2.3Version 2.3.1Version 2.4Version 2.5Version 3
Figure 2.1. The usage of different HL7 versions currently running in the
healthcare industry [NeoTool].
2.3.1 Introduction to HL7
HL7 was developed at University of Pennsylvania in the year 1987. The group
which found the standard had the intentions to devise a “language” which may allow
communications between disparate healthcare applications. Moreover the standard
was made quite general so as to cater global needs, because of which it got
international acceptance very soon. It was then recognized by ANSI.
The “language” basically consists of messages, which are composed of various
segments, which in turn contains data fields. The protocol comprehensively describes
messages, segments, fields, data types and some tables so as to cover all probable
events in a particular healthcare environment.
2.3.2 HL7's Mission
"To provide (global) standards for the exchange, management and integration of
data that supports clinical patient care and the management, delivery and evaluation
of healthcare services. Specifically, to create flexible, cost effective approaches,
Literature Survey
22
standards, guidelines, methodologies and enable healthcare information system
interoperability and sharing of electronic health records." [HL7-99]
2.3.3 Overview of HL7 Specification
The primary requirement for making any healthcare Information System HL7
compliant is that it should be able to send and receive process and store any required
HL7 message. HL7 defines a specific structure for these messages. This structure is
elaborated in next section.
2.3.4 Composition of HL7 Messages
The standard has defined the composition of the message as depicted in Figure 2.2.
2.3.4.1 HL7 Message. HL7 Messages are the kernel of the HL7 standard. The
information systems communicate with each other via these messages. These
messages are triggered by the various events that happen in a health care environment.
The standard has identified ample number of events that suffices the needs of typical
healthcare environments. Table 2.5 shows few examples of HL7 Messages.
Table 2.5. Examples of HL7 Events.
EVENT DESCRIPTION
A02 transfer a patient
A04 register a patient
A06 change an inpatient to an outpatient
2.3.4.2 Message Type. The standard has classified the messages under eleven heads.
There is 1-to-many relationship between events and message types. The detailed list
of classification of the messages is presented in the statistical analysis of the standard
(see Table 2.11).
Literature Survey
23
Table 2.6. Examples of Message Types.
MESSAGE TYPE DESCRIPTION
ORF Query for results of observation
DFT Detail financial transactions
MDM Medical document management
HL7 Message
Message Type Segments
Fields
Data Types
Figure 2.2. The composition of HL7 Message into segments, fields, and
components.
2.3.4.3 Segments. An HL7 Message is comprised of a group of segments in a defined
sequence. A segment is a logical grouping of data fields. Segments of a message may
be required or optional. They may occur only once in a message or they may be
allowed to repeat.
Table 2.7. Examples of Segments.
SEGMENT DESCRIPTION
MSG Message Header
EVN Event Type
PID Patient ID
Literature Survey
24
2.3.4.4 Fields. A field is a string of characters. A field is identified by a unique field
code and a field name. It should be composed of one or more data types defined in the
standard. Hence a field could be a simple or composite in nature.
Table 2.8. Examples of fields.
FIELD DESCRIPTION
00147 Admitting Doctor
00170 Bed Status
00380 Diagnosis Type
2.3.4.5 Data Types. The standard proposes a set fifty three data types classified
under twelve heads. The classified heads and their few examples are illustrated below.
Table 2.9. Classification of HL7 data types along with few examples.
Sr. No CLASSIFICATION EXAMPLES
1 Alphanumeric String, Text Data
2 Numerical Composite quantity with units, Money, Numeric
3 Identifier Coded values for HL7 tables, Coded value for user-defined
tables, Version identifier
4 Date/Time Date, Time
5 Coded Values Coded element, Coded with no exceptions, Composite ID
with check digit
6 Generic Composite
7 Demographics Address, Person Name, Telephone Number
8 Specialty/Chapter
Specific
Channel definition, Multiplexed array, Numeric array
9 Extended Queries Query input parameter list, Row column definition
10 Master Files Driver’s license number, Job code/class, Visiting hours
11
Medical
Records/Information
Management
Performing person time stamp
12 Time Series Date/time range, Repeat interval, Scheduling class value
pair
Literature Survey
25
2.3.5 An Instance of HL7 Message
HL7 defines a message A02 for the event- patient transfer. A message instance of
this event is taken from the developed system log and shown in the form of a Table
2.10. All segments begins from a new line and start with three letter code which
identifies the segment. The first row of the Table 2.10 shows the message header
segment with code MSH. This segment is a complimentary segment to all the
messages of the standard. It provides some basic information required to interpret the
whole message. For example the first character after MSH code in the message header
defines the field separator followed by four characters which defines encoding
characters. For our case the field separator is a pipe character- ‘|’ and the encoding
characters are ‘^~\&’ which means that the component separator is a carrot symbol-
‘^’, repetition separator is a tilde character-‘~’, escape character is a backslash
symbol- ‘\’ and the subcomponent separator is an ampersand character- ‘&’. With the
help of these symbols, the messages can be parsed and interpreted against the
standard’s specification.
Table 2.10. An instance of HL7 Message for the event A02 – “Patient
Transfer”
SEGMENT
NAME SEGMENT VALUE
Message
Header
MSH|^~\&|^ICU-2||^ICU-
1||200612272150||ADT^A02|#200612272150|P|2.3.1|||||||||
Event Type EVN|A02|200612272150|200612272300|02|420^Venkatesh|
Patient
Identification
PID|||12345||Khan^^Imran^^Er^Mr||19810612|M|||23 Purana Top
Khana^^Lucknow^U.P.^India||+91-
9935563272|||S|||||||Lucknow|||||India|
Patient Visit1 PV1||I|ICU-1||||123^Dr.Sarkar||||||||||321^Dr. Bhattacharya|
The message in the Table 2.10 can be interpreted as follows.
1. Message Header Segment. A message related to the event A02- ‘Patient
Transfer’ was transferred from ICU-2 to ICU-1 at 27-12-2006 21:50. The
version of the standard used in the message is 2.3.1.
2. Event Type Segment. The segment indicated again that the event happening
is a patient transfer A02. The transaction was recorded at 27-12-2006 21:50
Literature Survey
26
while the event actually happened at 27-12-2006 23:00. The operator
responsible for the transaction was Venkatesh with employee Identity number
as 420.
3. Patient Identification Segment. The patient Er. Mohd Imran Khan with
patient-Id as 12345 is a male born on 12-06-1981. He is a resident of 23,
Purana Top Khana, Lucknow, U.P., India. His telephone number is +91-
9935563272. His marital status is single (S) while birth place is Lucknow and
nationality is India.
4. Patient Visit1 Segment. The intype(I) patient is assigned a new location of
ICU-1. The attending doctor is Dr. Sarkar with employee-Id as 123 while
admitting doctor is Dr. Bhattacharya with employee-Id as 321.
It should be noted that the sample message is one amongst the smallest messages
as can be seen from the lots of empty fields. An HL7 message can at the most contain
500 fields. For detailed description of the standard, please refer HL7 v2.3.1
specification.
2.3.6 Statistics and HL7 Standard
Any assessment is incomplete without a thorough mathematical analysis. The
analysis brings out an interesting statistics. HL7 classifies various healthcare events as
depicted in Table 2.11. Table 2.12 shows the number of different components defined
in the standard of version 2.3.1.
2.4 Study of Decision Support Systems
Different authors provide different definitions and scopes of a decision support
system (DSS). Albert and Soumitra defines a DSS as- “Decision support systems
(DSS) are interactive, computer-based systems helping decision-makers (individuals
and/or groups) to solve various semi-structured and unstructured problems involving
multiple attributes, objectives, and goals” [Angehrn-98]. Some say that a DSS
provides advices (Active DSS) [Caleb-Solly-03] while others argue that they just
provide support to decisions (Passive DSS) [Lee-01].
Literature Survey
27
Table 2.11. The number of events under each classification of HL7 event.
Sr. No. EVENT TYPE NUMBER OF EVENTS
1 Patient Administration 64
2 Order Entry 2
3 Query 9
4 Financial Management 9
5 Observation Reporting 14
6 Master Files 11
7 Medical Records/Information Management 12
8 Scheduling 26
9 Patient Referral 15
10 Patient Care 20
11 Extras 6
TOTAL 188
Table 2.12. Number of various components in HL7 v2.3.1.
COMPONENTS NUMBER
Segments 110
Elements (Fields) 1477 (approx)
Data types 53
HL7 or User Defined Tables 200 (approx)
As far as scope of CDSS is concerned, it has been found that they provide various
levels of assistances- from generating reminders and alerts to extracting desired
knowledge and interpretation to diagnostic assistance, therapy critiquing and planning
to Image recognition and interpretation. At the most, a CDSS may land up to an
expert system.
2.4.1 Classification of Clinical Decision Support Systems
Some consider CDSS as extensions to information systems and classify them as
shown in Figure 2.3 [Caleb-Solly-03].
Literature Survey
28
2.4.2 Philosophy of Decision Support Systems
A Decision Support System does not just consist of a computer-based system.
Rather the decision maker (DM) and the computer-based systems are considered as
resources in the decision making process [Angehrn-98]. The role of computer-based
system is actually two-fold as classified below.
A Decision Support System does not just consist of a computer-based system. The
role of computer-based system is actually two-fold- firstly they provide a set of tools
which can help the Decision Makers (DMs) to find a logical representation of their
solution such that the representation can be easily analyzed, revised and further
explored. (Angehrn -98); and secondly to provide a set of tools which provide
suggestions and critiques like an advisor and stimulate for lateral thinking.
Healthcare Environment
Healthcare Processes • Integrating Systems between Processes • Communication Systems between Processes
Auxiliary Process • Systems supporting Auxiliary Processes
Care Process
• Systems supporting Care Processes
Supporting Processes • Supporting Systems
Medical Care Processes • Diagnostic Systems • Nursing Systems • Treatment or Therapy Supporting Systems
Figure 2.3. Classification of Health care Information Systems.
Literature Survey
29
2.4.3 Computing Techniques for Decision Support Systems
The concept of decision support system is very broad. Hence the scope,
classification, applications, advantages, computing techniques and of course the cost
and time. Some the computing techniques used for DSS are as follows.
• Artificial Intelligence
• Fuzzy Logic
• Genetic Algorithm
• Inductive Tree Methods
• Case Based Reasoning
• Rule Based Systems
An overview of some of the common techniques is given next.
2.4.3.1 Inductive Tree Methods. A decision tree is a flow-chart-like tree structure,
where each internal node denotes a test on an attribute, each branch represents an
outcome of the test, and leaf nodes represent classes or class distributions. In other
words, “a decision tree is a tree in which each branch node represents a choice
between a number of alternatives, and each leaf node represents a decision”- [Ding-
02 ].
Advantage of using decision trees are that they are simple to understand, requires
little data preparation, can handle both nominal and categorical data, can be validated
using statistical tests and perform well with large data in short time.
2.4.3.2 Case Based Reasoning. It has been proved that human mind uses case based
reasoning while taking decisions [Angehrn-98]. But the problem with the mind is that
it cannot properly recall the appropriate set of prior cases and cannot reason out the
differences between important and unimportant features. That’s why it has been
considered worthy enough to develop artificial CBRs to assist human mind in making
decisions . A fundamental architecture of CBR is shown in Figure 2.4.
i. Knowledge Base. Knowledge Base is a database or a data-warehouse
populated over a long period of time. Larger the amount of data better would
be the prediction set.
Literature Survey
30
ii. Rule Engine. It is an application program incorporating one or more
algorithms to find similarity between the cases. Similar cases are returned to
the Query Interface.
iii. Query Interface. It is a user interface through which a partial case is entered
initially. It displays the similar cases to the user and may also provide a
feedback from the user to the Rule Engine.
Figure 2.4. General Architecture of a Case Based Reasoning Systems
2.4.3.3 Rule Based Systems. These are predicting systems which contains an
exhaustive list of rules in the form of if-then-else statements. These rules are defined
with the help of a domain expert. The system accepts a list of conditions and produces
a set of outcome along with the sequence of rules which lead to the predictions.
2.5 Chapter Summary
Literature Survey reveals that HL7 standard is the most widely used standard for
healthcare integration. HL7 defines specifications for messages which are used for
communication between hospital information systems. The standard messages are
composed of various hierarchical components like segments, fields and datatypes.
HL7 defines its own set of datatypes. A module is developed which manages the
standards specifications efficiently. The module maps the ICU database to the
specification and vice-versa. It also provides facility to send and receive HL7
Knowledge Base
Rule Engine
Query
Interface
Partial Case
Similar Cases
Case History
Feedback
Literature Survey
31
messages and process them as well. The design of this module is described in the next
chapter.
For the decision support system, there are a wide variety of functionalities, techniques
and scopes. A full-fledged decision support system requires significant cost and time.
The clinical decision support system is intended to be built in an evolutionary order.
The present system is an application that extracts medically relevant knowledge from
a large set of information with the objective of guiding the practitioners in their
clinical practice. The design and process flow of CDSS is also presented in the next
chapter.
Chapter 3
System Design
Architecture represents the structural design of a system. The system may not
have a well known structure but whatever structure it will owe, that will be its
architecture. Prof. Paul Clements defines software architecture as “Software
architecture is the structure or structures of the system, which comprises of software
elements, the externally visible properties of these elements and the relationships
among them” [Clements-03]. An important point about this definition is that it asserts
that a system may have more than one structure. No single structure can be the
architecture. Further, Prof Clements emphasizes that even a structure can be presented
with the help of different views. Views are the pictures of a structure seen from
different directions.
3.1 Architecture of the Proposed Solution
An overview to the proposed system is provided in Figure 1.2. It is repeated in
Figure 3.1 again for convenience. As explained earlier, the system consists of two
developmental phases: phase I for implementing the ‘solution to communicative
information system’ and phase II for implementing the ‘solution to the decision
support system’. So as to bring out the various features and perspectives of both the
solutions, the whole system is elaborated with the help of following architectural
views and process flow diagrams.
System Design
33
Figure 3.1. System Overview. (Red arrows show data flow.)
3.2 Architecture of ‘Phase I- Solution to the Communicative
Information System’
For making the information system (SANJAVEENI) HL7 compliant, the whole
system was divided into several modules with well defined responsibilities.
3.2.1 Modular Architecture: Layered Viewed
Figure 3.2 shows the layered view of the modular structure of the Phase I-
Solution to the Communicative Information System. Since HL7 defines messages
pertaining to the Open System Interconnection (OSI) network model’s seventh layer,
the modules can be arranged in a layered fashion in accordance to the communication
sequence of the messages. Note that the layers in the Figure 3.2 do not have direct
links to the OSI layers.
The system boundary shown by the red line should also be noted. Each of the
layers is explained under following heads.
ICU Information System ICU Database HL7 Database
Clinical Decision Support System
HL7 Messaging Server
Other HL7 Compliant Information Systems
System Design
34
HL7 Interface
Network
HL7 Network MessagingServices
SendingModule
ReceivingModule
HL7 Message Management
ICU Information System(By R.Amirdha Gopal)
ICUDatabase
(By R.Amirdha Gopal)
HL7Specification
Database
HL7 SyntaxComposer
System To BeDeveloped
HL7Configuration
Manager
: IndicateCommunication
Figure 3.2. Phase I- Modular Architecture as a Layered Model
3.2.1.1 ICU Information System. ICU-IS is the lowest layer of the architecture and
is an already developed system. It consists of some running software modules that
provide the basic functionalities of the ICU. It should be noted that our system only
partially contains this layer. The proposed system will be built over it and hence only
few modules shall be modified.
ICU-IS manages all the functionalities of the ICU with the help of ICU Database.
This database stores all the fields required for the functioning of the ICU. Note that
System Design
35
though this database is not included in the ‘system to be developed’, but the
developed system is completely dependent on this database.
3.2.1.2 HL7 Message Management. This module will manage the incoming and
outgoing messages. Management will incorporate following activities.
i. Display of incoming messages and alerts.
ii. Processing and Archival of incoming messages.
iii. Automatic triggering of messages (outgoing) on some events.
iv. Explicitly sending the queries and getting their response.
3.2.1.3 HL7 Interface. This layer actually takes care of the incoming and outgoing
messages. This is divided into two obvious modules so as to deal with incoming and
outgoing messages. They are described below.
3.2.1.4 Receiving Module. After receiving a message, the system should validate it
and if valid send the required information to the HL7 Message Management Module
for processing. Both the functionalities require parsing the incoming message against
the pertinent HL7 syntax. The receiving module has the responsibility of message
validation, passing of required information to the layer below, and sending
Accept/Error acknowledgements to the sender.
3.2.1.5 Sending Module. This is the counterpart of the Receiving module and so
takes the information from the lower layer HL7 Message Management Module (in
case of automatically triggered messages or querying process) or Receiving module
(in case of acknowledgements and errors), arrange it in a proper syntax and send it to
the upper HL7 Network Messaging Services module.
3.2.1.6 HL7 Syntax Composer. This module is designed to assist the modules of
HL7 Interface. It serves their request by producing syntax against a particular HL7
event. It constitutes the syntax by extracting rules from an HL7 Specification
Database.
System Design
36
3.2.1.7 HL7 Specification Database. The most intriguing feature of the architecture
is this database. As against the general convention of storing specifications or rules as
productions and hard coding them in programs, a database is chosen to hold the
specifications. Moreover, the database is designed in such a way that any
modifications can be easily incorporated. This is done specially to meet the volatile
characteristics of the standard. It is anticipated that any major or minor change in the
standard (change in events, segments, fields, data types, HL7 and user defined tables
or a combination of any these) could be done by even an operator.
3.2.1.8 HL7 Network Messaging Services. The top most layer of the architecture is
to physically send or receive the messages over the network. This module will be built
on some standard communication protocols. That is why this module is also partially
included in the system boundary.
3.2.1.9 HL7 Configuration Manager. This module helps in mapping between HL7
fields and real ICU database fields. Since both the fields are quite different in terms of
length, data type and number of components, hence configuration files are defined to
map between the two. The module acts as sort of plug-n-play component as the whole
architecture can be configured to any other database by just changing this module.
Details of this layer are given in Chapter 4- Novel Features of the Solution.
3.2.2 Modular Architecture: Package Dependency View
Another view of the modular architecture can be represented in terms of the
dependency among the various modules of the system. Figure 3.3 shows the
module/package dependencies. At the core lies the module ‘HL7 Database Manager’.
Its sole responsibility is to make connection with the database and execute various
queries from the application. This module is directly dependent on Java Database
Connectivity (JDBC). The ‘HL7 Syntax Composer’ module is the only module
dependent on it. ‘HL7 Syntax Composer’ module generates syntax for given messages
in an efficient way so that the generated message is a ‘compressed’ one, yet fully
functional. Details of this module are also provided in Chapter 4- Novel Features of
the Proposed Solution.
System Design
37
Modules ‘HL7 Receiver’ and ‘HL7 Sender’ are the modules responsible for
message validation and HL7 message composition respectively. An additional
functionality of ‘HL7 Receiver module is to compose error and acknowledgement
messages. Since they directly deal with the syntax of messages, hence they are
dependent on ‘HL7 Syntax Composer’.
When a message is validated by the receiver module, it is sent to the ‘HL7
Message Management’ module for processing. Hence the receiver module also
requires services of message management module. On the other hand, when a
message is required to be sent it is decided by the message management module.
Once finalized, it asks the ‘HL7 Sender’ to compose the information in HL7 format.
Hence the sender module renders services to the management module.
Similarly, ‘HL7 Network Messaging Services’ module requires services of the
receiver module for validation and further processing when a message is received
while the sender module asks for the services of network messaging module once the
HL7 message is ready to be sent.
For message composition, the real database fields (i.e. the fields of the ICU-IS)
are required to be mapped to the HL7 specification and vice versa for information
retrieval from messages. Since the HL7 specification is disparate from that of ICU
database, hence mapping configurations are required. These configurations are
managed by module ‘HL7 Configuration Manager’. All the modules which perform
mapping require services from configuration manager.
Some general functionality is required by the sender and receiver modules. The
‘HL7 Utility’ module is responsible for providing these functionalities.
System Design
38
HL7 Receiver
HL7 Database Manager
HL7 Syntax Composer
HL7 Sender
HL7 Message Management
HL7 Network Messaging Service
hl7 Utility
HL7 Configuration Manager
Dotted arrow indicate dependency between packages.
Figure 3.3. Phase I- Modular Architecture as Package Dependency Diagram
3.3 Architecture of ‘Phase 2- Solution to the Decision Support
System’
The packaging of clinical decision support system is relatively simple but the
processing is quite complex. Processing details are provided in the coming sections.
System Design
39
3.3.1 Modular Architecture: Package Dependency View
Figure 3.4 shows the package dependency diagram for the clinical decision
support system. The system starts its execution with the CDSS Main Module which
renders the first user interface of the system. This interface introduces itself through
‘About’ menu item. It also shows the menu and options which the user can opt.
CDSS Main Module calls the CDSS User Interfaces for showing various screens
which allows the user to compose a query, execute a query and analyze it statistically
and graphically. CDSS User interface Module presents the whole schema of the ICU
in a hierarchical and meaningful form to the user. This information about ICU schema
is stored in an XML file which is managed by the CDSS XML Parsing Module.
During the composition and execution of user queries, the User Interface Module
takes the help of CDSS Database Manager which retrieves the results of all the
queries directly from the ICU database with the help of Java Database Connectivity
(JDBC) drivers.
Some general functionality is required by the above modules. These are taken care
of by the CDSS Utility Module.
CDSS Database Manager
CDSS Main
CDSS User Interfaces
CDSS XML Parsing
CDSS Utility
Dotted arrow indicate dependency between packages.
Figure 3.4. Phase II- Modular Architecture as Package Dependency
Diagram
System Design
40
3.4 Process Flow Diagrams of ‘Phase I- Solution to the
Communicative Information System’
Process flow diagrams are very helpful to understand the dynamic behavior of the
system [Booch-99]. The ICU-IS can have two different behaviors depending upon
whether it is behaving as a sender of message or the receiver of message.
3.4.1 ICU-IS as a Sender
The processes flow is depicted in the Figure 3.5 when the system behaves as a
sender of messages. The user will login into the system and user authentication is
performed. Then the user can either perform normal ICU activities or can go for
accessing data in other information system.
i. In case of normal ICU activities, some of them are registered to send
unsolicited messages to some destinations. These automatic triggering
activities and the desired destinations are managed by the administrator. In
such cases, HL7 messages are composed by the Unsolicited Sender.
ii. In case of query composition, the query is wrapped up along with the sender’s
information in an HL7 Message by the Unsolicited Sender.
In both ways, once the HL7 message is composed, it is sent to Message Sender to
send over to the network. The message sender can send to a single destination or can
also multi-cast the message to a number of systems depending upon the number of
receiving facilities registered for that event.
3.4.2 ICU-IS as a Receiver
As a receiver, the HL7 compliant ICU Information system runs a server all the
time to receive the messages from other information systems. As soon as the message
is received, the message is first saved to a safe location. Then the message may go
through one or more of the following processes.
3.4.2.1 Pre-processor. This process checks the message to verify four things.
i. That the message coming is just an acknowledgement of a prior message sent
by the ICU. In such cases the message is transferred to the ‘Acknowledgement
Archiver’ process.
System Design
41
Figure 3.5. HL7 Compliant ICU Information System as a Sender.
ii. That the HL7 version used in the message is compatible with the version
running in the ICU system. If not, then the control is passed to
‘Acknowledgement Composer’ process with correct error codes and
statements.
iii. That the message type is valid to be processed by the receiver. If the system is
unable to process any in-coming message, then error codes and statements are
sent to ‘Acknowledgement Composer’ process.
iv. That the message contains code demanding immediate level
acknowledgement. This condition is processed only when above three
conditions fails i.e. the in-coming message is a valid one. In this case ‘accept’
acknowledgement codes are sent to the ‘Acknowledgement Composer’ while
the original message is sent to the ‘Message Validation’ process for further
validation.
User Authentication
Query Composition
Unsolicited Sender
Message Sender
ICU Activities
<<Start Project>>
<<If Query Is Selected>>
<<If Other Activities are Selected>>
<<HL7 Message Composed>>
<<Query Composed>><<If Activity triggers an HL7 Event>>
<<Project Closed>>
<<If Query Is Selected>> <<If Other Activities are Selected>>
Activities with normal font are already developed Activities of the system. Activities with bold colour are newly developed.
System Design
42
Figure 3.6. Process Flow Diagram for the HL7 Compliant ICU- Information System as a Receiver of Messages
HL7 Messaging Server
Message Saving
Pre-processor
Acknowledgement Archiver
Message Validation
Query Processor
Message Display
Tabular Display
Acknowledgement Composer
Unsolicidated Sender
Message Sender
Post Processor
<<Start Server>> <<Message Arrival>> <<Message Saved>><<If Message is an Acknowledgement>>
<<Suucessfully Preprocessed>> <<if Accept Acknowledgement Requir...
<<Acknowledgement Compos...
<<Response after Query Executed>><<HL7 Message Composed>>
<<Closed>> <<Message Sent To Destinati...
<<Closed>>
<<Message Validated>>
<<If Message is a Query>>
<<If Message is an Unsolicidated Update>>
<<If Mesage is a Query Respocse>>
<<If Application Acknowledgement is Required>>
System Design
43
3.4.2.2 Message Archival. This process archives the acknowledgements against their
corresponding messages.
3.4.2.3 Acknowledgement Composer. Once the message is passed by the Pre-
processing unit and Message Validation unit, an acknowledgement can be sent to the
sender. The acknowledgement information is stored in the message itself. In case of
errors in the previous phases, acknowledgements will be carrying the error codes and
messages.
3.4.2.4 Message Validation. This process checks the message thoroughly and
validates each field of the message. It compares the message against the syntax
defined in the HL7 standard. Following checks are performed.
i. That the message contains all the required segments in the correct sequence.
ii. That the segments contain all required fields in the correct sequence.
iii. That the fields adhere to correct data types.
3.4.2.5 Post-processing. This processing checks the message to see what type of
processing is required by the message. The processes could be the Message Display,
the Query Response Display, or the Query Processor. Accordingly it directs the
message to the concerned process.
3.4.2.6 Message Display. This is a type of message processor for unsolicited updates.
It will simply parse the validated message and display the fields and components
along with their values to the user. It will also provide the functionality of saving the
message in the database schema in case the operator wants.
3.4.2.7 Query Response Display. This is another type of message processor, used to
display the message which is actually a query response. Therefore it renders the
information of the message in the form of a table. Query and message information are
also presented to the user so that he/she can recognize the concerned query.
3.4.2.8 Query Processor. In case any information systems want to access the ICU
information, they will send the request to the ICU in the form of a query. This
message is required to be executed and the result should be composed as an HL7
System Design
44
message and returned to the requester. The required query is executed by Query
Processor and resultant data is passed to the Unsolicited Sender.
3.4.2.9 Unsolicited Sender. This module is an HL7 message composition module. It
takes the required input data fields from other modules and composes a message
according to the HL7 syntax from the provided fields. It then passes the composed
message to the Message sender which sends the message to the destination.
3.2.4.10 Message Sender. This module is an HL7 messaging client program which
directs an HL7 message to one or more destinations. Depending upon the message
type, it extracts the destination addresses either from the database (in case of
unsolicited events) or from the message itself (in case of query processing).
3.5 Process Flow Diagrams of ‘Phase II- Solution to the Decision
Support System’
The objective of clinical decision support system is to guide the user to easily
compose a query, to present the result-set of the executed query, allow the user to
analyze them statistically and graphically. This process flow is depicted in the Figure
3.
The system starts from the Query Composition process. This process provides a
drag and drop option for composing a query. It also facilitates a user to modify a
query any number of times. Once a query is composed, it is executed and presented in
a table by the Query Response process. This process not only displays the query
response, but also provides the facility of grouping and ordering the result according
to one or more fields. One can always move back to the Query Composition process
to modify the wrongly composed query in case it does not provide the desired results.
On the other hand, the user can analyze the results graphically and statistically via
Graphical Analysis and Statistical processes respectively. From these analyses, one
can either move backward to the Query response process or can compose a new
query.
System Design
45
Query Composition
Query Response
<<Modify>>
<<Execute>>
Statistical Analysis
Graphical Analysis
<<Back>>
<<Modify>>
<<Analyze statistically>>
<<Analyze Graphically>><<Back>>
<<New Query>>
<<New Query>>
<<Start>>
Figure 3.7. Process Flow Diagram for the Clinical Decision Support System
The Query Composition process is a complex procedure because it guides a user
to compose a query. To rationalize human behavior is a difficult task. A naïve user
working on CDSS may try any combinations of the commands present on the user
interface. The system safeguards against all incorrect sequences of commands. Figure
3.8 shows the how the Query Composition process guides the user to compose a
query. This process accomplishes this task with the help of other widgets, data
structures and control variables. Major objects are explained below.
The array-lists named SELECT Argument List, FROM Argument List and
WHERE Argument List are used to store the arguments of SELECT, FROM and
WHERE clauses of SQL respectively.
Query Browser presents the whole ICU schema in a hierarchical order. It allows
the user to select the fields in two modes- SELECT and WHERE. SELECT mode
allows the user to simply select fields to be viewed while WHERE mode allows the
user to specify filters. In SELECT mode, when the user adds a field to the query, the
field name is added to the SELECT Argument List while the table name (to which the
field belong) is automatically added to the FROM Argument List. Note that the user
System Design
46
need not specify the table name explicitly. A table name is added to the list only
once, no matter how many of its fields are present in the SELECT Argument List or
the WHERE Argument List.
Condition c1: If table 'T' does not exist in the SELECT Argument List.
Condition c2: If no field of table 'T' exists in SELECT/WHERE Argument List
User QueryBrowser SELECT Arguments List
FROM Arguments List
Filter Dialog WHERE Arguments List
1: Select 'SELECT' mode
2: MODE = 'SELECT'
3: Select field 'F'
4: <if c1>Add table name 'T'
5: Return table number t
6: Add t.F
7: Delete field 'F'
8: Delete 'F'
9: <if c2> Delete table 'T'
10: Select 'WHERE' mode
11: MODE = 'WHERE'
12: Select field 'F'
13: Details of 'F'
14: Filter Conditions
15: Return WHERE clause 'W'
16: <if c1>Add table name 'T'
17: Return table number t
18: Add 't.W'
19: Select AND/OR operator
20: Add AND/OR
Figure 3.8. Sequence Diagram for the Query Composition Process
In the WHERE mode, as soon as the user selects a field a filter-dialog box pops
up. The filter-dialog box provides a list of operators as well as tips to specify filter
value. Once the filter value and operator is selected, it is added to the WHERE
Argument List. The user can select more than one filter attribute and may congregate
System Design
47
them with AND, OR, left parenthesis or right parenthesis operators. The Query
Browser monitors the whole query composition process with the help of stacks and
flags. In case of modifications, the user is guided to safely delete undesired attributes
or filters. The fully composed query is then dispatched to the ICU-Database and the
results are collected and displayed.
3.6 Chapter Summary
Both the modules- ‘HL7 Compliance’ and ‘Decision Support’ are well
modularized to keep high cohesion and low coupling which are the major design
principles of the Software Architecture [Lethbridge-04]. The process flow of both the
systems provides an insight of how the system works. The Architectures take care of
all the required functionalities by the ICU.
The whole of the Detail design of the system would be too bulky to be provided in
the thesis. But as some major non-functional requirements are identified, their need,
detail design and advantages are discussed in the next chapter. As the chapter
explains, one can realize that these non-functional requirements are really desirable by
the proposed solution.
Chapter 4
Novel Features of the Proposed Solution
Fulfilling functional requirements is a compulsion of software developers, but
providing non-functional requirements actually results in a competitive edge over the
others. Non-functional requirements directly improve the quality of a product and
hence bring good-will of the users, profit to clients and convenience to the developers
and maintainers. But equipping a product with non-functional requirements has been
found even more difficult than providing functional requirements [Lethbridge-04].
An inherent delusion among developers is that automation provides simple
translation of manual processing. But when such a system is developed the process
becomes even more cumbersome leading to bottlenecks and major sources of costs,
errors and delays [Boehm-00]. A software system should be thoroughly assessed for
performance and other quality attributes before going for implementation. The
proposed system may demand few changes in the work flow or addition of several
other features so as to run the system smoothly. Such changes should be readily
adopted.
As a thesis of Software Engineering, it was aimed to enrich the quality of the
project. A real application of Software Engineering principles and paradigms comes
here, when following features were provided to the project, which makes it unique
and novel.
1. HL7 Specification stored in database (Maintainability)
2. Compressed Syntax Generation (Efficiency)
Novel Features of the Proposed Solution
49
3. Use of Configuration Files and Plug-n-Play Architecture (Flexibility and
Reusability)
4.1 HL7 Specification stored in database (Maintainability)
Health Level Seven (HL7) Standard has evolved through various versions in the
past decade (please refer to Table 2.4 for the versions). The organization is still
heavily involved in improving the standard. Summits and conferences are held all the
year round which results in minor or major modifications to the standards. No doubt
the modifications improve the standard, but they adversely effect the applications of
the standards. Two applications working on different versions of the standard become
incompatible at some point or the other. To upgrade an application to the latest
version of the standard will require an overhauling by the maintenance and support
teams.
Generally standards are implemented as productions or grammar. Though HL7
provides such productions (refer Appendix D- BNF Message Descriptions of HL7
Version 2.3.1 [HL7-99]), they were found quite difficult to maintain. The problem
with this approach is that the productions are hard-coded to produce a compiler-like
module. Such modules are static and too much coupled to make changes. So the thesis
devises a more maintainable solution. The standards’ specification is stored in a
database. The advantage of using database is that changes can be made very easily
through queries or query browsers by even an operator. Since the application is
dependent of the database, it will incorporate any changes automatically, once the
database is updated.
4.1.1 Conceptual Modeling of HL7 Specification Using Entity-Relationship
Diagram
To keep the standard in the form of relational tables [Navathe-03], the standard
was conceptually modeled through Entity-Relationship Diagram (ERD) as shown in
Figure 4.1. The ERD is explained as under.
Novel Features of the Proposed Solution
50
Each message is triggered by a unique HL7 event which depicts a real world
happening of a healthcare environment. Every event is designated a code and a name.
As for example, in case of patient transfer event, the code is ‘A02’ and the name is
‘transfer a patient’. Events can be automatically generated (Unsolicited Update) or
specifically fired (Query). Unsolicited Updates are those messages which the sender
multicasts to the receivers without their demand. Note that in such cases, the sender
does not expect a responsive message from the receiver excluding acknowledgements
and error messages. The purpose of unsolicited updates is informative rather than
inquisitive. Whereas, when the message is sent as a query or its response, it is
classified under Query events.
Example. In the case of ICU-IS, the events of patient admission, transfer and
discharge are considered as Unsolicited Updates while that of query sent to other IS of
a hospital comes under Query.
The message generated is composed of several segments, the first one always
being the message header (MSH in HL7 terminology). Segments are also identified
by a unique code and name. Segments are related to the information regarding the
happened event, like patient’s identification, destination location, source location and
some other optional information in case of patient transfer.
The segments are composed of various optional and repeatable fields, which are
the subjects of information. As other components, every field is also given a unique
code and name. Patient name, mother’s name, date of birth, address, citizenship, and
nationality are few of the fields of Patient Identification (PID) segment.
A field is actually an HL7 data type which has a well defined format. There may
be different types of data types as explained in Chapter 2- Literature Survey (please
refer Table 2.9 for the allowable data types). As shown in the ERD, a field is either a
simple data type or a composite data type or an HL7/User defined value. A simple
data type represents a single value like a string or a number. Composite data types are
composed of one or more simple or composite data type. For example a person name
is defined as a composition of family name, given name, middle initial name, suffix,
prefix and degree which are all simple data types. There are some fields which always
Novel Features of the Proposed Solution
51
have a set of values. HL7 has coded many such fields. An example of HL7 defined-
value data type would be marital status which is defined in Table 4.1. HL7 also
permits the implementers of the standards to define and use their own (site-defined)
codes. Such values come under User defined data types.
EVENT
UNSOLICIDATEDUPDATE QUERY
d
Name
TRIGGERS MESSAGE1 1
ISCOMPOSED
OF
SEGMENT
Name
1
1...*
ISCOMPOSED
OF
1
Sequence
Length
DescriptionFIELD
HL7/USERDEFINEDTABLE
SIMPLE DATATYPE
d
COMPOSITEDATATYPE
Name
Values
NameIS
COMPOSEDOF Code
Code
Code
Code
Code
Code
Name
1...*
TOTALPARTICIPATIONAll events arespecialized.
DISJOINTCONSTRAINT: Anevent is either a query oran unsolicidated update.
DISJOINTCONSTRAINT: Allfields can specialized as atable, composite orsimple datatype.
Figure 4.1. The Entity-Relationship-Diagram for the HL7 Specification
Novel Features of the Proposed Solution
52
Table 4.1. Marital Status
VALUES FOR MARITAL STATUS
Single
Married
Divorced
Separated
Widowed
4.1.2 Schema Design of HL7 Specification
The ERD is further refined to relational tables with table-dependencies as shown
in Figure 4.2.
<<table>>EventDescription EventSegment
<<table>>SegmentDescription
<<table>>SegmentField
<<table>>FieldDescription
<<table>>DatatypeDescription
<<table>>TargetDatatype
Description
<<table>>Datatype
Component
<<table>>HL7UserDefinedTable
Description
<<table>>HL7UserDefined
TableValue
Figure 4.2. HL7 Database Schema Design
Novel Features of the Proposed Solution
53
All the tables ending with word ‘Description’ hold the primary information about
that entity. It is a sort of master table for that entity. While the tables formed by
concatenating the names of two entities represent relationships. It consists of
information related to one entity with respect to another entity. For example the table
‘EventSegment’ consists of information about different segments occurring in one
particular event. This particular relationship is further elaborated in the Figure 4.3.
Similarly, all other tables are designed and related to the others.
EventSegmentTID : Small IntegerEvent code : StringSegment Code : StringSequence : Tiny IntegerOptional : BooleanRepeatable : BooleanComment : Tiny Blob
EventDescriptionTID : Small IntegerCode : StringName : StringComment : Tiny Blob
SegmentDescriptionTID : Small IntegerCode : StringName : StringComment : Tiny Blob
Schema (1): Relationship between Event, EventSegment and Segment tables
Figure 4.3. The details of tables ‘EventDescription’, ‘SegmentDescription’ and
‘EventSegment’ and their relationships.
4.1.3 Convoluted Structure of Data types
As mentioned above, HL7 defines three data type classes- Simple, Composite, and
HL7/User-defined in such a way that Simple data type represents a single value,
HL7/User-defined are constants, and composite data type may consist of a
combination of these two. As for example Table 4.2 shows a datatype named
Extended Person Name (XPN) used for the name of a person.
Novel Features of the Proposed Solution
54
Table 4.2. Format of datatype- Extended Person Name (XPN)
DATATYPE
NAME DATATYPE FORMAT
Extended
Person Name
(XPN)
<family name (SIMPLE)> & < last_name_prefix (SIMPLE)> ^ <given
name (SIMPLE)> ^ <middle initial or name (SIMPLE)> ^ <suffix
(SIMPLE)> ^ <prefix (SIMPLE)> ^ <degree (SIMPLE)> ^ <name type
code (COMPOSITE) > ^ <name representation code (HL7 DEFINED)>
Note: ^ and & are component and subcomponent delimiters respectively.
Note that a composite datatype may again contain a composite datatype. In this
way, the HL7 datatypes are hierarchical in structure as can be seen in the Table 4.2.
To abstract this structure in a table as well as in an application program, design
patterns were used.
4.1.4 A Brief History of Design Patterns
Christopher Alexander is considered as the founder of Design Patterns as the
origin lies in his work of late 1970s. But the importance of Design Patterns was
realized in 1987 at the Conference on Object-Oriented Programming, Systems,
Languages, and Applications (OOPSLA). Since then Design Patterns gained more
importance and a number of papers and presentations were given by people like Kent
Beck, Erich Gamma, Grady Booch and Richard Helm.
Erich Gamma et al defines design pattern as “A design pattern is a general
repeatable solution to a commonly occurring problem in software design. It is a
description or template for how to solve a problem that can be used in many different
situations.” [Gamma-00]
4.1.5 Application of Composite Pattern
In Object Oriented Technology, the problem of convoluted structures is met by a
design pattern named Composite Pattern [Freeman-04]. Composite Pattern arranges
objects in part-whole hierarchies. The advantage of using this pattern is that objects as
well as composites of objects are treated uniformly.
Novel Features of the Proposed Solution
55
The pattern if applied to our problem would produce a solution as shown in the
Figure 4.2. Class ‘Datatype’ is a base class holding the common information of all the
datatypes. Classes ‘Simple Datatype’ and ‘HL7/UserDefined Datatypes’ are
subclasses of ‘Datatype’ responsible for processing Simple and HL7/UserDefined
datatypes respectively. Class ‘Composite Datatype’ is also a sub-class of the base
class ‘Datatype’ which is specialized in a way that it can contain children objects
which themselves inherit the base class ‘Datatype’. In other words, an object of
‘Composite Datatype’ can contain one or more objects of Simple, HL7/User Defined
or Composite datatypes.
Datatype
Simpledatatype
CompositeDatatype
HAS
HL7/UserDefinedDatatype
Figure 4.4. The application of Composite Pattern to the problem of
‘Convoluted datatype structure’
The use of the above pattern greatly simplified the design of the system, as will be
shown in the next section.
4.2 Compressed Syntax Generation (Efficiency)
The automated process of composition, interpreting, validating and processing of
HL7 Messages requires the standard’s specification in the form of syntax. Syntax
should hold the required information about all the constituents of a message in a
notational format. Each message has a unique syntax. All syntaxes are quite bulky in
size as can be seen from the example below.
Novel Features of the Proposed Solution
56
Example: Let us assume that a message contains 10 segments. On an average a
segment contains 20 fields out of which, say 10 are composite. Composite fields
contain 5 children on an average. Again we can assume that those composite fields
contain no composite sub-field in it. So the total number of fields in such a message
would be:
10 * (10 + 10 * 5)
= 600
Since each field is defined by 8 attributes which are field code, field name,
required/optional, repeatable, datatype and HL7/User defined table code, the syntax
will contain 600 tuples of information for each message [please refer Figure 5.1b].
The major problem with this bulky syntax would arise while fetching it from the
database. For the message in example above, the estimated number of queries is 61 as
shown in the Table 4.3. Now one can realize that the processing time for each
message would be quite high if only the syntax generation of each message requires
so many database operations.
Table 4.3. Number of queries required to generate syntax of a typical HL7
Message
MESSAGE
COMPONENT
NUMBER OF
COMPONENTS
REQUIRED
NUMBER OF
QUERIES
REASON
Message 1 1 To fetch all the segment against
this message code.
Segment 10 10 One query each for a segment to
fetch all its fields.
Fields (Non-
Composite) 10 2 * 10
Two queries per field: One to
access field’s information and
another to fetch its datatype’s
information.
Fields
(Composite) 10 3 * 10
Three queries per field: First to
access field’s information, second
to fetch its datatype information
and third to fetch the information
about the datatype’s components.
Total number of Queries required to generate the syntax of 1 message = 61
Novel Features of the Proposed Solution
57
4.2.1 Overlapping Structure of HL7 Messages
The problem of ‘bulky syntaxes’ can be resolved from two observations stated
below.
i. HL7 Syntaxes have common intra and inter level components.
ii. When one type of message is processed (sent or received), it is most likely to
process similar type of messages in the near future.
HL7 classifies all the events into eleven event types, as described in the Table
2.11. All the events (or otherwise messages) belonging to a certain event type share
common segments amongst each other. As for example, the events ‘Patient
Admission’ A01 and ‘Patient Discharge’ A03 belong to the event type ‘Patient
Administration’. They share twelve segments. This type of shared information
constitutes inter-level overlapping structure.
Intra level overlapping occurs because one field is found in many segments.
Moreover all the 1477 fields of the specification are mapped to 53 datatypes only.
This means that many fields belong to the same datatype.
The second observation is analogous to the concept of “Locality of Reference”
that is used in the memory management by modern operating systems. For example, if
a query message arrives at a system, the query response message would soon be
processed. The important factor here is again the same: both the messages belong to
the same event type and hence share some common segments.
4.2.2 Application of Flyweight Pattern
“Flyweight pattern uses sharing to support large numbers of fine-grained objects
efficiently”- [Gamma-00]. When applied to our context of overlapping syntaxes, it
produces a general solution as shown in Figure 4.3.
The class ‘Component’ has a private constructor so that the client cannot
instantiate it directly. Its member attribute ‘componentSet’ is an array to hold the
previously created objects of this class. The objects are accessed with the help of a
key named ‘compId’. The client, when it wants to create an object of class
Novel Features of the Proposed Solution
58
‘Component’, it requests through the method ‘getComponent’ which accepts the code
of the desired component type. If the component had already been instantiated before,
its object is returned from the array ‘componentSet’. If such an object does not exist, a
new object is created with the help of constructor and ‘createComponent’ method.
The object is placed in the array as well and its reference is returned to the client. This
concept is depicted in the Figure 4.4 where there are only three different objects of the
component (i.e A, B and C) but they are used by all the clients who request for them.
Client Component<<Component>> componentSet
<<Component>> getComponent(int compId)<<Component>> createComponent(nt compId)Component(int compId)
if(componentSet[compId] exists){return existing flyweight;}else{create a new flyweight;add it to pool of flyweight;return new flywei...
Figure 4.5. Application of Flyweight Pattern to produce compressed syntax.
Note that the class ‘Component’ in the Figures 4.3 and 4.4 stands in general for all
the components of HL7 i.e Messages, segments, fields, and datatypes. Hence the
pattern is repeatedly used for each component.
Figure 4.6. Concept of Flyweight Pattern
Novel Features of the Proposed Solution
59
This technique ends up in two advantages. Firstly, the syntax generated consists of
a unique definition at one place while its references are used where ever it is required.
Consequently it results in a Compressed Syntax. Hence the number of queries
required to fetch a syntax gets dramatically reduced.
The second advantage is that the component definitions fetched from the database
for processing one message is used again for processing another. As stated above,
messages show a great deal of overlapping structures and hence these shared
structures need not to be created again. The same syntactical object is used again and
again for any number of messages thus reducing that fetching time of that object. The
results vindicate these points in Chapter 5- Results and Output.
4.3 Use of Configuration Files and Plug-n-Play Architecture (Flexibility and Reusability)
The system architectures are presented in Chapter 3- System Design. However,
the developed system complies with yet another architecture- Plug-n-Play
Architecture. As in chapter 3, the architecture here is also explained in two phases-
‘Phase I- Solution to the Communicative Information System’ and ‘Phase II- Solution
to the Decision Support System’.
4.3.1 Architecture of ‘Phase I- Solution to the Communicative Information
System’
For HL7 messaging to take place, the operational database is required to be
mapped to the HL7 messages and vice versa. This mapping is defined in one of the
tables named ‘Target Database Description’ in HL7 specification database. Column
‘Code’ defines the code of the field which is related to some field in the operational
database. The name of the database, table name, field and primary key of that table
are stored in the concerned columns. The primary key value helps in accessing the
field value against desired record.
Novel Features of the Proposed Solution
60
Target Database DescriptionTID : IntegerCode : StringDatabase Name : StringTable Name : StringField Name : StringKey Name : StringComment : Tiny Blob
Figure 4.7. Table Design for mapping HL7 fields to the operational database.
For transforming a field in one domain into another and vice versa, the table
described above is not sufficient. This is because the ICU database and HL7
specifications are quite disparate. The ICU database was designed conventionally
even before there was any need for the compliance of the HL7 standard. The
differences are summarized with examples as below.
1. Differences in Datatypes. For many fields, the specification’s datatype differs
from that of the operational ICU database. As for example, the field ‘Patient-Id’ is
defined as an integer in the ICU database while HL7 defines it as a composite
datatype ‘Extended Composite ID with check digit’. This datatype consists of the
identity code of the patient as a string along with other complex but optional sub-
components.
2. Differences in Relationships. There is no 1-to-1 relationship between the
subcomponents of some fields in both the domains. For example, HL7 defines
‘Patient Name’ as a composite of ‘Family Name’, ‘Last Name Prefix’, ‘Given Name’,
‘Middle Initials’, ‘Suffix’, ‘Prefix’, ‘Degree’, ‘Name Type Code’ and ‘Name
Representation Code’, while ICU database defines it as a single component only.
On one hand, more than one distinct HL7 fields may get mapped to single ICU
field while on the other many ICU fields may also get mapped to one field of the
standard messages. An example for this would be the address of a patient. ICU
database contains five different fields for storing the address of the patient which are
‘Address Line1’, ‘Address Line2’, ‘City’, ‘State’ and ‘Country’. HL7 specification
Novel Features of the Proposed Solution
61
has only one composite field as ‘Patient Address’. Hence there could be 1-to-1, M-to-
1, 1-to-M, M-to-N relationship between the fields in the two domains.
4.3.1.1 Using Configuration Files. The scenario of Figure 4.5 shows the problem
above along with the solution. The contrasting colors between the standard’s
specification and the clinical database depict the degree of distinctness between the
two. A bi-directional mapping is required for the system to work. An intriguing
feature of this scenario is the ‘Configuration Manager’ module. This module contains
configuration files of which some are for the sending application and some for
receiving application. These configuration files contain field-specific rules which
dictate the application to transform the field correctly.
Figure 4.8. System Architecture as Plug-n-Play Model
Figure 4.6 shows excerpts from two configuration files showing the rules of
transformations. The syntax of the files is locally defined to be understood by the
application.
The advantage of maintaining such architecture is two fold. Firstly, suppose a
change is required in the present ICU schema. The change can be easily incorporated
Clinical Database
HL7 Specification
Database MAPPING
Sending Configurations
(FieldsA01.ini FieldsA02.ini FieldsA03.ini FieldsEQQ.ini FieldsTBR.ini)
Receiving
Configurations (Fields.ini)
CONFIGURATION MANAGER
Novel Features of the Proposed Solution
62
by reflecting proper changes in the configuration files. Had the mappings been hard-
coded, the source code would have to be modified. Secondly, if another healthcare
information system is required to comply with the HL7 specification, then the same
module can be reused since only the mapping needs to be redefined. Most of the
changes would be done in the configuration files and the table ‘Target Database
Description’ while rest of the module would undergo minor changes. This feature
makes the system quite flexible and reusable.
Figure 4.9. Excerpts from configurations files.
(Left: receiving configurations and Right: sending configurations.)
4.3.2 Architecture of ‘Phase II- Solution to the Decision Support System’
A decision support system is an application that may be required by most of the
departments of an organization. Keeping this point in view, the clinical decision
support system follows Plug-n-Play Architecture. There are two separate but
dependent modules- first one is a general decision support application which is
dependent on the second module. The second module contains information about the
department’s database in a standard format. Both modules combine together to form a
FieldsA01.ini #EVN
EVN00100:DATE EVN00103:DATABASE:3 #PID PID00106:CONFIG:0 PID00108:DATABASE:2 PID00110:DATABASE:0 PID00111:DATABASE:0 PID00114:DATABASE:0+1+2+3+5 . . .
Fields.ini #EVN 00100-0|0|STRING| 00100-1|0|STRING| 00103-0|6+3+4+2+1+5|STRING
00103-1|6+3+4+2+1+5|STRING 00106-0|0|NUMERIC 00106-1|0|NUMERIC 00108-0|5+2+3+1+0+4|STRING 00110-0|0|NUMERIC| . . .
Novel Features of the Proposed Solution
63
decision support system for a particular department. The beauty of the architecture
lies in the fact that as the second module is changed to represent some other
department, the entire application is changed to become a decision support system for
that department. This scenario is depicted in the Figure 4.7 which shows the
integration of decision support application with two application databases to produce
the corresponding DSS.
The second module is implemented in Extensible Markup Language (XML)
version 1.0. The XML property file holds information about the ICU schema in a
particular hierarchy. Figure 4.8 shows an excerpt from the XML property file. The file
is parsed with the help of Simple API for XML (SAX) parser provided by JDOM API
[Deitel-04]. Any modification in the XML file will automatically be reflected in the
application program. Moreover, any database details provided in this XML format can
be manipulated and processed.
Figure 4.10. The integration of decision support application with two
departmental databases to produce corresponding DSS.
The advantage here is exactly similar to that of using configuration files in Phase
I- Flexibility to modify the ICU database and Reusability for any other information
system.
Clinical Schema Details
Decision Support
Application
Pathology Schema Details
Pathology Decision Support
System
Clinical Decision Support
System
Novel Features of the Proposed Solution
64
Figure 4.11. An excerpt from XML property file.
4.4 Chapter Summary
The quality of the system is improved by making the proposed solution
maintainable, efficient, reusable and flexible. Maintaining a database for the
standard’s specification would be helpful in incorporating modifications in the HL7
standard. This feature is an innovative feature of the product as no such work was
found in Literature Survey. Compressed Syntax generation is another novel feature
proposed by this thesis. The system performance drastically improved due to the
application of this technique. The proof of their desired result is provided in the next
chapter.
ICUSchemaDetails.xml
<?xml version="1.0" encoding="UTF-8" ?> <root> <Schema name="ICU Schema"> <TABLE Name="Urine Details"> <Field name="Patient Id" FieldId="PatientId" TableName="zurineview" SchemaName="newicu"
DataType="INTEGER" PossibleValues="SELECT HospitalNo FROM newicu.patientmaster" Comments="Patient Id is a positive integer." />
<Field name="Daily Care Id" FieldId="DCareId" TableName="zurineview" SchemaName="newicu" DataType="INTEGER" PossibleValues="SELECT DCareId from newicu.dailycaremaster" Comments="Daily Care Id is a positive integer" /> . . .
</TABLE> <TABLE Name="Treatment Details"> <Field name="Patient Id" FieldId="PatientId" TableName="ztreatmentview" SchemaName="newicu"
DataType="INTEGER" PossibleValues="SELECT HospitalNo FROM newicu.patientmaster" Comments="Patient Id is a positive integer." /> . . .
Novel Features of the Proposed Solution
65
Following Plug-n-Play architecture was a measure to make the solution flexible
and reusable. No exclusive validation on this property is done as adherence to an
already developed and tested architecture validates the system.
Chapter 5
Results and Outputs
This chapter verifies the whole system design especially the new techniques
described in chapter 4- Novel Feature of the Proposed Solution. The advantages of
applying these techniques are documented in section 5.1- Results of the Application
of Novel Techniques. An overview of the major functionalities of the proposed
system is presented in next section 5.2- Some Outputs of the Major Functionalities.
5.1 Results of the Application of Novel Techniques
The techniques applied to bring about non-functional quality attributes were
assessed for producing actual results. The results are summarized under following
heads.
5.1.1 Results of maintaining an HL7 Specification database
(Maintainability)
The first desired and obvious result of such a scheme is that any modification in
the standard can be made without touching the source code. One needs to fire queries
for any changes. The number of queries required to change, append or delete a given
HL7 Message component is shown in Table 5.1. The table shows the maximum
number of queries required for each component. Due to the overlapping nature of the
specification (refer section 4.2.1- Overlapping Structure of HL7 Messages), the
Results and Outputs
67
modifications are never exhaustive. This characteristic result in significant reduction
of actual queries required.
Table 5.1. Number of queries required to modify, add or delete an HL7 Message
Component.
ADDITION,
MODIFICATION OR
DELETION OF A
COMPONENT
NUMBER OF QUERIES
REQUIRED REASON
Simple or
HL7/UserDefined
Datatype
n1 = O(1)
One insert, delete or update query
command for datatype description.
Composite Datatype
having D simple
components
n2 = O(D+n1)
One query command for composite
datatype description and D
commands for the component
descriptions.
Field which is referenced
by S Segments n3 = O(1+S+n2)
One query command for the field
description, S commands for each
referencing segment, and O(n2)
commands because a field belong
to some datatype.
Segment having F fields
and referenced by M
Messages
O(1+(N*n3)+M)
One query command for the
segment description, M commands
for referencing Messages and N*n3
commands for the related fields.
Message having S
Segments each having F
different fields
O(1+S+(S*F)+(S*F*n2))
One query command for message
description, S commands for
segment description, S*F
commands for field description and
S*F*n2 commands for respective
datatype.
NOTE: The result is provided in the big-O notation which connotes the maximum value. The
calculations are done with an assumption that the components or sub-components don’t exist at all or
all need to be modified or deleted. In real case, only few subcomponents are needed to be appended or
modified resulting in the drastic decrease of the queries required.
Results and Outputs
68
5.1.2 Results of Generating Compressed Syntax (Efficiency)
The verification of compressed syntax is shown with the help of figures 5.1a and
5.1b. Figure 5.1a shows the message ‘A02- Patient Transfer’ which was sent to the
ICU for processing. Note that the message is very short but valid. The message was
taken from the HL7 specification v2.3.1 sample messages. The application generates
full syntax for the verification of the message, no matter how short the message is.
The syntax is shown in Figure 5.1b. The message though bulky is still compressed.
This can be realized by observing that once a datatype definition is given, it is never
repeated again even on the repetition of the datatype. The figure highlights the field
‘Patient Name’ which is an Extended Person Datatype (XPN) in HL7 specification.
All the components of this datatype are described in juxtaposition to it. The next time
this datatype occurs in the field ‘Mother’s Maiden Name’, but this time no
specification is fetched out. The system passes a reference to the previous definition
internally.
The real advantage of the Compressed Syntax generation can be seen in the
diminishing running time of the system. Table 5.2 shows the average response time of
the different messages by developed system. The messages were sent successively
and the response time was measured carefully for each of them. The table connotes
following observation- the system took significant time to process first message, but
the time decreases as other messages were processed. As explained before (refer
section 4.2.1- Overlapping Structure of HL7 Messages), the time decreases because
the messages share components. These components are fetched once and used many
times. Response time decreases in first and second sequence of arrival of messages
A02, A01, and A03 respectively. But it increases slightly for the message EQQ. The
reason being that EQQ belong to different classification of message types (refer to
classification of HL7 Events Table 2.11) and hence its overlapping with previous
message syntaxes is relatively low.
Results and Outputs
69
Figure 5.1a. Sample Message for Event ‘A02- Patient Transfer’ taken from HL7
specification v2.3.1.
Figure 5.1b. Compressed Syntax for the event ‘A02- Patient Transfer’
Results and Outputs
70
Table 5.2. Average response time for the successive processing of HL7 messages.
TIMING SEQUENCE MESSAGE
AVERAGE RESPONSE
TIME
(IN SEC)
1st A02 (Patient Transfer) 7.71
2nd A01 (Patient Admission) 2.40
3rd A03 (Patient Discharge) 1.52
4th EQQ (Query Message) 3.49
5th A02 (again) 1.24
6th A01 (again) 1.20
7th A03 (again) 0.76
8th EQQ (again) 1.76
Measurement done under following conditions.
System Configuration: 512 MB RAM, Processor P-IV 2.4 GHz, Virtual Memory 768 MB
LAN Configuration: 5 mbps
Software: Normal running applications
5.2 Some Outputs of the Major Functionalities
The HL7 complying module involves much more processing work than user
inputs and outputs. When a message is received or, conversely required to be
composed by the system, the module first generates the specified syntax for that
message. As the specifications are stored in a database, the syntax is composed by
fetching a couple of queries. Once the syntax is ready, the message is either validated
and further processed or composed and delivered as per the requirements.
Though the development and working of the messaging module is independent of
other information systems, but the testing requires some other HL7 Compliant
information systems. Hence the system was tested against an instance of itself
installed on another system. Since both the systems are ICU information systems, a
scenario of two ICUs communicating with each other was assumed. For verifying the
system against the standards messages of the HL7 specification v2.3.1, the dummy
stub was created which was capable of sending any HL7 messages to the desired
system. The system was rigorously tested for various cases, errors were investigated
and debugged, as a result of which modifications and improvements were done. To
Results and Outputs
71
cover the whole testing phase is out of the scope of this dissertation. Some of major
cases are discussed below which also demonstrate the basic functionalities.
5.2.1 HL7 Compliant SANJEEVANI
5.2.1.1 Capability of Sending and Receiving Messages. Both the ICUs are termed
as ICU-1 and ICU-2 respectively and are configured to send messages to each other.
Three routine functionalities were transformed to the unsolicited updates where a
message is automatically composed and send to the specified client. Figure 5.2a
shows one such use case- ‘Add Patient’. In this form, the ‘SAVE’ button is
overloaded to automatic message composition and delivery. The form was filled and
saved at ICU-1. Figure 5.2b shows the arrival of message at ICU-2. The message pops
up at the corner of screen so as not to disturb the normal work of the operator. Figure
5.2c shows the full screen view of the message received. The message provides
information in an HL7 format- first specifying the field name and field value followed
by component-wise description of the same field.
Similarly, the ICU functionalities of ‘Patient Admission’ and ‘Patient Discharge’ are
also overloaded.
Results and Outputs
72
Figure 5.2a. Message Sending Capability of the ICU Information System.
(Message is composed at ICU-1)
Figure 5.2b. Message Receiving Capability of the ICU Information System.
(Message is received at ICU-2)
Results and Outputs
73
Figure 5.2c. Full screen view of the received message.
5.2.1.2 Capability of Querying Other Systems. With each receiving application
(other automated departments), the database contains the department related queries
that are required by the ICU. For example, the ICU may inquire about the
investigation details of the patients from the pathology or may want to get the
patient’s demographics from the registration department. These queries can be easily
added in the database by the administrator against any receiver. Figure 5.3a shows the
‘Query Sender’ interface. By choosing a receiving application, all the pertinent
queries are presented to the user. The user selects the desired query and sends it.
Investigation Details were inquired at the ICU-1 as shown in the figure. ICU-2
received the query message, processed it and sent it back to ICU-1. Note that the
query message gets processed silently without any notification to the operator. The
Query response as received by the ICU-1 is shown in the Figure 5.3b. Note that along
with the investigated information the interface also provides information about
message received and the query sent. ‘Query Status’ indicates that whether the query
was successfully executed. Had there been some error in query execution, the query
status would have indicated the occurrence of an error.
Results and Outputs
74
Figure 5.3a. Querying Capability of SANJEEVANI – Query Sending Interface.
Figure 5.3b. Querying Capability of SANJEEVANI – Query Response Interface.
Results and Outputs
75
5.2.1.3 Capability to Manage Receiving Applications. The basis of using HL7
standard was one of its missions; that is to develop a communicative information
system independent of any other system. This feature is quite important because an
organization often automates its manual departments, or upgrades existing
information systems or even completely changes it. These are the situations where the
loosely coupled systems prove a boon. HL7 Compliant SANJEEVANI adheres to this
loose coupling feature of the standard.
Any number of receiving information systems can be attached to the ICU
information system. The messaging module just needs to know the IP address of the
receiving application’s server. Receiving Application Identity starts with the character
‘z’ as per the ‘rules for site-defined codes’ of HL7 standard. Any meaningful name
can be given to the newly added system. This information can be easily added,
modified and deleted by the administrator of the system. Figure 5.4 shows the
administrator’s interface to manage the receiving applications.
Figure 5.4. Receiving Applications Management Capability- Administrator’s
Managing Interface
Results and Outputs
76
5.2.2 ANAVESHAK
The clinical decision support system provides a drag-n-drop facility to compose a
query on the first hand. It presents a whole hierarchy of ICU schema to the user. The
user can select any field of the database without any concern for the table it belongs.
The fields can be selected in two modes- ‘SELECT’ to simply view the attribute and
‘WHERE’ to filter the records. Figure 5.5a shows the ‘Query Browser’- the interface
to compose a query. It should be noted this interface guides the user thoroughly
through query composition process.
Figure 5.5a. ‘Query Browser’- An interface providing drag-n-drop option for
composing queries.
Figure 5.5b shows a dialog box which guides a user to specify filters for a
particular attribute. Note that this dialog box not only provides a list of operators that
can be used while composing a query but also a guiding tip for that particular field.
Results and Outputs
77
Figure 5.5b. ‘Filter Dialog Box’- an interface to specify filter attribute.
Figure 5.5c. Query Result Interface.
A query to get a list of all Nurses’ Id and their name (along with the patient-Id and
name) under whom patients died in ICU was composed in Figure 5.5a. The result
after execution of the query can be seen in the Figure 5.5c. If the query seems to be a
frequently used query, it can be saved. While if the user doubts at the semantics of the
Results and Outputs
78
query, he/she can move ‘back’ and modify the query. The user may also apply
graphical and statistical analysis on the result set.
One of the important features of the ICU is the observation of a patient. The
doctors or consultants may want to compare one or more observations to see the
correlation between them. Keeping this thing in mind, a special interface is provided
which enables the user to quickly compose a query to view one or more observations.
This interface is shown in the Figure 5.6a. Because viewing observations require a
join of many ICU tables and hence take time to execute, so it is recommended to view
only required observations at a time. The Figure 5.6a composes a query to view two
observations- ‘BP Systolic’ and ‘BP Diastolic’. The query response was graphically
analyzed using XY-Graphs. The graph produced as a result of analysis is shown in the
Figure 5.6b.
Figure 5.6a. Special Interface to quickly view observations.
Results and Outputs
79
Figure 5.6b. Analysis of observations ‘BP Systolic’ vs ‘BP Diastolic’ using XY-
Graphs.
5.3 Chapter Summary
SANJEEEVANI- the ICU information system is equipped with a communicative
module which is capable of sending and receiving standard messages. ICU can now
interact with the other HL7 complaint departments’ information systems. The system
thus eliminates the limitations of the previous information system. The system at ICU
not only provides the required functionalities but also shows satisfactory performance.
Because one cannot expect the ICU staff to run SQL queries, ANAVESHAK- the
decision support system proves a useful tool for information retrieval. Desired queries
can be composed through user-friendly interfaces. The results can be analyzed
statistically and graphically.
The dissertation is concluded in the next chapter. It also shows a glimpse of the
road head.
Chapter 6
Conclusion and Future Enhancements
The dissertation shows how the thesis meets its mission and objectives. The
system was designed to produce a communicative information system and a decision
support system. The system design is elaborated in Chapter 3- System Design.
Innovative features in the form of non-functional requirements are covered in Chapter
4- Novel Features of the Proposed Solution. Chapter 5- Results and Outputs vindicate
the benefits of these features. It also provides a visual overview of the major
functionalities of the system. This chapter concludes the successful completion of the
thesis by bringing out its achievements and worth. It also shows the road ahead by
pointing the scope of improvements in both ICU information system and clinical
decision support system separately.
6.1 Conclusion
In developing countries like India, healthcare organizations often go for partial
automation. The reasons are simple- low budget, time constraints, disinterested
management and unwilling employees. But the consequences are not that simple.
Such a system requires more registration counters, point-of-sales (POS) and user
forms. They ultimately results in alternate sequences of manual and automated
processes in a pipeline. It is obvious to realize that for a smooth flow of a pipeline, all
the processes should have equal processing time. Since manual and automated
processes differ in speed, hence few processes become bottlenecks while others sit
idle for most of the time. This alternate scheme can be removed by adopting complete
automation where the information can flow from one process to the other. Therefore
dumb information systems don’t cater to improve the overall workflow of an
Conclusion and Future Enhancements
81
organization. They ease the work of a smaller sphere by managing the data and easy
retrieval of information.
To sum up, communicative information systems are a genuine need of any
organization. They bring the real power of automation. This would require more
standards to be defined and every systems complying with one or more standards.
This thesis is an endeavor towards complete automation- a workflow with no manual
process. Although it is not ending up in an absolute removal of manual processes, but
it provides a platform where the development of such a system may begin.
An inefficient use of the IT potential is the place where digitized data is not used
properly. Data is collected over time and once a case (or transaction) is over it is
never used again. What’s the point in keeping data in such bulks? It is kept just to
meet the legal issues in case they arrive. It is seldom realized that such a data may
contain enormous knowledge. Various rules and trends may be derived by mining this
data. Rather when it comes to decision making, organizations assign the liability to
one or more people who provides decisions subjective to their knowledge. Human
decision is error prone if not backed with significant experience.
Decision Support Systems are supplementary to information systems so as to mine
knowledge from the past data which may enable the managers to lead the
organization. An elementary Decision Support system should become an integral part
of all the information systems. Departments with critical decision making process
should be equipped with high-tech decision support and expert systems. The thesis
provides an elementary decision support system to the ICU information system which
opens the whole database to the user and provides a way to compare and collate the
desired extracted data to derive knowledge.
In this thesis, the compliance of ICU information system with Health Level Seven
(HL7) has brought many desired features in the ICU and owes greater scope for the
future. Now the ICU can get messages from other departments as well as it can send
its own information to other departments. Prior arrangements can be made soon after
an alert of patient’s arrival is received. The billing of discharged patients can be
managed because of the notifications send by the ICU to the billing department. The
Conclusion and Future Enhancements
82
querying system of the HL7 module will prove an amenity to the ICU staff. An
authorized user can query other systems of the hospital right from the ICU desks.
Thus the information of a patient related to any department can be produced at the
ICU in a few clicks only. Such quickly available information would certainly help the
doctors in taking better decisions.
The clinical decision support system also proves a nifty tool to the ICU. First of
all it presents the whole schema in a hierarchical order. This not only clears the
picture of the information structure but encourages the user to extract information.
Desired information can be fetched by composing queries through easy drag- and-
drop features. The user is guided through out the query composition process and the
system safe-guards against any possible errors. The system can be used from various
perspectives. A doctor may use it to fetch cases similar to a given case and so get the
effective diagnosis and treatment. A resident or junior doctor might get case studies
for learning purposes. Students may use as well for observing some unknown
relationship between various investigations, treatments and observations. It can be
used by ICU managers to assess the performance of the ICU staff by examining the
statistics of adverse events or success rate against its employees.
In all, it is hoped that the project will better organize the information and mine
knowledge, so as to help the doctors to save life.
6.2 Future Enhancements
The road ahead may go in two different directions- firstly to broaden the scope of
the problem and secondly to enhance the existing solution. In other words, our
mission- “To organize medical information and to mine knowledge from it, to assist
the doctors to save life” can be put forward by either defining entirely new objectives
or by improving the present one. As in other chapters, the discussion is pivoted on the
information system and clinical decision support system separately.
Conclusion and Future Enhancements
83
6.2.1 HL7 Compliant SANJEEVANI The existing solution can be improved by redesigning the ICU database. The
reason being the ICU database is incapable of harnessing the full benefit of HL7
standard. An HL7 message can contain about 500 fields, but the ICU database
supports not even 25 % of it. The new database should be compatible to the standard.
This can be achieved by designing the database using Reference Information Model
(RIM) guidelines [RIM-04]. RIM uses UML to represent a complete and static view
to HL7 design and requirements.
Another enhancement would be to increase the number of messages that the HL7
module can accept and process. This would require the HL7 specification database to
be populated with new message details. In case of unsolicited messages, only database
population will do, but for query messages the application program needs to be
appended with that message processor program. Consequent to this improvement one
may think of providing an HL7 Specification Managing Tool which can provide the
various details of current HL7 version as well as can easily upgrade the standard to a
new version. In such a case, a guided operator can modify the specification easily and
there will not be any need of the maintenance team to intervene.
For broadening the scope of ICU automation, other medical standards can be
adopted [please refer Table 2.1 Consolidated Health Informatics Domains and
standards]. For transfer of medical images, DICOM is the one and only standard. The
ICU information system can comply with DICOM to access images from radiological
and other departments.
ICU uses a wide variety of electronic equipments and monitoring devices. The
readings are taken and noted from time and time. Even the readings from these
devices can be captured by the ICU information system by connecting it to these
devices. This would require the compliance of devices as well as ICU information
system to a common standard.
Conclusion and Future Enhancements
84
HL7 can itself be used in a broader scope. One improvement would be to hoist an
HL7 server which can serve requests to mobile devices. Mobile devices can be
equipped with an HL7 browser and doctors carrying them can access patient’s
information from anywhere. The communication can be the other way also where the
mobile devices would be getting alerts and messages regarding critical events [Park-
05].
6.2.2 ANAVEHSHAK The first improvement which can be given to the present CDSS would be to
provide a web-interface. If a web server can be hoisted running the CDSS application,
any user can harness its benefit from anywhere. Any number of users can access the
application at a time. Moreover no special softwares are required to be installed with
individual machine- only web browsers will do. But such a system needs to add a
module of user authentication.
The CDSS presents the whole ICU schema to the user. It may be required by the
ICU managers and doctors to analyze other databases like Pathology or Pharmacy,
simultaneously with the ICU database. For such a case, the XML configuration file
needs to be updated with the information of other databases.
Yet another improvement would be including more statistical and graphical
techniques. The current system provides ‘Measures of Centrality’ (that is Mean,
Median, and Mode etc.) in statistical analysis. Other measures like, ‘Measures of
Relative Location’ (like Percentile and Z-Score) can be incorporated in the
application [Marchini-06]. Similarly, graphical analysis can be enhanced by adding
Quality Control Charts like R-Chart, S-Chart and Median Chart.
The CDSS is developed on an evolutionary model, so the idea of information
extraction could also be refined as well as moved towards predictions. Various
algorithms can be used to transform the present information-extraction system to full
cases-extraction system (CBR). Such a CBR system would be provided with a partial
case of the ICU and it would fetch a ranked set of all similar cases. The user can then
choose the percentage of cases required for his study and analysis.
Conclusion and Future Enhancements
85
A new objective can as well be framed to develop a predictive system. An expert
system can be developed which given a case would predict some parameters like
required investigations and observations or probable diagnosis. An expert system can
work on an initial set of rules which can always be augmented with new rules based
on the experience of the system. It should be noted that new rules should only be
added after an experts’ assessment.
There are numerous directions of enhancement to our present system. Our vision
is only confined by our sight.
APPENDIX-A: Installation Guide
86
APPENDIX – A
Installation Guide
This appendix contains instructions for installing HL7 Compliant SANJEEVANI
2.0 and ANAVASHEK 1.0. This will include downloading of required software,
installing and configuring them so as to provide a platform to run the product.
A.1 Target Audience In general, any one who is interested in this project can read this user guide. But, the
intended audiences of this Installation Guide are developers, and system
administrator.
A.2 Software Requirements
1. Java 5
2. MySQL 5
3. MySQL JDBC connector 3.1.12
4. JFreeChart
5. JSci
6. JDOM
In addition to the above, the softwares which are used for development is listed
below. This will be helpful for the maintenance of SANJEEVANI and
ANAVESHAK.
7. NetBeans 5.5
8. MySQL Query Browser 1.1.18
SANJEEVANI and ANAVESHAK is packaged into a Java Archive (jar) file and
two Database backup File. SANJEEVANI requires a configuration file also for
logging. All the files are listed below.
1. HL7CompliantICUProject.jar
2. CDSS.jar
APPENDIX-A: Installation Guide
87
3. hl7specification.sql
4. icu.sql
5. ICUlogging.properties
A.3 Software Installation Sites
All the software listed in section above are open source and free. The download
sites of software are listed as following
1. Java 5 can be downloaded from http://java.sun.com/javase/downloads/
2. MySQL 5 can be downloaded from
http://dev.mysql.com/downloads/mysql/5.0.html
3. JDBC connector 3.1.12 can be downloaded from
http://dev.mysql.com/downloads/connector/j/3.1.html
4. MySQL Query Browser can be downloaded from
http://dev.mysql.com/downloads/gui-tools/5.0.html
5. NetBeans 5.5 can be downloaded from
http://www.netbeans.info/downloads/index.php.
6. JFreeChart 1.0.0 can be downloaded from
http://www.jfree.org/jfreechart/index.php
7. JDOM 1.1 can be downloaded from http://jdom.org/downloads/index.html
8. JSci can be donloaded from http://jsci.sourceforge.net/
A.4 Hardware Requirements
The minimum hardware required is
1. Intel or AMD Mother Board
2. Pentium III Processsor
3. 256 MB RAM
4. 20 GB HDD
5. Lan Card or Modem
APPENDIX-A: Installation Guide
88
A.5 Installation of the database
1. Install MySQL5. MySQL 5 installation: Its detail is given in the downloaded
package of MySQL 5.
2. User account creation. Create a user account. This account will be used by
the applications to access the database. The username and the password for
this account should be same as in the applications.
3. Database creation. Create two database with the name hl7specification and
icu.
4. Loading database with the schema. The database is loaded from the
databases schema the files hl7specification.sql and icu.sql. With the help of
the following command the schema is loaded.
c:\>mysql -u root -p hl7specification< hl7specification.sql
and
c:\>mysql -u root -p icu< icu.sql
Both the files should be accessible from the path of the command prompt. The
system asks for the password before loading the database schema.
A.6 Installation of the Applications
1. Installation of Java 5. Install JDK 1.5 and JRE 1.5 form the downloaded Java
5 bundle by referring to their instructions.
2. Setting the Class path. Put the HL7CompliantICUProject.jar and CDSS.jar
file in the classpath. All the files can be put in the JRE_HOME\lib\ext
directory, to automatically include them in classpath. Here JRE_HOME is the
folder where JRE is installed. The default directory is C:\Program
Files\Java\jre1.5.0_05.
3. Configuration file Settings. Create a folder c:\icutemp\config and copy the
ICUlogging.properties file in the folder. This file can be modified to redefine
FileHandler and Error FileHandler Pattern to the location of the log files.
Create two more folders in the directory where the application program is
stored. The folders should be named “MessageReceived” and “MessageSend”.
APPENDIX-A: Installation Guide
89
The folders are used by SANJEEVANI for storing the messages received and
sent respectively.
A.7 Starting the Application
Write two batch files which will start the applications. The contents should be as
below but with correct paths.
For HL7 Complaint SANJEEVANI
@Echo off
java –jar “c:\Program Files\Java\jre1.5.0_05\lib\ext\ HL7CompliantICUProject.jar”
c:\icutemp\config\ICUlogging.properties
For ANAVESHAK
@Echo off
java –jar “c:\Program Files\Java\jre1.5.0_05\lib\ext\ CDSS.jar”
Double clicking the batch file, will initialize and start the application.
APPENDIX-B: Views Used by ANAVESHAK
90
APPENDIX – B
Views Used by ANAVESHAK
ANAVESHAK uses views to present ICU schema in a meaningful way. All the
views are listed here along with the fields they contain. The list would be useful in
understanding the ICU Schema and to browse the required field in the CDSS.
Table B.1. Details of ICU Views used by ANAVESHAK
VIEW NAME FIELD NAME
Patient Id
Daily Care Id
Urine Substance
Urine Value
Units
Minimum Normal Value
Urine Details
Maximum Normal Value
Patient Id
Daily Care Id
Name of the drug
Dose
Drug Route
Frequency
Treatment Details
Time
Patient Id
Daily Care Id
Target
Minimum Target Value
Maximum Target Value
Units
Target Hours
Target Reached
Hours to reach target
Target Details
Reason
Staff Details Daily Care Id
APPENDIX-B: Views Used by ANAVESHAK
91
Member Id
Staff Name
Staff Designation
Patient Id
Patient's Name
Age
Height
Weight
Marital Status
Occupation
Annual Income (In Rs)
Blood Group
Telephone Number
Address Line1
Address Line2
City
State
Country
Date of Admission to Hospital
Date of Admission to ICU
Admission Under Doctor
Relative's Name
Relationship
Admission History
Discharge Status
Date of Discharge from ICU
Date of discharge from Hospital
Number of days in ICU
Discharged To
Relative Satisfaction
Discharge Summary
Patient Admission-Discharge
Details
Patient Alive After Discharge (Days)
Patient Id
Daily Care Id
Observation Name
Time
Observations Details
Units
APPENDIX-B: Views Used by ANAVESHAK
92
Minimum Normal Value
Maximum Normal Value
Patient Id
Daily Care Id
Investigation Name
Sent Date
Result
Units
Minimum Normal Value
Maximum Normal Value
Investigation Details
Summary
Patient Id
Daily Care Id
Mode
Shift
Name of Drug/Fluid
Intake Route
Intake Amount
Intake Start Time
Intake End Time
Urine
Vomit
Stool
Fluids Details
Insensible Loss
Daily Care Id Diagnosis Details
Diagnosis
Daily Care Id
Date
Bed
Bed Number
Intubated Date-Time
Extubated Date-Time
Ventilation Start Time
Ventilation End Time
Weaning Start Time
Weaning End Time
Daily Care Details
ETT_NO
APPENDIX-B: Views Used by ANAVESHAK
93
Length
Morning Cuff Pressure
Evening Cuff Pressure
Night Cuff Pressure
Bed Sore On Arrival
Glasgow Coma Score
Acute Physiology And Chronic Health II (APACHE II)
Sequential Organ Failure Assessment (SOFA)
Multiple Organ Dysfunction Score (MODS)
Revised Trauma Score (RTS)
ALI
RiskA
RiskB
RiskC
RiskD
Total Risk Score
Patient Id
Daily Care Id
Specimen
Sent Date
Received Date
Organism Grown
Culture Sensitivity Detaiils
Summary
Daily Care Id Complication Details
Complication
Allergy Details Allergy Details
Allergy
Patient Id
Daily Care Id
Adverse Event Adverse Event Details
Event Cause
APPENDIX-C: List of HL7 Message Components used by HL7 Compliant SANJEEVANI
94
APPENDIX – C
List of HL7 Message Components used by HL7 Compliant SANJEEVANI
This Appendix provides an overview of the different messages and message
components used by HL7 Compliant SANJEEVANI. This would be useful for
understanding the scope of the system while interacting with other information
systems.
SANJEEVANI uses messages shown in Table C.1. The table also shows the
segments that are carried by each message. Since each segment is not required every
time, hence the optional field is also shown.
Table C.1. HL7 Messages (along with their segments) used by SANJEEVANI
MESSAGE SEGMENT REQUIRED/OPTIONAL
MSH- Message header R
EVN- Event type R
PID- Patient identification R
PD1- Patient additional demographic O
NK1- Next of kin/ Associated parties O
PV1- Patient visit R
PV2 -Patient visit additional
information O
DB1- Disability O
OBX- Observation/result O
AL1- Allergy Information O
DG1- Diagnosis Information O
DRG- Diagnosis Related Group O
PR1- Procedures Segment O
ROL- Role 12 O
GT1- Guarantor O
IN1- Insurance O
A01 - Admit/visit
notification
IN2- Insurance Additional O
APPENDIX-C: List of HL7 Message Components used by HL7 Compliant SANJEEVANI
95
Information
IN3- Insurance Additional
Information Certifacate O
ACC- Accident Information O
UB1- Universal Bill Information O
UB2- Universal Bill 92 Information O
MSH- Message header R
EVN- Event type R
PID- Patient identification R
PD1- Patient additional demographic O
PV1- Patient visit R
PV2 -Patient visit additional
information O
DB1- Disability O
A02- Transfer a patient
OBX- Observation/result O
MSH- Message header R
EVN- Event type R
PID- Patient identification R
PD1- Patient additional demographic O
PV1- Patient visit R
PV2 -Patient visit additional
information O
DB1- Disability O
DG1- Diagnosis Information O
DRG- Diagnosis Related Group O
PR1- Procedures Segment O
ROL- Role 12 O
A03- Discharge/end visit
OBX- Observation/result O
MSH- Message header R
MSA- Message Acknowledgement R ACK- General
acknowledgment ERR- Error O
MSH- Message header R
EQL- Embedded Query Language R EQQ- Embedded Query
Language DSC- Continuation Pointer O
MSH- Message header R
MSA- Message Acknowledgement R
TBR- Tabular Data
Response
ERR- Error O
APPENDIX-C: List of HL7 Message Components used by HL7 Compliant SANJEEVANI
96
QAK- Query Acknowledgement R
RDF - Table Row Definition R
RTD- Table Row Data R
DSC- Continuation Pointer O
The segments shown in Table C.1 are elaborated in Table C.2 to show the fields they
contain.
Table C.2. HL7 Segments along with their fields.
SEGMENT FIELD
Set ID - DB1
Disabled Person Code
Disabled Person Identifier
Disabled Indicator
Disability Start Date
Disability End Date
Disability Return to Work Date
DB1- Disability
Disability Unable to Work Date
DSC- Continuation Pointer Continuation Pointer
Query Tag
Query/Response Format Code
EQL Query Name EQL- Embedded Query Language
EQL Query Statement
ERR- Error Error Code And Location
Event Type Code
Recorded Date/Time
Date/Time Planned Event
Event Reason Code
Operator ID
EVN- Event type
Event Occurred
Message Control ID
Acknowledgement Code
Text Message
Expected Sequence Number
MSA- Message Acknowledgement
delayed Acknowledgement Type
APPENDIX-C: List of HL7 Message Components used by HL7 Compliant SANJEEVANI
97
Error Condition
Field Separator
Encoding Characters
Sending Application
Sending Facility
Receiving Application
Receiving Facility
Date/Time Of Message
Security
Message Type
Message Control ID
Processing ID
Version ID
Sequence Number
Continuation Pointer
Accept Acknowledgment Type
Application Acknowledgment Type
Country Code
Character Set
Principal Language Of Message
MSH- Message header
Alternate Character Set Handling Scheme
Date/Time of Birth
Sex
Race
Primary Language
Marital Status
Religion
Ethnic Group
Citizenship
Ambulatory Status
Set ID - NK1
Name
Relationship
Address
Phone Number
Business Phone Number
NK1- Next of kin/ Associated parties
Contact Role
APPENDIX-C: List of HL7 Message Components used by HL7 Compliant SANJEEVANI
98
Start Date
End Date
Next of Kin / Associated Parties Job Title
Next of Kin / Associated Parties Job Code/Class
Next of Kin / Associated Parties Employee Number
Organization Name - NK1
Nationality
Living Arrangement
Publicity Code
Protection Indicator
Student Indicator
Mother’s Maiden Name
Contact Reason
Contact Person’s Name
Contact Person’s Telephone Number
Contact Person’s Address
Next of Kin/Associated Party’s Identifier
Job Status
Handicap
Contact Person Social Security Number
Living Dependency
Set ID - OBX
Value Type
Observation Identifier
Observation Sub-ID
Observation Value
Units
References Range
Abnormal Flags
Probability
Nature of Abnormal Test
Observ Result Status
Date Last Obs Normal Values
User Defined Access Checks
Date/Time of the Observation
Producer's ID
OBX- Observation/result
Responsible Observer
APPENDIX-C: List of HL7 Message Components used by HL7 Compliant SANJEEVANI
99
Observation Method
Living Arrangement
Publicity Code
Protection Indicator
Student Indicator
Handicap
Living Dependency
Patient Primary Facility
Patient Primary Care Provider Name & ID No.
Living Will
Organ Donor
Separate Bill
PD1- Patient additional demographic
Duplicate Patient
Set ID - PID
Patient ID
Patient Identifier List
Alternate Patient ID - PID
Patient Name
Mothers Maiden Name
Date/Time of Birth
Sex
Patient Alias
Race
Patient Address
County Code
Phone Number - Home
Phone Number - Business
Primary Language
Marital Status
Religion
Patient Account Number
SSN Number - Patient
Drivers License Number - Patient
Mothers Identifier
Ethnic Group
Birth Place
PID- Patient identification
Multiple Birth Indicator
APPENDIX-C: List of HL7 Message Components used by HL7 Compliant SANJEEVANI
100
Birth Order
Citizenship
Veterans Military Status
Nationality
Patient Death Date and Time
Patient Death Indicator
Set ID - PV1
Patient Class
Assigned Patient Location
Admission Type
Preadmit Number
Prior Patient Location
Attending Doctor
Referring Doctor
Consulting Doctor
Hospital Service
Temporary Location
Preadmit Test Indicator
Re-admission Indicator
Admit Source
Ambulatory Status
VIP Indicator
Admitting Doctor
Patient Type
Visit Number
Financial Class
Charge Price Indicator
Courtesy Code
Credit Rating
Contract Code
Contract Effective Date
Contract Amount
Contract Period
Interest Code
Transfer to Bad Debt Code
Transfer to Bad Debt Date
PV1- Patient visit
Bad Debt Agency Code
APPENDIX-C: List of HL7 Message Components used by HL7 Compliant SANJEEVANI
101
Bad Debt Transfer Amount
Bad Debt Recovery Amount
Delete Account Indicator
Delete Account Date
Discharge Disposition
Discharged to Location
Diet Type
Servicing Facility
Bed Status
Account Status
Pending Location
Prior Temporary Location
Admit Date/Time
Discharge Date/Time
Current Patient Balance
Total Charges
Total Adjustments
Total Payments
Alternate Visit ID
Visit Indicator
Other Healthcare Provider
Prior Pending Location
Accommodation Code
Admit Reason
Transfer Reason
Patient Valuables
Patient Valuables Location
Expected Admit Date/Time
Expected Discharge Date/Time
Estimated Length of Inpatient Stay
Actual Length of Inpatient Stay
Visit Description
Referral Source Code
Previous Service Date
Employment Illness Related Indicator
Purge Status Code
PV2 -Patient visit additional information
Purge Status Date
APPENDIX-C: List of HL7 Message Components used by HL7 Compliant SANJEEVANI
102
Special Program Code
Retention Indicator
Expected Number of Insurance Plans
Visit Publicity Code
Visit Protection Indicator
Clinic Organization Name
Patient Status Code
Visit Priority Code
Previous Treatment Date
Expected Discharge Disposition
Signature on File Date
First Similar Illness Date
Patient Charge Adjustment Code
Recurring Service Code
Billing Media Code
Expected Surgery Date & Time
Military Partnership Code
Military Non-Availability Code
Newborn Baby Indicator
Baby Detained Indicator
Query Tag QAK- Query Acknowledgement
Query Responce Status
Number of coloumns per row RDF- Table Row Definition
Coloumn Description
RDT- Table Row Definition Coloumn Value
Table C.3 shows the various HL7 specified datatypes and their components.
Table C.3. Classification and components of HL7 Datatypes.
DATATYPE CLASSIFICATIONS COMPONENTS
Identifier
Text
Name of coding system
Alternate identifier
Alternate text
CE- Coded Element COMPOSITE
Name of alternate coding
system
APPENDIX-C: List of HL7 Message Components used by HL7 Compliant SANJEEVANI
103
Message type CM- Composite COMPOSITE
Trigger event
ID
Check digit
Code identifying the check
digit scheme employed
Assigning authority
Identifier type code
CX- Extended Composite ID with
check digit COMPOSITE
Assigning facility
License number
Issuing state DLN- Driver’s license number COMPOSITE
Expiration date
DT- Date SIMPLE
Entity identifier
namespace ID
Universal ID EI- Entity Identifier COMPOSITE
Universal type
Financial class FC- Financial class COMPOSITE
Effective date
Namespace ID
Universal ID HD- Hierarchic designator COMPOSITE
Universal ID type
ID- Coded Values for HL7 tables HL7 DEFINED CODES
IS- Coded value for user USER DEFINED
CODES
Job Code JCC- Job Code/ Class COMPOSITE
Job Class
NM- Numeric SIMPLE
Point of care
Room
Bed
Facility
Location status
Floor
PL- Person Location COMPOSITE
Location description
Processing ID PT- Processing Type COMPOSITE
Processing mode
APPENDIX-C: List of HL7 Message Components used by HL7 Compliant SANJEEVANI
104
HL7 item number
HL7 data type
RCD- Row Coloumn Definition
COMPOSITE
Maximum coloumn width
SI- Sequence ID SIMPLE
ST- String SIMPLE
TN- Telephone Number SIMPLE
TS- Time Stamp SIMPLE
Version ID
Internationalization code VID- Version Identifier COMPOSITE
International version ID
Street address
Other designation
City
State or province
Zip or postal code
Country
Address type
Other geographic
designation
County/parish code
Census tract
XAD- Extended address COMPOSITE
Address representation
code
ID Number
Name
Given name
Middle initial or name
Suffix
Prefix
Source table
Assigning authority
Name type code
Identifier check digit
Code identifying the check
digit scheme employed
Identifier type code
XCN- Extended composite ID number
and name
COMPOSITE
Assigning facility
APPENDIX-C: List of HL7 Message Components used by HL7 Compliant SANJEEVANI
105
Name representation code
ID number
Check digit
Code identifying the check
digit scheme employed
Assigning authority
Identifier type code
Assigning facility ID
Name representation code
Organization name
XON- Extended composite name and
ID number for organizations
COMPOSITE
Organization name type
code
Name
Given name
Middle initial or name
Suffix
Prefix
Degree
Name type code
XPN- Extended person name COMPOSITE
Name representation code
Any text
Telecommunication use
code
Telecommunication
equipment type
Email address
Country code
Area/city code
Phone number
XTN- Extended telecommunications
number COMPOSITE
Extension
For more details, refer HL7 specification v2.3.1.
References
1. [Aden-05] Marco Eichelberg, Thomas Aden, and Jo¨ Rg Riesmeier, “A Survey
and Analysis of Electronic Healthcare Record Standards”, ACM Computing
Surveys, Vol. 37, No. 4, December 2005, pp. 277–315.
2. [Amicas] Amicas- An organization providing Radiology, medical image and
information management solution, www.amicas.com
3. [Angehrn-98] Albert A. Angehrn and Soumitra Dutta, “Case-Base Decision
Support”, Communications of the ACM, May 1998.
4. [Boehm-00] Barry Boehm, “Spiral Development: Experience, Principles, and
Refinements”, Spiral Development Workshop, February 9, 2000, SPECIAL
REPORT, CMU/SEI-2000-SR-008.
5. [Booch-99] I.Jacobson, G. Booch, J. Rumbaugh, “The Unified Software
Development Process”, Addison Wesley, 1999.
6. [Caleb-Solly-03] Praminda Caleb-Solly, “Clinical Decision Support Systems”,
Seminar for the Health Informatics, Intelligent Computer Systems Centre,
2003.
7. [Clements-03] P. Clements, “Why Is Software Architecture Important?”,
Seminar at IIIT-Allahabad, January 2007.
8. [Deitel-04] H.M. Deitel, P.J. Deitel, T.R. Nieto, T.M. Lin, P. Sadhu, “XML
How to Program”, PEARSON Education, 2004.
9. [Ding-02] HUA DING, X-K.W., “Research on Algorithm of Decision Tree
Induction”, First International Conference on Machine Learning and
Cybernetics, 2002, Beijing, IEEE.
References
107
10. [Fernandez-05] Eduardo Fernandez, Tami Sorgente, “An analysis of modeling
flaws in HL7 and JAHIS”, ACM Symposium on Applied Computing, 2005.
11. [Gamma-00] Gamma, Erich, Helm, Richard, Johnson, Ralph, “Design
Patterns: Elements of Reusable Object-Oriented Software”, Addison Wesley,
England, 2000.
12. [Gopal-06] R.Amirdha Gopal, “Information System for Assessment of
Functioning of Intensive Care Unit and Rule Extraction with ID3 Algorithm”
Thesis, 2006, IIIT-Allahabad.
13. [Freeman-04] Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates,
“Head First Design Patterns”, O’REILLY, October, 2004.
14. [HL7-99] Health Level Seven Organization, HL7 Standard v.2.3.1,
www.hl7.org.
15. [Kaiser-06] Kaiser Family Foundation, “Comparing Projected Growth in
Health Care Expenditures and the Economy”, Healthcare Survey, May 2006,
http://www.kff.org/insurance/snapshot/chcm050206oth2.cfm
16. [Lee-01] Grace S Loo, Philip C H Lee, “A Soft Systems Methodology Model
for Clinical Decision Support Systems”, 2001 IEEE.
17. [Lethbridge-04] T. C. Lethbridge and Robert Laganiere, “Object-oriented
Software Engineering: Practical Software Development using UML and
Java”, Tata McGraw-Hill, 2004.
18. [Marchini-06] Jonathan Marchini, “Introduction to Probability Theory and
Statistics for Psychology and Quantitative Methods for Human Sciences”,
Lectures and Notes Slides, 2006,
http://www.stats.ox.ac.uk/%7Emarchini/phs.html
References
108
19. [Navathe-03] R. Elmasri, S. B. Navathe, “Fundamentals of Database
Systems”, PEARSON Education, 2003.
20. [NeoTool] NEOTOOL- Healthcare Integration Solutions, “The HL7
Evolution”, white papers, www.neotool.com
21. [Park-05] Jinwook Choi, Sooyoung Yoo, Heekyong Park , “Seamless Real-
time Clinical Data Integration for Mobile Clinical Information System”,
Proceedings of the 21st International Conference on Data Engineering (ICDE
’05), 2005 IEEE.
22. [RIM-04] HL7 Reference Information Model, v 02-04 (7/28/2004),
http://www.hl7.org/library/data-model/RIM/C30204/rim.htm#rimBallImplic
