International Journal of Medical Informatics 49 (1998) 89 – 96

Availability of software services for a hospital information

system

Norihiro Sakamoto
Di6ision of Medical lnformatics, Kyushu Uni6ersity Hospital, Futuoka, Japan

Abstract

Hospital information systems (HISs) are becoming more important and covering more parts in daily hospital
operations as order-entry systems become popular and electronic charts are introduced. Thus, HISs today need to be
able to provide necessary services for hospital operations for a 24-h day, 365 days a year. The provision of services
discussed here does not simply mean the availability of computers, in which all that matters is that the computer is
functioning. It means the provision of necessary information for hospital operations by the computer software, and
we will call it the availability of software services. HISs these days are mostly client – server systems. To increase
availability of software services in these systems, it is not enough to just use system structures that are highly reliable
in existing host-centred systems. Four main components which support availability of software services are network
systems, client computers, server computers, and application software. In this paper, we suggest how to structure
these four components to provide the minimum requested software services even if a part of the system stops to
function. The network system should be double-protected in stratus using Asynchronous Transfer Mode (ATM) as
its base network. Client computers should be fat clients with as much application logic as possible, and reference
information which do not require frequent updates (master files, for example) should be replicated in clients. It would
be best if all server computers could be double-protected. However, if that is physically impossible, one database file
should be made accessible by several server computers. Still, at least the basic patients’ information and the latest
clinical records should be double-protected physically. Application software should be tested carefully before
introduction. Different versions of the application software should always be kept and managed in case the new
version has problems. If a hospital information system is designed and developed with these points in mind, it’s
availability of software services should increase greatly. © 1998 Elsevier Science Ireland Ltd. All rights reserved.

Keywords: Hospital information systems; Network service; Software services

1. Introduction of clinical operations [1]. It will probably

become essential when recording and saving
Hospital Information Systems (HISs) are electronic charts are legally recognised and
becoming one of the most important aspects are introduced to clinics. Under those cir-

1386-5056/98/$19.00 © 1998 Elsevier Science Ireland Ltd. All rights reserved.

PII S1386-5056(98)00015-X
90 N. Sakamoto / International Journal of Medical Informatics 49 (1998) 89–96
cumstances, HISs must be available whenever
patients are examined. At hospitals, medical
examinations take place 24 h a day, 365 days
a year. Thus, the HIS, as the hospitals’ core,
will be expected to be reliable 24 h a day, 7
days a week. Of course, 24-h-systems have
been used in banking and telecommunica-
tions. Could we just borrow their systems to
create reliable hospital information systems?
The existing architecture of the systems does
not seem enough.
Until now, the study of reliability has been
carried out mainly on the mainframe. Most
24-h-systems now use mainframes, due to
operations of banking and others are usually
centre-focused by nature. For example, for
an administration system of a bank account,
any information on a particular account is
handled uniquely by a central host computer.
Then the information of withdrawal and re-
ceipt of the account need to be transacted at
once. Otherwise, consistency of the adminis-
tered information will be lost and contradic-
tions will occur. In other words, transactions
done simultaneously might crash and only
one of them is executed, causing contradic-
tions in the result. For example, there is an
account with $10000. If one tries to withdraw
$5000 from a bank machine and the other
tries to withdraw $7000 from a different bank
machine at the same time, only one of them
would succeed in the transaction. Or, just to
get a bank statement of an account, the
information needs to come from the central
host computer, not from the particular bank
machine itself. Thus, in most cases, centre-fo-
cused systems which allow their terminals to
only show and input information are desir-
able. Then, when reliability of a system is
concerned, it can be divided into the reliabil-
ity of its central host computer, and that of
its connections. However, in most cases, the
networks are simple one-to-one connections,
making the reliability of its central host com-
puter the most important.
For most hospital information systems up
till now, patients’ accounting was the main
job. In that case, administrations are per
patient, and centre-focused systems like on-
line systems of banks are suitable as it needs
to check repetitious examinations and pre-
scription information. User terminals are
used only to input orders to claim insurance,
and calculations and other transactions are
done by the central host computer. Thus, the
reliability of finance-centred HIS has to be
quite high, as it is the same as that of existing
host computers.
However, in recent years, the down sizing
of systems has become popular, and system
architectures with client-server style are more
popular than those that are host computer
centred. Also, the transactions done by HISs
are developing from merely the calculation of
fees to electrical medical charts. By introduc-
ing an order entry system with high quality
reference to patients’ history, electronic
charts can handle various types of informa-
tion. In other words, since an order entry
system has been introduced, most operations
in the examination area of hospital informa-
tion systems are done by client computers [2].
In these systems, the central server (host)
computer works mainly as a data base server,
finding and sending data according to re-
quests of client computers. Also, it registers
and updates data according to requests of
client computers. As processing and display-
ing the data are done by client terminals,
terminals’ responsibility is higher than in a
centrefocused system. Accordingly, changes
in computer system architectures and opera-
tions handled by HISs have increased the
number of client–server systems in HISs.
Compared with centre-focused system ar-
chitectures, client–server systems rely less on
the expensive central server (host) computer
and more on the less expensive client com-
puters. So, a whole system costs less than a
 N. Sakamoto / International Journal of Medical Informatics 49 (1998) 89–96
centre-focused system. Also, it deals easily
with expansion and changes in the operation
by dispersing the jobs to several servers or
adding more necessary servers. On the other
hand, client–sever systems have less security
or reliability compared with centre-focused
systems. In a centre-focused system, increase
in reliability of its central host computer di-
rectly leads to increase in reliability of the
whole system. However, in a client–server
system with its basic functions distributed to
servers, reliability of every server needs to be
increased to increase reliability of the whole
system. Increased reliability of its network
system to connect all those computers is also
important. So, to obtain equal reliability to
centre-focused systems in client-server style
systems, many new problems need to be
considered.
This paper points out reliability matters
that may lead to problems in developing a
high-functional order entry system as a
client – server system with functions between
existing order entry system and electronic
medical charts, and suggests solutions.
2. Availability of software services
The gauge of reliability of a HIS is not
how long the computers last but how certain
the system provides its service. This paper
will call this gauge ‘availability of software
services’, and will distinguish it from the sim-
ple availability of computers. Availability of
software services of a HIS means users (that
is, doctors and nurses) can execute necessary
work to examine patients by using a client
computer of the system. There are at least
two reasons why availability of software ser-
vices needs to be distinguished from the
availability of computers. One is that soft-
ware used in a HIS is not usually for general
use. It needs to be newly developed or cus-
91
tom-made for each hospital. Operations of
the computer itself and that of the software
service may often differ. Those newly devel-
oped or expanded software often contain
bugs, and that may cause the software service
to get stuck, without any defects on the com-
puter. Moreover, as it has several professions
of users and it supports different tasks, fre-
quent changes in software are required. Every
time a change occurs, it may threaten
availability of software services. The second
reason is, as it is stated earlier, each comput-
er’s work status and availability of software
services may not coincide. As several servers
are involved, the break down of one of the
servers could be covered up by another
server. However, if servers strongly rely on
each other, break down of one server could
lead to that of the whole service of the sys-
tem. Thus, when developing a client–server
system, it is necessary to put the emphasis on
availability of software services more than on
the availability of computers. For example, if
services necessary for a hospital operation
can be executed even when its hospital infor-
mation system’s hardware stops for some rea-
son, reliability of the system is very high.
3. Requirement issues
The minimum requirement of a HIS is to
be available to its users 24 h a day, 365 days
a year. Hospital operation is divided into
many sections, and at least for now, all of
those sections are not automatically-operated
and included in the HIS. Thus, even if the
HIS stops, each section can still function, and
minimum operations can take place. So, a
HIS needs to be able to function to ease
hospital operation even in case of break
down in a part of the server. The following
services by HISs are expected under normal
circumstances:
92 N. Sakamoto / International Journal of Medical Informatics 49 (1998) 89–96
“ ablility to register new patients’ informa-
tion (name, address, patient number, etc.);
“ ablility to look up patients by patient’s
name, patient number, etc.;
“ ablility to get reference of examination
history, test history, prescription history,
etc.;
“ ablility to enter prescription and test
orders;
“ ablility to send entered orders to related
sections of the system.
Until now, it was common to operate by
hand when a HIS had failed. That is because
existing HISs are centre focussed, and all
software services need to be stopped when its
central server stops. However, as it is stated
before, a client–server system can continue to
provide services when its central server stops.
With that assumption, the following func-
tions, at least, must be atainable in cases of
emergencies:
“ ability to register of new patients’ informa-
tion (name, address, patient number, etc.);
“ ability to look up patients by patients’
name, patient number, etc.;
“ ability to obtain reference of the up-dated
examination history, test results, prescrip-
tion, etc.;
“ ablility to enter prescription and test
orders;
“ ablility to print the entered orders;
“ ablility to automatically register the en-
tered orders as records after the system
recovers.
To be able to give reference of up-dated
examination history, test results and prescrip-
tions is a useful function. However, it is not
essential right now, because hand written
charts are always required. In most cases,
examinations of patients can take place with-
out reference to the HIS. However, it will
become essential as electronic charts become
more common and HISs become the core of
hospital operations. Also, to enter orders
manually when the system stops, it is neces-
sary to have prescriptions and application
forms readily available. It is also a nuisance
for the user (i.e. the doctor) to keep all the
documents and remember where they are.
Moreover, after a long period of normal
functioning of a HIS, its users may become
too used to enter orders by using information
(medication data, amount of medication, pre-
vious test-results, etc.) from the system to
perform operations without its help.
Client–server systems can be divided into
four major components from the view point
of availability of software services. Those are
server computers, client computers, network
systems, and application software. Thus,
availability of software services of client–
server systems in a HIS needs to be deter-
mined by availability and relation of each of
those components. To maintain the system
and to retain availability of software services,
it is better to keep the dependency among the
components to a minimum. The stronger the
dependency, the more complex the whole sys-
tem would become. Not only one compo-
nent’s failure would lead to a failure of the
whole system, but also some acts taken to
improve the reliability of one component
could decrease that of another, or even that
of the whole system. So, we suggest to in-
crease the reliability of each component by
developing a system with its components as
independent from each other as possible. The
next section will explain how to increase
availability of software services separately on
each component.
4. Solutions
4.1. Network system
A network system is the basic component
of a client–server systems’ architecture. The
 N. Sakamoto / International Journal of Medical Informatics 49 (1998) 89–96
network system itself does not provide direct
service to its users, but if the network system
stops, all servers cannot function because
they have no connections with their clients.
Thus, a constant reliability, like that of a
power supply, is expected from a network.
Structures of networks can be divided to
two styles; bus style and star style. Ethernet is
an example of the bus style, and Asyn-
chronous Transfer Mode (ATM) is an exam-
ple of the star style. In concept, a bus style
network has several computers connected on
one network line, and one line is used by all.
The design and facility of the system are
simple, but the single line could become the
bottleneck to cause congestion, causing prob-
lems in speed of communications. At the
same time, as distractions on the single line
would affect all the computers, its reliability
is not very high. On the other hand, a star
style network is connected one-to-one. Al-
though the system costs more, distraction on
one line does not affect the function of other
lines. So, it can be said that the reliability of
star style networks is higher than that of bus
style networks. Recently, ATM switches are
becoming less expensive and more common.
To build a highly reliable HIS, ATM net-
work seems the better solution.
In an ATM network, computers are usu-
ally connected in a stratum through Hugs
instead of being connected to the ATM
switch one by one [3]. In other words, about
ten computers are connected to one HUB,
and each HUB is connected to the ATM
switch by a one-to-one network. Thus, if
there is a failure in a line higher than a HUB,
all the computers below that particular HUB
would be affected. To keep the damage to a
minimum, client computers that are physi-
cally close to one another (ones in the same
nurse station, for example) should be divided
into at least two groups and each group
should be connected to different HUBs. That
93
way, even if one line gets disconnected, not
all the computers in the same section would
be affected. That would leave some problems
in speed and convenience matters, but the
availability would be secured. In addition,
HUBs will be connected to two ATM
switches. During normal operations, one of
them would be in use and the other would
stay as a back-up. As for server computers,
they will be connected directly to ATM
switches as they handle more information
than client computers. They will also be con-
nected to two ATM switches, but both
switches will be used at all times to ease the
tension on the network. If one of the lines
gets disconnected, the software service will
not be affected, although its speed would
become slower. When there are two or more
ATM switches, the switches need to be con-
nected in the same manner. One ATM switch
should be connected to another through at
least two lines.
If there are more than three ATM
switches, each switch needs to be connected
to at least the other two switches. By setting
up an effective routing table, all the con-
nected lines would share the workload to
increase its communication speed. Also, in
this connection, even when an ATM switch
stops functioning, computers on its line will
still be able to function. Although more com-
plicated than unitary double connections,
these stratus double connections take less
trouble and cost to be set up in addition to
advantages of availability. Fig. 1 shows the
connections of the suggested network.
4.2. Client computers
Large HISs involve hundreds of client
computers. It is almost impossible to keep
them all running without any problems. It is
more reasonable to have a goal to always
have a certain number of the computers func-
94 N. Sakamoto / International Journal of Medical Informatics 49 (1998) 89–96
tioning normally than trying to increase the
availability of each and every computer.
Since hospital operations function in several
sections, it is important that all terminals in
one section do not fail at the same time.
Thus, it is necessary to provide client com-
puters with power and network in at least
two ways. Client–server systems are divided
into thin clients and fat clients by roles of
clients or quantities of functions. Thin clients
have little function on the client side, and
most transactions are done by the server side.
Client computers will receive inputs from
users and send them to the server, then out-
put the result according to the screen instruc-
tions by the server. An extreme example of a
thin client is a terminal of a host computer,
but thin clients usually do transactions or
Fig. 1. An ATM network design for a HIS with high
availability of software services.
user interface. On the other hand, in fat
clients, most parts of the application logic are
done by the client computers.
We will look at an entry of a prescription
order as an example. In thin clients, a user
will input a name or a part of a name of a
medicine. The data is sent to its server com-
puter and information on the requested
medicine will be searched. The result of the
search will then be sent back to the client
computer, and the client computer will dis-
play it. The user will choose necessary
medicines, and repeat this procedure to fill
out the prescription. In fat clients, informa-
tion on medicines is kept by the client com-
puter, and the search and display of
requested medicines by its users are all done
by the client computer. When using fat
clients, the development of application soft-
ware is more concerned with the client com-
puters than when using thin clients.
Development of application software for
client computers is usually easier and has
more development tools than for server com-
puters. Also, in the earlier example, several
communications were necessary in a thin
client to make and enter one prescription
while only one communication was required
when using a fat client. Since it means a fat
client relies less on server computers and a
network system, it is less affected by func-
tioning status of server computers and the
network system. Thus, when availability of
software services is considered, fat clients are
better. In fat clients, the more complex the
development of application software, the
more data are needed to be kept by the
clients. Master files on different items
(medicine information, test items, etc.) need
to be replicated and kept in clients, but they
would only be up to 100 MB, no burden to
today’s client computers’ hard disc capacities.
Also, updates of master files, which do not
happen very often, are done easily through
 N. Sakamoto / International Journal of Medical Informatics 49 (1998) 89–96
the network. Although client applications are
usually done in reference to local master files,
availability of software services can be in-
creased even more by making it possible to
search from servers in case master files get
destroyed.
4.3. Ser6er computers
In HISs, server computers mainly function
as database servers. Server computers are
usually grouped by medical operations or
types of orders for the performance of up-
dates and searches of a database, and sim-
plicity of the back up operations. As hard
discs are most prone to physical damage in a
database server, RAID should be used at
least in server computers. Many database
management systems (DBMSs) can use both
raw disks and OS file systems as repositories.
Although raw disks used to be faster than OS
file systems, their speeds are almost the same
now that OS file systems’ page cache technol-
ogy has improved. If an OS file system is
used, the reliability would increase as it is
possible to use the OS functions including
back up functions.
There are at least two reasons for which
database servers might stop. One is damage
in hardware of server computers, including
hard discs, and the other is break down of
the software of DBMSs. In both cases, as
long as there is a back up computer which
can take over the operations, there will be no
problem [4]. However, it will be very expen-
sive to double-protect all the servers and their
hard discs, and replicating data would also be
time consuming in large HISs. Thus, double-
protection would not be a very reasonable
idea considering the burden on computers
and networks. We recommend making a
repository of the database or data file avail-
able from several database servers by using
OS functions such as Network File Sharing
95
(NFS). This way, even when a DBMS of one
database server stops, that database can still
be accessed through another database server.
The set up of DBMSs and application pro-
grams would need some additional functions,
but availability of software services would
greatly increase. Also, even when it is impos-
sible to double-protect all servers, some data-
bases like patient census and demographic
profiles, latest prescriptions and test results
need to be double-protected. Usually, patient
census and demographic profiles use less than
200 bytes per patient, which is up to only 100
MB for 500000 patients. Also, prescription
and test results data for the latest 3 months
would be around 100 MB, no problem to be
double-protected. By taking these precau-
tions, minimum patients information can be
accessed even when some server computers
stop.
4.4. Application software
Application software in HISs have more
change requests than that in other business
systems. That is not only because of daily
progress of medical technologies, but also
because of existence of many different sec-
tions relating to hospital operations or fre-
quent revisions of medical insurance systems.
Software in HISs need to be flexible to those
change requests, but developing new software
or revising them cannot avoid bugs. When
these bugs are fatal, they can greatly affect
availability of software services. Thus, it is
essential to test software. Even when a new
software passes the test, the old one should
be kept in case there is a failure in the new
one. The old software would not have the
new functions, but at least the service would
not have to stop totally. When applications
of server computers are upgraded, applica-
tions of client computers need to be able to
correspond to the new and the old versions,
96 N. Sakamoto / International Journal of Medical Informatics 49 (1998) 89–96
or the other way around. Such management
of different versions will secure availability of
software services.
5. Conclusion
The change from centre-focused systems to
client – server systems is progressing. How-
ever, client-server systems do not yet have the
reliability that the host computers have. Con-
sidering the increase of reliability of client–
server systems as the job of information
engineering, our paper has suggested realistic
methods to increase availability of software
services in hospital operations.
References
[1] P. Degoulet, C. Safran, G.H. Bowers, Design and
processing issues for the health care professional
workstation: summary and recommendations, Int.
J. Bio-Med. Comput. 34 (1994) 241 – 247.
[2] P. Degoulet, F.C. Jean, C. Safran, The health care
professional multimedia workstation: development
and integration issues, Int. J. BioMed. Comput. 39
(1995) 119 – 125.
[3] T.C. Banwell, et al., Physical design issues for very
large ATM switching systems, IEEE JSAC. 9 (8)
(1991) 1227 – 1229.
[4] J.P. O’Connor, in: J. Biskup, M. Morgenstern and
C.E. Landwehr (Eds.), Trusted RUBIX: A Multi-
level Secure Client-Server DBMS, Database Secu-
rity, VIII (A-60), Elsevier, North-Holland, 1994,
IFIP.